👋 Hey {{first_name|there}},
Your team applies the same scrutiny to every technical decision. Here's the triage that tells you which ones actually need a review and which ones just need a green light.
Why this matters / where it hurts
Someone opens a pull request to swap an internal HTTP client library. Reasonable change. Low blast radius. But the team treats it like a database migration, scheduling two meetings, drafting a design doc, circling through three rounds of async comments. Two weeks pass. The feature work stalls. And the library swap that could have shipped on a Tuesday afternoon is still sitting in draft.
Now picture the opposite. Someone picks a new message broker for a critical payment flow during a Friday standup. No doc. No review. Just a confident "I'll set it up." Six months later, three teams are coupled to a broker nobody fully understands, and switching away would burn a quarter.
These look like different problems. They're not. Both happen because the team applies one level of scrutiny to every decision, or none at all. Library swaps get the same ceremony as schema changes, and someone will call a meeting to debate folder structure as if it were a public API contract. In Lesson #40 on ADRs, we covered how to make decisions findable. This week is about what comes first: figuring out which decisions deserve the ceremony.
🧭 The shift
From: "Every architecture decision needs thorough review."
To: "Match the rigor to the reversal cost."
The framing comes from Jeff Bezos. A one-way door is a decision that locks behind you. Expensive to undo, painful to reverse, and sometimes flat-out impossible. A two-way door is the opposite. You walk through, look around, and if you don't like what you see, you walk right back out. The cost is low. The damage is minimal.
Here's the thing most teams get wrong. The vast majority of their decisions are two-way doors. Perhaps 70 or 80 percent of the choices made in a quarter fall into this bucket, yet teams default to a heavyweight ceremony for all of them because treating everything as critical feels responsible. It isn't. It's slow. And slow, applied uniformly, is its own kind of risk.
Default to action on two-way doors. Ship it, measure it, reverse if needed.
Reserve heavyweight review for one-way doors only. These are the choices that create lock-in, touch external consumers, or reshape data you can't easily reconstruct.
When in doubt, ask one question: "What would it cost us to undo this in 30 days?" A couple of days of work? Two-way door. Move.
🧰 Tool of the week: Decision Door Triage Card
Decision Door Triage Card: classify any technical decision in under 15 minutes.
Decision summary. One sentence. What are we choosing, and why now?
Reversal cost. How many engineer-days to undo this in 30 days? Under 3 days = two-way door. Over 3 = one-way.
Blast radius. Who is affected? Internal team only = lower risk. Other teams or external users = higher risk.
Data impact. Does this change how data is stored, shaped, or consumed? If yes, lean toward one-way.
Contract exposure. Does this touch a public API, event schema, or SLA? If yes, treat as one-way until proven otherwise.
Dependency lock-in. Would switching away require migrating state, retraining people, or renegotiating vendor terms? Score: none / moderate / high.
Decision path. Two-way door → team lead approves, ship within the sprint. One-way door → short design doc + review before committing.
Timebox. Two-way doors get 48 hours. One-way doors get 1 week with a scheduled review.
Rollback sketch (one-way only). Write 2–3 sentences describing what rollback would look like. If you can't describe it, that confirms the classification.
Owner and check-in. Name one person accountable. For one-way doors, schedule a 90-day review to validate the choice.
🔍 In practice: The message broker debate
Scenario: A team needs async notifications for a new feature. Everything is synchronous REST today. Two options: use the existing RabbitMQ cluster, or adopt Kafka because "we'll need it eventually."
Scope: Notification subsystem only, but three consuming services across two teams.
Context: Six-person team. Tight sprint. No one has production experience running Kafka.
Decision summary: Choose a message broker for cross-team notification delivery.
Reversal cost: Switching brokers after six months of producers and consumers = 3–6 weeks. Well above the 3-day line.
Blast radius: Cross-team. Three services rely on the message schema.
Data impact: Yes. Those schemas become a contract the moment consumers start parsing them.
Dependency lock-in: High. Client libraries, monitoring, alerting, and runbooks all couple to the broker.
Classification: One-way door. This gets a design doc and a 30-minute review.
The tradeoff we accepted: We didn't evaluate a third option, managed SQS, because the timebox forced a binary choice. Probably fine. But I think about it sometimes.
Result: The team committed to RabbitMQ within one week. No month-long debate. The reasoning lives in ADR-0052, and the 90-day check-in confirmed the choice held up.
✅ Do this / ❌ Avoid this
Do this:
Run the triage card on any decision that triggers a meeting invite. If it comes back two-way, cancel the meeting and ship.
Keep two-way door approvals light. A Slack thread or a PR comment is enough.
Revisit one-way door decisions at the 90-day mark. Conditions shift, and what felt permanent in Q1 might become reversible by Q3.
Pin the triage card somewhere visible in your team's decision channel so people reach for it before they escalate.
Avoid this:
Treating "we've always reviewed library choices" as justification. Challenge inherited ceremony.
Using "two-way door" as a license to skip thinking. You still need a reason for the choice. You just don't need a committee.
Letting seniority override the framework. A staff engineer's gut feeling doesn't turn a two-way door into a one-way door.
Spending more time classifying a decision than making it. If triage runs past 15 minutes, default to one-way and move forward.
🎯 This week's move
Copy the Decision Door Triage Card into your team's shared docs or wiki.
Walk your team through it at the next standup or retro using a real example from last quarter.
Pick one pending decision and run it through the card live. Let the team feel how fast classification goes when there's a framework instead of a debate.
Agree on approval paths: two-way doors get team-lead sign-off in 48 hours, one-way doors get a design doc and a scheduled review.
By the end of this week, aim to: have the triage card adopted and one real decision classified using it.
👋 Wrapping up
Not every decision deserves a design doc. Most deserve a bias for action.
The real question is never "is this important?" It's "what would it cost to reverse?"
Match the ceremony to the stakes. You'll ship faster, and the things that actually matter will get the scrutiny they need.
Know a developer stuck in review-committee purgatory? Forward this issue to them. That's how this community grows.
⭐ Good place to start
I just organized all 40 lessons into four learning paths. If you've missed any or want to send a colleague a structured starting point, here's the page.
Thanks for reading.
See you next week,
Bogdan Colța
Tech Architect Insights