A few years ago I watched a very interesting documentary about World War 2. Amongst the new facts I learnt, what surprised me the most was all the chances that Hitler had to win the war, and how the Nazis’ blame culture was one of the factors that contributed to their defeat.
Hitler’s generals were afraid of the consequences of failing in the battlefield. Nobody was willing to acknowledge any mistakes, errors, or misfortune, so only good news was reported, and bad news was disguised or just not reported at all.
Any successful company should already know the power of a blameless culture, and how not following it puts them in a disadvantage.
That said. What does it mean for Software Developers? Let’s check.
In the rest of this article, I will assume that you are working in a company with a blameless culture. If you’re not, maybe you should consider a position somewhere else.
Processes
We mere humans are destined to make mistakes. It’s in our nature. Even the most talented people in any field make mistakes sometimes.
Because Software Developers are not an exception to this, we have processes in place to prevent and catch our errors.
These processes should ideally be automated tools that will not make mistakes (they may have some bugs, but they’re still better than trying to rely on us alone). Take for example a linter: it is a lot better and faster at spotting all the bad indentation in a PR than the author or the reviewers.
Even when using tools in our process, there is always plenty of room to improve. For instance, is the linter checking all directories? Are the automated tests running? Will deployment be blocked if there’s a failure? If an uncaught error is released, will a notification be sent? Will the right people receive the notification? Will these people have the tools and knowledge to solve the problem? And so on.
Because we make errors in all sorts of things, the same idea can be applied to everything we do. For example, if you always make the same typo when running a command in your terminal, you could add an alias with the typo! Next time you make that typo, you’ll still run the intended command.
Five Whys
A technique commonly used to root cause issues is the Five Whys. In summary, that means asking “why” a problem occurred, and then ask again until you have asked it five times in total.
There is a catch though.
It’s not about you, it’s about the process.
I’ve noticed that people sometimes get defensive when asked why a problem occurred.
In a blameless culture, nobody is trying to blame you. We ask “why” to understand what part of the process failed to prevent or detect a human error, as it is likely that another fellow human will make the same mistake in the future.
For example, recently I helped to identify the root cause of a problem that got to production and was live for about five hours before anybody noticed (except our users, sadly). A developer made a mistake, sure, but that’s irrelevant. What’s really important is why our system allowed this error, and why the system did not report it in a timely manner.
In our case, we identified that the root cause was lack of appropriate testing for this feature, and lack of monitoring in this area to report about this kind of failures.
No pointing fingers
If you make a mistake, expect your name to be called out many times when talking about a problem you were involved in, but not to blame you.
Making a company-wide or public announcement naming you as the person introducing the bug would be completely inappropriate, but adding your name in the incident ticket so you can be reached out for questions is expected and necessary.
The fact that you were involved in an issue is exactly that, a fact. Facts are important to have all relevant information to solve problems and avoid them in the future. Whoever was involved or caused a problem or incident has the most context on what really happened and can help fix it and prevent it, so it just makes sense to know who this person was.
Once I worked in a team where some engineers felt deeply offended because someone asked them “why” about an issue, and even reached out to HR because of this unfair treatment. True story. They decided to give that question the wrong intent.
Just like it in that story, it is up to you how you decide to interpret when someone asks you why. If you have a growth mindset, you will understand that people is just asking a question to get information.
It takes personal growth to understand that nobody is pointing fingers at us when asking why. Reassurance and support from your team are key to develop this skill.
Support your team
This could be surprising to you, but not everyone has experienced a blameless environment.
Lots of people come from different cultural backgrounds and have lived different experiences. In an ideal world, everyone should have the benefit to make mistakes and learn from them, but life doesn’t work like that.
Particularly, consider new graduates or trainees. They have little to no professional experience, and they want to showcase how awesome they are. Imagine their terror when they make their first big mistake if they think they will fail their evaluations.
As a more experienced developer, or somehow who has been part of a blameless culture, it is your responsibility to look after those who have not and help them so they can really be part of this culture, and not be afraid of making mistakes.
There’s a limit
Blameless cultures accept that we make mistakes, but also expect that we learn from them.
If you make a terrible mistake, learn from it. Nobody will blame you if you screw things up, we all understand. I promise. However, everyone will also expect that you will learn some lessons, and that you will not make the exact same error again.
Imagine that someone deletes all data from the production database. It is expected that this person will add some safety checks on the way they work, in addition to any improvements to the company’s process. Any reasonable step must be followed to prevent the same mistake from happening again.
Now imagine that this person deletes all data from the production database five more times in the next six months by making the same mistake over and over. Does it sound like this person learnt anything at all?
Blameless culture has its limits. Some companies may be more flexible than others, but you don’t want to test them. Just make sure that whenever you make an honest mistake, you learn from it. If you do, that will be the end of the story and you will have gained a funny anecdote to tell later on in your career.
A blameless culture is the best way to allow the best of us to flourish, but it requires courage to acknowledge mistakes.
When following the Five Whys method you will be asked tough questions, so you need to have a growth mindset to understand that nobody is trying to rub it in your face, and that there is no need to become defensive.
If you feel like this, speak with your manager or someone experienced you can trust. If you are someone experienced in your team, look after teammates that could be more vulnerable.
And lastly, always learn from your mistakes!
Cheers,
José Miguel
Share if you find this content useful, and Follow me on LinkedIn to be notified of new articles.