One-Way Doors vs Two-Way Doors: A Heuristic for How Much Analysis a Decision Deserves

TL;DR: Not every decision deserves the same amount of debate. Some choices are easy to undo if you’re wrong, and some are almost impossible to take back. Sorting a decision into one of those two buckets before you argue about it tells you how much process it actually needs — and stops teams from spending three weeks on a button label while rushing the one choice they’ll be stuck with for years.

Picture a mid-size product team called Northwind. They’re building a new refunds service for their payments app. In the same week, two decisions land on the table.

The first: what should the JSON field be called that tells the client whether a refund succeeded? status or refund_status? This kicks off a Slack thread with forty replies, a shared doc, and a 45-minute meeting with six people in it.

The second: which database should store the refund records? Someone suggests a NoSQL store because “it’s what we used on the last project.” Nobody pushes back much. The team picks it in the last ten minutes of an unrelated planning meeting and moves on.

A year later, the field name is trivial to change with a find-and-replace and a deprecation notice. The database, on the other hand, has become the thing every other service now depends on, and migrating off it would take a quarter of dedicated engineering time. Northwind spent their debate budget on the wrong decision.

This happens more often than teams like to admit. The fix is a simple heuristic borrowed from how some experienced operators think about decision-making: sort every decision into “one-way door” or “two-way door” before you decide how much process to wrap around it.

What makes a decision a one-way door

A one-way door is a decision that’s expensive or slow to reverse once you’ve walked through it. Once you’re on the other side, going back means real cost: rewritten code, migrated data, retrained users, or a public commitment you can’t quietly withdraw.

Choosing your primary database is usually a one-way door. So is picking your cloud provider, designing your public API’s authentication model, or setting a data retention policy that regulators will hold you to. These decisions tend to spread. Other systems get built assuming they’re true, which is exactly what makes them expensive to unwind later.

A two-way door is the opposite: cheap and fast to reverse. If you get it wrong, you notice, you fix it, and the cost of that mistake is small. Renaming a JSON field before it has real external consumers, choosing a default page size for a list endpoint, or picking which logging library to use inside one internal service — these are all two-way doors. You can walk back through and try again.

The key thing the heuristic points out: the amount of debate a decision deserves should scale with how hard it is to reverse, not with how loud or confident the people arguing about it happen to be.

Why teams get this backwards

Two-way doors often feel like they deserve more debate than they do, because they’re the decisions everyone has an opinion about. Naming things, code style, which of two equally fine libraries to use — these are visible, easy to have a view on, and safe to argue about because nobody’s job is at risk if the group is wrong. So arguments about them expand to fill the time available.

One-way doors often get less scrutiny than they deserve for the opposite reason: they’re frequently technical, unglamorous, or made early — before anyone has enough information to argue confidently. Database choice, message queue choice, and core data model decisions often get made in the first two weeks of a project, by whoever happens to be in the room, before the team has enough shared context to push back effectively.

There’s also a social dynamic at play. Disagreeing loudly about a reversible decision costs you nothing. Disagreeing about an irreversible one — especially one a senior engineer already leans toward — can feel like picking a fight. So the decisions that most need scrutiny sometimes get the least of it, precisely because scrutiny feels riskier there.

A simple test to sort decisions before you argue about them

Before a decision gets a meeting, a doc, or a debate, ask one question: if this turns out to be wrong in six months, what does undoing it cost us?

If the honest answer is “we change a config value and redeploy,” treat it as a two-way door. Let one person make the call, timebox any discussion to fifteen minutes, and move on. If it’s wrong, you’ll find out cheaply and fix it.

If the honest answer involves a migration plan, a deprecation window, contacting external partners, or work measured in weeks rather than hours, treat it as a one-way door. That’s where the meeting, the written proposal, the second opinion from someone who’s been burned by this kind of choice before, and the explicit sign-off all earn their cost.

Where a decision lands on this chart tells you how much process to apply — not how strongly people feel about it.

Notice what this test does not ask: it doesn’t ask how technically interesting the decision is, how senior the person proposing it is, or how confident anyone sounds. It asks one narrow, practical question, and that question is usually answerable in under a minute — which is itself useful, because a decision nobody can quickly classify is often more consequential than it first appears.

Back to Northwind

Run the test on Northwind’s two decisions and the mismatch becomes obvious. The field name: if it’s wrong, they rename it, ship a new API version or a short-lived alias, and move on within a day. Cheap. Two-way door. It didn’t deserve forty Slack replies.

The database: once three other services read from it, once dashboards are built against its query patterns, and once a year of production data lives in its specific format, walking it back means a migration project with its own budget and risk. Expensive. One-way door. It deserved more than the last ten minutes of an unrelated meeting.

Here’s the part that actually changes how a team works: once Northwind adopted this heuristic, they didn’t spend less time on decisions overall — they spent the same total time, redistributed. Two-way doors got a fast, single-owner call. One-way doors got a short written proposal, a day for anyone to raise concerns, and a named decision-maker who owned the call once the window closed.

Same total debate budget, spent where the cost of being wrong actually lives.

The takeaway

Most teams don’t have a shortage of diligence. They have a misallocation of it. The fifteen-person thread about naming a field and the ten-minute nod toward a database choice usually aren’t a sign that anyone is lazy or careless — they’re a sign that nobody paused to ask which decision could actually hurt them later.

Before your next architecture debate starts, ask the one question that sorts it: how expensive is it to undo? Let that answer — not who’s in the room or how strongly they feel — decide how much process the decision gets. Your reversible decisions will move faster, and your irreversible ones will finally get the scrutiny they were always going to need eventually, just on your terms instead of an outage’s.