Devlivery cadence and capacity, a team's delivery does not grow linearly with size

A significant part of my job in the past has been to plan for the growth of an engineering organization. There are a number of things to consider when doing this:

Why do you need the growth?

Really though, specifically what value do you intend to create with the growth? This first concern should be clear, but being comprehensive pays dividends later.

Why are you growing?

What business value do you intend to deliver with that growth? If you work at a large enough company, either you or your manager will build a business case for it, even if it isn’t formal.

This is mainly because organisational growth is front loaded operational cost. You are making a bet: the cost is your increasing burn rate, the payoff is the business value you enable, and the plan (the answer to the why question) is the means by which you investigate the wager and then decide if indeed you do want to grow now and by how much.

We’ve seen the consequences of either poor or risky versions of this wager in the news recently, through layoffs - this is a whole topic onto itself though.

So back to it: why are you growing? Get very comfortable with the answer to this question, wether you, your manager or general manager owns the decision. Ultimately you are responsible for turning delivery need into delivery capacity. You should clearly understand what you intend to be able to deliver incremental to what you currently can deliver.

With that in mind…

What are the bounds of growth your engineering org can cope with?

Regardless of the delivery capacity you need to build that new value, your organisation has a bound on the growth it can sustain while remaining productive and taking on serious risk.

What is the fastest the organisation could grow and what is the slowest it could sustain - considering attrition and delivery expectations?

The first step: consider the speed at which you can grow. This will vary depending on the size of your team, but is a function of the number of people you can effectively onboard in parallel. You’ll usually want to consider:

  • The speed at which a high quality hiring pipeline can put bums in seats
  • Impact on your existing engineers and the teams they work in (given the investment you currently have in onboarding):
    • engineers need to interview, and quite often your best engineers provide your most trusted signal. This implies there is a trade off between the speed of the hiring pipeline and the impact those engineers can have in their teams
    • teams will need to onboard new joiners, doing this is a valuable investment but like any investment, there is a cost (mostly in terms of time) associated. There is a limit to the number of engineers a team can onboard in parallel
  • Bottlenecks in cross functional teams. What are your ideal engineer to Product Manager, Engineering Manager, Data Science or Designer ratios? (Other disciplines may be more important for your case). Do those hiring pipelines operate at the same speed? If not, plan a little ahead, talk to your Product and Data peers!

Your engineering organisation can only grow as fast the number of high quality engineers it can attract, onboard and the cost (including short term impact loss) it’s prepared to pay.

The next step: consider what the expectations on delivery cadence over time are? That is, what do you need to deliver when, including right now.

This concern is nuanced and important to communicate to stakeholders - especially non technical stakeholders. Two key concepts are important to manage and communicate:

  • A performing product engineering organisation should be delivering new, hopefully innovative, product into the market. As new product initiatives become succesful (as they find product market fit), they naturally generate operational burden. This burden is not just the maintenance and reliability required to run those products, but a consistent programme of optimization that hones the product offer and it’s operation into a well oiled machine.

  • As an engineering organisation grows, it slows down (your job is to limit that decline in speed!). Lots has been written about this, but I find the graph analogy the easiest. As a complete graph grows in the number of nodes, the number of edges grows quadratically. Even when well managed (not a complete graph and far from quadratic growth), information still has to make more hops.

Delivery capacity is a sublinear function to new people

The consequence is that delivery capacity is sublinear to new people - that is each new person that joins your team will on average add a smaller increment of productivity to the team than the last. This is true at the smallest scale, a team of 3 tend to get more done per person than a team of 6; and at the largest scale, an org of tens of teams tends to deliver less per team then an org of 3 teams.

This axiom becomes more pronounces as your organisation becomes larger, and importantly it is true on average. Amazing hires are worth their weigth in gold and directly contradict this axiom, and some hires simply don’t work out.

This axiom essentially means the function of org size (X) to productivty per person (Y) wants to be concave, and a large part the engineering leadership role and indeed your energy is to fight against that concaving pressure. You do this in mirriad ways, by keeping your hiring bar high, by providing autonomy to your teams (less unnesesary hops), and much more.

So what next?

You still have new experiences, features and products you’d like to deliver and have the means to grow your team. What next?

Hopefully understanding 1. the value you intend to deliver, 2. the speed with which your org can grow and 3. the relationship between the growth and delivery capacity, will dissuade org planning of the form X new people (enigneers, data scientists, product managers) to build Y thing in your roadmap. This form is an easier sell to a leadership team, because of the ilusion of neatness, but rarely actually works.

Rather, I would encourage you plan for (and communicate about) delivery capacity. That is, plan for both the increasing operational burden (from products that are succeeding in the market) and for the ability to build new product.

This distinction isn’t just useful for managing up - it’s helpful in keeping you the planner of a team or an org, intellectually honest. It forces you to ask the question: am I willing to pay in inneficiency to have some more delivery capacity? If so, to deliver what, when? Do I want the cost of more overhead for the potential of more people? This question should dissuade you from the very bad habit of taking any headcount you can have.