There are few terms more misunderstood than this one. Not only do we like to automatically equate the term with a forgiving error culture, we are also rarely aware of why we actually need it and how much work is involved.
»We need an error culture« is a call heard in many corridors of our organizations. Usually meaning that someone likes to avoid the danger of getting their head bitten off, if something goes wrong.
I am kind of on your side, but unfortunately the things are much more complex than that, if we want to get any benefits from a new or improved error culture. On the one hand there is the basic understanding, what error culture actually means, and on the other hand there are almost always areas, where errors are just not allowed.
Imagine you are working on a project in finance, and suddenly your customers bookings run amok. You do not want to live through that. If something like that happens, we could be close to closing the doors of our companies forever.
Overly dramatic? Maybe.
The term »error culture« only means, that there is a consistent defined handling of errors in our company. It does not say anything about how that handling looks like. To say, that we need an error culture, and to mean, that we need a forgiving error culture will only lead to misunderstandings.
Even hunting the responsible person down to give him a good and painful kick in the ass – after the slightest hint of a mistake – is some sort of error culture. It is a consistent and defined handling of errors, or is it not? If it is in the slightest helpful in any case is a complete different question, leading us to my fist core point: what do we want to achieve?
Sometimes the argument looks like that:
We are in a transformation process. Part of it is, that teams and individuals act independently and that we work on our processes and methods. We will have to experiment on that, but if someone has to fear some kind of negative effect for himself, no one will try something new. Therefore we will not develop.
I am sort of on your side again, but again things are a bit bigger than that. At the beginning of our journey we naturally ask ourselves, what we want to achieve. If we are only concerned with not hindering experiments in our own procedures, then this is an extremely limited sphere of activity, that we may start with, but which I do not want to end with. In addition to how we do it, there is also the question of what we are doing.
As a company we would like to know, how to react, if an error occurs, because we do not want to discuss what to do over and over again, when we should take action. With an error culture we can control our reactions and work on our quality assurance.
But that does not come cheap. A proper error culture causes work. Lots of work.
Let us start at the start: giving proper room for experiments on our own methods, reacting appropriately and quickly to errors, and to produce fewer errors – meaning working on our quality assurance – sounds really nice.
We will not be able to do that in a single team, we will have to go through our department or the whole organization. Furthermore, we will have to go step by step. Do not underestimate this – there is a lot of work to do. Just changing some of our core processes could be a real pain.
The question who we need for all of that solely depends on our organization, but trust me: we will be better off, if we start with fewer people involved. That prevents us from endless pointless meaningless discussions over the smallest of details. We will see automatically, who has to be part of our efforts. Do not try to assume that beforehand. Most likely you will forget someone and invite others, that you could perfectly live without.
With every desire for a forgiving error culture, we have to be aware, that some things are simply not allowed to happen. Remember the example with our customers bookings running wild. Meaning that we most definitely will need some error classes between apocalypse and little shit.
I would advise you not to graduate this too finely. You just cause yourself a lot of unnecessary work. In general, three or four error classes, which we form after the questions of how many people are affected and how serious the effects are, are completely sufficient. Of course, we want to know how we react both internally and externally. How do we communicate? When do we fix?
With this we would have solved the questions of how to react as a company, and a lot would have been achieved. The thing with our own experiments will be part of the error classes. Is there an external impact? When do we fix? It is all the same.
Next thing to look at is the potential in our quality assurance, and here the real work starts. To define the reaction of our company to errors and to build error classes and so on, is something we do once. It might be a long process to get there. It might be difficult. It might be a lot of work, but we have to do it just once. After that, it is part of our never ending circle of joy in our control loop and will be reviewed again, but it will not cause work over and over again.
But if we start to replace the question who has done it with where is the flaw in our system causing this thing to go unnoticed, we will be forced to work on our quality assurance over and over again. We will have to work on our test systems and find ways to fix holes. We will be forced to work on and with the people involved. We will have to work on our processes over and over again. That is not only exhausting, it costs time and money and lots of discipline, but it will lead to less errors produced.
We will have to look for the flaws in our system over and over again – not every time. Not with the smallest mistakes, that bear no consequences, not with our entry error class, and maybe not with our second. But if things get more expensive, a proper error culture will be less expensive in the long run.
Of course, fixing an error and not asking the further questions is simple and does not require lots of work, while looking for a flaw in a system and fixing that may cause much more work. Therefore it is an investment. Having to fix the same error a couple of times changes the math. Avoiding bugs in our products, that may cause negative experiences of our customers and a negative image, changes the math again.
As already indicated above, due to the error classes, we also have different scales in our organization that are affected. Small stuff can probably stay within the team. A bug fix will be prioritized at some point and the job is done. There is no need to worry about corporate communications and a coordinated effort to debug. Nevertheless, it is also helpful here if different teams have at least similar reaction patterns. That helps us with our customers and users as well as in the internal coordination. We don’t have to make that more complicated than it is, but we should at least agree once on how we should basically handle small things.
Above many of our considerations and actions is the desire to objectify mistakes in order to avoid them in the future. A witch hunt with subsequent punishment of the person responsible does not help anyone. We do not want to say, that a mistake is a good opportunity to learn from it – I just can not stand that term anymore – we want to solve problems. We can only do that, if we look at things objectively and soberly.
If we have an opening in our quality assurance, causing similar errors to be shipped more than once, we do have of course a flaw in our system, that can not be fixed by kicking someone, who was unlucky enough to produce that particular error this time.
However, that does not mean that in the case of (let’s call it) gross negligence, we will not also have unpleasant conversations. But not much is gained with a pep talk, we want to find out how we can avoid these things in the future.
Error culture does not mean that everything is allowed and remains inconsistent, it means above all that things are objectified.
Core: The term »error culture« says nothing more than that we have a defined, consistent handling of errors. We have to work out what this looks like. Our goal is to use our error culture to adapt our approach, e.g. in quality assurance.
If you would like to find out more, if you want me to work with your teams and managers on this and other topics, simply speak to me.
