Headcount Stops Solving the Problem at a Shared Constraint

There is a point in most growing companies where the hiring plan keeps being approved and the output stops following it. Teams are larger than last year, the budget for people has grown with revenue, and the things the leadership team watches move at the pace they moved before: releases, launches, closed deals. Nobody is idle. The new people are working. The company as a whole is not producing more.

The usual reading is that the new hires are still ramping, or that the wrong people were hired. Both happen. The more common cause is structural, and it appears in companies that hired well. Every person added to an organisation draws on a few resources that do not grow when headcount does, and past a certain size those resources become the constraint.

What a hire consumes

A new engineer needs a code review, a slot in the release, and a working understanding of a platform that a handful of people built. A new account executive needs deal support, a pricing decision, and time with the two sellers who know how the product is actually bought. A new product manager needs a place on the roadmap, which means a decision from someone who already owns too many. In a small company these resources are abundant relative to demand. In a larger one, each hire queues for them.

This is a different problem from a single team hiring around rework, which we wrote about in when to add headcount and when to fix the process. That is a fault inside one loop. This is a ceiling across the company, and it can arrive in an organisation whose individual processes are sound.

The shared resources that bind fall into three kinds, and naming the one that binds is most of the diagnosis:

• a person, or a small group, whose judgment every piece of work passes through
• a platform, release train or shared system that every team has to change in order to ship
• a standard that lives in people's heads rather than in anything a newcomer can read

When the constraint is a person

The first kind is the most common and the least discussed, because the person is usually senior and the queue forms politely. A founder who still approves pricing exceptions, a head of risk who signs off on every new product feature, a technology lead who reviews every architectural change. Each was the right control at forty people. At two hundred, the same control turns every hire into one more item in a single inbox. Adding people upstream of that inbox lengthens the queue without changing the rate at which it clears.

When the constraint is a platform

Checkout and payment teams show the second kind clearly. A company grows from two product squads to six, and all six need changes to the same payment service before customers see anything new. The service has one release window and one team that understands its failure modes. Each new squad adds demand on that window. The roadmap fills with work that is ready and waiting, and the squads are told to plan better.

When the constraint is a standard

Sales organisations show the third. Early sellers learned the qualification standard by sitting next to the founder. Later cohorts learn it from the early sellers, in whatever time those sellers can spare from their own targets. As the cohorts grow, the standard thins, ramp time stretches, and the best sellers spend more of their week teaching and less of it selling. The company has bought more capacity and paid for it with its best capacity.

The method we use is short, and it starts from the work rather than from the organisation chart. It reads the last quarter of real items, whether releases, deals or launches, and asks the same four questions of each:

• what did this item wait for, and who or what was it waiting on
• how many other items were waiting on the same thing at the same time
• did that queue grow as the teams feeding it grew
• what would have to change for the queue to clear without that person or system

The third question carries the method. A constraint that does not grow with headcount shows up as a queue that does. When the same name or the same system sits at the front of most waits, and the wait got longer as the company hired, headcount growth has stopped solving the problem. A hire does not add capacity to the company. It adds demand on the one thing the company has not been able to grow.

A hire does not add capacity to the company. It adds demand on the one thing the company has not been able to grow.

Output per person is the wrong measure

Revenue per employee and similar ratios are tempting here, and they mislead. They fall during every investment phase for reasons unrelated to constraints, and they say nothing about where the work is stuck. The measure that locates the problem is the wait at the shared resource, read against the size of the teams that feed it.

Once the constraint is named, the reflex is to stop hiring. That only stops the queue from growing. It does not clear it, and it leaves the teams that were promised help without any. The work is to change what the constraint does, so that new people stop needing it for most of what they do.

A remedy for each kind

A person is relieved by moving decisions: writing down the cases they decide the same way every time and handing those to the teams, while the person keeps the exceptions. That is the work of assigning decision rights as a company scales, and it is usually the cheapest change available. A platform is relieved by running it as a product, with its own team, its own roadmap and an interface that lets squads ship without negotiating a release. A standard is relieved by writing it down well enough that a newcomer can learn it without borrowing an expert's afternoon.

Hiring resumes in a different shape

None of this ends hiring. It changes where the next hires go. Often the most valuable hire after the diagnosis is one placed at the constraint itself: a second person with pricing authority, a platform engineer, an enablement lead who carries the standard. One hire at the constraint does more than several hires feeding it. The rest of the plan can then go ahead, because the people it adds no longer queue behind the same door. Keeping that true as the company keeps growing is a question of operating cadence between $10M and $100M, where the forums that move decisions have to grow with the company.

The diagnostic is a few weeks of reading real work and naming the shared resources it waits on. We run it as part of our consulting work under growth discipline, ideally before the annual headcount plan is approved, while the cost of a wrong answer is still only a spreadsheet.

The result is usually a smaller hiring plan and a larger change to who decides what. Where the constraint is a standard held by a few senior people, the work continues as training that writes the standard down and teaches it, so the next cohort ramps on the standard rather than on whoever had a free afternoon.