Willy-Peter Schaub

833 points
User profile image.
Vancouver, Canada

Since mid-’80s, I have been striving for simplicity and maintainability in software engineering. As a software engineer, I analyse, design, develop, test, and support software solutions. I am passionate about continuous innovation and to share learnings from the digital transformation, by Microsoft and the ALM | DevOps Rangers, to a DevOps culture to adapt people, process, and products to continuously deliver value to our end users. You can follow me on www.linkedin.com/in/wpschaub, https://willys-cave.ghost.io, https://twitter.com/wpschaub, and https://www.agents-of-chaos.org.

Authored Content

Authored Comments

Thanks for your feedback.

Your question is a good one and one for which we are trying to find an antidote. Alex talks about a blameless DevOps in his https://opensource.com/article/19/8/failure-feature-blameless-devops article, which highlights one root cause for the fear of failure … blame.

In a team environment based on trust, vibrant debate, commitment, and accountability there is an appetite for experimentation, an acceptance for failure, and an understanding that failure is an opportunity to learn and improve.

Holding up a release, delaying a deadline, being a bottleneck, or getting a lack of feedback are challenges that the team is accountable for, not individual team members. By standing your ground as a team, you minimize the opportunity to blame and demotivate individuals, which in turn becomes toxic for the team.

Trying to “poke the hornet’s nest” … which is something we are continuously doing these days q;) … is a way to enable and encourage innovation, rather than provoke. It works best when we have a culture that embraces experimentation, continuous innovation, consuming failures as learning opportunities, and scorns blame.

To get back to your question. Trust is the pillar of a healthy DevOps mindset and many (if not all) of the fears and dysfunctions originate from a lack thereof. For example, traditional and centralised management will be reluctant to trust a team that swears on agility, experimentation, failure, and is continuously open for business.

You may need an experienced coach and facilitator, to drive transparency, information sharing, position teams and its members as an asset not a liability or punching bag, and set up a foundation of trust.

Remember, DevOps is a continuous journey without a destination. Changing attitudes and eliminating fear will take time!

Thank you! We'd appreciate your candid feedback on what and why is essential in your environment.