Forty-five minutes. That's how long a brilliant engineer I've worked with spent presenting a comparison matrix for a backend framework. Performance benchmarks, learning curve, documentation quality, ecosystem maturity, hiring pool, long-term maintainability, etc. Color-coded. Beautifully researched. At the end, someone asked the obvious question: "so which one are we going with"?
Silence. Then, "well, it depends on how we weigh the criteria".
Nobody decided anything that day. Or the next week. Two more meetings and one sixteen-page RFC later, the project shipped two months late, which was what everyone privately suspected would happen from the start. For the record: the service handles about twenty requests per second at peak. Any of the presented frameworks would have been invisible in production.
I see too many engineers making poor decisions. And the irony is that the smartest engineers are often the ones most afraid to decide.
Intelligence makes indecision easier, not harder
Here's the uncomfortable mechanic behind it. The smarter you are, the more failure modes you can see. A junior engineer picks MySQL because it's what they know. A very senior engineer can enumerate twelve scenarios where MySQL becomes a problem, eight where the alternative does, and four where the real issue is something nobody's thought of yet.
That's a genuinely useful skill. It's also a trap, because seeing every way a decision can go wrong makes every option feel wrong. And when every option feels wrong, the most comfortable move is to not choose. Gather more data. Write another Confluence document. Schedule another review. Wait for someone else to commit first so you can critique instead of own.
Analysis feels like work. It looks like work. It produces artifacts. But a decision is the only thing that actually moves a project, and a spreadsheet comparing options is not a decision. It's a very sophisticated way of postponing one.
Indecision is a decision, and usually the worst one
The dirty secret of most technical choices is that they matter far less than the deliberation suggests. Postgres or MySQL. REST or GraphQL. Monorepo or polyrepo. In the majority of real projects, either option would have been fine, and the team would have adapted around whichever one they picked.
What's never fine is the six weeks spent not picking. That time is gone. The feature didn't ship, the customer didn't get their fix, and the team burned energy relitigating the same trade-offs in every standup. You didn't avoid the cost of a wrong decision. You paid the cost of no decision, which is quieter but almost always larger, because nothing is learned from it.
A wrong decision teaches you something within weeks. Indecision teaches you nothing, forever.
The safest move is to never commit
Here's what I think is really going on. In a lot of engineering cultures, being wrong in public is expensive and being slow is invisible. If you commit to an approach and it doesn't work, there's a name attached to the failure: yours. If the project quietly drifts for a quarter because nobody committed to anything, the failure has no name. It belongs to everyone, which means it belongs to no one.
Smart engineers learn this game fast. They've usually built their identity on being the person who's right. So they play it safe. They wrap everything in maybes. They "raise concerns" instead of making calls. They become world-class at explaining why every option is risky, which coincidentally is a position from which you can never be blamed.
It makes sense to act this way when the rules reward it. But it quietly holds your career back, because the engineers who actually grow into leadership roles are not the ones with the best comparison matrices. They're the ones who made calls, including the wrong ones, which they owned and fixed.
Most decisions are written in pencil, not ink
Some decisions are written in ink: hard to undo, and you'll live with them for years. Choosing your core language, taking on a major vendor lock-in, a public API contract. Those deserve real deliberation.
Almost everything else is written in pencil. You can erase it. Picked the wrong library? Swap it. A well-structured Express app migrates to Fastify in a sprint, and by then you actually know your requirements, so you're migrating with real data instead of guesses. The mistake I see constantly is treating pencil decisions with ink-level ceremony: weeks of RFCs and stakeholder reviews for choices that could be reversed in a sprint.
The skill isn't avoiding wrong decisions. It's correctly sorting decisions by reversibility and spending your caution budget only on the irreversible ones.
What nobody says out loud
I'll close with the thing that's uncomfortable to admit. The fear of deciding usually isn't about the project at all. It's about protecting the story we tell about ourselves: that we're the smart one, the careful one, the one who doesn't make mistakes. Every deferred decision keeps that story intact for another week.
But nobody remembers the engineer who was never wrong because they never committed to anything. The ones worth working with are the ones who look at incomplete information, make the best call available, put their name on it, and fix it fast when reality disagrees.
Being smart gets you a seat at the table. Deciding is what you're actually there for.
