Almost every software team has one. The billing integration, the data pipeline, the legacy admin tool, the deploy script nobody else touches. There’s one developer who actually understands how it works, and everyone else routes questions to them. It works fine right up until the day that person gives two weeks’ notice.
Why This Happens Even on Good Teams
Nobody sets out to create a single point of failure. It happens gradually. One person builds the system, so they’re the natural person to fix it when it breaks. Every fix deepens their understanding and makes it faster for them to handle the next issue than for anyone else to learn. After a year or two, the knowledge gap is wide enough that handing it off feels like a project nobody has time for.
The system keeps working, so the risk stays invisible. Nothing on a dashboard measures how many people could fix it at 2am.
What It Actually Costs When They Leave
The obvious cost: slower fixes. The first real incident after their departure takes days instead of hours, because whoever picks it up is learning the system and debugging it at the same time.
The hidden cost: frozen roadmaps. Teams often stop changing a system nobody understands. Features that depend on it quietly get deprioritized, not because they aren’t valuable, but because no one wants to be the person who breaks it.
The expensive cost: rewrites that didn’t need to happen. When a system becomes a black box, the tempting answer is to replace it. Sometimes that’s right. Often it’s an expensive rebuild of something that worked fine and just needed someone who understood it.
How to Spread the Knowledge Before Anyone Gives Notice
Find your single points of failure on purpose. Ask the team a simple question: for each critical system, who besides the obvious person could fix it during an outage? Any system with one name next to it is on the list.
Pair on real work, not documentation sprints. Long documentation efforts rarely get finished or read. Having a second engineer shadow and then lead the next few real changes to the system transfers knowledge far more reliably.
Write down the “why,” not just the “how.” Code shows what a system does. What’s usually missing is why it was built that way, what was tried and abandoned, and which parts are fragile. A short page of that context is worth more than a long page of setup instructions.
Rotate on-call and maintenance through the system. If only one person ever gets paged for it, only one person will ever understand it. Deliberately routing smaller issues to other engineers builds familiarity before it’s urgent.
The Bottom Line
A system only one person understands isn’t a people problem or a documentation problem. It’s a risk that sits quietly on the balance sheet until the day it doesn’t. The cheapest time to fix it is while that person is still around to teach, not after their last day.