What darkness lies between decisions?
Work is simply whatever we must do to get from one decision to the next.
Venkatesh Rao, Tempo
An important metric: How many questions can you ask your system in a day?
Justin Searls (paraphrased from memory)
In the field of software development, many of us are already familiar with the extreme value of tight feedback loops as applied directly to writing code. Test-driven development’s “Red-Green-Refactor” development loop is a microcosm of this mindset, in which a programmer is given feedback on their function under development in ideally a few seconds at most. This also gets applied with the practices of continuous integration and deployment–or at least, such is the intention.
It’s curious, then, that we’re much less explicit about optimizing shortening the distance between decisions from a leadership perspective. Especially as Agile-as-practiced has degraded into a collection of prescriptive ceremonies without users understanding their intent, much of our focus has shifted to the performance of the stuff that comes between decisions, rather than finding ways to squash it.
Ultimately, this is the job, admittedly simplified:
- What’s the next decision you or your team needs to make?
- What do you want before making that decision?
- What actually keeps you from making that decision right now?
- Do you actually need more information, or can you make a provisional decision and backtrack without losing too much time/effort?
- Are there other decisions this depends upon first? Restart this cycle with that/those decision(s).
- Make the decision
- Move on and start this loop again
The rest is either noise or semantics.
What else do you have between your decisions? And what of that can you get rid of?
