/bks/images/image-o0b82.png)
Most of us like solving problems - it's just part of our nature. If we find something that makes our job harder than it needs to be, we like to work out a better way of doing it, and make life a little easier. We tend to do that whether at home or at work, and that’s generally a good thing - it feels proactive.
And that tendency doesn’t just happen at an individual level. A team leader likes to improve the way their team works, or a department head may want to introduce new process to reduce costs or improve productivity. This all sounds ideal, but there is an issue with this, one that I see all too often. Despite good intentions, an issue occurs when we draw the boundary around the problem too tightly.
Imagine someone who regularly has to complete a form that passes information to another team. They redesign it to make it quicker and easier to complete. They remove a few fields they think are pointless, add some information they think is important, and perhaps rearrange the layout so it better matches the way they work. From their perspective, it’s a genuine improvement as it saves them time, reduces their frustration, and makes their part of the process more efficient.
However, further down the chain, things look rather different. The receiving team now has to hunt for the information they need, ignore information they don’t, and chase down something that is no longer captured at all. Perhaps they create their own spreadsheet to fill the gap, add an extra check, or start emailing the originator for clarification. What saved two minutes in one place might now consume ten somewhere else, as well as introducing delay, duplication, opportunities for error, and extra frustration.
Before long, both teams have adapted their own processes to compensate for the other. And because each process makes sense to the people who created it, they can become surprisingly protective of it. Suggestions for change can feel less like an attempt to improve the whole process and more like someone interfering with something that already works perfectly well.
Scale that behaviour from one person to a team, department, or function and the consequences become much more significant. Purchasing may reduce unit costs by ordering larger quantities, while inventory and working capital increase. Sales could win a highly customised order that hits its target, but creates complexity downstream. Finance may introduce additional controls that reduce financial risk but slow operational decisions.
Again, none of these people is necessarily behaving irrationally - quite the opposite. They are solving the problems they can see and improving the things they have responsibility for. The difficulty is that the improvement has been judged from one position - or one perspective - in the system. But from an organisational perspective, it doesn’t actually need every box to operate at maximum efficiency; but it does need the whole system to perform well.
This is also one of the ways silos develop. We tend to think of organisational silos as departments that don’t communicate with each other. But the physical or organisational boundary isn’t really the problem. The problem comes when the boundary of the department also becomes the boundary of people’s thinking: my job - my team - my budget - my targets.
And organisations can inadvertently reinforce that behaviour; if people are rewarded for optimising their part of the system, we shouldn’t be surprised when they continue to optimise their part of the system. That reward doesn’t have to be a bonus, it might simply be what gets measured, what gets discussed at the monthly meeting, or what earns a pat on the back from the boss. Over time, people learn what matters.
So, sub-optimisation isn't just an operational problem, but is very much a management and leadership problem. Someone needs to be looking beyond the individual parts of the process, and asking what all those apparently sensible local decisions are doing to the overall performance. It also requires people at every level and every part of the process to understand a little more of the system around them: what happens before their part, what happens afterwards, and how their decisions affect somebody else’s ability to do their job.
And that is very much a cultural trait. We want people to solve problems and make things better. But perhaps we also need to encourage one additional question before congratulating ourselves on an improvement: Better for whom — and better for what?
Sometimes making your bit of the organisation work better really does make everything better. Sometimes it just moves the problem somewhere else.
Ad Futurum
Graham