“Every system is perfectly designed to get the result that it does.” ― W. E. Deming
Irina Rokosz
There are two ways to build an operating system: the quick and dirty way, and the long and thoughtful one.
The Quick & Dirty Way
You just give a few pointers to your employees, “Here’s what I want you to do: one, two, three… Now off you go to do it!”
As people start struggling with how to reach these goals, some veer to the left. So you say, “No, no, that’s not where I want you to go.” And you put some rules in place to steer them back to the main track.
But people keep struggling with how to reach the goals, so some then veer to the right. And again you go, “No, no, no, that’s not where I want you to go either.” And you put some more rules in place to steer them back to the middle.
Still, people don’t understand exactly how they’re supposed to act or why. They get increasingly creative at breaking the rules, while you get increasingly frustrated. So you start imposing penalties, and fines, and eventually firing people.
If I come to investigate your operating system now, I’ll see a huge pile of rules that no one can encompass in full, not even you. Some rules will contradict each other, some will already be obsolete, and some will leave us wondering as to “What does the author want to convey?”
Why is that? Because you didn’t actually build a system from the start — you simply started piling rules on top of each other. No one managed that pile, and now the pile is even too big to manage. There are too many forces pulling people in too many directions.
But more importantly, you don’t know where your operating system is pointing, what its North Star is, what it’s geared to achieve. You can hope it will achieve what you want, but chances are much higher that it won’t. The “system” you have right now is clearly incentivizing different behaviors than the ones you want — and nobody knows why. So if your organization truly manages to deliver what you want at the end, it will be despite the operating system, not because of it. It will require brute force on a daily basis.
On a side note, this type of leadership is the topic of Dr. Deming’s Red Bead Experiment:
The Long & Thoughtful Way
There’s a second way of building a system, which is not very popular. It’s when you spend a lot of time upfront thinking and designing the system you want: setting up a clear purpose for how it should behave; looking at all the system elements, their relationships, and how they affect one another; preventing or minimizing risks that will occur along the way; and so on.
When you finally implement that system, you set a goal for it, and you spend much less time course-correcting. You will always have some learning and improving to do, regardless of the system, but with this approach it will be minimal.
Most importantly, the main purpose of the system will be clear and not subject to change, because the whole system will be geared towards it. Change the purpose, and you need another system.
Imagine you’re building a bike. The purpose of the bike, as a system, is to take you from point A to point B. You will still have to use the handlebars to course-correct as you go. But while you’re pedaling and keeping your balance, you will get to point B.
Can you change your goal? Yes. You can go to point C instead, in just the same manner. You get to choose your goal, and you get to steer your system — because now you can. You know how your system works, and you know how to direct it to where you want to go.
Is this approach to building a system harder to do? Sure! It takes much more time and much more thought to design it. But that’s the system you want to have — comprehensible, logical, predictable, manageable, and maybe even fun to use 😉