When Hiring Stops: How Managers Can Prevent Team Burnout

In this blog, I will provide options to ensure, the existing team doesn’t burn out when hiring stops.

When I was new to management, there was an announcement in the company that all hiring would be paused for a few months until the budgets were finalized.

At this time, my team needed new team members to handle the upcoming work.

When senior management announced the decision, I fought hard for exceptions, but every effort was met with silence and ultimately led nowhere.

I had no idea how to handle the situation.

When the team members were informed about this, they were worried about overworking and concerns related to work-life balance.

It got me thinking about the options to handle the situation.

The Options

Following are the 3-options that I wanted to try.

Option#1: Stop work on a few items
One of the first things that came to my mind was to stop working on a few items.

I wanted to check for work items that were mostly internal but not for customers.

This way the load on the team could be reduced.

Option#2: Internal hiring
If the external hiring is stopped, can I do internal hiring?

All teams in the organization had hiring stopped, so I attempted to find a team with extra resources.

This was hard because no manager wanted to leave their team members in this situation.

Option#3: Reprioritization
The worst-case scenario is to deprioritise some of the customer-facing features.

I anticipated a tough conversation with the Product Managers, knowing they’d be under pressure, to deliver the features on time.

But this will guarantee a lower load on the team.

The Result

Option#1 and option#3 helped to ease the load on the existing team members.

I identified the internal work items. The internal process automation initiatives were taken out and delayed until new members were hired.

This increased some of the manual work and more stringent reviews. But it reduced the load.

The reprioritization discussion with the Product Manager was challenging. Using the MoSCoW prioritization framework features that were “could have” and “will not have” were identified.

This helped delay items for future releases.

Overall the load on the team was in control. But it was maxed out.