DevOps has many different meanings depending on the perspective and experience of anyone you might ask. The tech industry generally aligns on DevOps being a set of practices and culture that an organization adheres to in order to deliver operational excellence. DevOps should not be a team, a set of tools, or something you can bring in a consultant to apply to your organization. Excellent leaders in the DevOps space realize that self-reflection and attempts to correct any issues are the most effective ways to improve.

If there is anyone in the landscape of technology I trust most to come up with a succinct set of definitions for operational capabilities, it would be Martin Fowler. So I general work off the definition of DevOps Culture posted on his site by Rouan Wilsenach. Summarized here are the highlights of these tenets:

  • Increased Collaboration
  • Shared Responsibility
  • No Silos
  • Autonomous Teams
  • Building Quality into the development process
  • Feedback
  • Automation

In software development practices (both engineering and management), there are studied issues that hinder the success of projects known as anti-patterns (Wiki definition, and read more here). Over the next week I will discuss some anti-patterns to positive DevOps culture, how to identify them, and what to do to fix them. Based on the above definition, here are the anti-patterns we will look to recognize within our organizations:

These are high level points for very large swaths of problems, and ones that myself and the engineers around me have worked very hard to eliminate over the past five years. The toughest thing about these issues is that to do these for yourself will require working within the confines of the system you are a part of. People do not get “more people” so they can do DevOps, nor “new tools” to succeed. There will be a measure of risk anyone must burden in undertaking these capabilities.

As in anything worth succeeding at in work or life, there will be the opportunity for failure. But how you respond to and change from those failures will determine the outcome. Few people are fired for trying to make things better. If it happens then, it is possible you have had favor in that process to get out of a place so toxic as to resist change at levels all the way to HR. Best of all, a DevOps journey is just that, a road in which the final state is always reset once you cross the finish line and head towards the new goal.