Not all decisions carry equal risk, and treating them all the same creates unnecessary bottlenecks.
The Three-Question Framework
Before making any technical decision, ask:
-
What’s the impact if we’re wrong? Consider blast radius, user experience degradation, and recovery cost. A wrong color choice in UI affects aesthetics; a wrong database architecture affects years of work.
-
How hard is it to reverse? Some decisions can be undone with a code change and deploy. Others require migrations, data transformations, or architectural rewrites. The ease of reversal directly determines decision-making velocity.
-
Can we mitigate fast with a small blast radius? Even risky changes become manageable through careful rollout strategies. Feature flags, canary deployments, and progressive rollouts transform irreversible-looking decisions into tiny experiments.
Speed Through Downside Management
The counterintuitive principle: “Speed compounds when you manage downside.” Moving fast doesn’t mean moving recklessly. It means making many decisions and handling the wrong ones well.
This approach contrasts with Hammock Driven Development, which emphasizes deep thinking before action. Both have their place—use the three-question framework to decide which mode fits the decision at hand. Reversible decisions with small blast radius deserve speed; irreversible architectural choices deserve hammock time.
The goal isn’t perfect decisions—it’s a high decision throughput with controlled failure modes. Make ten decisions where a competitor makes one. Be wrong on three of them. Roll back those three within hours. Still ship seven improvements while they’re still deliberating.
Relationship to Agency
Decision velocity correlates directly with agency. Teams that can make and reverse decisions quickly maintain higher volitional agency—they shape their technical direction through rapid iteration rather than waiting for certainty that never comes.
The three-question framework provides the judgemental capacity needed for responsible fast decision-making. It’s not about moving blindly, but about having clear criteria for when to move fast versus when to slow down.