Building things the right way
Last week I wrote about how organisations need ‘things’ (tools, procedures, policies, etc) that work, and how operations people are the kind of folks who like building those sorts of things.
This week I want to tell you about what I mean by the "that work" bit of "things that work". What does it mean for systems and processes to work?
The obvious answer is - to put it bluntly - that they are not crap.
Unfortunately a lot of systems are crap. You know this from your own experience. If you have ever had to interact with an organisation's systems (from the inside as a member of staff, or from the outside as a customer) you will know how often they are in the range from "a bit rubbish" to "unbearably bad".
Often that is simply because the people designing those systems didn't stop to think about the consequences of their design. They were busy people, working under pressure, and they tried to get a problem solved as quickly as possible. It's totally understandable - but it leads to bad outcomes.
The cost of this is huge. These bad policies and processes are a constant source of drag (on your organisation, and on the economy as a whole). This is a major source of waste, and every bit of it that we can eliminate frees up extra capacity to generate value and impact with the limited resources we have available.
Here are some things that I think we should be aiming for when building systems:
Have an understanding that goes back to first principles and gets to the real purpose that a structure is serving. For instance: What is the true purpose of a job description? What does a really good one do that a bad one doesn’t?
Design structures as tools that have an end user. Ask: "What will it be like for someone to use this, and how can we eliminate as much friction as possible from that experience?"
Where legal boxes have to be ticked, make this is the tail and not the dog. The emphasis should be on helping people do their job and to better manage risks; the things you have to say to tick legal boxes should be shredded to the bare bones.
Write in plain, concise language. Just because something is a 'policy' doesn't mean it has to be written in high-falutin' legalese. Say "start" and not "commence". Say "person" and not "designated individual".
Don't try to lock down every single possible detail. No matter how much you try, reality will just not be nailed down. So accept that. Explicitly leave room for people’s good judgement and guide them on the ways to use it.
Design ‘non-violent’ solutions that are minimally prescriptive. People should be free to adapt a process as much as possible to their own way of working. Don't be like those online forms that show aggressive error messages if you fill in the boxes on a page out of sequence. Don't make every box on a form 'required' unless they really are essential.
Following these principles leads to better systems. Better systems reduce waste. They also have other positive impacts that I'll talk about next week.