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!

3 thoughts on “Decisions about decisions

  1. Hi James,

    Excellent piece, and thanks for sharing it with us all.

    I like how you talk about lean principles that you find useful, as opposed to talking about adopting lean as a whole approach. I think that mentality is important to make good decisions, the ability to digest information and pick out only what you feel is useful.

    Lean is a good example, because it often gets a lot of bad press. People make remarks such as “What did you expect other than failure, when copying something from the manufacturing industry”, or “A lean approach might be good for making thousands of copies of the same car, but not for unique software”. The later statement is obviously flawed as a lean approach to car manufacturing could be the prototyping of several models, or parts at the same time, and making decisions on which to use, and which to keep in development in a parallel fashion.

    This bad attitude to an approach which may, or may not be useful as a whole is small minded. However, being able to take the useful aspects an fit them into your own approach, is much more productive, rather than simply dismissing things.

    So it’s refreshing to see your open-mindedness.



  2. Thanks Darren. When I started writing this I wasn’t thinking about Lean at all. It was only once I was underway that I thought, “hang on, some of this is entirely consistent with Lean”.

    It’s not surprising that Lean principles can be applied outside software development. Lean goes with the grain of human nature when it should, and also applies a helpful corrective when it should do. Traditional techniques did the reverse. They cut across the grain of our sound instincts and encouraged our damaging ones.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.