The most expensive person on a software team is not always the person with the highest salary.
Sometimes it is the person everyone else has to route around.
A Chinese X thread in late April summarized a management anecdote attributed to Pavel Durov: a software project is slipping, two Android engineers are on it, and the obvious move is to hire a third. But one of the two is creating more drag than progress. Remove that person, the story goes, and the team catches up without the extra hire.
The anecdote is too tidy to treat as proof. As management logic, though, it points at a real inversion.
Call it Durov's inverse: in some teams, removing one net-negative contributor creates more velocity than adding one average contributor.
Fred Brooks gave us the older version in 1975. Brooks's law says that "adding manpower to a late software project makes it later." His explanation was not mystical. New people need ramp-up time. Existing people have to explain context. Communication overhead grows as the team grows. In software, headcount is never pure capacity. It is also coordination cost.
AI makes this harsher.
A strong engineer with good judgment now has more output available per hour than before coding agents became normal. They can draft code faster, inspect alternatives faster, write tests faster, and move through boring work with less friction. That sounds like an argument for bigger teams. Usually, it is an argument for smaller, sharper ones.
When strong people get amplified, weak coordination gets expensive.
The first cost is rework. AI makes code generation cheap. It does not make bug triage, architectural cleanup, or post hoc reasoning cheap. A teammate who sprays plausible but low-reliability output into the repo can create a lot of motion that feels like progress until someone senior has to trace it, rewrite it, or contain the damage. In that environment, "more output" is a bad metric. The scarce resource is clean output that does not need rescue.
The second cost is attention. Net-negative contributors consume the focus of the best people around them. They ask questions they should have resolved themselves. They reopen settled decisions. They need constant translation between the real problem and the version they think they are solving. They add meetings because nobody trusts the handoff. They add review cycles because nobody trusts the first pass. What disappears is uninterrupted concentration, which is the highest-yield resource on a software team.
The third cost is ambition. This one is less measurable, so managers miss it. Put one chronically sloppy, defensive, or disengaged person in a high-agency team and the group starts designing around the weakest node. People stop proposing bolder moves because they do not want to spend two extra days dragging someone through the consequences. Standards get softened. Problems get decomposed around fragility instead of speed. The team does not only move slower. It starts aiming lower.
This is why the wrong person can do more damage in an AI-native workflow than in an older one. When the best people on the team can each operate with agentic tooling, the gap between high-judgment and low-judgment work widens. The bottleneck moves away from raw production and toward selection, correction, and integration. If machines make it easier to generate work, the value of humans shifts toward deciding what should survive.
A weak contributor now collides with the most important part of the pipeline.
Do not turn this into macho startup advice. The true drag does not stem from junior engineers, slow onboarding, or different working styles. A junior engineer who learns fast, owns mistakes, and reduces future load is an asset. A careful generalist who takes small tasks off a staff engineer's plate is an asset. A teammate who needs onboarding today but compounds tomorrow is an asset.
The problem is the person who persistently converts everyone else's focus into overhead.
That person can be senior. That person can be charismatic. That person can look busy. The signal is not whether they produce artifacts. The signal is whether their presence reduces or increases the amount of correction the system needs after they touch it.
Most companies are bad at seeing this because they still think in seat count. Headcount feels additive on a spreadsheet. Hiring looks like action. Removing a drag looks like conflict. So the default move is to preserve harmony and buy another seat. That is often the most expensive version of avoidance. If the existing system has a negative node inside it, adding fresh capacity around the node spreads the drag across a larger surface area.
The practical management question is not "Do we need more people?" It is "What is actually making this team slow?"
If the answer is missing capability on a clear, separable workstream, hire. If the answer is a fantasy schedule, reset the schedule. If the answer is low divisibility, weak focus, or a person whose output creates more downstream work than upstream progress, headcount will not fix it. Fix the system first.
A useful diagnostic is simple: look at your strongest people and ask where their week goes.
If they are blocked on raw task volume, more hands may help. If they are blocked on code review rescue, repeated hand-holding, decision churn, or social damage control, another hire may make the problem worse. The leverage move is subtraction, reassignment, or narrower role design before expansion.
The old software-management line is that nine women cannot make a baby in one month. The AI-era version is sharper: you can now generate a month of mediocre code in an afternoon. That only increases the value of people who can tell what is worth keeping.
In modern product teams, capacity is not the number of people who can touch the work. Capacity is the number of people who improve the system without forcing everyone else to absorb them.
Once you see it that way, the obvious fix changes.
The third engineer is not always the answer. Sometimes the fastest path back to velocity is removing the reason the first two engineers were slow.