“A golden bridle does not improve the horse.”
― Seneca the Younger

Recently, I had a few interesting conversations with my fellow colleagues about marketing and selling DevOps expertise. After a lively thought exchange and hearing opinions from people with a different professional background, we had several distinct offering formats to evaluate. Folks from engineering suggested to build our offer around specific technologies that are often associated with DevOps; business representatives talked about presenting DevOps as a solution to common challenges in modern enterprises; people from sales and marketing voted for something that can be packaged and easily sold on a mass-market or offered as a service with clearly defined terms and conditions. Here an intense debate started. As time passed, the only common ground we found was the understanding that we needed disambiguation for the term ‘DevOps’ as each person saw it differently.

I already wrote a post about common misunderstandings of DevOps, so my next thoughts will be mostly based on the ideas explained in it.

DevOps as a technological marvel

Building an expectation towards DevOps on specific tools or technologies is a common fallacy. Although we cannot withstand the fact that some tools and technologies have gained a strong association with DevOps methodology, it has such an extensive range of applications that no single software can address them all at once. Apart from that, each DevOps-enabling application is usually focused on one specific practice like build or deployment automation, configuration management, monitoring, etc.

As a result, if you build a foundation for DevOps expertise on a single tool, you will drastically narrow your focus area to few practices only. Although such an approach is fine if a client already has a clear understanding of the target area to improve and defined success criteria, in more complex environments, most challenges cannot be solved in a purely technological way.

One more caveat is the usage of ‘DevOps’ term in a software product name. Overall, it has a misleading effect as many people seriously think that if they use that software, it makes their work DevOps-aligned, which, of course, is not true. It is like believing that buying a new pair of running shoes will make you an Olympic champion.

DevOps as a solution

If we consider creating our own product for implementing DevOps or a list of different tools that combine a solution, we still will be talking about a subset of mostly technical practices that is only a fraction of what DevOps is. Additionally, implementing that solution for the sake of the solution itself won’t benefit your clients if they don’t understand what specifically should be improved to archive their business goals.

Trying to compile a list of tools that should bring your clients to a DevOps era won’t help you either. That list might quickly exceed a few hundred items and overwhelm you with the amount of work to implement them. Of course, there are known blends of technologies which play nicely with each other, but that should not deceive you. Having proper tools is one thing; knowing how to apply them most effectively in a specific case is another.

Also, as there is no magic potion to cure all diseases, there is no universal solution to solve all challenges DevOps addresses. So, in most cases, the best you can do is to limit your DevOps solution to a limited range of tasks it should solve. What is more, when talking about business value, connecting the dots between specific DevOps practices and resulting business outcomes is not a trivial task, especially on a large scale.

DevOps as a service to consume

Many IT companies try to offer DevOps as a service, which might be an intriguing option for clients that prefer to outsource their non-core activities. At a quick glance, it seems like a great idea – if you can outsource accounting, logistics, facility maintenance, etc., why not do the same regarding DevOps? The trick here is how you perceive DevOps in your organization.

Providing such functions as services imposes certain constraints on them. In the case of traditional outsourcing domains, the business usually sees them as stream-aligned operations with well-defined inputs and outputs. As a result, to perform those operations according to the respective service agreements, service providers restrict service scope to a limited range of atomic functions in order to make the service manageable.

In contrast, DevOps as a methodology is not limited to a single function but encourages you to experiments with multiple practices to find out what works for you the best. Finding a proper balance between the flexibility and limitation of your DevOps services might be a hard challenge on its own as one combination of DevOps practices might suit the needs of a specific client segment but have no value to other ones.

Apart from that, you should also distinguish between DevOps as a consultancy service and DevOps-enabling software that is offered in the form of subscription-based service. In the former case, you pay for professional consultancy and training; in the latter, you mostly cover the license cost of a specific product.

To conclude

DevOps is not something you can buy with money; it’s what you practice. Practicing it is is similar to developing good habits at both individual and team levels. Day after day, deliberately and progressively. Experimenting, failing, learning from those failures, and seeking new ways to improve.

A DevOps consultant is like a coach, he or she can teach you how to play, but it must be you actually paying that game to win it. It’s you who must learn the basics, show up on the playfield, experience the hardship and toil of exercises to get better at what you do. Champions won their prizes, not simply buy the medals.