# The challenge of not making a decision 2026-02-14 · 5 min read · #tech · #career Source: https://jopcmelo.com/articles/the-challenge-of-not-making-a-decision The worst decision you can make is no decision at all. I've seen this pattern kill momentum at startups more than bad architecture, more than technical debt, more than any single engineering mistake. The slow poison of "let's think about this more" and "we need more data" and "let's revisit this next week." From an engineering perspective, indecision is expensive. Here's why. ## The hidden cost of "pending" When a decision isn't made, work fragments. Picture this: your team needs to decide between two API designs. Instead of picking one, leadership says "let's get more input." What happens next? - Engineers start building around the uncertainty, creating abstractions "just in case" - Some team members assume Option A, others assume Option B - The PR sits open, context slowly evaporating from everyone's minds - Three weeks later, you revisit the decision with less context than before The "cost" of the decision was never the choice itself. It was the limbo. ## Momentum is everything at a startup Startups don't die from making wrong decisions. They die from making no decisions. When you're small, speed is your only advantage. Big companies have more engineers, more money, more brand recognition. What they don't have is the ability to move fast. Every decision goes through layers of approval, committees, legal review. As a startup, you can ship in a day what takes them a quarter. But only if you actually decide to ship. I've watched teams spend weeks debating whether to use PostgreSQL or MySQL, while a competitor shipped the entire feature on SQLite and captured the market. The "right" database didn't matter. The shipped product did. ## Tempo beats speed Making one fast decision is easy. Making fast decisions consistently, across your entire organization, over years? That's the real moat. Steve Blank calls this [*tempo*](https://steveblank.com/2009/04/10/good-enough-decision-making/) — the ability to make quick decisions consistently over extended periods of time. Not just for the CEO, but for the entire company. Speed is a moment. Tempo is a culture. Here's the math that matters: by the time a big company gets the committee to organize the subcommittee to pick a meeting date, your startup could have made 20 decisions, reversed five of them, and implemented the fifteen that worked. ## The engineering morale problem Here's something that doesn't show up in sprint metrics: engineers hate limbo. We're problem solvers. We want to build, ship, iterate. When decisions hang in the air, it's demoralizing. The best engineers I've worked with share one trait: they'd rather have a clear wrong direction than no direction. Because a wrong direction can be corrected. No direction just... drifts. When your team keeps hitting "waiting for decision" blockers, they stop proposing bold ideas. Why bother? It'll just end up in committee purgatory. ## Reversible vs. irreversible Jeff Bezos has this framework of Type 1 and Type 2 decisions. Type 1 decisions are irreversible — walk through the door and you can't come back. Type 2 decisions are reversible — you can always change your mind. The problem? Most teams treat every decision like it's Type 1. Should we use React or Vue? Type 2 — you can migrate if needed. REST or GraphQL? Type 2 — you can version your API. Microservices or monolith? Type 2 — you can split or merge later. Most technical decisions are reversible. The cost of reversing is almost always lower than the cost of not deciding. Bezos frames this as the difference between [*Day 1 and Day 2*](https://medium.com/seek-blog/building-an-organization-with-high-decision-velocity-db9a29fde474) companies. Day 2 companies make high-quality decisions, but slowly. Day 1 companies make high-quality, high-velocity decisions. Slow decision-making isn't just inefficient. It's a symptom of becoming a Day 2 company — and Day 2 is the beginning of irrelevance. ## The 70% rule Here's a heuristic I've adopted: if you have 70% of the information you need, make the decision. Waiting for 90% certainty means you're probably too late. The market moved. The context changed. Your competitor shipped. The remaining 30%? You'll learn it faster by doing than by analyzing. Ship the feature. See how users react. Iterate. ## What good decision-making looks like The best engineering teams I've been part of share these traits: - **Time-boxed discussions.** "We'll decide by Friday" is infinitely better than "let's keep discussing." - **Clear decision owners.** Someone has the final call. Not a committee. A person. - **Bias toward action.** When in doubt, ship something and learn. - **Disagree and commit.** Once decided, everyone rows in the same direction — even if they disagreed. - **Blameless reversals.** If a decision was wrong, change it without drama. No "I told you so." ## Ship or sink Indecision feels safe. It's not. Our brains are wired with [status quo bias](https://medium.com/seek-blog/building-an-organization-with-high-decision-velocity-db9a29fde474): we see more risk in action than inaction. "Let's gather more input" feels responsible because your instincts tell you waiting is safer. But in a startup, waiting IS the action. You're actively choosing not to move while the market moves around you. Every day you don't decide is a day your competitor might. Every week in limbo is a week your engineers spend working around uncertainty instead of building real value. The challenge of not making a decision isn't that you might be wrong. It's that you're definitely standing still. And in a startup, standing still is the same as moving backward.