English | EN 
DevOps transformative journeys are not cheap for any organization to embark upon. There are the tangible costs of around the infrastructure necessary to support your journey. And there are the intangible costs associated with things such as: lost development velocity, and the intrinsic cost of the necessary organizational change. I do want to be clear that in this case infrastructure in this instance not only refers to the servers supporting the new tools that you will need to acquire, but also the cost of any new software that you will need to purchase to support your automation, along with the supporting business “infrastructure” (redefined teams, new processes, etc). Licensing costs and the trade-off of different version of software, Visual Studio Professional vs. VS Enterprise and IntelliJ vs Eclipse as examples, is an exercise best left to the reader.
Let’s not forget about the cost of employee turnover either. As an ex-developer, I always found that the companies that I didn’t like working for, were the ones where their PROCESSES got in the way of me performing at the level that I felt I was able to achieve. If you have been following my posts you will probably see a common thread in regards to DevOps; it is about the people and process, where tooling supports these two pieces of the DevOps philosophy. Also, as I like to provide thought provoking questions in my posts, I want to pose this one to you, the reader, “How much do you spend on licensing for numerous different tools, how much does down time cost you, and how much does employee turn-over cost (or how much does it REALLY cost to hire a new engineer due to acquisition costs, and reduced productivity)?”
So how can the business justify an evolution and modernization to their current software development practices? Metrics, KPIs, and industry reports to the rescue! Due to the proliferation of the DevOps philosophy, finding this information is getting easier. In most cases anymore, it can be had for the low, low cost of your email address (but don’t worry, you can unsubscribe later). For the rest of this post, I am going to borrow heavily from Puppet’s State of DevOps Report 2016. Puppet does a great job every year of quantifying the current benefits for organizations to embark on a DevOps Journey.
So let us take a look at the easiest thing to quantify, the acquisition of a new employee. Our numbers for an acquisition looks like this:
- Software Engineer
- Salary: $100,000USD
- Recruiter cost: 20% ($20,000USD)
- Expected ramp up time to full productivity: 9 months
We have to spend $20,000USD just to ACQUIRE a resource. Once they start working, and we will assume that they start on the first day of your fiscal cycle, you will subsequently pay $75,000USD, just to “train” that employee. So all told, you have spent $95,000USD in 9 months, for a $100,000USD employee. What if we can retain that employee? What if we can reduce turnover? According to Puppet’s report, employees in high performing organizations are 2.2 times more likely to recommend their place of employment to their peers.
While every organization will always have turnover, what happens when we are able to reduce it? If I am willing to recommend my employer to a peer, does that mean I have any plans of going somewhere? Probably not. Not only will I want to stay, I will also become your recruiter (for FREE!). The point here is that embarking on a DevOps journey helps to prevent “brain drain” from within your organization, thus maximizing the value you will obtain from your current employees. The reduction of recruitment costs is just an added bonus.
That’s great you say . . . but recruiting costs are “insignificant” in the grand scheme of things. To that I would say, you are right; but the $75,000USD you spend training a new hire adds up quickly if you have 100 engineers, and a 25% turnover rate.
One of the major KPIs that those of us in IT are usually measured on, directly or indirectly, is how many outages per year we have. Outages for an application can cause both direct and indirect costs. Directly, we may lose sales, or fall afoul of regulatory requirements and be fined, just to name a few. Indirectly, we may have lost brand good will, lost faith in our product / offering in the case of a SaaS solution, impacted other areas of the business, caused work slow-downs, or even lost a bid on a new contract.
So the question becomes, “How do we quantify this down time?” If we run a website that is an e-commerce solution, this number is easy to quantify. You take the average amount of sales per hour and multiply it by the number of hours of outage, add in labor for your employees working on the outage, and don’t forget to add in the cost of lost productivity from your engineers not working on moving the product forward. For other, non e-commerce, based solutions . . . Puppet’s report to the rescue!
For Puppet’s State of DevOps Report 2016, they provided the following chart:
But “WAIT!!!” you say. High performing organizations spend more on downtime than low performers. If you are trying to save me money, or even help me help the business to earn money, then why are you telling me that I need to become a High Performing organization? One thing that we have to look at, when viewing this data, is that this chart assumes that every deployment requires an outage. If we fix our process to shift quality left, while implementing appropriate deployment models, how often does an outage occur? If we have followed our DevOps Philosophy, then very rarely, if ever.
What is not covered in this chart is what is the lost business value during our Mean Time to recover metric? Or in other words, what is the intrinsic loss of business value? How many new sales are we not capturing? How many customers are we losing, to never get them back? This chart only shows the cost to an organization, based upon an outage cost of $500,000 per hour.
Bringing it Together
I titled this blog post “DevOps isn’t Cheap”, maybe I should have titled it “Not Embarking on a DevOps Journey isn’t Cheap”. In reality though, the cost of getting to a mature organization is going to be costly. Disruptions to development, new tooling, training, redefining processes all have a cost. Some of these are quantifiable costs as we can measure the lost development velocity, we can show the cost of the new tooling, we can show how much we spent on training. Some of these costs are intangible, and mostly fall around the question of “How much in potential business do we lose every year as we continue to do things the same way we have been doing them for years?”
When looking for an ROI on your investment in your DevOps Journey, it is safe to assume that it will be two to three years before you see significant savings in effort (especially from a financial planning standpoint). But if you are looking to provide a good strong estimate for your budget, think about things this way: if after one year, you can save 10% on your engineering efforts, how would you make that argument for the investment?
As I like to close my posts with a question . . . “What would you do with 10% more engineering time?” (I really LOVE the points made in Puppet’s State of DevOps Report 2016)
