The Decision You Didn't Make

Most failed projects were not decided badly. They were never decided at all.

Somebody raised the question in a thread. Two people replied with opinions. A third said they'd look into it. The thread scrolled away, the sprint started, and the codebase quietly picked an answer on everyone's behalf. Six months later there is a migration nobody has budget for and a meeting where four people take turns saying they thought someone else owned it.

TL;DR

Most project damage does not come from a decision made badly, it comes from a decision that was raised, discussed, and never actually closed, so the calendar or the codebase closed it by default.

• The unmade decision is a choice that got default-resolved by inaction, not deliberation, and it is invisible until it is expensive.
• Unlike a bad decision, an unmade one cannot be reviewed or reversed, because nobody agreed it happened.
• Rework from unsettled requirements and decisions eats an estimated 30 to 50 percent of development effort industry-wide.
• The fix is not a governance program. It is a habit: every open question gets an owner and a date, in writing, before the thread scrolls away.
• Silence in a decision thread is not agreement. Treat it as a red flag, not a green light.

The thread looks like progress. Three people engaged with the question. None of them closed it, so the deadline did.

Decisions Don't Fail, They Go Missing

Engineering culture is well equipped to talk about bad decisions. We have postmortems for outages, retros for missed estimates, and a whole vocabulary for decisions that were made and turned out wrong: the framework that didn't scale, the vendor that got acquired, the schema that didn't survive contact with real data. A bad decision is a known shape. Someone can point at it, ask who made it and why, and change course.

An unmade decision has no shape at all, which is exactly what makes it dangerous. Nobody chose the microservice boundary, the retry policy, or the ownership of the shared table. Somebody typed an option into a channel, got a thumbs-up from one person, and the option became the plan because nobody said no before the branch was merged. Three months later there is no decision to audit, because there was never a moment anyone can honestly call the team deciding anything. There is only a default that accreted, one unanswered message at a time.

This is the pattern I call the unmade decision: a choice that was visibly raised and never visibly closed, so it got resolved by whichever force moves fastest, usually the calendar or the first line of code that happened to get written. It is not a decision anyone can be held accountable for, because accountability requires a moment of choosing, and there wasn't one.

What Does an Unmade Decision Look Like in Practice?

The shape repeats with almost boring consistency. It usually starts in a channel, and it usually looks like this.

A migration gets proposed in a design doc. The doc has a section titled "open questions," and one of the open questions is which team owns the cutover. Nobody edits that section again. The doc gets approved anyway, because the parts everyone cared about are settled and the ownership line reads like an administrative detail someone will sort out later. Later arrives during the actual cutover, when two teams each believed the other one was watching the dashboards.

Or: an API gets a new field added under time pressure, with a comment that says "we should decide the validation rules for this properly," and a ticket gets filed. The ticket sits in a backlog no one grooms, because the API works without the validation, right up until a client starts sending malformed data that both teams assumed the other side would reject. Nobody decided the validation rules would be skipped. The backlog decided, by being a place where decisions go to die quietly instead of a place where they get tracked to closure.

What makes this pattern hard to catch in the moment is that every individual step looks like reasonable behavior. Raising the question was right. Replying with an opinion was right. Filing a ticket instead of blocking the merge was often the correct call under the actual time pressure that existed.

The failure isn't in any single step, it's in the absence of a step: nobody ever said, out loud, "we are deciding this now, here is the answer, here is who owns it."

Why Is an Unmade Decision Worse Than a Bad Call?

A bad decision is expensive but bounded. Someone made a specific choice for a specific reason, the reason is written down somewhere, and when it stops working, the team can look at the reasoning, see what changed, and make a new choice. The cost is the cost of being wrong once.

An unmade decision has no such ceiling, because it never got fixed in the first place. It keeps being re-decided, silently, by whoever touches the adjacent code next, and each of those people makes a slightly different assumption about what was "already decided." Industry estimates put the share of development effort lost to rework, most of it traceable to requirements and decisions that were never actually settled, at somewhere between 30 and 50 percent. That is not the cost of one wrong call. That is the cost of an organization continuously re-litigating the same unresolved question in a dozen different places, none of which know about the other eleven.

There is also a defect-cost curve every engineer has seen in some form: a problem caught at design time costs roughly one unit to fix, the same problem caught during implementation costs several times that, and the same problem caught after release costs dramatically more again. An unmade decision is, structurally, a design-time problem nobody catches at design time, because nobody agreed it was a decision that needed catching. It gets caught instead at the most expensive point available: production, during an incident, in front of the people with the least context and the most pressure to move fast.

This is also why unmade decisions are so hard to argue about later. The same translation problem shows up when a project cannot defend its own numbers: once a cost has no owner and no recorded reasoning, it stops being a decision anyone can debate and becomes a fact of the system nobody can explain.

None of this requires anyone to have been careless. It requires only that the team's default behavior toward an open question was silence, and silence compounds.

How Do You Stop Unmade Decisions This Week?

The fix is not a decision-making framework, a new meeting, or a governance committee. Those solve for a different failure mode, the bad decision made in the wrong forum. The unmade decision needs something much smaller: a rule that an open question is not allowed to remain unowned.

In practice, that means three things, and none of them take more than a few minutes to apply.

First, treat "open question" as a status, not a footnote. If a design doc, ticket, or thread contains an unresolved item, it gets a name, an owner, and a date, written down in the same place as the rest of the decision. If no one will own it by a specific date, that is itself information worth surfacing, not a detail to bury in a comment.

Second, distinguish silence from agreement. A thread where three people replied and nobody objected is not a decision, it's an unmoderated conversation that happens to look like consensus. Before treating it as settled, someone has to say the words: "this is what we're doing," and someone has to be named as having said them.

Third, when a decision is genuinely still open at the point work has to start, say so out loud, and pick a default deliberately rather than letting one get picked by accident. A team that consciously says "we don't know yet, so we're going with the simplest reversible option until we do" has made a decision. A team that just starts building has not, even if the code looks identical either way.

None of this is process for its own sake. It is the difference between a choice a team can point to, defend, and change, and a default nobody agreed to that quietly becomes load-bearing.

The Punchline

Somebody will eventually ask, in a retro or a postmortem, "who decided this?" and the honest answer, most of the time, is nobody. That answer should be uncomfortable. A team that can't name who decided something can't review it, can't defend it to a stakeholder, and can't learn from it when it goes wrong, because there was never a decision there to begin with, only a silence that outlasted the deadline.

Coming Up in This Series

The next part stays inside the room where decisions like this get made, or don't: the architecture review. It turns out the review board is not really evaluating the best technical argument, it's evaluating the best-defended one, and the risk that actually ships is usually the one raised by the person with the least social capital to push back on the room.

---

If this resonated and you're the person who ends up responsible for whether things actually ship, follow along. The series covers the 12 things I think separate projects that land from projects that stall: how decisions get made, how work gets delegated, how technical risk gets translated into business language, and what to check in your first month on a project you didn't start.