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.

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.

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

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.

I started out with the framing,

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

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.

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.

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:

Include their needs in the final strategy proposals.

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.

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.