“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 building 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 ignore the fact that some tools and technologies have gained a strong association with the 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 a 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 use of the ‘DevOps’ term in a software product name. Overall, this 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 will still talk 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 achieve 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 that 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 the 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. Moreover, 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 who 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 experimentation with multiple practices to find out what works best for you. 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 others.
Apart from that, you should also distinguish between DevOps as a consultancy service and DevOps-enabling software that is offered as a 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 similar to developing good habits at both individual and team levels. Day after day, deliberately and progressively, experiment, fail, learn from those failures, and seek 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 playing that game to win it. You must learn the basics, show up on the playfield, and experience the hardship and toil of exercises to get better at your work. Champions won their prizes, not simply buy the medals.
