There used to be a developer at a previous company who understood the deployment pipeline.

I know this sounds like an understatement, but it is not really about what the pipeline did or how many steps were in it or which tools were involved. There was one person who knew why a certain build step had been added three years before I ever met him. He left suddenly. The pipeline started failing intermittently and nobody could figure out why until they read his code, which contained comments that made no sense on their own but when assembled created a picture of a production failure from an era where the rest of the team had largely forgotten what it felt like.

Most engineering teams have this same story except without any good ending. You hire someone good who knows everything about how things work in practice rather than theory. That person stays for two years, writes code that works, leaves because a competitor offered more money or they got bored or their kid was born or whatever specific reason people leave jobs that have nothing to do with whether the work was meaningful. And when they go, they take something with them that no documentation tool can preserve.

I am talking about context and not the kind stored in ADRs or design docs. The kind that makes a function call make sense even though the code itself reads as completely unnecessary. This is the single most expensive thing software companies pay for, and it happens constantly because hiring is inherently imperfect; you never know exactly who will stay long enough to write something durable or whether someone’s specialized knowledge is actually fragile until it evaporates on a Tuesday when everything goes wrong at once.

The weird part is how visible this becomes only in retrospect. The developer who stays for five years and understands three separate services and the APIs between them is easy to identify as valuable, but the person who left after six months took with them something far more expensive because nobody noticed they were needed until they actually left. This is why team size matters less than tenure. A team of three people who stayed together for four years will outperform a team of ten who have been there an average of six months even when that bigger team has better credentials, faster typing speed, and more impressive previous employers on paper.

Companies try to solve this with documentation, wikis, architecture review boards, and any number of process frameworks sold under expensive conference titles. But none of them actually work unless the person they are trying to replace already started writing down their thinking before they left. Knowledge transfer is something that requires active participation from both sides; the person leaving has to think about who replaces them and the person arriving has to be curious enough to ask what makes things behave differently than expected. You can document process but you cannot document intuition without making it feel like a different thing entirely, and that distinction matters precisely because it makes the transfer so fragile.

The developers I have admired most throughout my career were never the ones with the fastest build times or the cleanest APIs. They were the ones who left notes in code that read as advice rather than documentation. A comment saying this only works because the database has exactly one row at a time; remove this line when you add the second tenant and nothing else, but those four words taught me how to read production systems the way the author would have wanted them understood. That is actually something you can build into your process by writing things as if someone less experienced than you will eventually encounter them alone, at an unholy morning hour, when they need to make a change and they do not have time to ask questions. The knowledge tax was never about replacing people. It was always about giving the next person fewer reasons to feel lost when they inherited something that worked perfectly until it did not.