Common business lore has it that businesses that make decisions fast are at an advantage over those that are slower at decision making. Is that always the case? Are there situations in which you would be better off taking your time?
Earlier this week I was considering a change of direction for a personal project. It seemed good at the time, and even though it would mean quite a bit of extra work in the log run the benefits seemed worth it. This morning, while reading a friend’s newsletter, a new idea came to me that would give me the same benefit that I was looking for with hardly any of the extra work the previous idea required. Had I not given this a week to mature, I would have either lost a bunch of time due to rework (bad) or would have been stuck with something that required a lot more work in the long run (awful).
First of all, there are different kinds of decisions that we need to identify. My hypothesis is that while you should always be fast for some kinds of decisions, there are others that are best left to simmer for a while.
Consider prioritising support tickets. This is clearly a case where speed is beneficial. In they come, out they go, delighting your users along the way with your fast response times. You might not be able to make on the spot decisions about all of them, but driving your average response time downwards seems to be always a good idea.
Support tickets are work items that, in general, tend to require little effort to tackle. If you make a wrong decision, you might lose a few hours of time from one engineer. That seems a reasonable price to pay for delighting your users in all the other cases where you get it right.
Let’s switch now to important, sweeping product changes. Suppose you’re evaluating a large project that will require multiple months of product and engineering effort. Does it really make a difference if you start that project today or after a couple of days reviewing some data and taking some walks thinking about whether you should really take your product there?
The decision-making process in these two cases is likely very different. With the former you can follow some general guidelines and make a call with little data and some thoughtful questions that are often easily answered – How big is this ticket? How many people does it affect, and how often? Which people? Is there a known solution that fits into the product? The latter case, however, requires answering broader questions that are not so simple. How big is this, and do we believe our estimate? Does this make sense in terms of your roadmap? Who is going to work on it, and therefore who is not going to work on other things? Each of these questions is more complex and will often require consulting other people in the organization. Importantly, some of these questions can affect your product positioning. These are the decisions that, in my opinion, should not be made quite so quickly.
This is another case where you should take commonly found advice with a grain of salt. Always being fast can lead you to wrong decisions while always being slow will certainly drag you down. Be mindful of how you approach each decision you need to make, to ensure that you’re using the appropriate process for each situation.