Why Organisations Get Stuck
and how you can help, using 6 Systems Thinking ideas.
I want to tell you about Pachinko machines.
Pachinko machines are these wonderful gambling machines in Japan, where steel balls enter from the top and, depending on where the ball ends up, you may earn a cash prize. In a lot of these games, you have no control over the ball after its entry. The path of the ball — and your fortune — is ultimately at the mercy of the pins.
I want to share something else with you.
“The system that people work in and the interaction with people may account for 90 or 95 percent of performance.”
— W. Edwards Deming
It’s been observed over and over that the performance of an organisation is governed not by the capabilities of its staff, but by the organisation’s structure and processes.
You may have heard this put another way: “if you had put anyone else in that position, the outcomes would have been the same”.
Does this remind you of anything?
Yes: organisations are Pachinko Machines.
Whilst the pins of the pachinko machine guide the steel balls after they’re dropped in, an organisation’s culture guides its staff after they join. Culture is harmonising — it helps us understand how to operate in our organisation, and it also reduces the likelihood of us straying too far off-piste.
In one organisation, I noticed that the leaders always Slacked everyone when they were stepping away from their keyboard. Eventually as the organisation grew, everyone started doing this. It was self-perpetuating.
Organisations also naturally use structure and processes as a way of reinforcing culture.
In another organisation, every engineering decision was scrutinised as a team before it was finalised. The approach became widely accepted because it generally led to better outcomes, and was later reinforced by weekly all-hands design calls.
I want to be clear: this harmonised behaviour is not a bad thing, particularly early in an organisation’s life, as we want to encourage behaviours that have historically made our organisation successful.
However, as the world changes, some of the harmonious behaviours will no longer prove beneficial. There will be a need to encourage people to explore new paths, and for the organisation, this means reconfiguring its pachinko pins.
Idea 1: structure drives behaviour.
There are a couple of interesting experiments that illustrate this, but I want to talk about one involving snakes: The Cobra Effect
The Cobra Effect is an anecdote from the British rule of colonial India.
The British government was concerned about the number of venomous cobras in Delhi. They therefore offered a bounty for every dead cobra. Initially this was successful as large numbers of snakes were killed for the bounty. Eventually, however, enterprising people began to breed cobras for the income. When the government became aware of this, the reward program was scrapped, causing the cobra breeders to set the now-worthless snakes free. As a result, the wild cobra population actually increased.
So, the British created a pachinko machine, but misconfigured the pachinko pins (the bounty), and the balls did not follow the path they expected. They ended up with people breeding more cobras.
“Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way, do not complain about illogical behaviour.”
— Eli Goldratt
In an organisation: if you measure people, and measure them the wrong way, the effect will be detrimental to the organisation as a whole.
The example close to all our hearts is Developers and Operations. If they are separate teams, and Developers must deliver to deadlines (and potentially cut corners in order to do so), and Operations must keep the systems stable — the two teams will conflict and the results will be undesirable.
I want to now talk about organisational size.
In many respects the ideal organisational size is 1, because then that one person has all the context to make informed strategic decisions. As organisations grow, and organisation start to split people into their first teams, we still probably have enough context to make good decisions, or access to that context through those immediately around us.
But, what about a multinational multidivisional multidimensional monoliths?
If I wanted to make a major change in an organisation like this — such as how we deliver software — I’d need to understand just about every part of the organisation. If I made decisions just based on what I know from within my team, it’s unlikely they’d be the decisions for the organisation as a whole.
I’m not trying to suggest one organisational structure is necessarily better than the other. I am suggesting that as an organisation gets bigger, it naturally gets harder to see the whole — to have access to all the context, all the pieces of a puzzle, that would allow you to make an informed and far-reaching decision.
I also believe organisations have historically divided themselves into smaller pieces — such as divisions — in an effort to reduce complexity, but this often makes it even harder to understand the whole as it becomes difficult to see beyond team boundaries.
And that’s what complex is: something that is composed of many interdependent parts, and thus hard to understand.
However, there are ways of understanding complexity — and we’ll show you how.
Idea 2: Organisations are complex, where no one person can see the whole.
“As organisations grow, they move into the complex domain. […] there is no privileged perspective from which the system as a whole can be understood — not even the CEO’s office — […] nobody can hope to understand more than a small part of the whole.”
— Jez Humble et al
Here’s a simplistic example of what happens when we cannot see the whole. Let’s first represent the different teams that may be involved in software delivery in one line — everyone who comes between “please” and “thank you”.
If we imagine this is one big pipe, with the diameter of that pipe representing the throughput of each of the teams, then we might see that the Dev is the point in the pipe that’s the most narrow (shown above in red), and that would restrict the overall flow of water through that pipe. Making the pipe wider anywhere else but here will not increase the overall throughput.
Putting it another way: the throughput of the entire software delivery system is equal to that of the team with the lowest throughput — in this case, the Dev team.
Therefore, if I was in the Test team, any time I invested in helping my own team go faster would be waste. I need to go and help the Dev team.
Soon after, it’s likely the Test team throughput would become the constraint. Constraints are neither good nor bad, you just need to be aware of where they are.
If I was the manager in Test and I wasn’t able to see the whole, I might ask for more development projects to come down the pipe so my team could operate at full capacity — particularly if my performance is measured on how many tests my team runs in a day. However, this would only make things worse as it would create more of a backlog for the dev team!
Idea 3: there is only one key constraint at any one time.
As we saw in the previous example, the one key constraint that limited the overall throughput was the throughput of the dev team. Helping improve the throughput of the whole system is predicated on helping that one team first. Directing our efforts anywhere else would have been waste.
Let me tell you another story.
In 1995, the Yellowstone National Park Service reintroduced a number of wolves to tackle an overpopulation of deer and elk.
As expected, the wolves fed on deer and elk, reducing the populations.
However, the decrease in deer, elk, and other wolf prey removed a burden on the vegetation, allowing it to flourish. The enhanced vegetation then increased the food supply and cover for small animals. This led to an increase in small mammals and birds as well as their predators like foxes, hawks, and badgers.
Additionally, wolves killed and expelled coyotes which further helped to increase the small animal populations. The revegetated hillsides and riverbanks meant that the soil and slopes became stabilised by plant and tree roots. The reforestation of hillsides and riverbanks created habitats attractive to beavers whose dams further reduced riverbank erosion. The reforestation of hillsides and riverbanks created habitats attractive to beavers whose dams further reduced riverbank erosion.
Without loose soil erosion depositing silt into waterways, the channels of the rivers became narrower and more direct.
The presence and activity of the wolves literally altered the course of rivers.
Idea 4: Complex systems are interconnected
The above video walks through a real example where Dan Young and I used a Systems Thinking tool to diagnose the underlying root cause of a number of symptoms at a multinational energy provider.
Idea 5: Understanding systems requires a different toolset
Understanding a system requires us to use a different toolset. We need something that can help us look behind symptoms and trace them back to a single root cause, or key constraint.
It is particularly hard for people to see the root cause behind symptoms when there is a delay between cause and effect, or when the relationship between cause and effect is indirect.
Wolves didn’t change rivers directly, it was through a chain of cause-and-effect over time.
Finally, Idea 6: technology solidifies processes.
I’m sure you’ve gone through that familiar feeling. You’ve just started that new job, working at a cool tech company. You approach your first day with excitement, passion, vigour. You sit down with the team for the first time and they’re all awesome. Then, you find out they have a monolith.
Your smile descends into shock. You secretly wish to yourself that technology never existed, because unwinding a monolith is so complex — like swapping out an engine in a plane mid-flight.
So, that’s why — before we write our first line of code — before we create that first stage in our continuous delivery pipeline — we must first understand if what we’re about to do is going to help the organisation as a whole, and if we’re going to solidify the right processes.
Technology solidifies processes, and processes reinforce culture. That means you — as developers — are in control of the pachinko pins, and you control the game.
In summary:
- Be curious to look behind behaviours, because structure drives behaviour
- Connect the pieces, because organisations are complex, where no one person can see the whole
- Unleash your inner doctor and treat the cause not the symptom, because there is only one key constraint and therefore only one cure
- Look for safe-to-fail experiments, because complex systems are interconnected
- Remember that understanding systems requires a different toolset
- Seek first to understand, because technology solidifies processes
This article is a write-up of a talk I was fortunate to give at the London Continuous Delivery Meetup on 10th December, 2019.
