Whenever knowledge silos come up in a small team, the fix arrives from the same place: more documentation. A wiki gets created, a template gets shared, it is filled in eagerly for two weeks, and then it goes quiet. Six months later the same question goes to the same person again, and that person answers it in ten seconds again.
I think we are looking for the problem in the wrong place. In a three-person team a silo is not a documentation gap, it is a routing habit. The question goes to whoever will answer it fastest. Speed is a good thing — and it is exactly what holds the silo together. I covered the organizational side of deliberately distributing responsibility in operational delegation design; what I am after here is smaller and sneakier: routing nobody noticed they were deciding.
Why was 16 sixteen?
I paid the bill for this in my own blog infrastructure on 25 June 2026. The GitHub Actions workflow that generates content had a preflight check at the top: if the server's load was above a threshold, the run was skipped. The threshold was load average > 16, on an 18 vCPU VPS.
That day the blog produced not a single article for a full day. Silently. No errors, no alarms; every run skipped itself saying "load is high." When I finally looked, the machine was in perfect health: 73-87% of the CPU was idle, 81 GB of RAM was free, the disk was 16% full. The misleading part was the metric itself — bursty workloads and temporary cgroup throttling pushed load average into the 18-30 range while the CPU sat there twiddling its thumbs. The fix moved the threshold from load average to CPU idle percentage: skip only when there is real saturation, meaning idle drops below 12%.
But the fix is not the point. The point is the question that followed: why was 16 sixteen? I was the person who put that number there, and I did not know either. There was no calculation behind it, just an evening. The decision itself was recorded — the code was right there — its rationale was not. In a one-person setup we call that forgetfulness; in a three-person team the same thing is called a silo.
Why silos form so fast in a small team
In a large organization silos form slowly, because process gets in the way: reviews, handovers, on-call rosters. A small team has none of those brakes, and worse, the silo looks efficient. If Ali knows the network side, giving network work to Ali is the right call — for that day.
What is wrong is not the decision but its repetition. The sixth time the same request goes to the same person, it is no longer a choice; it is an organizational reflex. At that point the team no longer divides work, it summons a person. And nobody notices when it happened, because in every individual case the fastest path was chosen.
In a small team the cost of this does not show up during vacations — if it were that obvious we would have solved it long ago. The cost shows up on the days that person is available but busy. The work gets parked, someone says "Ali will look at it tomorrow," and nobody records that as an incident.
Why writing it in the wiki is not enough
Chapter 28 of Google's SRE book, which covers getting a new engineer ready for on-call, makes an honest observation about documentation: outdated documentation is a comparatively small problem for senior engineers, and it is the newcomer who is genuinely in need of up-to-date documentation. In other words, the cost of documentation rot is paid not by the person who wrote it but by the person who needs it most. In a small team those two are almost never the same person.
The same chapter openly argues against teaching people by throwing them into the fire — "trial by fire": that route may eventually produce good operations people, but the results fall short of the mark. The way to move knowledge is neither a pile of documents nor a swimming lesson in the deep end.
What I took from this is that documentation does not carry knowledge, it carries decisions. Instead of writing a list of steps, write the reasoning. The mature form of that is the architecture decision record; in the ADR community's own definition, a decision record captures an architecturally significant choice together with its rationale, its trade-offs and its consequences. If there had been two sentences of reasoning next to that load > 16 line, the flaw in the reasoning would have been visible on the first read. I discussed turning that record into a habit in the decision log discipline. I covered the rhythm of making tacit operational knowledge visible in the quiet knowledge inventory; the difference here is that the goal is not to take inventory but to change where the request is routed.
Intervention 1: change the request's address
The cheapest intervention is to change not who answers, but who gets summoned. On the code side there is a ready-made mechanism for this: CODEOWNERS. According to GitHub's documentation the file lives in the repository's .github/, root, or docs/ directory, searched in that order, and the first one found wins. When a pull request modifies files they own, the owners are automatically requested for review. The file must exist on the pull request's base branch, so a rule you add on your own branch does nothing for pull requests targeting that branch. There is a second gotcha that bites more often: code owners are not automatically requested to review draft pull requests — until the PR is marked ready for review the mechanism stays silent, and most small teams work in drafts. Pattern order matters: the last matching pattern takes precedence. And when "Require review from Code Owners" is enabled on a protected branch, an approval from any of the owners is sufficient — not all of them.
That last detail matters for small teams. If you list two names the gate does not lock up, but the second name now has to look at what is going on every single time. That is precisely what breaking a silo requires: mandatory exposure.
In my own repository the rule is this: every single-owner area gets opened as a gap to close. The number of owners is not a maturity indicator, it is a risk indicator.
Intervention 2: shadow, then reverse shadow
The second intervention is about the handover method, and the most common mistake here is stopping halfway. That same SRE chapter separates two stages: first the new person shadows the experienced one — in PagerDuty's description, the shadow responder receives the alerts, joins the calls in listen-only mode, and afterwards schedules time with the responder they shadowed to ask their questions. Then the roles flip. In the stage the book calls "reverse shadow," the newcomer becomes primary on-call and owns all incoming escalations, while the experienced on-caller "lurks in the shadows, independently diagnosing the situation without modifying any state" and stays "available to provide active support, help, validation, and hints as necessary" — available, but not at the wheel. I wrote about the team-level operating model for shadow rotations separately in shadow on-call and skill transfer.
Most teams skip that second half, and the difference hides exactly there: watching teaches you what the work looks like, driving teaches you the work. In a three-person team the drill version is this: the second person does the next real task while the first sits beside them without touching the keyboard. A ten-minute job takes forty. Those thirty minutes are the tuition you pay; the alternative is a silent outage that lasts a day.
Intervention 3: the absence drill
The only honest way to measure whether a silo is actually broken is to declare that person deliberately absent. Put it on the calendar: on Thursday, Ali is not looking at the network side. Ali is in the office, alive and well, but the questions do not go to him.
Every blockage that surfaces that day is a finding and needs to be written down. What surfaces is predictable: missing access, a dashboard whose address nobody knows, the reason a cron job runs at that particular hour, a rule someone added by hand a year ago that nobody else knows exists. The access item is especially insidious — PagerDuty's guide puts it in one sentence: everyone should have their access needs verified before they are assigned to an on-call rotation. Even the most solid handover hits a wall in the first five minutes if the person's account does not exist.
The absence drill has a second benefit in small teams: for once, knowledge transfer looks like a project. It has a date, an output and a result. I have never seen the sentence "let's focus on documentation for a while" clear space on a calendar; the sentence "Ali is out on Thursday" clears its own.
Why not every silo is worth breaking
Everything I have written so far has a cost, and I do not want to hide it: bringing in a second person slows every task down. In a small team time is the scarcest resource, so "let's break all the silos" sounds good but is a goal people abandon in practice.
I draw the line with two questions. First: if this area stops, does the business stop? Payment flows, authentication, restoring backups — being one person deep there is not acceptable. A reporting script touched twice a year, on the other hand, can stay with one person; if it breaks, the cost is an afternoon.
Second: how quickly does the knowledge rot? Knowledge learned once and valid for years is cheap to transfer. In a constantly changing area, handover is not a one-time ceremony but an ongoing expense — and if you are not willing to pay it, do not start the handover at all, because half-transferred knowledge is the most dangerous kind. The second person believes they are competent while actually knowing the system as it was six months ago.
The mechanism also has its own way of rotting: the second owner approves without reading. The silo does not disappear then, it gets a green checkmark on top — which is the worst outcome, because now it looks closed. The only thing that works against this is making approval expensive: the second person has to ask at least one question when approving, or takes a turn driving the pull request outright.
So breaking a silo is not a virtue, it is an investment decision. Choose every silo you break deliberately, accept the rest deliberately, and write down what you accepted.
A decision framework
Ask your own setup these questions in order:
- Over the last month, what percentage of requests in one area went to the same person? If you do not label tickets, the repository already knows:
git log --since="1 month ago" --format='%an' -- <path> | sort | uniq -c | sort -rn. If one name is above 80%, there is a silo, not a question mark. - When did the second person in this area last drive the work themselves? Watching does not count.
- Do your critical thresholds, cron schedules and magic numbers have reasoning next to them? If not, that line lives in one person's memory.
- Does the second person's required access work today? If you have not tested it, your answer is no.
- If this area's owner disappeared for a week, would the work wait or continue?
Filling in this list takes half an hour and usually produces an embarrassing result. Embarrassing is good news; it means you found something measurable. I discussed the runbook side of handover debt in managing runbook debt.
Closing
In a small team, silos do not come from bad intent or laziness. They are the natural consequence of always choosing the fastest path. That is why you break them not by writing more, but by routing more slowly: by giving the request to the second person and writing down why the number is that number.
My load > 16 line taught me this: the most fragile part of a system is the number nobody questions. And for a number to be questionable, there first has to be a second human responsible for it.
Top comments (0)