I find myself using this rubric when deciding how much I should push back on something that doesn’t feel quite right.
- Reversibility: Would it be difficult to reverse this decision later?
- Blast radius: Is the impact of getting this decision wrong large?
- Forward binding: Will this decision change how future decisions are made?
If I can answer “no” to all three questions, it isn’t something I should overthink.
I use these three questions in a variety of situations:
- A colleague makes a recommendation I’m not sure about.
- Something in a pull request doesn’t look quite like I’d do it.
- A coding agent makes a call I don’t fully understand yet.
If one of those questions is a “yes,” I need to dig in and maybe push back. Otherwise, I’m comfortable letting it go.
This framework is similar to Amazon’s one-way and two-way doors idea.
I’ve been using these questions for a decade now, but it was only recently that I captured the rubric in writing. I did so because the code review skill I was working on was burying me in findings, and I noticed I was asking the same three questions while reviewing each issue the skill found. Defining these questions and adding them to the skill allowed it to address a large number of its low-confidence findings without requiring my input, letting me focus on the few decisions that warrant my attention.
Having these questions in my back pocket has helped me to avoid a lot of stress and conflict at work, and has let me more easily focus my attention on what actually matters.