Blameful vs Blameless Culture: Which is the DevOps Way?

Blameful vs Blameless Culture: Which is the DevOps Way?

- in DevOps
581
0

SCENARIO: A major release has gone bust, taking down an e-commerce site for sixteen minutes.

In this scenario, when a major release tanks, operational and development teams start firefighting almost immediately. Later they roll back the change. When the rollback is complete, a root cause analysis is performed to identify the reason for the release failure.

All the post-failure activities are fine, but what is being felt deep down? What are the thoughts running in the minds of project managers and team members?

Who is the person who developed the piece of code that caused the failure? Who is the tester who has signed off on it?

Although processes look objectively, finger pointing begins almost immediately. People start pointing fingers mostly at the developer and also at the tester. In other words, the blame game begins!

Blaming individuals for failures is the culture that we embrace. We blame others, and others blame us when we fail. We have come to accept criticism in the face of failure. This embeds fear in our unconscious minds and affects our ability to innovate.

Innovation is a result of fearless antics, and has been set as a benchmark for success, respect and prosperity.

The DevOps way is the answer to innovate. How different is the DevOps way you might ask when we refer to fear and the blame games people play?

DevOps expects people to make mistakes. We are humans, imperfection is our middle name. DevOps therefore designs processes that allow mistakes made by imperfection minds to be identified early on in the cycle, and have them rectified before going any further.

DevOps culture does not believe in blaming individuals, but instead builds a support system that catches defects during the development lifecycle.

The culture that is adopted in DevOps is a blameless culture. People don’t blame others for the failures as there are measures and checks in place to capture the errors in the developmental stages, and not place bets in the production.
This way of working allows developers to work fearlessly, try new things, and come out on top. It is always important for the system to provide an ecology, where innovation can happen, and DevOps puts its weight behind people, and help them succeed.

In DevOps oriented teams, there is a sense of shared responsibility where the entire team collaborates and produce results as one unit rather than being me vs you. When you start working as a unit, there is a synergy that supports members of the development team to aid each other when they are hit against a wall.

Originally published on iDevOps

About the author

Abhinav Kaiser is an author and a management consultant. He has authored Become ITIL Foundation Certified in 7 Days and Workshop in a Box: Communication for IT Professionals. He works as a consulting manager for a top consulting firm. He advises businesses, organizations and enterprises in the areas of DevOps, IT service management and agile project management frameworks. Social Media : Facebook | LinkedIn | Twitter | Google Plus

Leave a Reply

Your email address will not be published. Required fields are marked *


You may also like

Incident Management Lifecycle – Incident vs Request

In the second set in the incident management