Guidance for Quick Decision Making
It's a healthy philosophy in engineering to be quick at decision making and then sticking to that decision, properly following quality guidelines and best practices. This sports a strong sense of agility, focus, and quality. A while back, a past manager of mine with whom I’m still talking frequently pointed me to an interesting thinking tool that can help with the precision of the “quick decision making” part. It’s about viewing decisions as one-way or two-way doors.
Simply put, a decision that’s a one-way door can’t be easily reverted, making and implementing it will have some sort of definitive cost to it. Conversely, a decision that’s a two-way door can be reverted without too much cost. How we go about making decisions then considerably depends on their nature.
For example, a new variant of a feature can be rolled out in a way that allows it to be switched off quickly in case anything bad happens - an undiscovered bug, or bad user response. Feature flags are what’s normally used to enable that. The decision to roll out the feature can be made very quickly, as long as the criteria for rolling it back or keeping it are clear, and a way to roll back is built right in.
As another example, a big initiative that moves the infrastructure from one cloud provider to another is one that can’t be easily reverted: contracts are signed, database architectures changed, and applications wired in different ways and sometimes even rewritten. Such a decision needs to be prepared carefully, and risks need to be analysed.
The article offers some ways of looking at the nature of decisions to carve out two-way door segments in decisions that look like big one-way doors. Perhaps one way of framing the difference is in terms of learning. What can I learn after making this decision, and how much actual pain will the learning involve? The greater the pain, the more one-way.
Tags: work