The argument arrives in every board meeting now, and it sounds like arithmetic. AI-native competitors are doing more with less. The tools have made each engineer several times more productive. The team was sized for a world where code was expensive to write, and it is not that world any more. Therefore the team should be smaller. Large companies have said the quiet part loudly, with reports of targets to shrink engineering by more than half on the strength of the new tools, and founders of much smaller companies hear that and feel the pressure to follow. The arithmetic is not wrong about the cost of writing code. It is wrong about what the engineers were for.
Fear is a poor basis for organisational design, and the fear here is specific: that a leaner competitor will ship faster and win. That may be true. But a cut made to match a competitor’s headcount rather than to fit the company’s own system is a cut made without looking at what the people actually do, and what engineers actually do, in any company with a system old enough to have customers, is mostly not writing code. It is knowing how the thing works.
What leaves the building
When an engineer leaves, the tickets they were going to close are the least of what goes. What goes is their mental model of the system: which service talks to which, why that queue is configured the way it is, what the odd branch in the payment handler protects against, which of the three ways to do a thing is the one that does not break in production. None of this is written down, or not completely, or not in a form that is current. It lives in the person, and it was built over years of touching the system and watching it fail.
The tools that make code cheap to produce do nothing for this. An agent can write a new handler in seconds. It cannot tell you that the handler will interact badly with a retry policy set three years ago by someone who left, because that knowledge was never in the code, only in the head of the person who set it. A company that cuts the people and keeps the tools has kept the ability to add to the system and lost the ability to understand it, and a system that grows faster than anyone understands it is not more productive. It is more fragile, at a rate that compounds.
There is an older lesson in distributed systems that applies here without modification. The hardest failures are never in any single component; they are in the interactions between components, in the assumptions each one makes about the others, and those assumptions are documented nowhere because they were never decided, only accumulated. The people who have watched the system fail enough times to know its interactions are the company’s only record of them. Remove those people and the interactions do not go away. They just become surprises.
Incidents are where you find out
The loss becomes visible in exactly one place, which is the incident channel at the worst hour of the worst day. Something breaks in a way the tests did not anticipate. The on-call engineer, who is competent and diligent and joined after the cut, cannot tell whether the failing component is supposed to behave that way. The person who could have told them in thirty seconds is gone. What follows is hours of archaeology, reading code that nobody now fully understands, guessing at intentions, making changes whose side effects nobody can predict, while customers wait. The productivity gain from the cut is real and was banked months ago. The cost arrives all at once, in the form of an outage that a system with its memory intact would have ended in minutes.
A company that cuts the people and keeps the tools has kept the ability to add to the system and lost the ability to understand it.
This is the sense in which the cut is not a saving but a deferral. The money not spent on salaries becomes the money spent on the outage, plus the customers who left because of it, plus the slower velocity afterwards because everyone is now afraid of the system. The invoice does not say headcount reduction on it, so it is never connected back to the decision, and the same decision gets made again at the next board meeting with the same arithmetic.
A test before you cut
There is a simple test for whether a proposed cut is a productivity gain or a deferred outage, and it can be run in an afternoon. For each person on the list, ask two questions. What do they know about how the system works that is not written down anywhere. And who else could answer a production question about their area at two in the morning. If the answer to the first is a lot and the answer to the second is nobody, the cut is not removing a cost. It is removing the system’s memory of itself, and the memory will be needed on a schedule the company does not control.
Run the test honestly and it also reveals where the documentation debt is worst, which is useful whether or not the cut proceeds. Every name for which the second answer is nobody marks an area of the system that the company does not, as an organisation, understand. That is a risk today, with the person still in the building, and it is worth fixing on its own terms.
The test tends to sort people in a way that surprises founders. The engineer who closes the most tickets is often not the one whose departure would hurt most. The one whose departure would hurt most is often quiet, has been there a long time, and spends a suspicious amount of time answering other people’s questions rather than shipping features. That person’s productivity looks poor by the metrics that justified the cut and is, in practice, the thing holding the system together.
What to protect
If the cut has to happen, and sometimes it does, the thing to protect is not seniority or output but comprehension: the small number of people who can still reason about the whole system, or about a whole critical part of it. Keep them, even if their ticket count is low. Then spend the months after the cut using them to write down what they know, in a form the remaining team and the tools can use, because the alternative is to remain one departure away from an outage nobody can fix.
The deeper move is to refuse the framing that started the conversation. The question is not whether the company can do more with fewer people. It almost certainly can. The question is whether the system still makes sense to the people left to run it, and no productivity multiplier answers that. Cheap code makes it easier to build a system nobody understands. It does not make understanding it cheaper. Check the second thing before acting on the first, and the cut you make will be the one you can afford.