The senior in bunker mode
Everyone has an opinion about juniors. Almost nobody talks about the senior who hides the system and likes it when the team stops the week they are away.
On this page›
Everyone has an opinion about juniors. They do not know git. They ask everything. They paste from the model without understanding it. Almost nobody talks about the other character.
The senior who has spent eight years in the same repository. The only person who can deploy. The one who greets every new hire as if the arrival were an audit.
How you recognize them
It does not take a long diagnosis. Four habits give it away.
Everything is "we already tried that", and they never say when or why. The sentence ends the conversation. The team learns to stop proposing.
"The code is the documentation." It is not. The code says what it does today. It does not say what was discarded, what deal exists with the business, or what breaks if you move that condition.
Their code reviews are oral exams. Forty comments, zero approvals. The review is not there to raise the quality of the change. It is there to remind everyone who decides.
They go on vacation and the team stops. And they like being called. The phone on the beach is proof that the system does not walk without them. That proof is useful to them.
I call this senior bunker mode.
Why it happens
The interesting part is not the joke. It is the incentive.
Catherine Connelly and her colleagues described knowledge hiding as what happens when someone asks for what you know and you choose not to give it: playing dumb, answering sideways, or explaining why "now is not the time". It is not the same as lacking the knowledge. It is withholding it.
Later work in that line ties the behavior to job insecurity. If you believe your value is being the only person who can put out the fire, sharing the map feels like giving up the job. The bunker is a survival strategy, not a personality someone brings from home.
Companies reinforce it without announcing the policy. The person who documented the system so the fire would not start gets a "thanks" in a retro. The person who put it out at 3 a.m. gets the public story, the bonus, and the reputation of being indispensable. Heroics are visible. Prevention looks like nothing happened.
Engineering already has a name for the result: a bus factor of one. If that person is away, the team cannot deploy, does not know the vendor contract, does not know which bit must not be touched. The system fits in one head. That is not seniority. It is an operational risk with a title.
Being senior is something else
Being senior is not knowing more than everyone else. It is how much the team knows because of you.
A senior takes knowledge out of the bunker and leaves it where another person can use it on a Tuesday without calling. A runbook. A decision written with the context, not only the conclusion. A review that approves when the change is fine and points at the one thing that actually matters. A deploy someone else can run while they are away, and that does not hurt them.
The bunker can be right about the content. Sometimes "we already tried that" is true. The difference is whether that truth is shared or used as a door.
And yes: I have been that senior on some days. I kept context because explaining it would take longer than doing it. I reviewed to prove I had read, not to unblock. I felt useful when they wrote me on vacation. Noticing it does not fix it. It is the only way to stop treating it as something that only happens to other people.
A short talk on measuring bus factor from real repository data:
If you are the new person
Do not try to win the bunker with admiration or a redesign in week one. Ask in writing. "Where is the deploy?" "What should I not touch?" Leave the answer in the same place you asked, even if it is incomplete. Every question that lives only in a direct message feeds the bunker.
If the answer is "we already tried that", ask for the date and the reason. Without aggression. Someone who actually knows can usually say it. Someone protecting a seat usually changes the subject.
If you lead
Stop rewarding only the fire. In the same meeting, ask who left the system in a state where the fire was unnecessary. Give the deploy two owners. If one person cannot leave for two weeks, that is not a compliment to them. It is a failure of yours.
Measure the bus factor with a simple test: can the team ship a release without that person? If the answer is no, that answer is the quarter's work, not another initiative.
If you are the bunker
Nobody is going to take the craft away because you wrote it down. You give it up yourself if your only leverage is that other people cannot move. Teaching the system is the part of the job that does not fit in the repository, and it is the part that justifies the title.
Pick one thing only you know today. Write it down. Let someone else do the deploy once, with you watching and your hands off the keyboard. A vacation where nobody calls is not a loss of status. It is the sign that the team knows something because of you.
Being senior is not knowing more than everyone else. It is how much the team knows because of you.
— from this article
References
- Connelly, C. E., Zweig, D., Webster, J., & Trougakos, J. P. (2012). Knowledge hiding in organizations. Journal of Organizational Behavior, 33(1), 64–88.
- Bus factor, Wikipedia.
- Video: Surviving the Bus Factor, CodeScene.
> What did you think?
> Thread [00]
moderatedLoading replies…