Friday, September 14, 2012
Decide Not, Not Not Decide
Amongst my pet peeves (and I've collected a lot over the years) is the way in which unresolved upstream decision points can impact downstream. That's not to say I think all choices have to be made instantly (although there is theory on efficient decision-making e.g. satisficing) but I do think that clarity is imperative.
When I'm waiting for a decision to license some further action on my part I don't want to have to expend energy and resources keeping possible options - and their dependencies - open, keeping resource on hold ready for an always impending decision - and perhaps compromising my other missions - and remembering to look up periodically to see whether the decision has arrived.
When I'm waiting for a decision, I want the decision maker to be open about (a) what the chosen option is, or (b) that they aren't going to decide yet and why and what would enable a decision, and when. That removes uncertainly and frustration, adds clarity and frees me to deploy resource elsewhere based on a shared understanding of the status. It also makes it possible for me to decide whether to expend some resource trying to enable the decision.
Not deciding is not the same as deciding not to decide (yet).