The Name That Arrives First

The name that arrives first is nearly always the same one, and it arrives first because it is right. The person who can do this fastest has done something like it before. Their estimate is lower and honest: they will not read the module from the top, they know which of the two configuration paths is live, and they will not lose a day to the thing everyone loses a day to. None of that is a bias I could train out of myself, because it is not a bias.

So the work goes there. And because it went there, the distance between that person and everybody else on that subsystem is a little wider than it was this morning, which makes their estimate for the next one a little lower, which makes the decision a little easier next time. Forty repetitions later there is one engineer who understands billing, and a manager who is genuinely surprised by that, because at no point did anyone decide it.

What those four seconds are actually pricing is a trade between throughput now and capability later, and only one side of it is visible while you are making it. Throughput now has a number attached: the estimate, the sprint, the date somebody downstream is waiting on. Capability later has no number, no date and nobody asking after it. A trade where one side is quantified and the other is not is not a trade at all. It is a default with a ceremony around it.

Vacation quietly becomes a risk. A week off is fine, everybody says so, and then a deploy waits, or a decision waits, or someone makes a change to that subsystem far more carefully than they otherwise would and it takes three days instead of one. None of that gets recorded as a cost of the vacation, because it does not look like one. The tell is noticing you would rather a particular person did not take leave in a particular month, and that you have never said so out loud.

The on-call rotation is a story you tell. On paper five people carry the pager for a service. In practice three of the five, when paged for the part that actually pages, will wake up a fourth. The rotation is real for everything the team understands in common and decorative for the one component with a name attached to it. This is the version of the problem that gets discovered at two in the morning, by whoever drew the short straw, on the worst possible night to be discovering things.

A team where everyone has touched everything a little is a team where nobody holds a model of anything, and the model is what lets a person read a symptom and name the cause without opening the code. Depth compounds. It compounds only where somebody has been allowed to stay in one place long enough for the compounding to start, and a rotation policy applied evenly to everything is a way of guaranteeing that nobody ever does.

The correction also underprices transfer, badly. Handing a subsystem to a second person is not that person reading some code. It is weeks of questions in both directions, work delivered slower than it would have been, a first change that is worse than it should be and gets reworked, and a review cycle from the very person you were trying to unburden. That cost is real, it arrives immediately, and it arrives in the same quarter you are being asked about.

So the position I actually hold is an uncomfortable one and I would prefer it were tidier. Some concentration is correct and the goal is not to remove it. The goal is to be able to tell the concentration that is buying you depth from the concentration that is buying you a hostage situation, and to be able to tell them apart while there is still time to do something other than worry.

Durable knowledge is the why. Why the system is shaped like this rather than the obvious way. Which invariants are load-bearing, and what fails silently three services away when one of them is violated. What was tried, abandoned, and whether the reason for abandoning it still holds. Where the sharp edges are and which of them are deliberate. Almost none of that is in the code, most of it is in no ticket anywhere, and all of it will still be true in three years.

Perishable knowledge is the current mess. The quirks of the migration in flight. Which of two configuration systems is authoritative this month. The workaround for the bug that gets fixed next release. The order the services have to come up in until somebody repairs the startup script. It is genuinely useful, it is genuinely held by one person, and in six months every line of it will be wrong in a way that makes writing it down worse than not having written it down.

Only one of the two is worth distributing. Durable knowledge in a single head is a real exposure and worth spending a quarter to fix. Perishable knowledge in a single head is fine, and spreading it burns two people's time on facts with an expiry date on them. Most tribal-knowledge panic never makes this distinction, which is how it reliably produces a documentation initiative that generates pages nobody reads about things that stopped being true before the pages were finished.

The cheap signal is already in version control. For each subsystem you care about, ask who has changed it in the last year. If the answer is one name, that is not a feeling about the team, it is a measurement, and its virtue is that it requires nobody to admit anything or fill anything in. It needs no tool either: the question is answerable in an afternoon for a dozen components, and the list it produces is shorter and more obvious than people expect.

There is real research behind the idea and it is worth citing carefully. Avelino, Passos, Hora and Valente published an automated approach to estimating truck factors in 2016, applied it to 133 popular GitHub projects, and found roughly 65 percent of them had a truck factor of two or fewer - which is to say that for most well-known open-source software, two departures would stall it.

Read the design before carrying that number anywhere. It infers knowledge from file authorship in git history, on open-source projects whose contribution patterns are not a company's, and the authors checked it against developer surveys on a subset of systems, where the agreement was partial rather than clean.

The sharper caution comes from later work. Jabrayilzade, Evtikhiev, Tuzun and Kovalenko surveyed 269 engineers and built a multimodal bus-factor estimate that added code review and meeting participation to version control, tested across 13 projects at a single company, and it identified the critical people better than version-control-only tools did.

Thirteen projects at one firm is a narrow base, so I take that as a caution rather than a finding, and a caution is the right way to use the cheap signal anyway. It is a screening test, not a verdict. It hands you the list of subsystems worth asking a question about, and then you go and ask the question, because the interesting case is the one where a second name shows up in the history and cannot actually explain why the retry logic is where it is. Participation is visible in git. Understanding is not, and a rubber-stamp review looks exactly like a real one from the outside.

Give it to the second-fastest person and have the fastest review it. This is the highest-leverage move available to a manager and I will argue for it harder than anything else here. It costs one review cycle and some patience. The work still lands at the standard of the person who knows, because they are on the change. The person who did not know now has a model instead of a description. And the review becomes real in both directions, because the expert has to say the invariant out loud rather than simply honoring it, which is often the first time it has been said out loud at all.

Rotation works, but only if it is long enough to be uncomfortable. A rotation measured in sprints produces tourists. For it to build anything, somebody has to be in a subsystem long enough to own an incident in it, ship something that surprised them, and come back to their own change six weeks later and have an opinion about it. That is a quarter, not a sprint. The honest cost is that throughput on that component is worse for the whole quarter, and the only version of this that survives contact with a roadmap is the one where you said that in advance rather than explaining it afterward.

Documentation is cheapest to make and quickest to rot. Aimed at the durable half it is worth writing and worth maintaining: why the shape, which invariants, what was tried and rejected. Aimed at the perishable half it is an obligation that will be quietly wrong within two releases and will then mislead somebody at three in the morning who had no way of knowing it had gone stale. Wrong documentation is worse than none, because none makes people ask a person, and asking a person is the transfer that actually works.

Incidents go to whoever is fastest. Always, without discussion. Nobody's development plan is worth an additional twenty minutes of a customer outage, and a manager who treats a live incident as a growth opportunity is spending somebody else's money to buy it. That is not a compromise of the principle. It is the principle correctly bounded, and a version of this argument that does not concede it is not describing anywhere real.

The failure is the drift outward from there. A great deal of ordinary work feels urgent and is not: a date somebody committed to in a meeting, an escalation that is loud rather than severe, the last two weeks of a quarter. Each one is an individually defensible reason to hand the work to the fastest person, and every one of them is the same reason. The aggregate is a team that has spent two years running everything as an incident and has no second-fastest person available for the next real one.

The fastest person usually wants to keep it. Not out of empire building, and usually not out of insecurity either. Being the person who knows is a large part of how they are valued and how they value themselves, and that is a reasonable thing for it to be. Ownership is identity. So taking a subsystem away is heard as a judgment about competence even when the reasoning has nothing to do with them, and it is heard that way before the reasoning is offered.

So the reasoning has to be said out loud, to them, before it shows up in an assignment. "I am giving this one to somebody else and I want you reviewing it, because you are the only person who can do it and that is a problem I own" is a different conversation from watching a ticket go somewhere unexpected and drawing your own conclusions. The first is a statement about the system. The second is a statement about them, and they will make it one whether or not you meant it.

Unfamiliar code got cheaper to enter. A model that will summarize a module, trace a call path and draft a plausible first change lowers the entry cost of a subsystem somebody has never opened. That is real, and it weakens the strongest practical objection to reassignment, which was never that other engineers are incapable - it was that it would take them too long and the date was real. The mechanical half of unfamiliarity is meaningfully cheaper than it was two years ago.

The durable half did not move at all. Why the invariant exists, which design was tried and thrown away and whether its reason still holds, what breaks silently elsewhere when a rule is relaxed: none of that is recoverable from the code, because it was never in the code. A model reads what is there. The expensive knowledge is a record of what is not there and why it is not, and the person holding it is still the only copy of it in the building.

And there is a survey to read with its design in mind. DORA's 2024 report found teams adopting these tools reporting higher individual productivity and flow while delivery throughput and stability moved the wrong way. It is a self-reported practitioner survey, so it measures association and perception rather than effect, and I would not build a policy on it. It is consistent with what I would have predicted, which is a weak kind of evidence: the cheap half of the work got cheaper, and nothing that governs whether a change is safe moved.

I should not pretend there is a method here. There is no formula, and the honest position is that most of the time you cannot tell depth from a dependency until something forces the question, which is usually a resignation or a hospital. I have been wrong in both directions: I have spread work that should have stayed put and lost most of a quarter to the transfer, and I have left work where it was because a date mattered more, then done the same thing again two months later.

What is available is much smaller and worth having anyway. The decision gets made at the moment somebody says a name in a standup, in four seconds, with nothing written down, and the only intervention I have found that reliably helps is noticing that a decision is being made at all. That is the entire discipline. Not a rotation policy and not a documentation initiative - one extra beat before the name, in which the thing being traded is briefly visible to the person trading it away.