Someone Has To Own The Decision

When a technical discussion keeps circling the same two options without landing on either, the problem is almost never that people need more information. It is that nobody has been told, or has claimed, that the decision is theirs to make. Everyone is debating. Nobody is deciding. Those are different activities, and a team can do a great deal of the first without producing any of the second.

I watched this play out again this week on a small piece of work: a service that could reasonably be shipped two ways. It could run as a native background process on the machine it lives next to, which suits teams who already know how to operate that kind of service and integrates cleanly with the tooling they already trust. Or it could ship as a portable container, which trades that tight integration for consistency across every environment it might end up running in. Both are defensible. Both were argued well, by people who understood the trade-off completely after the first exchange. And the thread stayed open for days anyway, with new comments occasionally restating a version of the same two paragraphs already written above them.

That is the tell. When the second and third rounds of a discussion add no new facts, the discussion has stopped being about information and started being about permission. Everyone involved is waiting for someone else to say the sentence that actually ends it — "we're doing the container" or "we're doing the service" — and nobody has been assigned that sentence as their job. Committees are very good at surfacing a trade-off. They are structurally bad at closing one, because closing a trade-off means overruling half the room, and nobody wants to be the person who did that without a mandate to.

I see the same shape well outside architecture reviews. Product teams debate whether to ship the smaller version now or hold for the fuller one, with both cases well made, until the launch date arrives and the decision gets made by default rather than by anyone choosing it. Hiring panels split evenly on a candidate and let the split stand in for a decision, when a split is not a decision, it is the absence of one. Even rostering and small operational choices fall into the same pattern once enough reasonable people are looped in: more voices make the case for each option sharper, not the choice between them clearer. Volume of discussion and quality of a decision are almost unrelated once the facts are already on the table.

Part of why this happens is that deciding feels riskier than discussing, even when it demonstrably is not. A comment that lays out a trade-off can be right forever, because it never commits to anything that can later be shown wrong. A decision can be revisited and criticised. So in any group without an explicit owner, the incentives quietly favour endless analysis over a call, because analysis is safe and a call is exposed. That is not laziness or bad faith. It is a completely rational response to an unclear reward structure, and I do not think you fix it by asking people to be braver. You fix it by making the exposure someone's actual job rather than a personal risk they have to volunteer for.

The practical version of that is naming an owner before the debate starts, not after it stalls. Not a committee, one person, whose role in the conversation is explicitly to listen to the trade-off and then end it. Everyone else's job shifts from "argue for my preferred option" to "make sure the owner has what they need to choose well," which is a much less adversarial position to be in and tends to produce better information as a side effect, because people stop defending a position and start actually describing the trade-off. It also matters whether the decision is reversible. A choice you can unwind next sprint deserves a fast, cheap call from whoever owns it, because the cost of being wrong is small and the cost of drift is not. A choice that is expensive to reverse deserves the same named owner, just with a higher bar for the input they gather before they use their authority to close it. What it never deserves is an open thread with no name attached, because that is the one structure guaranteed to convert either kind of decision into weeks of restated trade-offs.

The cost of getting this wrong is not just the calendar time, though that is real — a decision that should take an hour of thought stretching into a week of intermittent thread refreshes is a week nobody gets back. The larger cost is what it teaches people about how the team works. When a thread sits open long enough with no resolution, contributors learn one of two lessons, and neither is good. Either they learn to escalate small trade-offs further up the chain than they need to, because the group clearly will not close them, which slows everything down and centralises decisions that never needed to be centralised. Or they learn to quietly proceed with their own default and let the thread die unresolved, which is how you end up with two implementations of the same idea living in different corners of a codebase, each built by someone who correctly concluded that waiting for an answer was the losing strategy.

The habit worth building is a small one. The moment you notice a discussion restating a trade-off it already stated clearly the first time, stop adding to it and ask the plainer question instead: whose call is this. Not as a complaint, just as the missing piece of the process. Most of the time the honest answer is that it is nobody's call yet, which is fixable in a sentence. It is a far cheaper fix than the week of drift that follows from leaving the question unasked.