Making Good Decisions (Part 1)

Making good decisions is one of the hardest parts of leadership.

What follows is a simple model you can use to make better decisions, with more confidence.

My experience is in digital, so that’s what I will write about, but this model works across disciplines.

Remember choosing which subjects you wanted to study at school? For me in the UK, this was choosing my 9 GCSEs.

I bet most of you did not get great advice. You mostly were left alone to circle around what at the time seems to be one of the biggest challenges in your life! Your future depends on this!

Is your best friend taking the same as you? Do you like the teacher? I don’t know about you but I made some pretty random choices.

Then we grew up, got work in digital and we got to make some more decisions. Things like which platform should we buy? Or what programming language should we focus on?

There are some pretty common tools out here to help, things like the MoSCoW method, where we decide based on if a list of features are ‘must’, ‘should’, ‘could’ or ‘would’. This is often used when designing a software procurement. Someone throws together a long list of features and they ask ‘stakeholders’ what they want. In my experience, they must have everything. And when they ‘should’ or ‘could’, they usually mean a version of must. ‘Would’ means we don’t care, but would like it anyway now you are asking...

A typical outcome is that software vendors who are good at having (or pretending to have) lots and lots of features win. And you and your organisation generally loses.

People do other things too, keep lists of risks, make a cost / benefit spreadsheet.

These things aren’t bad, and they can help, but...

Let’s start with a simple multi-criterion model. This is ideal for any situation when there are a lot of dimensions and you have multiple options to choose between.

To illustrate how this works let’s run with a toy example of choosing which programming language to focus on in an organisation.

First of all we need to come up with a set of criteria. These are things that we think play a part in the decision.

When we are selecting a programming language to focus on, we might consider:

• Easy to learn - is the language easy for people to pick up?

• Ecosystem - is there a strong community and ecosystem around the language?

• Functional - does it support a functional programming style?

• Strongly typed - does it feature strong or weak typing?

So let’s take our initial list of criteria, the things we think are part of our decision process, and score them based on what we think would be ideal, where 0 is not important and 5 is very important

This ideal shows us what we care about - we care a lot that the language is easy to learn and that there is a good ecosystem. We also have a preference for native functional programming support, but think strong typing is less important. So this ideal already quantifies our bias and shows our preferences. It is already a great communication tool, for talking about the choice with others.

Well, in our scenario of choosing a programming language in an organisation, we can do a couple of things with this model.

First, let’s go ahead and score some languages against our criteria.

So how does this help us?

First let’s quantify the difference between our choices.

For JavaScript, the difference is 4.

For Go, the difference is 8.

So does this mean we should choose JavaScript, as it has the lowest difference?

Maybe. Before taking the outcome at face value, it is better to ask some questions first, to test the evaluation model you have built.

A good question is always: “Is this what I expected?”

Check you are not missing any criteria - is there something else about the languages that you want to capture? Maybe you really care about a good standard library for example, something Go excels at.

Another useful exercise is also to look at the results spatially - to plot them on a simple line. It helps see distance, and, with a few options, identify clusters.

So what else can we do with this model?

So far we have established criteria, scored them against an ideal and compared that ideal to actual programming languages. We have seen how we can use the results of this exercise to prompt more questions and how to visualise the results.

Now let’s use this model to learn about others, and help reach a better decision as a group.

As well as better choices yourself you can also use the model to better understand the choices of others.

Let’s explore a couple of ways to do this.

A simple thing is to ask others interested in the decision to review the criteria and also to score their own ideal. People’s ideals will likely be different, and this exercise will help highlight the point’s of agreement or disagreement.

In this table we are comparing the ideal with the preferences of K, B and N.

Again, looking at the distance between scores is very revealing. We can see attitudes in the team to functional programming and strong typing are often very far apart. Finding resolution on these criteria is going to be key to the success of your decision amongst your team, and now you know what people actually care about it, and how much.

Instead of starting from a single ideal, another useful method is to deduce the ideal from multiple observations

Let’s take the table above, and remove the ideal.

Now we can create an ideal based on a the preferences of the team, by taking a rough average:

See how much it differs from the ideal we defined earlier, without the team?

So now you have a simple model to help make decisions.

We have seen how to define and reflect on what is important to you, how to simple quantify people’s preferences to enable better discussion and how to deduce an ideal from observations.

There are so many models that can help people working in digital make better decisions, share the process and engage people.

In the next post in this series we’ll look at using some more sophisticated models like decision trees to help us understand the implications of decisions, even when you have limited or no information.

Hope this was interesting for you, and thank you so much for reading.