Team shapes when throughput stops tracking headcount
Almost every planning assumption in a modern engineering organisation rests on output being roughly proportional to people. Break that link and team design, capacity planning and the org chart all need different logic.
There is a number that runs most engineering organisations, and it is rarely written down. It is the implicit conversion rate between headcount and output. Everyone has one. It is why a director asks for four engineers rather than three, why a roadmap gets cut when a team loses two people, and why “how many engineers would that take” is a question everybody understands.
The conversion rate was never precise. It was famously non-linear, it varied by team and domain, and adding people to a late project made it worse. But it was monotonic and roughly stable, and that was enough to plan on. Two teams of six produced more than one team of six. A team that lost half its people produced substantially less.
When agents produce a meaningful share of changes, that relationship weakens considerably, and a surprising amount of organisational design turns out to have been resting on it.
What the link actually was
It is worth being precise about what breaks, because the naive version of this claim is wrong.
Headcount was never really a proxy for output. It was a proxy for four distinct capacities that happened to travel together in a human being: the capacity to produce changes, to decide what should change, to absorb changes through review and operation, and to hold context about a system over time.
One person supplied all four. Hire one more and you got more of each, in fixed proportion. That fixed proportion is the thing that made headcount a usable planning unit.
Agents supply one of the four in effectively unlimited quantity and none of the other three at all.
Production
Turning a decided intent into a candidate change. Now abundant and cheap. No longer a reason to hire.
Decision
Deciding what should change and what done means. Unchanged, human, and now the binding constraint.
Absorption
Review, risk sign-off, operating the result. Unchanged and under far more load than before.
Context
Holding a model of the system over years. Unchanged, slow to build, and impossible to buy quickly.
Once you see it this way the practical questions get clearer. Adding an engineer to a team that is constrained by decision capacity does very little, and always did; it is just now more obvious because you cannot hide behind the extra production. Adding an engineer to a team constrained by absorption helps only if that person can actually absorb, which for the first six months they cannot, because absorption depends on context.
The team size argument gets rewritten
The classic case for small teams was communication overhead. Connections grow quadratically, coordination cost eats the gains, so keep teams under about eight and give them a clean interface to the rest of the world. That argument is intact and I have no quarrel with it.
The classic case for teams being at least a certain size was different and less discussed: you needed enough hands to get the work done, enough coverage to survive holidays and illness, and enough people that the on-call rotation was not cruel. That case is the one that weakens.
The result is that the lower bound on team size drops while the upper bound stays where it was. Teams get smaller, and the smallest viable team becomes uncomfortably small.
I want to flag the failure mode immediately, because it is the one I would bet on. A team of three with agents can produce the change volume of a team of eight. It cannot absorb the operational load of a team of eight, and it certainly cannot carry a humane on-call rotation. Organisations will notice the first fact, act on it, and discover the second one during an outage at two in the morning eight months later. Production capacity and operational capacity are different things and only one of them scales with tooling.
Capacity planning without a conversion rate
If headcount no longer converts to output, what do you plan with?
The honest answer is that you plan against the constraint, and you have to know what it is. This is less convenient than a conversion rate and considerably more accurate than one ever was.
In practice the constraint is somewhere unglamorous. Test environments that cannot run in parallel. A staging database with one copy. A security review with a five-day queue. One staff engineer who owns anything touching billing. None of these are solved by hiring, and all of them are cheaper to fix than a headcount increase, which is the good news buried in an otherwise disorienting shift.
The bad news is that this requires an organisation to be able to say where its constraint is, and most cannot, because the reporting was built to answer “are we on track” rather than “where is work waiting.”
The context problem gets worse, not better
Of the four capacities, context is the one I would worry about most, and it is the one least discussed.
Context is knowing why the system is like this. It is built slowly, mostly through doing the work and being present for the incidents. It has always been expensive to acquire and impossible to transfer quickly. And it degrades: a system being modified faster than anyone reads it will outrun the mental models of the people responsible for it.
Two forces make this worse simultaneously. Volume goes up, so there is more to know. And the traditional mechanism for building context, namely writing and reviewing the code yourself, is exactly the activity being reduced.
I do not think this is fatal but I do think it is the largest unpriced risk in the whole transition. The teams that handle it seem to do a few consistent things: they keep decision records rather than relying on memory, they rotate people through areas deliberately rather than letting silos form by accident, they treat the incident review as a teaching artefact rather than a compliance one, and they resist the temptation to let a single person become the only one who understands the newest subsystem, which is a temptation that grows when that subsystem was built in a week.
What the org chart looks like
I am wary of drawing a target organisation, because the honest position is that nobody has run this experiment for long enough to know. A few directional statements seem safe.
Fewer, more senior people per team, with the junior pipeline being a genuine and unsolved problem. The traditional apprenticeship was doing the simple work under supervision, and the simple work is what automated first. Nobody has a good answer to this yet, and the organisations claiming they do are usually just not hiring juniors.
More people whose job is the system rather than the features: the platform, the verification pipeline, the criteria standards, the observability. This work was always undervalued relative to feature delivery and the ratio has now shifted enough that underinvesting is visibly expensive.
Flatter, because a layer of management whose primary function was collecting and relaying status has lost its primary function. What survives in that layer is the part that was always harder: developing people, and making the calls that the data does not make for you.
Where this breaks down
Regulated and safety-critical domains do not get to be small. Segregation of duties requires that the person who writes a change is not the person who approves it, and separate people to operate it. That is a floor on team size that no amount of tooling removes, and it is a legal floor rather than an engineering one.
Domain coverage is not the same as capacity. A three-person team may produce enough, and still fail because none of the three knows the tax rules, the hardware, or the regulator. Headcount was also buying domain breadth, and that is a fifth capacity I left out of the model above because it varies so much by industry.
Small teams are fragile in ways spreadsheets do not show. One resignation from a team of three is a third of the context, and possibly all of the context for one subsystem. The efficiency case for small teams is real and the resilience case against them is also real, and I do not think the trade is as favourable as the productivity numbers suggest.
The whole argument assumes high agent leverage, which is domain-dependent. In a codebase with poor test coverage, unusual internal frameworks, or heavy regulatory constraint, the production multiplier is much smaller. Redesigning an organisation around a multiplier you have not actually measured is how you end up understaffed and confused about why.
The takeaway
Headcount was never really the input. It was a bundle of four capacities that happened to arrive together, and agents unbundle exactly one of them. Production got cheap. Decision, absorption and context did not move at all, and they are what your organisation is actually made of.
Plan against the constraint rather than a conversion rate. Expect the constraint to be a test environment or a single approver rather than a shortage of engineers. Watch context debt specifically, because it is the failure that stays invisible until an incident.
If you take one thing into next week: ask where work is waiting in your team, and check whether anyone would be able to answer that question with evidence rather than opinion.
The next piece follows the thread into hiring, which is the process most obviously calibrated to a set of skills that were valuable for reasons that have partly stopped applying.