Decisions about decisions

Last week I was sounding off about the poor way we often handle problems. There’s another topic that’s been bugging me; the poor way we deal with decisions, applying a decision making style suited to one environment in a completely inappropriate context.

People often have a strange attitude towards decisions. Their instinct is that important decisions require a lot of time and effort. Also, they have an irrational gut feeling that decisions become important and justify lots of our time simply because they are complex. We can get rattled by trivial decisions, where there are surprising complexities that make it difficult to give a definitive right answer.

I’ve been given two pieces of invaluable advice about decision making. The first was from my father when I was still at school.

”Very often the worst decision is no decision. Often the difference between two options is less than the consequences of hanging around, wasting time and not making any decisions at all. Just make your decision and get on with it.”

The second piece of advice was from my manager just after I left university. He went on to become a famous and wealthy businessman. He also had a somewhat cavalier approach to business ethics, which ultimately attracted some very unfavourable press, so I won’t name him. I don’t want to give the impression I endorse his views in general. We disagreed about the way to conduct business, but I’ve found his advice about decision making valuable.

He’d asked me to research a company that we might invest in. I took a couple of days to produce a detailed and thorough analysis explaining all the pros and cons of investing.

He read it, then told me that it was a good, thorough piece, but I’d wasted time on delving into too much detail.

“There are probably no more than about three factors you have to take account of before you make a decision. The rest are either unimportant or irrelevant. The trick is being able to recognise the key points and not waste time on stuff that won’t actually affect the decision”.

Often we get intimidated by the thought of taking responsibility and taking decisions. So we retreat into time-wasting detail. It shows we’re taking our responsibilities seriously and helpfully defers the point when we have to make our decision.

So, yes, my father and my manager were right. An unwillingness to take appropriately quick decisions can have a paralysing effect, and we do have a tendency to plunge into suffocating detail rather than focussing on what really matters.

However, the advice from my father and my manager weren’t rigid rules. They were just guidelines, and shouldn’t be applied inflexibly in every situation.

During the Second World War my father served in the airborne forces, a branch of the army in which making quick decisions and then getting on with it wasn’t a management style, it was a matter of life and death. Later he was a successful salesman and senior sales manager. That career encouraged and rewarded his decisiveness.

My manager was leading a fast moving investment team, buying and selling shares every day. Again, cool and quick thinking were crucial.

The context is crucial when it comes to selecting a style of decision making. In software development we’ve been hopeless at taking decisions and that’s largely because we haven’t recognised the context, which is different from the environment my father and manager thrived in.

Some organisations have a culture that assumes sound decisions require time and detail; if they throw a load of time and analytical effort at a problem they can confidently set their decisions in stone. That’s how the Waterfall, and traditional development methods operated.

Other places favour bold, early decisions, imposing arbitrary implementation dates on projects before anyone knows how much work is involved, or settling on outline design solutions before the requirements are understood (or instead of the requirements, see my blog on Tom Gilb’s thoughts on requirements).

Mostly we’ve mixed up our decision making styles in a way that defies logic and business sense and has given us the worst of both worlds.

Senior executives have applied the advice of my father and manager recklessly, going for ill-informed decisions while project teams have got lost in detail, ignoring big and simple signs that could have let them take important decisions earlier.

The paradox for such teams has been that they might have been taking months to reach irreversible decisions, but the truth was that the decisions were often taken too early in the logical sequence of the project, e.g. the confusion of design and requirements (Gilb again) and the pretence that a viable user interface can be confirmed before the users have tried it.

So, my experience in IT has taught me a third maxim.

The right initial decision is usually to decide what sort of decision we’re looking at.

Should we just do it? Take a quick decision and move on. Either it doesn’t matter, or the right answer is clear now.

Should we park it till later and not waste time agonising over it now, when we don’t have the right supporting information?

Or should we make a provisional decision, act on it and revisit it when we know more?

The trick is to know what sort of problem we’re looking at.

That takes us on to Lean, which has a very pragmatic and helpful attitude towards decision making. It incorporates the principle of taking decisions at the “last responsible moment”.

That doesn’t mean the last possible moment. It’s not a recipe for indecision and procrastination. The last responsible moment could be very early, depending on the circumstances.

This is one of the aspects of Lean that appeals to me. It not only makes sense in software development terms, it also recognises the general point that context is crucial rather than pretending that a single, inflexible approach to decision making applies in every circumstance.

As Mary Poppendieck put it in “The Predictability Paradox”, sadly not available on-line.

“You need to develop a sense of when decisions must be made and then make them when their time has come. It is equally important to develop a sense of what is critically important in the domain and make sure these areas are not overlooked in the decision-making process.”

Mary and Tom Poppendieck expanded on this in their book “Lean software development: an agile toolkit”.

So it’s useful to keep running mental checks, to make sure you’re treating the decision appropriately, and not just taking a decision because you’re feeling gung ho, or deferring a decision because you want more and more information that won’t really affect the final decision.

It’s also important to have confidence in your own judgement and experience. Point out to critics that a quick decision isn’t necessarily a hasty one, and a deferred decision doesn’t mean indecisiveness. It all depends on the context.

Finally, and please, if you know me, don’t inflict on me any more meetings that last for an hour after everyone has reached agreement, but in which people felt they had to drag in more and more ammunition to support the big decision. One day I may just go berserk!