Engineering Journal · LEADERSHIP · June 25, 2025 · 16 min read
A Team That Needs You on Holiday Does Not Have a System
The highest-leverage work on a small team is not the hard pull request. It is reducing the number of facts that only exist in one person's head.
By Golam Sorwar, Tech Lead and Full Stack Engineer in Dublin.
I have been the person whose phone stayed on during leave. I have also been the person who enjoyed that a little, which is the part that is harder to admit. Being needed feels like value. It is often a design smell.
I already wrote about the decisions a tech lead cannot leave ownerless. This is the other side. Even if those decisions have names, the team can still be one skull away from a stall: the deploy incantation, the vendor dashboard, the reason a job runs at 02:10, the "do not touch" module.
If the product cannot survive your week off, you do not have a team with a system. You have a team with a dependency that walks around.
Context
Small product groups — web, API, a mobile client, operational software — grow this dependency naturally. The first person who wired payments or mail or the tenant switcher keeps getting the ticket. Review becomes a bottleneck because only they can smell the danger. Documentation feels like a luxury when the same person is also shipping.
I still write code. The trap is using that as proof that the knowledge is shared. Code that only one person dares to change is not shared. It is a private language with a public repository.
The same pattern shows up in vendor access. One person has the Stripe login, the mail provider, the DNS, the "real" AWS console. When they are away, the team can still merge code and still cannot answer a simple "what did the provider do." That is not an IT inconvenience. That is an ownership hole in the architecture.
The problem
The apparent problem is bus factor as a slogan. We should document more.
The real problem is load-bearing folklore. The organisation runs on steps that are not in the application: who to ask, which flag, which queue to retry, which customer is special. Folklore is fast for the person who owns it and impossible for everyone else.
If you "fix" this with more meetings, you have moved the folklore into a calendar. If you fix it by writing novels, you have moved it into a wiki nobody opens during an incident.
The problem is also incentive. The expert is fast. The organisation likes fast. Every hour they spend making someone else able to be fast looks like a loss on a board that only counts tickets. Holiday-readiness will not win that board unless you name it as work. If you do not name it, you will keep being complimented for answering Slack from a train.
The tempting solution
Ask the expert to write a README this quarter. Pair once. Say we have a culture of sharing.
Or rotate people randomly onto every area so nobody is deep. You have replaced a single point of failure with a team of tourists.
Why that is not enough
Documentation that describes screens and not decisions goes stale on the next feature. People need "why we do not run this migration at noon," not a screenshot of Horizon.
Pairing that does not change ownership leaves the expert as the reviewer of record forever. The other person was a visitor.
Heroics hide the metric. If you always answer, the team never feels the gap. The gap is the product. You are papering it.
Review-as-bottleneck is the polite version. The expert does not mean to be a gate. They are the only person who has been burned by the path, so every similar change waits. Waiting looks like quality. It is also a queue with one consumer. Queues with one consumer do not take holidays. They take laptops to the beach.
Options
Keep the expert model and pay them well. Advantage: speed in the known areas. Disadvantage: hiring, holidays, and illness become incidents. This is how many small teams actually run. Naming it is at least honest.
Make every area a committee. Advantage: no single owner. Disadvantage: no single owner.
Named owners with a documented deputy and a written decision log for the sharp edges. Advantage: someone is accountable, someone can cover, the "why" is findable. Disadvantage: you have to refuse some work so the owner can write the dull page. I want this.
Automate the folklore into the product: runbooks as commands, guarded deploys, replay tools. Advantage: the system carries the knowledge. Disadvantage: you must maintain the tool. Worth it for the weekly rituals. Not for every paragraph.
Record decisions, not procedures. A page that says "we do not retry this vendor, here is why, here is the human path" will outlive a page that says which button to click in last year's Horizon. Procedures rot. Decisions stay load-bearing. Teach the decision and the current command. Skip the screenshot novel.
Trade-offs
You trade the expert's flow for the team's ability to move without them. They will feel slower. They are buying optionality.
You trade some depth. A deputy will not know every scar. They need the scars that are still load-bearing.
You should not trade away the expert's craft by making them a full-time writer. The job is to make the dangerous ten percent explainable, not to narrate every helper. If the expert disappears into a wiki, you have moved the bottleneck from production to prose.
Decision
I treat holiday-readiness as a quality of the system, not as a personality trait of being "supportive." Before I take a week, I want a deputy who has actually performed the risky path once, and a page that states the decisions that still surprise people.
If I cannot leave, that is a backlog item with a name. It is not a compliment.
I also watch my own reviews. If every risky pull request waits for me, I have built a queue that looks like quality and behaves like a single point of failure. The fix is not to review less carefully. It is to encode the scar in a test or a checklist so someone else can merge the next similar change without waiting for my mood.
Implementation / Thinking process
List the paths that would page someone: payments stuck, mail backlog, a failed deploy, a tenant mix-up, a vendor token. For each, write the decision, the danger, the command, the "do not." Keep it short. If it cannot be short, the path is too magical and should be simplified.
Change review so the expert is not the only merge. That may mean the expert writes the test that encodes the scar, then someone else ships the next change against that test. The test is the deputy that never sleeps.
When I am the expert, I practice answering with a link and a walkthrough, not a silent fix. A silent fix teaches the team to bring me live incidents as a service.
Shadow on-call is useful. So is the opposite: the expert is not allowed to touch the first hour unless the deputy asks. That sounds harsh. It is how you discover the missing sentence in the runbook.
Vendor access gets the same treatment. A shared, audited login or a second named owner is not bureaucracy. It is how you stop a password manager entry from being a production dependency. If only one human can open the dashboard, you do not have an integration. You have a priesthood.
I also ask people to teach backwards. The expert writes the page. The deputy performs the path. Then the deputy edits the page. If the page cannot survive that edit, it was a transcript, not a tool.
I keep the list of "only I know this" short enough to review in a monthly half hour. If the list grows, that is the backlog, not a personality quiz. The items are usually access, a weird clock, and a module nobody wants to open. Those three are enough to stall a week. They are also enough to plan.
Failure modes
The deputy who is named and has never been allowed to fail. Ownership theatre.
The document that is a transcript of a call. Nobody can scan it when they are scared.
The expert who documents as revenge — so much detail that the page is a second codebase. Brevity is a kindness.
The rotation that puts a new person on mail week without a floor. Sharing is not the same as throwing.
The holiday that is "covered" because someone has the password and not the decision. Access without the "do not" list is how you get a brave deputy and a worse week. Coverage is the path performed once, not the vault opened.
Operational consequences
When this works, the expert gets to do deeper work instead of being a router. When it does not, they burn out and the organisation is surprised, which is an odd reaction to a single point of failure doing what single points do.
Stakeholders will still try to "just ask you." You have to redirect in front of them, or you have taught them the old design.
There is a hiring consequence too. If the only way to be useful is to have been present for last year's scars, you cannot onboard. New people will look slow. They are not slow. They are locked out of a language that was never written down. You will then conclude that "good people are hard to find" when you have made the job a memory test.
Lessons
Leverage on a small team is the number of correct actions someone else can take without you. Code quality is part of that. So is the unglamorous page that says why the job is not on the default queue.
If you are proud of being the only one who can do it, you have optimised for identity. The product needs a system. Identity does not page well at 2am, and it does not board a flight. A system does both, badly at first, then better.
What I would do differently today
I would have named deputies before we had a painful holiday, not after. Pain is a poor planning tool. A calendar is a better planning tool.
I would have written decision records for the weird clocks — the 02:10 job, the vendor who must not be retried, the table you do not vacuum at noon — before I wrote more onboarding prose. New people do not fail on how to run npm. They fail on the weird clocks.
I would have treated "I will just do it, it is faster" as a debt with an owner. Sometimes it is the right hour. It is never a strategy. If the same silent fix happens twice, the third time is a page or a command, not another hero evening.
Closing thought
A team that needs you on holiday does not have a system. It has a bottleneck with a passport. The passport should be allowed to leave. The work of leadership is to make the dangerous knowledge findable, the ownership shared enough to survive a week, and the silent heroics slightly embarrassing.