Context

At the time of writing, I’m about 4 months into the journey as an Engineering Manager. A question that I’ve been trying to find ways to answering is, “What are the skill and capacity need of my team today and what are they likely to be tomorrow?”

After ~a quarter of a year in this role, I’ve managed to skate by by constraining the definition of “tomorrow” to “next quarter”. But what I think will really set a team up for long term success is to shift that definition of “tomorrow” from just one or quarters ahead to one or two years ahead.

My goal here is to outline the processes of developing a Team Growth Strategy.

Restate your vision

What is the purpose of your team? This is the “meta why” - what you are asking for are more resources; why you are asking is to be able to build more awesome things more quickly; why you want to build those awesome things is to fulfill the vision of your team. This is useful context to set for your audience (and yourself) as you go about these conversations.

Define the roadmap

Does it make sense to ask for more resources if you don’t know what you’d do with them? Having a well defined roadmap of initiatives is a prerequisite for being able to thoroughly think through staffing needs.

A “well defined” road map, for this purpose, is one in which

Initiatives have been identified
Impact sizing of these initiatives has been done

Put together high level estimates

Use past data about similar work, if available, to come up with course gained estimates for each initiative. These don't need to be scientific. No need to drill down to the level of project milestones.

The cumulative output of roadmap + estimates is be useful context to share with stakeholders.

Outline the scenarios

I started out with the framing,

What can we get done next year with our current team size?
What could we do if we doubled in size?
What could we do if we tripled in size?

Those questions are useful to ask. Ultimately, though, the thing you’ll need to communicate to stakeholders are answers, which should be concise narratives.

Example narrative

We've identified X workstreams. We've worked on Y of them, but have only been able to do so in sequence. We need more headcount to be able to consistently work in parallel. At our current size, we anticipate being able to move metric M by P0% in one year.

If we get H1 headcount, we anticipate being able to increase metric M by P1% in one year.
If we get H2 headcount, we anticipate being able to increase metric M by P2% in one year.

A side note on “size”

At this level of abstraction, it is easier to focus on the number of roles and maybe the levels for each rather than the specific individuals who will occupy each role. People aren’t fungible, but specific individuals are not the focus of this exercise.

Itemize all of the roles, not just engineers

An engineering manager may not be the person best - or at least not solely the best - positioned to identify future needs in functions besides engineering such as design, product, data science, etc. Talk to all discipline leads in order to:

Identify the bottle necks (present or projected)
Get a sense of their needs that you may not have identified as yet

Include their needs in the final strategy proposals.

Rough estimate of timing needs

When do you think you’ll need to fill specific roles?

Perhaps you don’t think you’ll need to hire another <insert function> until your hit a certain team size or number of parallel projects. Include that information as well.

Credits

I want to mention that I “invented” very little, if any of this. This process has been derived from listening to (and being held accountable by) more experienced leaders. I figured that these thoughts were worth writing down because even though I’ve read several books on management, I hadn’t encountered - or at least retained - concrete ways to strategize about growing a team.

On defining team growth strategy: An approach to building business cases for capacity