The person everyone waits for
Every business with a small technical team has one. The developer who built the first version, knows why the invoice job runs at 2am, remembers which customer has a special pricing rule and is the only one who can deploy. When they are on holiday, nobody touches production. When something breaks at the weekend, they get the call.
They are usually excellent. That is the problem. Everything routes through them because they are fast and reliable, and so nothing else ever gets built up around them.
How it ends up this way
Nobody decides to create a single point of failure. It builds up gradually.
- The early system was built fast, by one person, with no time for documentation.
- Other developers came and went, but the original one stayed and kept the difficult parts.
- Deployments, server access and third-party accounts were set up under their login.
- When something urgent happens, it is quicker for them to fix it than to explain it.
- Writing things down never beats the next feature in a priority discussion.
Asking them to document everything in their spare time rarely works. They do not have spare time, and knowledge written in isolation misses what the next person will actually need to know.
What rides on one person
| If they are away or leave | What happens |
|---|---|
| Production incident | Nobody knows how to diagnose or roll back |
| Routine deployment | Releases stop, or someone guesses |
| Expired certificate or credential | Nobody knows where it is configured |
| Customer asks why a figure is wrong | Nobody knows the rule behind it |
| Hiring a replacement | The new person has nothing to learn from |
There is also a quieter cost while they are still there. They become a bottleneck on every decision, work queues behind their availability, and they burn out carrying it.
How we spread the knowledge
What we do is add a second experienced developer alongside them, with the explicit job of learning the system by working on it and writing down what they learn.
- Map the system with your key developer: components, servers, scheduled jobs, integrations, accounts and the dark corners they worry about.
- Pair on real work. Our developer takes tickets in each area of the system, with your developer reviewing, so learning happens through doing rather than long handover meetings.
- Write runbooks as we go: how to deploy, how to roll back, how to restore from backup, what to check when a particular alert fires.
- Move accounts and access to the business. Hosting, domains, repositories and third-party services are owned by company accounts, with named individuals given access.
- Put infrastructure into code where practical, using tools like Terraform or the cloud provider's templates, so server setup is written down and repeatable.
- Test the result. At some point the second developer runs a deployment and a restore on their own while the original one watches. Gaps show up quickly.
We also look at the scheduled jobs and integrations that run without anyone watching. These are the pieces most likely to fail silently after a key person leaves, because nobody else knows they exist. Each one gets a short note: what it does, when it runs, what breaks if it stops and how to tell whether it ran.
This is done with your developer, not around them. The aim is to take load off them, and most people in that position are relieved rather than threatened.
After the knowledge is shared
Two people can deploy, diagnose and fix. Your key developer can take a proper holiday. Runbooks and architecture notes sit in your repository where anyone can read them. If they do leave one day, you have a handover that is already mostly done.
You can then decide whether to keep our developer on, reduce their hours or hand everything to a new in-house hire, and any of those is workable.
Does this describe your team?
- One developer is the only person who can deploy or fix production.
- Their holidays are planned around the release calendar.
- Server, domain or cloud accounts are under their personal login.
- There is little or no written documentation of how things work.
- You would struggle to brief a replacement if they left tomorrow.