Every engineering org I've worked with has one. The person everyone routes decisions through. The senior architect who signs off on every design. The tech lead who reviews every pull request personally. The founder who still approves every database migration.
It looks like leadership. It feels like control. It's a countdown timer.
The Person You Route Everything Through Is a Liability
I've watched this pattern kill more good ideas than bad hiring ever did. A team has a genuinely useful proposal, something to speed up delivery or cut real risk. It goes to the one brain who decides. This person is busy, or tired, or doesn't see it the way the team does. The idea dies in a Slack thread. Nobody escalates because escalating past the decision-maker feels like a career-limiting move.
This isn't a people problem. It's a structural one. When one person holds the authority to say yes or no on every meaningful call, you've built a system with exactly one point of failure, and it isn't a server.
There's a name for this in engineering circles: the bus factor. It's the number of people who'd need to disappear before your project stalls. A 2015-2016 study of 133 popular GitHub projects found 65% had a bus factor of 2 or lower. Fewer than 10% cleared a bus factor of 10. Not a fringe problem. Most software teams run on borrowed time.
The left-pad incident is the sharpest example. A single maintainer pulled an eleven-line NPM package, and thousands of projects broke overnight. One person, one decision, one afternoon of chaos across the internet. This is what concentrated decision-making looks like when it fails in public.
Speed Is the Excuse, Not the Reason
Ask anyone why one person makes all the calls and you'll hear "it's faster." Sometimes it is, for about six months. Then this person becomes the bottleneck for every decision in the org, and "faster" turns into "everything waits for Dave."
I get the appeal. A single decision-maker means no debate, no meetings, no waiting on consensus. But you aren't buying speed. You're buying speed today at the cost of resilience tomorrow. Resilience is what matters when Dave is on vacation, gets promoted, or leaves for a better offer.
There's also a quieter cost. When one person decides everything, the team stops bringing their best thinking. Why sharpen an argument for a proposal if the outcome depends on one person's mood on a given morning? I've seen sharp engineers go quiet in meetings, not because they had nothing to say, but because they'd learned it never changed anything. Not a productivity loss you'll see on a burndown chart. Still real, and it compounds.
What Collective Decision-Making Looks Like
I'm not arguing for decision-by-committee. Committees are their own kind of dysfunction, slow and mushy and built to avoid blame rather than reach clarity. The alternative to one brain deciding isn't everyone deciding. It's the right group deciding, with a clear process, and the authority distributed instead of only claimed to be.
Here's what this looks like in practice:
Architecture decisions get written down and reviewed, not announced
If your architecture decisions live in one person's head, or in a Slack DM nobody will find later, you don't have a decision-making process. You have a rumor. Write the decision down: what problem it solves, what you considered, what you picked, why. Let more than one person weigh in before it's final. Not bureaucracy. The difference between a decision and a guess which happened to work out.
Skills and context get made visible, not hoarded
A useful exercise here is a skill matrix: map out who on the team owns what, and where the gaps sit. When gaps are visible, teams fix them on purpose instead of discovering them during an outage. If only one person understands the payment system, this isn't a fact about your team. It's a decision your team made, whether anyone meant to make it or not.
Rotating ownership beats permanent ownership
Code review, on-call, design review, all of it works better when the rotation includes more than the two most senior people. Rotating ownership does two things at once: it spreads the knowledge, and it forces the "senior" thinking to get explained out loud, which usually improves it.
Delegate the decision, not only the task
There's a real difference between "go build this" and "you decide how this gets built." Handing someone a task while keeping every decision for yourself isn't delegation. It's dictation with extra steps. If you want a team growing into better judgment, you have to let them exercise judgment, including the judgment to get it wrong sometimes and learn from it.
Disagreement gets rewarded, not punished
Here's the piece most orgs skip. It's easy to say "we want more voices in the room" and then quietly punish the first person who uses theirs to push back on the boss. If someone raises a concern about a decision and gets shut down, or worse, gets a cold shoulder in the next meeting, everyone else in the room learns the real rule fast, and it isn't the one written on the poster in the break room.
I've watched engineering managers negotiate this directly with their teams, laying out exactly which decisions the team owns outright, which ones need a manager's sign-off, and which sit somewhere in between. Naming the boundary out loud beats pretending everyone has equal say when they don't. Teams handle limited authority fine. What breaks them is authority supposedly shared but not really, dressed up in language about empowerment while every real decision still funnels through one desk.
The Uncomfortable Part for Leaders
If you're the person everyone routes decisions through, this is going to sting. Being the bottleneck feels like being important. Your calendar is full. People need you. This feeling is seductive, and it's also a trap, because it means your team's capability is capped at your personal bandwidth.
The leaders I respect most did the opposite of what felt natural. They pushed decisions down and out, even when it meant watching someone make a call they wouldn't have made themselves. They accepted short-term friction, more debate, more visible disagreement, in exchange for a team able to function without them standing over it.
Here's the real test of whether you built a team or a dependency. Take yourself out of the loop for two weeks. If decisions stall, you didn't build a resilient team. You built an expensive, well-paid single point of failure.
Start Small
You don't need to blow up your org chart to fix this. Pick one category of decision you currently make alone and hand it to the team this month. Architecture choices for a new feature. Which bugs get priority. How the on-call rotation works. Write down who owns the decision now, and let them own it, including the outcome.
Innovation doesn't die because a team lacks smart people. It dies because one brain became the ceiling everyone else's ideas had to fit under. Raise the ceiling. Spread the decisions. Watch what your team does when they're trusted to think.
Who's the one person your team routes every decision through, and what happens the week they're out?