The Blast Radius of a Technical Decision
The decisions that get six weeks of review are rarely the ones that bind an organization for years: measuring a choice by who it binds, for how long, and what undoing it costs, and matching review effort to that reach instead of to how big the decision looks.
Two decisions from a few years ago. The first was the framework for a new service: six weeks of debate, a comparison document, and a comment thread longer than the document. The second was a field in an event payload, added in a routine pull request and approved without discussion, because nobody in the review thought of it as a decision. The framework was replaced eighteen months later in a quiet two-sprint effort that nobody outside the team noticed. The field outlived my time at the company: when I left, four services parsed it, two of them with regexes, and changing it meant coordinating all four plus a backfill of two years of stored events. For all I know it is still there, binding people I never met.
The review effort tracked how big each decision looked. It should have tracked how far each one reached. I call that reach the decision’s blast radius: who does this bind, for how long, and what does it cost to undo. Most of what I do differently now, compared to when I was a senior engineer making locally correct calls, is ask those three questions before deciding how much attention a choice gets.
Measuring a radius
The three questions have concrete answers if you go looking for them.
Who does it bind is not who is in the room; it is who will read the data, call the interface, or copy the code. The event field bound every future consumer of that topic, and consumers of a topic only accumulate. The framework bound one team, because every other team touched the service through its API and could not have told you what it was written in.
For how long means: when does changing this stop being cheap? An implementation detail is changeable until the next deploy, so its window never really closes. A stored data shape is changeable until the second reader ships, and after that the window is gone whether you noticed it closing or not. A contract customers build on closes the moment they build, which is usually before you find out they did.
What does undoing cost is the most useful of the three because it can be ranked. An edit. A deploy. A negotiation with another team. A migration with a backfill. A breaking change to paying customers. Each step is roughly an order of magnitude more expensive than the one before, and a decision’s true weight is which rung it lands on, not how long the meeting about it was.
Why the big-looking decisions are often the small ones
The framework debate looked big because the choice was expensive to make: lots of options, strong opinions, real differences. But expense at decision time says nothing about expense later. What sets the radius is the propagation mechanism. Data propagates by being read, and every reader hardens the shape. Interfaces propagate by being called, and every caller turns your edit into their negotiation. Examples propagate by being copied, and the first service in a new repo is a template whether it wants to be or not. Defaults propagate by being inherited: the timeout in the shared HTTP client, the retry policy in the service scaffold, the nullable column nobody argued about. I once traced a production incident to a one-line default that had outlived three reorgs and the person who set it; nobody in the postmortem knew it was a decision at all.
The framework had none of these mechanisms working against it. It sat behind a service boundary, so nothing outside the team read it, called it, copied it, or inherited it. The event field had all four. I expect that pattern now: the choices that cross boundaries are usually small enough to make in passing, and the choices big enough to earn a debate are usually the ones we have already learned to put behind boundaries.
Buying back reversibility
Radius is not fixed; you can spend design effort to shrink it. Every move is a version of the same one: put indirection between the decision and the people it would otherwise bind. An interface in front of an implementation keeps the implementation on the cheap end of the undo ladder. A version on a data format lets a new shape coexist with the old while readers migrate (expand-contract, applied one level up). A feature flag turns a rollback from a deploy into a toggle. Had that event field gone out inside a versioned envelope, changing it would have been an addition instead of a negotiation with every consumer.
Indirection is not free (a layer to maintain, one more concept for every reader), so the spend has to match the radius. Wrapping a private helper in an interface because something might change is the same miscalibration as shipping an unversioned public payload, pointed the other way.
Spending the review where the radius is
What I changed about my own process runs in both directions. Decisions on the expensive end of the undo ladder (a data model the product will sit on, an API customers build against, a security boundary) get the slow treatment: written up, reviewed by the people who will inherit them, decided once. These are the one-way doors, and there are far fewer of them than the meeting calendar suggests. Everything else gets decided quickly by whoever is closest to it, because reviewing a two-way door as if it were a one-way door is pure cost without an obvious return, and an organization that is deliberate about everything teaches people to work around the deliberation.
What sends a change into that written review is how it propagates even when the diff is one line. A choice that sits behind a well-defined boundary gets a timebox even when opinions run hot. One line of schema can bind more people for longer than a thousand lines of implementation, and the size of the diff will never tell you which one you are looking at.
The forecast problem
Two caveats from living with this. The widest-radius decisions are often the ones nobody makes: decline to pick a standard and the standard becomes whatever each team did first, a choice with maximal reach and no owner. Part of the job is noticing those and dragging them into the open before drift settles them.
And the radius is always a forecast. I have called something a harmless two-way door and learned years later how many things had quietly come to depend on it; the consumers you bind are the ones who show up after you stop watching. The calibration never gets perfect. The difference is asking the three questions at all, because the field in that event payload would have failed every one of them, and any reviewer who asked would have caught it in the same pull request that waved it through.