Will your DevOps transformation ever be over?

By now you may have already realized that DevOps transformation doesn’t only involve software development and IT operations. Today’s DevOps is business thinking at the highest level. A major part of DevOps is taking ownership of the results of your work, understanding those results, and having them change the way you make decisions right now.

DevOps belongs in the C-Suite

The most powerful form of DevOps happens in the C-Suite because the best DevOps transformations involve everyone and the big picture is crucial. Without this perspective, your DevOps in digital transformation will be limited to individual teams, will be slower and more expensive, and will not lead to optimal results.

C-Suites can mobilize their whole organization, working as one seamless operation, without teams expecting others to deal with potential problems later. In order do this, every team needs to have a DevOps attitude, taking responsibility for the results of their work all the way to production deployments and maintenance. The birth of DevOps was in IT, where it created a common goal between developers and IT operations to automate repeating processes, reduce costs, and make shorter time-to-market a reality.

Nowadays, the only place DevOps can reach its full potential is in the C-Suite. DevOps should support top management decision making (innovations, new products, new markets) and further a fast operation while being backed by automated metrics to prove it’s working.

Your DevOps transformation should have an expiration date

The full results are achieved only once the transformation to an organically evolving organization is complete. This means you need to pursue and demand that from the very start of your transformation path. For the transformation to ever be over (because your organization is running as an advanced DevOps organization on all levels, including C-Suite decision making), it needs to have an expiration date.

For your DevOps transformation to have an expiration date, you should think twice before setting up distributed in-house DevOps departments, or at the very least plan ahead to what will happen to your organization when you complete your transformation. You risk creating DevOps Team silos (see ‘Anti-type B’ as illustrated on DevOps Topologies), where the responsibility of executing DevOps sits with the DevOps Team and not with every team in your organization.

Instead, a DevOps transformation should be seen as distinct projects that are executed to a pre-agreed timeframe with an endpoint (expiration date) where your organization has taken all the benefits of DevOps and is executing and sharing them on a day-to-day basis.

The four stages of a DevOps transformation includes an expiry date at the end

Why don't businesses set a timer on their DevOps transformation?

The principle way companies make DevOps transformation an ongoing ordeal is by hiring in-house DevOps experts and integrating them into their existing teams, or building a new DevOps team.

This has the immediate benefit of looking like it costs less than hiring a consultancy. And yet in the long term, it is more expensive because those employees remain on your payroll and you need to find new projects for them once the DevOps transformation is complete. The danger is that after the first part of the transformation, your own DevOps engineers (who would be better suited for efficient development work) cling on to the DevOps responsibilities that should be shared among the team or organization.

But isn’t hiring in-house DevOps experts the best way to retain DevOps knowledge after the transformation is complete? It may seem so, as DevOps experts remain part of your department. Naturally, working with consultants holds the risk that they will take the knowledge with them, leaving you dependent on more consultancy. Yet in-house experts come at a cost: having those DevOps experts as a permanent part of your organization communicates to other staff (including C-Suite) that DevOps responsibilities do not sit with them, thereby greatly decreasing the effectiveness of your software production, the development teams, and your DevOps transformation.

The benefits of a DevOps transformation with an expiration date

I've touched on the benefits already. Here are some more reasons to take this seriously.

1) Expiration date transformation reduces costs in the long run and makes them more transparent: you have an estimated price tag on how much any distinct step or pursuit of your transformation will cost.

2) The end result of a transformation should be an organization-wide DevOps machine. If you choose to build the machine with external help, remember that the parts in the machine are your developers and technical management, and the machine only works once those developers know DevOps very well. That’s how the DevOps knowledge that is relevant to producing value in your organization stays in-house. Otherwise, you could argue that the DevOps transformation is not complete.

If, for example, you start doing the DevOps transformation with a DevOps consultancy company, you right away gain the best practice from the organizations the consultancy has worked with before, only now tailored for you. When you hire individuals, any experience from other organizations ends when they begin their work with you.

3) Speed is very important. Shorter lead times are an advantage that industry leaders around the world already have, which makes DevOps more than a nice-to-have and is one of the reasons it's becoming an executive target. By setting an expiration date, you recognize that DevOps transformation is not some far-away goal but an end goal that an increasing number have already reached, and one that your organization wants to arrive at as quickly as possible.

Your DevOps transformation should have an expiration date. Does it yet?

There's no need to create a new team in your organization that shouldn't have been there in the first place just to help your organization run more effectively. DevOps is no more than good strategy, open and supportive culture, taking responsibility, sharing best practices and automating everything you can. It’s not a separate entity, which is why it shouldn’t be a separate department.

Sceptical? The first step is the DevOps assessment and roadmap, even if you’re planning to do your DevOps transformation in-house. If you want to hear more about this, please get in touch.