Not blaming individuals in at the heart of DevOps. This is done objectively to ensure constructive experimentation. The line to draw is how far are you willing to let the blame fall on the entire team rather than individuals. Or are we shrinking individual’s accountability under the garb of shared responsibility? The answer to these questions is somewhere in between and is not a pure white or a black.
The concept of blamelessness is wonderful for the ears in the flattened world. It rings bell-a-plenty with being inclusive and promoting team growth. But if it was ever believed that being blameless was boundary-less, then the skeptics were dreaming.
DevOps is firmly behind shared responsibility – for a reason. The methodology wants the team to experiment and be wild in order to innovate. The safety net is the process and the tools that don’t let things blow up. The mistakes and the experimentation are done in a progressive way and not in a repulsive manner.
What do I mean by this? If you end of making mistakes the first time and even after rectification continue doing the same mistakes, blamelessness does not give you the cover. If you fudge your efforts to make up for the shortfall of your productive hours, once again blamelessness is not your shield. If you wanted to find an alternate way to cut down on the technical debt, which ends up fusing the application, the DevOps processes and tools identify the bug early in the game and nobody is going to hold you responsible for it. For the optimist, you might have identified one of the ways the logic that won’t do.
To keep things simple in DevOps, do what you think is right and learn quickly from your mistakes. Nobody is going to blame but rather the team would embrace you into the group of sharing responsibilities. Their successes will be yours and likewise. Blamelessness should be a launchpad for innovations and not a sponge for soaking in generosity.
