A partner team was blocked and could not ship, and the proposed fix landed in my chat as a reasonable, tidy request: give them access to our repositories so they can study how we built this.
On the surface it is a fair ask. The team is stuck, we have working code, share the code, unblock the team. Clean. Fast. Done.
It was the wrong fix. And the thing that made it wrong is a pattern I have watched play out in more than one company, so it is worth writing down.
Table of contents
Open Table of contents
The reflex
When a team is blocked, access looks like the obvious lever. It is easy to grant, easy to measure, and it feels like decisive leadership. Someone is waiting on you, you flip a switch, they are unblocked. You get to close the ticket and feel useful.
The trouble is that access is a proxy. It stands in for the thing people actually need, which is understanding. Most of the time the two are not the same, and confusing them quietly creates a worse problem than the one you started with.
What access actually buys
Here is what happens when you hand a repository to a team that has never worked in that domain.
They clone it. They open it. They find working, production-grade code that assumes a pile of context they do not have: why the architecture is shaped this way, which decisions were deliberate, which are scars from an old incident, what the non-obvious edge cases are. Code without that context is not knowledge. It is noise with good syntax highlighting.
So they do the only rational thing. They go find the one person who does understand it, and they ask. Same as before. You did not remove the dependency on that person. You added a detour through a repository first, and then routed everyone back to the same desk.
A repository tells you what the system does. It rarely tells you why, and the why is the part people are actually stuck on. Handing over the code and calling it knowledge transfer is like handing someone a dictionary and calling it a conversation.
The real bottleneck
Once you follow the questions back to their source, the actual problem shows up, and it has nothing to do with permissions.
The blocker was that all the knowledge lived in one person’s head. One senior engineer understood the domain, the integrations, the sharp edges. Everyone else, internal or external, eventually funneled back to that one person. That is a bus factor of one. It is a single point of failure, and we would never tolerate it in our infrastructure, yet we tolerate it in our people all the time because it never pages anyone. It just quietly caps how fast anything can move.
Granting repo access to trapped knowledge does not release the knowledge. It multiplies the number of confused people lined up outside the same door.
If one person leaving would take critical knowledge out the door with them, that is not seniority. It is a risk you have not mitigated. Treat it like any other single point of failure, because that is what it is.
The question that ends the debate
There is a second reason the easy fix was the wrong one, and it is the one that usually cools the argument fastest in the room.
The code in question was proprietary. It carried the parts of the product that are actual market differentiators. So when someone pushes “just grant access,” the question to ask back is simple: who owns the responsibility if this leaks or gets reused somewhere else?
Access to proprietary work is close to irreversible. Once it is out, you cannot un-share it. That single question reframes the whole thing. It stops being a conversation about convenience and becomes a conversation about liability, and those are decided very differently. Most people asking for broad access have not priced in that risk, because it was never their risk to carry.
The fix that scales
The investment that actually solves this is boring, slower, and correct: get the knowledge out of the one head and into a form other people can consume without a meeting.
That means documented flows, contracts, and the architecture decisions with their reasoning. It means recorded walkthroughs the team can rewatch as many times as they need, instead of booking the one expert for the same explanation five times. Documentation scales. A person answering the same question on repeat does not, and worse, they start to resent it.
| Grant repo access | Transfer the knowledge | |
|---|---|---|
| Speed | Fast, feels done today | Slower, pays off for months |
| Bus factor | Unchanged, still one head | Reduced, knowledge is shared |
| Partner team | Code they cannot read yet | Self-serve, rewatchable |
| Risk | Irreversible exposure | Contained, you choose what to share |
| Solves the real problem | No | Yes |
The best part is that it fixes two problems with one investment. The partner team gets genuinely unblocked, and you stop being one resignation away from losing something critical. You would need two separate initiatives to get both of those any other way.
Why leaders reach for access anyway
If the transfer is so clearly better, why is the reflex always access?
Because access is fast and visible, and transfer is slow and invisible until later. Granting a permission produces an immediate, legible result. Writing things down and recording sessions produces nothing you can point at this week. It only pays off in the weeks after, quietly, when the questions stop coming. Under deadline pressure, the fast and visible option wins almost every time, even when everyone in the room half-knows it is a patch.
That is exactly the moment leadership is supposed to earn its keep. Choosing the slow fix that removes the problem over the fast one that hides it is most of the job.
Closing thought
When a team is blocked, the useful move is not to ask what access they are missing. It is to ask what is actually blocking them.
If the honest answer is “one person is the only one who knows how,” then no permission on earth will fix that. You can grant every repo you own and the bottleneck stays exactly where it was, because it was never a wall. It was a person. Get what is in their head into the open, and you solve the delivery problem and the bus factor in the same move.
Repos are cheap to share. Understanding is not. Do not confuse the two, especially when someone is standing over your shoulder asking you to.
