A “DevOps Engineer” Is Not Your Missing Link to DevOps Maturity

When I was first enlightened to the Agile Manifesto, I was an enterprise IT Service Management practitioner, occasionally feeling more like a hindrance to the software delivery process, rather than a helper. I felt like my eyes were opened as I discovered this passion for DevOps that grew within me. Ironically, I wanted to transform my surroundings into DevOps culture all at once with a “Big Bang”. I was very excited to evangelize DevOps to my colleagues, but many of them were skeptical at best and I constantly had to remind myself that change doesn’t happen overnight. I thought the solution was to create a new DevOps Engineer role that I could help bridge the gap between Dev and Ops. This did not happen like I hoped it would. But as they say, fine wine gets better with time and as I matured over several years, I gradually introduced new DevOps concepts in bite-sized chunks, built a structured road map, and I began to see the fruits of the fundamentals by simplifying our ways of working. I broke it down into five fundamental questions about DevOps maturity.

1. What do my business leaders need from my team and what problem(s) am I trying to solve?
2. What are viable ways to solve these problem(s) with the skills I have in-house?
3. What are some ways to foster hidden DevOps skills, encourage new leaders, and promote cross-training to develop more T-shaped skills models?
4. Have I implemented very basic Agile principles and processes with the tools I have to establish velocity and productivity metrics for my team?
5. How can I create measurable mechanisms of accountability, such as SLAs and OLAs, for my team to be held accountable by our business leaders?

I imagine my story is not unique. Many tech evangelists are enthusiastic about the next big thing and we like to develop complex frameworks to handle major changes. In terms of DevOps, we may have overcomplicated some things as the DevOps train gained speed over the years. The benefits of DevOps are real, but DevOps practitioners must be more responsible by being better IT Leaders and better stewards of DevOps culture. 

No doubt, bringing in a DevOps Engineer to any organization at any maturity level will yield some immediate results, but they can only go so far and will quickly burn out if Senior Leaders and Executives do not understand the major roadblocks of traditional org structures. Before any IT manager drops a job posting for a DevOps Engineer in hopes to get immediate value, I think it is important to go back to basics of their own business and evaluate themselves based on these five questions.

Each of these questions can spawn major initiatives of their own right. Do not underestimate them. Even if these questions have been answered it is good to regurgitate them with your stakeholders quarterly, at minimum, if not more frequently to better evaluate the growth and health of your team. Each question should be associated with a maturity model, such as a Capability Maturity Model (CMMI). From within one’s own IT team, “maturity” can seem like a subjective interpretation when self-evaluating, but so long as your stakeholders agree on measurement criteria it can be a powerful driver in your DevOps journey. This is what a CMMI does - it helps your team establish real criteria for levels of maturity.

Let’s go out on a limb and say that your IT team has self-evaluated their Agile and DevOps team maturity as a Level 2 or Level 3 using CMMI. At this point, team members are likely to have some common language in the Agile framework, they understand the general principles of DevOps, beginning to automate simple development or infrastructure requirements/tasks on a repeatable basis, and they are operating in a somewhat measurable manner. Even still, a DevOps Engineer might not be your “missing link” that will supercharge your team.

Given that an IT org should be understanding core concepts of Agile and DevOps, they should understand what “technical debt” means for their team. They should also understand how to identify and remediate some of this tech debt. In personal finance, how do you pay down on debt? You create margin in your daily activities to pay off debt little bits at a time. Same is true for tech debt. Know that tech debt isn’t just code that needs to be refactored, or improving log monitoring, or that nagging error thrown when a user session ends instead of rerouting safely to the login menu. Tech debt is also future debt, similar to how a municipality uses set aside funds to upgrade roads and bridges in preparation of a new heavy industry. In software terms, that could be improvements to your software delivery pipeline, or creating flexible, ephemeral infrastructure through automation. You may choose to use your team’s existing knowledge of things like good source code management, or build and unit test automation to create repeatable, consistent, and reliable flow of code to Dev and Test environments.

The point here is that a DevOps Engineer that really understands their value can certainly be worth their weight in gold, but a great DevOps Engineer also acknowledges that the members of an existing team could be better off leveraging existing skills and capabilities, rather than adding a new functional DevOps role to the team. Consider creating a DevOps Center of Excellence, or an internal “DevOps Dojo” community of practice that focuses solely on facilitating continuous learning and improvement for existing Product Teams. Try these alternative ways to build effective DevOps team structures to help unlock hidden potential in your journey to DevOps maturity.