You have a proposal. And someone suggested checking with Mike. It does not sound like a problem. It sounds like due diligence, like someone being careful, like a team that knows its own limits. And in the moment, it usually is all of those things. But if you have seen this before, you start to notice what happens right after it gets said. The proposal does not stop. Nobody declares it blocked. The meeting continues. But something is different, and everyone feels it, and nobody mentions it, because what would you even say? The formal owner is still the formal owner. The decision is still theirs. It is just that now there is another path the thing has to travel before it actually moves.
Mike is usually an engineer. Staff+, technical, probably not in the call when it was decided who owns this kind of decision. But he knows the system in a way that has proven, more than once, to be the relevant kind of knowing. He remembers the migration that went wrong for a reason nobody documented. He knows which dependency will make this design expensive in a year. He knows which team will feel blindsided and cause friction and technically be right to.
So the company learned to route through them. It became the path that did not blow up, and people are rational, so they kept taking it. The person gets overloaded. The people around them get less capable, because they keep renting judgment instead of building it. The formal map and the working map drift further apart, until the difference becomes something everyone understands and nobody officially acknowledges. That gap has a cost. Then one day everyone realizes it cannot move without them.
When Maps Overlap On Mike
How the System Creates This Person
This usually starts innocently. A team needs history, so they ask the person who was there. A manager needs risk calibration, so they ask the person who has seen the system fail before. A product person needs to understand why engineering keeps pushing back, so they ask the engineer who can translate without turning the conversation into a fight. He helps. Then he helps again. Soon he becomes the shortest route between confusion and movement.
Companies like it because it is fast. It avoids a lot of processes. It lets everyone pretend the system is more legible than it is. It does not have to make the decision path clear, because Mike can tell you who matters. It does not have to improve the handoff between two teams, because Mike can translate.
The Person May Actually be Very Good
This is why I do not like framing these people as villains. Often they are good. Sometimes they are excellent. Their judgment has weight because they earned it the hard way. They saved the release. They caught the hidden dependency. They warned people before the migration went sideways. They watched the same obvious improvement fail three years ago, and now they can smell the sequel before everyone else has opened the document.
The problem starts when the company stops separating the judgment from the person. The concern is not written down. The failure mode is not explicit. The decision rule is not shared. The bridge between teams is not repaired. People just keep going back to Mike. Over time, the company is no longer using their judgment. It is storing judgment inside Mike.
The Favor Becomes Architecture
This person is absorbing ambiguity. They are making bad interfaces survivable. But such favor can turn into architecture if nobody stops it. The system starts assuming Mike will always be there. Mike will remember. Mike will translate. Mike will object. Mike will catch it. Mike will know who to talk to. Mike will notice the hidden risk before the rest of us make fools of ourselves. That is dependency with a better reputation.
How the Room Starts Moving Around Them
Once too many maps point to one person, people learn to read rooms differently. A normal engineer asks a question and the room answers it. Mike asks a question and the call gets awkward.
His hesitation carries more weight. People interpret his silence. His discomfort becomes a signal. The proposal may still be technically sound, but the energy changes. Now people want one more review, one more alignment, one more pass. That kind of checking can look responsible, but after a point it is one of the signs that execution has started to drag.
This is how the silent veto usually works. It does not need a formal no. It only needs enough uncertainty from the person everyone has learned to trust. I do not mean this as a conspiracy. People have simply learned that moving without Mike can be expensive. So it slows down.
Disagreement Picks Up Hidden Weight
On paper, this is just a technical disagreement. In practice, it feels a bit different. If you disagree with Mike, you are not only disagreeing with a design comment. You may be pushing against old history, trusted judgment, hidden dependencies, and half the company’s memory of what went wrong last time.
You may have the better argument and still lose the argument because people do not know whether you have the better map. Mike might be wrong about the current issue, but everyone remembers the last time he was right. That past correctness keeps subsidizing present authority.
This is the legend effect. He was right often enough that now he does not even have to be right. He just has to be uncertain.
Everyone Else Gets Trained
There is another cost that is easier to miss. When everyone checks with Mike first, other people stop building certain muscles. They stop forming their own reading. They stop testing their judgment early. They bring work to Mike too soon, or avoid work Mike might dislike. They learn how to route around the person instead of learning how to reason through the issue.
People wait. They soften. They pre-negotiate. They avoid saying the half-formed thing in the call because they do not want to look naive in front of someone who might know the hidden history. Again, sometimes that caution is earned. But if a team needs one person’s blessing before it can trust its own judgment, the team is not only using Mike. It is shrinking around Mike, which is the opposite of how self-managing teams become real.
What to Do Before the Dependency Hardens
If you are dealing with this from the side, do not start by assuming obstruction. That is tempting, especially when someone outside your line still changes the shape of your work. But frustration is not a diagnosis. It just tells you that something is in the way. It does not tell you what it is, or whether it is actually wrong.
So before you decide what to do, figure out what has pooled there. These things look similar from a distance and require completely different responses up close. Real system judgment, earned through failures the rest of the org has forgotten, is not the same as old territory being defended. Cross-team trust that took years to build is not the same as executive confidence that was never stress-tested after the person who granted it left. A hidden dependency nobody thought to document is not the same as inherited caution that outlived the risk that created it. Usually you are looking at some combination. The combination is important because the move that works on one actively backfires on another.
The most useful question you can ask is not "do you agree with this?" It is "what went wrong last time, specifically?" Ask what the constraint is protecting and whether what it is protecting against is still possible. Ask who got burned, how badly, and whether the conditions that caused the burn still exist. Ask which part of the concern is a live wire and which part is scar tissue that never got updated because nobody thought to check.
A real concern gets clearer when it has to explain itself in concrete terms. A concern that is mostly momentum from an old failure starts to thin the moment someone asks it to be specific, which is usually where status theater and real risk finally separate. The question does not confront the person. It just asks the resistance to show its work.
Do Not Make the Meeting Carry the Whole Disagreement
A lot of avoidable damage happens because people walk the first real disagreement into the call. They build the case, polish the doc, collect the data, and then discover that the call is not where the decision starts. The call is where earlier alignment becomes visible, or where missing alignment becomes painful. Working expectations need to be explicit before the call starts to avoid that churn.
If one person has that much gravity, talk earlier. Just to understand the shape of the resistance before it becomes public. Test the idea while it is still cheap to change. Find out whether the reaction is about risk, surprise, missing context, or control. People call this politics because they dislike it. Sometimes it is politics. Often it is just routing. If the work matters, do not let the first meaningful collision happen when everyone is watching.
Stop Praising the Symptom For too Long
A person who can translate between teams without making everyone defensive is valuable. But if the same person keeps appearing in architecture debates, delivery risks, historical explanations, escalation paths, and cross-team translation, that is no longer just a compliment.
This is a system smell. The company is telling you that too much context lives in one place. Do not punish the person for that. Do not flatten them into irrelevance because their influence makes the org chart uncomfortable. That would be stupid. Strong engineers should have influence.
The Fix is Not to Route Around Mike
The tempting answer is to make Mike less important. Remove him from the path. Stop checking with him. Force the formal owner to own the decision. On paper, that sounds healthy. I think that is usually wrong. If Mike became load-bearing, it is because something real pooled there. History, judgment, trust, the memory of old failures, the ability to translate between teams that otherwise misunderstand each other. Cutting him out too quickly removes the part of the system that was still catching the dependency before it hurt you.
The better move is to keep Mike in the route, but stop letting the route end in Mike. Every time his judgment changes a decision, ask what part of that judgment should become visible to everyone else. What failure mode did he see? What dependency did he know about? What rule of thumb was he using? What history made the proposal unsafe? That is how you turn a person back into a system.
The strange part is that a company may need to rely on Mike for a while to become less dependent on Mike. That sounds contradictory, but I think it is the honest version. You cannot de-risk a human shortcut by ignoring the only person who understands why the shortcut exists. You de-risk it by making what they carry more portable, one decision at a time.