The Complex Task of Simplicity

If you want to make things truly simple to use by your customers, you will nearly always have to make your organization take on more complexity – Gerry McGovern

Yesterday, I delivered a talk at a conference that was aimed at getting organisations ‘back to basics’.

The problem, I proposed, was that we live in a complex world and many of us just can’t help trying to help tackle every issue.

  • Climate Change
  • Wellbeing
  • Income inequality
  • Health

That’s often in addition to the core reason we were set up in the first place. The problems we were set up to solve were once quite simple, but as organisations get larger there’s more technology, more people, more regulation. We put together processes, controls, reviews, and structures and these factors together create a great amount of complexity.

There’s a paradox here. Although we appreciate the benefits of simple customer experiences and great design in our everyday lives, we often forget all about it when we walk through the door at work.

My contention is we have stopped seeing it. We don’t even recognise how complex we’ve become.

There’s some science to explain how we may have become ‘complexity blind’.

Our brains cope with complexity by identifying key features and filtering out unnecessary detail. On seeing that the space you enter has walls, a floor and a ceiling, you know you have entered a room and can usually ignore the details. You can find where to sit quite easily without getting all distracted by the view out the window or the pictures on walls. This is an example of what the French psychologist Jean Piaget termed a “schema”. Schemas can be useful because they allow us to take shortcuts in interpreting the vast amount of information that is available in our environment.

When your working day is crammed full of meetings and emails it’s easier to just screen out the bullshit and the complexity and just , well,  try to cope.

And sometimes we don’t just take mental shortcuts – we take physical shortcuts too.

Back To Basics_ How Can We Simplify Our Business In Complex Times_ (1)Back To Basics_ How Can We Simplify Our Business In Complex Times_ (4)

Desire paths were beautifully described by Robert McFarlane as “paths & tracks made over time by the wishes & feet of walkers, especially those paths that run contrary to design or planning”, They spring up when humans vote against design – with their feet.

But desire paths exist within our organizations too, when colleagues make illicit shortcuts through bad policy and procedure to make their working lives a little easier.

Sometimes there are very visible signs of complexity , such as long lists of KPIs or structure charts that look like a company is preparing for an invasion of Europe rather than serving customers.

Last year Sky admitted that they had identified over 2,000 KPIs within their business. They took radical action and reduced it to just 30. Interestingly , they did this by cutting the people involved by 84%. They admitted the KPIs fulfilled no purpose whatsoever and  were just in the business because “someone liked them”.

How can we simplify complex organisations? 

As Steve Jobs said, simple can be harder than complex. Most of our organisations default to the difficult for a reason – it’s easier.

Being simpler means spending more time in problem definition, and more time observing what users need and how they behave. Einstein believed that the quality of the solutions we come up with will be in direct proportion to the quality of the description of the problem we’re trying to solve. Not only will solutions be more abundant and of higher quality, but they’ll be achieved much more simply.

Simplicity also means saying no to things and doing less. Many of an organization’s activities are misaligned from , or have poorly defined, strategic objectives. We often anchor around the wrong thing. That’s why some big institutions have no chance – they are hit by random plans and transformations rather than anchoring around purpose and iteration.

This takes discipline though as it means killing vanity projects and saying no when something doesn’t fit into the plan

It also means taking a different view of design – and removing activities rather than adding them in.

Back To Basics_ How Can We Simplify Our Business In Complex Times_ (5)

The Dutch traffic engineer Hans Monderman challenged this thinking with his idea of “Shared Space”. His concept was simple. Remove all traffic lights, signs, and road markings. The results were the opposite of what most people expected. The traffic moved slower, people paid more attention, and accidents ultimately declined.

Monderman’s theory was that increasing traffic regulations reduces personal responsibility, the need for drivers and pedestrians to pay attention to what is happening around them.

“The trouble with traffic engineers is that when there’s a problem with a road, they always try to add something,” Monderman says. “To my mind, it’s much better to remove things.”

What would our organisations look like if , when faced with a problem, we focused on removing things rather than adding them in?

What if every time we added a new activity we abandoned an old one?

Back To Basics_ How Can We Simplify Our Business In Complex Times_ (6)

The second of the Bromford Design Principles is abandon activities that don’t add value. I’m going to put my neck on the block and suggest it has been the least successful of the nine principles we introduced. Yesterday certainly reminded me that should be my personal focus in 2020.

Ultimately simplification means making it easier for your people to get things done and for your customers and other partners to work with you.

As the world becomes more complex, simplifying strategy, leadership, decision-making and all of our communication becomes more important than ever. It should be our number one focus – but it certainly isn’t.

Being simple – it’s complex.

 

Why We Are So Bad At Defining Problems

If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions. – Albert Einstein

I don’t know whether Einstein ever used those words. It may be just like the Henry Ford “Faster Horses” quote – something perfectly phrased and also perfectly true that no-one actually ever said.

Whether he said it or not, Einstein believed the quality of the solution you generate is in direct proportion to your ability to identify the problem you hope to solve.

And of course he was right, you can’t really solve a problem you don’t fully understand. “If you can’t explain it simply, you don’t understand it well enough”. Another quote he (probably) didn’t say.

Either way, 60 years after his death, many of our organisations have still failed to learn his most valuable lesson. So what is so difficult about problem definition?

Many of our organisations have set the climate for solution focused rather than problem defining behaviours.

A solution focused culture is exacerbated by the following conditions:

  • Leadership putting pressure on finding quick fixes and the realisation of short term goals – rather than long term impact
  • Discussing problems, or considering that organisation itself may be part of the problem, is seen as taboo or a sign of weakness
  • Management falls in love with a solution too easily even if it’s not solving the problem at hand
  • An implicit assumption that leaders have all the answers. “Let managers manage and get on with it”
  • A lack of evidence based enquiry – which allows bullshit organisational ‘facts’ to circulate and obfuscate true problem definition

In my work over the past five years, since I’ve given up having any operational responsibilities, I’ve seen how easily we can all lapse into solution focused work.

Unlike Einstein, when given an hour we often spend – at best – 5 minutes on the problem and the remaining 55 minutes solutionizing.

Our+Approach+To+Design++-+Simon+Penny+(7)

As Simon Penny writes in a great piece for Bromford Lab “when we talk about design we are using it as shorthand for 4 key elements of problem solving activity – discovery, definition, development and delivery. That means that at least half of what we do is based on truly understanding and defining the problem we are trying to solve and the other half is based on developing, testing and iterating ideas into a scalable solution. In short, we think about design as a whole end-to-end process”.

So rather than seeing problem definition as a one off activity, it’s now what we do all the time, objectively helping the organisation to solve the right problems and resist its inbuilt solutionist behaviours.

The five step approach to problem definition

1 – Establish the need for a solution

This sounds completely obvious but just because you’ve seen or thought of a solution doesn’t necessarily mean one is actually needed.  Starting with a high level question of “What problem are we trying to solve here?” and being very clear about it is a good starting point. You’ll usually come up with a lot of further questions – so don’t even bother trying to fully define the problem at this point. There may not even be one.

2 – Match the problem to organisational strategy

Even if you’ve established the need for a solution – it may not be one your organisation is best placed to provide. No organisation, large or small, can manage more than five or six goals and priorities without becoming unfocused and ineffective. The best organisations don’t try and do everything. They focus on trying to solve fewer problems, in better ways.

That involves finding your ‘irreducible core’ of services and then constantly refining and innovating against it.

It also means saying no to trying to solve everyone else’s problems.

3 – Explore the context to the problem

Often your problem will be one that the organisation has tried to resolve before. We rarely stop to reflect on why our previous efforts failed and what we should avoid this time.

If the problem is industry wide, it’s crucial to understand why the market has failed to address it, and whether it is even feasible.

4 – Writing the problem statement

Now you’re ready to write something down. A problem statement should describe the undesirable gap between the current-state and future-state. It should avoid any mention of a solution and be no longer than a tweet.

5 – Initial prototype solution

As Simon Penny also wrote here , prototyping can also be used to test an idea; not by creating a smaller working version of a service or product, but by testing the many different component parts or even thinking abstractedly in order to start to uncover what it might feel like to use the service or product. This can be tested – with people – to help you further refine the problem. Thinking of prototyping as part of the problem definition helps you avoid falling in love with your first idea.

All of this takes time , and this is why our organisations are bad at it.

Falling in love with the problem , rather than the solution means:

  • Accepting your first idea could be the worst idea – and might be wrong
  • Being brave enough to pull the plug when you realise you’re not the ones to solve it
  • Becoming comfortable with failure – as the only way you’ll ever explore a problem worth solving is through a ‘try, fail, learn and try again’ model.

When you truly fall in love with problems, not solutions, you not only stand a better chance of solving them. You also start unlocking a path to a better, less complicated organisation.


Footnote:

By the way – it is possible to argue you can solve problems without first defining them.

I’m currently travelling and it’s inconceivable that we once had to carry suitcases. The first wheeled luggage was invented by Bernard Sadow because he had a bad experience in customs returning from Aruba. Struggling to carry his heavy luggage, he observed an airport worker effortlessly rolling a heavy machine on a wheeled skid. The rolling suitcase was born.

That’s not how our organisations work though. If the eureka moment was so common place we’d have solved most of our most intractable problems by now!

%d bloggers like this: