You Already Know What to Do

You know the pattern. Someone drops a question in Slack. Maybe it's about which logging library to standardize on, or whether to move a service boundary, or how to handle a specific edge case in the API design. Within minutes, there's a thread. Opinions start stacking up. Someone schedules a meeting to "align." The meeting spawns a follow-up. Three days later, the team is still talking about a decision that one person could have made in five minutes on a Tuesday morning.

This is not collaboration. This is a leader quietly outsourcing their job to a group chat.

The frustrating part is that most engineering leaders who do this are not lazy or incompetent. They're often the most conscientious people on the team. They care about getting it right. They don't want to step on anyone. They've read enough about psychological safety to know that unilateral decisions can damage trust. So they ask. And ask. And ask. And the team watches all of this and starts to wonder: does anyone actually know where we're going?

Why This Keeps Happening

There are exactly two reasons a leader over-consults on decisions.

The first is that they genuinely need information they don't have. Maybe the decision touches a system they don't know well, or it has downstream effects on a team they don't talk to regularly. In that case, asking makes complete sense. You're not looking for permission. You're filling a real gap in your understanding before you commit to something.

The second reason is that they want cover. If the decision goes sideways, they can point to the process. "We discussed it as a team." "Everyone had input." The outcome becomes a shared responsibility, which means no one person has to own the failure. This feels like humility. It is not. It is fear.

Only one of those reasons is worth acting on. If you need information, go get it. If you need courage, that's a different problem, and a meeting won't fix it.

The Actual Test

Here's how to know which situation you're in. Ask yourself one question before you open that Slack thread or send that calendar invite: Do I already know what I would do?

If the answer is yes, stop. You don't need input. You need to decide and move. What you're about to do is not gather perspectives. You're about to look for someone to agree with you so you feel better about a call you've already made. That's not collaboration, that's insecurity.

If the answer is genuinely no, then the next question matters: what specific information would change my decision? If you can name it, go find that information from the one or two people who actually have it. If you can't name it, you're probably not missing information. You're missing confidence.

The Framework That Actually Works

Stop thinking about decisions in terms of how uncomfortable they make you. Start thinking about them in terms of two things: blast radius and reversibility.

Blast radius is how many people and systems are affected if you get this wrong. Reversibility is how hard it is to undo if you need to change course.

A decision with a small blast radius and high reversibility should almost never require a meeting. Pick the logging library. Choose the folder structure. Set the default timeout value. Make the call, document it briefly, move on. If it turns out to be wrong, you fix it. The cost of being wrong is low. The cost of the three-day Slack thread is not.

A decision with a large blast radius or low reversibility is a different story. Choosing a data storage architecture to underpin five services over the next three years warrants careful input. Deprecating an API that external partners depend on requires the right people in the room. Not everyone. Not a committee. The specific people whose knowledge or whose work will be materially affected by the outcome.

The keyword there is specific. The problem with chronic over-consultation isn't just that it wastes time. It trains your team to treat every decision as if it requires a quorum. When you model that behavior, they replicate it. Suddenly, your entire organization is waiting for consensus on things that should take minutes.

On Inclusion and What It Actually Means

The obvious objection here is that inclusive decision-making builds buy-in. That teams feel more ownership over outcomes when they've had a voice in shaping them. That psychological safety requires people to feel heard.

All of that is true. None of it means what people think it means in practice.

There is a real difference between including people in decisions that affect them and using your team as an emotional support system for decisions you are paid to make. Genuine inclusion means bringing people in early, when their input can actually change the direction you take. It means asking a senior engineer about a technical tradeoff before you've already decided, not after. It means looping in the team lead from another squad before committing to an integration approach that will create work for them.

What it does not mean is running a poll because you're nervous. It does not mean opening a thread to "get everyone's thoughts" on something you already have a clear opinion about. That's not making people feel included. That's making them do your emotional labor while you pretend it's a collaborative process.

People can tell the difference. They might not say it out loud, but they feel it. The endless requests for input on small decisions don't build trust. They erode it slowly because they signal that the person who is supposed to be steering doesn't fully trust their own hands on the wheel.

Speed Is a Leadership Output

This part doesn't get talked about enough. The pace at which decisions get made is itself a signal to your team about the health of the organization.

When a team watches their manager poll the room on every call, something shifts. It's subtle at first. People start to notice that things take longer than they should. They start to feel that forward motion requires everyone to agree, which means it's always one dissenting opinion away from stalling. The most decisive people on the team, the ones you most want to keep, start to get frustrated. They didn't sign up to spend their days in alignment meetings about things that should have been decided before lunch.

Speed doesn't mean recklessness. It means having a clear enough framework so you can move quickly on decisions that need speed and slow down appropriately for those that don't. The leaders who do this well aren't faster because they're smarter. They're faster because they've stopped confusing discomfort with complexity.

A hard decision and an uncomfortable decision are not the same thing. Hard decisions are hard because the information is incomplete, the tradeoffs are real, and the consequences are significant. Uncomfortable decisions are uncomfortable because you'd rather not be the one to own the outcome. Hard decisions deserve process. Uncomfortable decisions deserve a moment of honesty with yourself, followed by a decision.

What Chronic Indecision Costs You

The cultural cost of this pattern is real, and it compounds. Teams that operate under chronic indecision start to lose their sense of direction. Not dramatically, not all at once, but gradually. People stop bringing their best thinking to problems because they've learned that nothing will happen with it until everyone agrees, and that getting everyone to agree takes forever. The team's energy shifts from doing the work to managing the process around the work.

Worse, the people most capable of leading begin to disengage. They don't need a perfect leader. They need a leader who actually leads. Someone who gathers the right information, makes a call, owns the outcome, and adjusts when necessary. That's the whole job. Not certainty. Not perfection. Just a clear enough signal that someone is actually making a decision.

Map your decisions against blast radius and reversibility. Be honest about whether you're asking because you need information or reassurance. Bring people in when their input genuinely changes the outcome. And when you already know what you'd do, do it.

Your team does not need you to be right every time. They need you to actually decide.

The Tech Lead Operating System — practical structure for leads who are running everything out of their head and need a system that makes decisions faster, not harder.