It’s been said many times before, but culture truly is a crucial aspect of any DevOps journey. Cultural changes usually form a big part of any DevOps undertaking – and with the wrong mindset, it’s easy to end up with a culture of blame.
Collaboration mitigates blame
The crux of a well-functioning DevOps culture is collaboration. Clearly, collaboration between the development and operations teams is important, but collaboration needs to span all teams for the benefits to be felt widely. This collaborative mindset immediately reduces any tendency to blame others, as you share the same goal: To deliver the best product as quickly as possible.
In all systems, failures are inevitably going to occur at some point. Commonly, post-mortems are held to get to the bottom of the issues and determine actionable outcomes. The goal of the post-mortem is to learn from these failures to prevent recurrence and improve the quality of the deliveries.
It’s not personal
When something goes wrong in a team that follows DevOps practices, the core principles mean that the fault doesn’t lie with any individual but with the system itself. This idea shifts focus away from blaming individuals, and tries to maximise the improvements made after the event. Punishing or reprimanding employees generally has no positive effect in the long term. If there is any risk of blame or reprimand then the employee is de-incentivised to give full details about the situation and decision-making process of the failure. This means that any investigation cannot be thorough enough to determine the full context.
Blame – even directed inwards – is a negative thing and doesn’t help to gain insight into the context of the situation or how to reduce the risk in the future.
If the underlying vulnerabilities in the system are not addressed, the situation is very likely to recur, if not with the same employee then with someone else. There is no improvement or moving forward here.
Considering the bigger picture
To establish this blame-free culture, management needs to model the behaviour that they hope to achieve. When determining the failure causes, it is important to remember that whatever action the employee took made sense at the time, so we need to understand the factors which lead them to make this decision.
Human error should never be attributed as the root cause as this does not provide any useful basis to make improvements going forward. Instead we need to understand how the error was possible, and try to prevent it from being possible again. By analysing failures in this way, an organisation can become safer than it would be had it simply punished the relevant employees. Only by constantly seeking out and shrinking vulnerabilities can organisations reduce risk.
Remove the fear of repercussions
Once the blameless culture is established, and employees can freely discuss their mistakes, they can become passionate about helping others to avoid the same mistake. Employees are likely to be motivated and should be enabled to improve processes and systems to reduce the risk of future issues. Without any fear of repercussions after failure, employees will feel more confident to experiment with changes and innovation. This means that there can be a positive culture of improvement and optimisation – which produces better business value.
Producing more business value with ongoing improvement and optimisation while collaborating with the whole team is at the heart of true DevOps.
Want to know more?
To learn more about incorporating DevOps in a structured way within your business, download our DevOps Solution Brief and discover how we can support you to rapidly build the necessary framework.
Contact us to have a conversation with one of our DevOps experts today!
Bronwyn Davies
Latest posts by Bronwyn Davies (see all)
- Winner! Unicom Most Innovative Project 2023 - 27th February 2023
- Sandhata Gini – Our internal chatbot - 1st February 2023
- Goodbye 2022 - 19th December 2022