Why Your "Senior" Engineers Can't Make Decisions (And Whose Fault It Is)

Decision paralysis in senior engineers is a leadership failure. Not a talent failure, not a hiring failure — a leadership failure. And the leader responsible is almost always the CTO or VP Engineering sitting in the same room who keeps wondering why their senior people can't just make a call.

I've walked into enough engineering organisations to recognise the pattern immediately. A technically strong engineer, five or seven years of experience, strong architecture instincts — and they will not commit to a database choice without a sign-off from someone two levels above them. Or they spend three sprints "evaluating" two nearly-equivalent approaches and produce a 12-page document instead of a decision. Or they escalate every ambiguous question upward rather than resolving it with the information they have.

The cause is almost never intellectual. It's structural. It's cultural. And it's fixable — but the fix has to come from above.

What Decision Paralysis Actually Looks Like

It's worth naming the specific symptoms, because they're often misread.

Endless evaluation. The engineer collects more data, more options, more opinions — not because they lack information, but because committing to an answer feels dangerous. What's actually happening: they've learned, through experience in your organisation, that decisions get reversed, questioned, or overridden after the fact. Collecting more data is insurance against being wrong in public.

Escalation of low-stakes questions. The engineer asks their manager whether to use Postgres or MySQL for a new microservice, or whether a particular API should be REST or GraphQL. These are not hard technical questions. They're questions that require authority to answer — and the engineer doesn't believe they have it.

Decision by committee. Every architectural choice gets workshopped across five engineers until it reaches consensus or runs out of time. The stated reason is "collaboration." The real reason is that no single person believes they have the standing to make the call unilaterally, so the group absorbs the accountability. When something goes wrong, nobody is responsible.

Deferral to the highest-paid opinion. The most technically dubious idea in the room wins because it came from the person with the largest title. The senior engineers present — who often know better — said nothing, or said something once, softly, and then stopped pushing.

The Three Root Causes

These are not mutually exclusive. Most organisations I work with have all three operating simultaneously.

Root Cause 1: Authority was never granted, only implied

The job description said "senior engineer." The onboarding said "you'll own your domain." The manager said "we trust you." But nobody ever specified, concretely, which decisions this person can make unilaterally, which require consultation, and which require approval. The engineer is operating in a fog of implied authority — and experienced professionals know that implied authority evaporates the moment it becomes inconvenient.

The fix is explicit decision rights. Not a RACI chart — those are bureaucratic theatre. A simple, honest conversation: "You own the data layer for this service. That means you decide the schema, the migration strategy, and the indexing approach without checking with me. You consult me on cross-service contracts. You involve me in decisions that cost more than €20k or affect our SLA commitments." Write it down. Be specific about the boundaries.

Root Cause 2: Decisions get overridden without explanation

This is the most corrosive pattern I encounter. A senior engineer makes a decision — database choice, library selection, service boundary — and three weeks later someone with a larger title makes a different call, often without acknowledgment that a decision had already been made, and almost never with an explanation of what was wrong with the original reasoning.

The engineer learns two things: their decisions are provisional (so not worth defending), and technical reasoning is less important than organisational hierarchy (so not worth developing). Both lessons actively degrade the engineering culture you're trying to build.

If you need to reverse a technical decision made by a senior engineer, that reversal requires an explicit conversation: "Here's the decision you made. Here's what's changed or what I see differently. Here's why I think we need to go a different direction." Even if you have the authority to override unilaterally, the way you exercise that authority teaches your organisation what authority means.

Root Cause 3: The psychological cost of being wrong is too high

Good decision-making requires psychological safety. Not the corporate-wellness version of psychological safety — the operational version: do people believe that being wrong in this organisation, while exercising good judgment with available information, will not damage their reputation or career?

In many engineering organisations, the honest answer is no. Being wrong about a technical call is treated as a competence failure rather than an information failure. Engineers who made defensible decisions with the information they had get blamed when outcomes are bad. Engineers who escalated and deferred get implicitly rewarded because the accountability diffused.

This creates a rational response: optimise for not being wrong, which means not making decisions. The engineer who spent three sprints evaluating two databases is not incompetent. They're rational actors responding to the incentive structure you built.

The three root causes reinforce each other in a self-sustaining loop:

The Diagnosis You Need to Do

Before you can fix this, you need to understand what's actually driving it in your specific organisation. Three questions to answer honestly:

If you don't like the answers, the problem is yours to fix.

What Actually Works

I want to be concrete about interventions that change behaviour, not just interventions that generate policy documents.

Publish the decision log. Start maintaining a simple decision record — one paragraph per significant decision, who made it, what options were considered, what drove the choice. Publish it internally. This normalises the act of making decisions, makes the decision-making process visible and learnable, and creates a shared record that reduces second-guessing. After ninety days, look at who is and isn't contributing decisions. The absence is diagnostic.

Run a "decision audit" on your last quarter. Go through the last three months of engineering discussions, Slack threads, and meeting notes. Identify every decision that took more than two weeks to reach resolution. For each one: what was actually blocking it? Was it ambiguous authority? Missing information? Waiting for someone's approval? Categorise the blockers and fix the system, not the individual.

Deliberately confer authority and then stay out of the way. Pick one senior engineer. Pick a meaningful decision — not a trivial one. Tell them explicitly: "This one is yours. I'm not going to weigh in unless you ask me to." Then don't. Even if their instinct is different from yours. Especially if their instinct is different from yours. What you're building is evidence — for them and for the team — that authority is real and not performative.

Change how you respond to wrong decisions. The next time a senior engineer makes a call that doesn't work out, the most important thing you do is how you respond in the following week. "Walk me through the reasoning" is the right response. "Why did you think this was a good idea?" is not. One response treats the engineer as someone who made a defensible choice with incomplete information. The other treats them as someone who failed. Your team is watching.

The Uncomfortable Implication

Senior engineers who can't make decisions are expensive in ways that don't show up on the salary line. They slow delivery. They create escalation chains that consume manager time. They model indecision for more junior engineers who are learning what "senior" behaviour looks like. And they leave — because good engineers want meaningful authority, and when they realise the authority they were promised isn't real, they find an organisation where it is.

The question worth asking yourself honestly: are you building an engineering culture where decision-making is a practised, recognised, career-advancing skill? Or are you running an organisation where the safest move for any ambitious engineer is to escalate, document, and wait?

Most engineering leaders would say the former. Most engineering cultures operate like the latter.

The gap between those two things is not a training problem. It's a leadership one.

If you're working through this kind of organisational challenge — unclear authority, escalation cultures, senior engineers who aren't operating at level — let's talk. I work with engineering organisations at the structural level, not just the process level. Book a 30-minute discovery call and let's figure out what's actually driving it in your context.