Your Engineering Team Doesn't Have a Velocity Problem - It Has a Decision Problem
Most teams blame slow shipping on technical debt, process overhead, or not enough engineers. The real bottleneck? Decisions that take weeks when they should take hours. Here's how to fix it.
Your sprint velocity is dropping. Features are slipping. The backlog is growing faster than the team can burn it down. The obvious conclusion: we need more engineers. Or better tooling. Or fewer meetings.
Wrong diagnosis. In most teams we’ve worked with, the engineers aren’t slow. The decisions are.
A developer finishes the core logic in two days. Then spends a week waiting for someone to decide whether the feature should use modal dialogs or inline editing. Another three days blocked because nobody has confirmed the API contract with the partner team. Two more days because the design review keeps getting rescheduled.
The code took two days. The decisions took two weeks. But the retro will blame “technical complexity.”
The decision bottleneck is invisible
Here’s why this problem is so persistent: nobody tracks decision latency. Teams track cycle time, PR review time, deployment frequency. But the gap between “I need an answer” and “I got an answer” lives in Slack threads, email chains, and the dead air between meetings.
It’s invisible in your metrics. It shows up as “in progress” on the board for three weeks, and everyone assumes the work is hard. Sometimes it is. But more often, someone is waiting for someone else to make a call.
The usual suspects
Decisions that need “alignment.” This is the corporate word for “nobody wants to be wrong alone.” A choice that one senior engineer could make in ten minutes gets routed through three stakeholders, a design review, and a product sync. By the time everyone’s aligned, two weeks have passed and the developer has context-switched to something else.
Reversible decisions treated as irreversible. Jeff Bezos called these Type 1 vs Type 2 decisions, and most teams get the classification catastrophically wrong. Choosing a database engine for your core product? That’s hard to reverse - take your time. Choosing the copy for an error message? Just pick something and ship it. You can change it in five minutes.
The HiPPO effect. The Highest Paid Person’s Opinion becomes the de facto decision-making mechanism. Engineers learn to stop making choices because the VP will override them anyway. So they wait. And wait. And the VP is in back-to-back meetings until Thursday.
Missing decision owners. “The team” is responsible. Which means nobody is responsible. A question gets asked in a channel, three people give partial answers, nobody commits, and the developer picks the safest option (which is usually doing nothing until someone tells them explicitly).
What fast teams do differently
They assign decision owners, not just task owners
Every project should have a clear answer to: “Who can make binding decisions about X?” Not “who should be consulted.” Not “who has opinions.” Who can say “we’re doing it this way” and have that stick?
At IndieStudio, we push clients to name a decision owner for every workstream. Not a committee. A person. That person can consult whoever they want, but the team knows exactly who to go to. The difference is immediate - blockers that used to sit for days get resolved in hours.
They set decision deadlines, not just delivery deadlines
If a design decision needs to be made for the feature to proceed, that decision gets a deadline on the board just like the feature does. “API contract finalised by Wednesday” is as concrete as “endpoint implemented by Friday.” If the decision deadline slips, it’s visible. It gets discussed in standup. Someone is accountable.
They default to reversible
Unless someone can articulate why a decision is hard to undo, the default assumption is: pick something, ship it, learn from it. This isn’t “move fast and break things” recklessness. It’s recognising that most choices in software have low reversal costs and high delay costs. The information you gain from shipping is almost always more valuable than the information you gain from another week of deliberation.
They push decisions down
The person closest to the problem makes the call. Senior leadership defines constraints and goals - “the page should load in under two seconds” or “we need to support offline mode.” Within those constraints, the implementing team decides how. No escalation required. No approval chain.
This requires trust. And trust requires a culture where making a wrong call and course-correcting is valued more than making no call and waiting for permission.
The math that should scare you
Take a team of six engineers, each costing the company roughly $150K per year loaded. That’s about $75 per engineer per hour. If each engineer loses five hours per week to decision-related blocking - waiting for approvals, sitting in alignment meetings, re-doing work because a late decision changed requirements - that’s $117,000 per year in pure waste. For one team.
And that’s the conservative estimate. It doesn’t account for the context-switching cost when an engineer picks up a different task while blocked, then has to mentally reload the original problem when the decision finally arrives. Research consistently shows context switches cost 15-25 minutes of productive time each. A developer who gets blocked twice a day and switches tasks each time loses nearly an hour just to mental overhead.
How to diagnose this in your team
Track one thing for two weeks: every time an engineer is blocked, note what they’re blocked on. Not the technical blocker - the decision behind it. You’ll start to see patterns fast.
Common findings:
- 80% of blocks trace back to three or four decision points that could have been resolved before the sprint started.
- Design decisions are the slowest to resolve. Not because designers are slow, but because “design review” becomes an open-ended conversation with no clear endpoint.
- Cross-team dependencies are decision proxies. “Waiting on the platform team” usually means “waiting for someone on the platform team to decide whether they’ll support our use case.”
Once you see the patterns, the fixes write themselves. Pre-decide what you can before the sprint. Put time limits on design discussions. Create explicit interfaces between teams with named owners on each side.
The uncomfortable truth
Slow engineering teams are rarely an engineering problem. They’re a leadership problem. The engineers know what to build. They’re waiting for someone to tell them it’s okay to build it.
If your team is shipping slowly, don’t reach for more process, more engineers, or more tools. Look at where the decisions are stuck. Fix the decision flow, and the code will follow.