I looked at “mistake proofing a process” a few articles ago and I was thinking about how to remove dumb (or dangerous) decisions from a process.
This has been an important thing to consider for some of my clients in the past because people using a process could cause themselves and others a lot of harm when they make a mistake. But for most of my clients lately, a mistake would annoying but far from deadly and dumb decisions are easily forgiven and quickly corrected.
As a result, some of this article could be over the top. But sometimes when we build experiences for customers and repeating processes for internal staff, I think it is still worth looking at whether we can help establish the conditions for people to make good decisions.
Each of these approaches would either be done in a workshop, or included in your regression testing as you incrementally build your process, app or experience.
Let’s start slow
So the first approach is to regression test what you are building, but don’t test that things work, test what would happen when people who are ill-informed, new to the process or flat out distracted while context switching would have to make decisions.
Ask these questions as you walk through your process or the experience of using your product:
- Who is doing something here, who might need to make a decision?
- Do they know there is a decision to make?
- Does it really need to be made, or could we have an automated thing do it or at least an obvious guide that pops up to say what should happen?
- Would they have the right information to make the decision? How do they know where to look if they don’t?
- Are we distracting them with unnecessary noise, right when they need to be able to pause and think?
- If they guess wrong, does the system either warn them or allow a safe and happy recovery?
- Do other people need to know what decisions are made, or do people need refer back to the decision later?
- Do people really need to know? How would they find out?
- Are we collecting and storing useless or distracting information that makes key things harder to find? Do we make communicating or finding out about decisions cumbersome or easy?
People have told me that this is not regression testing because we should only test these things when we are building something new. Controversially though, I find that you learn more about bad decisions when you come back to something later than when you know subconsciously what decisions should be made and you have the right test data in your hands.
Usually, you can finesse or tweak what you have as you come back and retest it.
To get more serious you can include decision making in your mistake proofing attack on the system or you can do some proper regression testing that includes mistakes being made multiple times.
Strategic choices to design bad decisions (or good ones)
Many years ago, I learned that you your delegate things to people and empower them to get things done. I also learned that people often have things delegated to them without being empowered, even though that makes no sense.
But more troubling for me was that people like me who prefer to take initiative rather than go and ask for permission sometimes also cause problems if they have no accountability for the outcome of what they do and little or no understanding of the impact of those decisions. Sometimes this is laziness or a lack of empathy for those impacted but it is often the result of arrogance, ignorance or impatience, all of which I have suffered from when under pressure.
So I think we should trust people and stuff like that, but we also need to build processes and systems where people know their decisions and actions have consequences and that they have the power to do good or bad, or ask for help, as a result.
So here is what I learned:
Delegation without empowerment is micromanagement
Empowerment without accountability is disrespectful and dangerous
Accountability without authority and the ability to seek/validate information is cruel and results in inertia
So when you want to be super evil, you should “empower people” by delegating things to them … but not really do it. Instead, use nice words to micromanage people who are ignorant of what is going on, while being disrespected and feeling like they are in (at least psychological) danger. But I guess you should really say you are being cruel rather than empowering.
I hope this is obvious to a lot of people. But often, good people don’t realise that when they create a process they are also embedding either “informed” empowerment, or trouble.
It follows then, that if you build a process based on “we trust our people” then you should make sure that they are clear that they have been delegated the right and obligation to make decisions (and hence occasional mistakes).
That in turn suggests that:
- It is clear to people whether they are empowered to think, or just following your instructions. If they are empowered then they know you will disagree with some of the outcomes and that you are not a crying baby so you will cope.
- You remind people that the power to make decisions comes with the accountability to exercise judgement
- You admit that in order to be accountable, they must have the authority to act on their decisions, access to the right information to know the impact of their decisions, time to think and permission to stop and ask. They have the right and obligation to highlight when these are missing.
- They also need to understand that there will be mistakes and they will need to be both empowered and accountable to manage the recovery from those mistakes. In some cases this also means that the process must make it simple for concerned stakeholders to become aware of the mistake and the mitigation.
All that is, I think, straight forward when you are working with people in a team. But it is harder to build into a process. Yet if you don’t think this through then it is important that the default is that people are both empowered and accountable to do what they want, even though that means deviating wildly from the process you have created.
In other words, embed empowerment into the process or deliberately remove it from some decision points (er – place boundaries around choices, with an explanation as to why).
If you don’t do that then, it is your decision, but the consequence is that I can pretty much guarantee that people will not follow the process.
So don’t spend too much time documenting, explaining and rolling out something you know will be ignored. Instead worry about what happens when nobody is following the process and you have a lovely document sitting unread somewhere in a library.
James King 