DevOps Value

“I spend a large portion of my customer face time speaking with financial executives.” – FP Complete Engineering I am always surprised to learn how often they fail to invest any time in calculating the ROI on DevOps. They do on everything else, so why exclude DevOps? To put this in terms they can understand […]


“I spend a large portion of my customer face time speaking with financial executives.” – FP Complete Engineering

I am always surprised to learn how often they fail to invest any time in calculating the ROI on DevOps. They do on everything else, so why exclude DevOps? To put this in terms they can understand I will often ask them to write me a check for some big number relative to their business. For example, I’ll say something like this “Can you write me a check for $250,000, so I can pay for the last couple of outages you had?” When they hear a big number like this, of course, they recoil and say, “We don’t have the budget for that!” My obvious response: “Sure you do, you are paying for this all the time, but not as one lump sum.” And that is the crux of the issue. It’s death by a million little cuts. It’s six hours of downtime here, two lost customers there, losing a staff member due to burn out here, lost productivity there. It all adds up, and when you do the math, it can be downright scary.

It’s time to start doing the math on this huge financial drain and start thinking about how to get out of this technical debt. An easy way to look at this is to think of a simple tool like a hammer. Almost everyone has used a hammer at some point in their life. Sure it has its drawbacks, if you ever hit your thumb, you will know what I mean, but it works. Now, if you had to build an entire house, that hammer doesn’t seem so great after a while. When you watch construction workers with a nail gun, it’s amazing to see how many nails they can drive in a short period and never hit a thumb. There is no downtime, and everything happens quickly. At the end of the day, the easiest way to measure DevOps roots back to the principle, “Time is Money.” The central idea is to get your product to market as quickly and reliably as possible. In the case of the nail gun, there is a minimum speed gain of three times faster. In the case of DevOps, the math is not quite so simple, but it can be calculated. So the question is simple. Use a hammer or a nail gun? DevOps is the nail gun, and most companies are still relying on that hammer. Better tools, better results.

Let’s first take a look at the concept of velocity of revenue. This is a common phrase as it applies to DevOps ROI, but the core tenet is that the quicker you get your software to market, the quicker it generates revenue for your business. It has been proven empirically that when a company releases software, they get a revenue spike and that revenue falls off over time only to spike again during the next release. Now imagine you do a release once every three months. That’s four revenue spikes per year. With a proper DevOps implementation, it would be very reasonable to expect that you could release software every month, if not every week. Even at the monthly rate, you have created 12 revenue spikes per year as opposed to 4. Companies that create revenue from software releases should be measuring these revenue spikes. A simple calculation will tell you how much revenue you are losing due to infrequent software releases. Not to mention the hidden costs of not getting bug fixes and new features released on time. How many customers are lost to competitors due to your slow pace?

Another factor to consider with a modern DevOps approach is what costs are being avoided? The calculations here are relatively easy once you know your operating costs. For example, if your average salary for engineers is $65 per hour and each deployment results in four hours of extra time due to failures along the way, then you know that this costs you $260 per deployment. If you are deploying every week, you just saved yourself a tidy $13,520 per year. This is just one cost to consider avoiding. What about the cost of unhappy developers who are being pulled into DevOps tasks and start thinking there are better places to work and eventually leave. What about the lost productivity of that same developer who is not writing code while he/she fights with a failed deployment. Not to mention the worst case scenario: Your deployment brings down your production environment, and now customers cannot buy products or do their work. Suddenly, you have lost revenue or need to forgo revenue because you have not met your own SLAs. Not to mention the ill-will and bad publicity that results from these events.

So, what about the soft costs? The things we can’t seem to measure. Nicole Forsgren of Chef conducted research into this topic and has shown that companies that have high-performing DevOps teams are twice as likely to exceed their financial goals such as profitability and market share. To assess if your organization fits this criterion, you need to look at three criteria:

  • deployment frequency,
  • lead time to deploy and
  • mean time to restore.

If you score high in all three of these criteria, then statistically speaking, your financial performance will be much higher than if you scored low in all three criteria. In short, there is a very high correlation between DevOps and financial performance and that has been proven even without doing all the complicated DevOps calculations. Stop using that hammer!

Peter Drucker has said, “you can’t manage what you can’t measure.” When it comes to DevOps, management needs to take a more aggressive role in quantifying DevOps events. This may seem unimportant when you are fighting a deployment nightmare but when it’s over the damage needs to be assessed. When we measure, we create accountability and when people become more accountable they immediately seek ways to improve. Without this, you become a victim of DevOps Groundhog Day where you wake up every day repeating the same tasks as the day before until you feel hopeless. But if you do measure, learn, and adjust, then the next day will be different. Just ask Phil!

Start doing the math

It’s time to start doing the math on this huge financial drain and start thinking about how to get out of this technical debt. An easy way to look at this is to think of a simple tool like a hammer. Almost everyone has used a hammer at some point in their life. Sure it has its drawbacks, if you ever hit your thumb, you will know what I mean, but it works. Now, if you had to build an entire house, that hammer doesn’t seem so great after a while. When you watch construction workers with a nail gun, it’s amazing to see how many nails they can drive in a short period and never hit a thumb. There is no downtime, and everything happens quickly. At the end of the day, the easiest way to measure DevOps roots back to the principle, “Time is Money.” The central idea is to get your product to market as quickly and reliably as possible. In the case of the nail gun, there is a minimum speed gain of three times faster. In the case of DevOps, the math is not quite so simple, but it can be calculated. So the question is simple. Use a hammer or a nail gun? DevOps is the nail gun, and most companies are still relying on that hammer. Better tools, better results.

Let’s first take a look at the concept of velocity of revenue. This is a common phrase as it applies to DevOps ROI, but the core tenet is that the quicker you get your software to market, the quicker it generates revenue for your business. It has been proven empirically that when a company releases software, they get a revenue spike and that revenue falls off over time only to spike again during the next release. Now imagine you do a release once every three months. That’s four revenue spikes per year. With a proper DevOps implementation, it would be very reasonable to expect that you could release software every month, if not every week. Even at the monthly rate, you have created 12 revenue spikes per year as opposed to 4. Companies that create revenue from software releases should be measuring these revenue spikes. A simple calculation will tell you how much revenue you are losing due to infrequent software releases. Not to mention the hidden costs of not getting bug fixes and new features released on time. How many customers are lost to competitors due to your slow pace?

Another factor to consider with a modern DevOps approach is what costs are being avoided? The calculations here are relatively easy once you know your operating costs. For example, if your average salary for engineers is $65 per hour and each deployment results in four hours of extra time due to failures along the way, then you know that this costs you $260 per deployment. If you are deploying every week, you just saved yourself a tidy $13,520 per year. This is just one cost to consider avoiding. What about the cost of unhappy developers who are being pulled into DevOps tasks and start thinking there are better places to work and eventually leave. What about the lost productivity of that same developer who is not writing code while he/she fights with a failed deployment. Not to mention the worst case scenario: Your deployment brings down your production environment, and now customers cannot buy products or do their work. Suddenly, you have lost revenue or need to forgo revenue because you have not met your own SLAs. Not to mention the ill-will and bad publicity that results from these events.

So, what about the soft costs? The things we can’t seem to measure. Nicole Forsgren of Chef conducted research into this topic and has shown that companies that have high-performing DevOps teams are twice as likely to exceed their financial goals such as profitability and market share. To assess if your organization fits this criterion, you need to look at three criteria:

  • deployment frequency,
  • lead time to deploy and
  • mean time to restore.

If you score high in all three of these criteria, then statistically speaking, your financial performance will be much higher than if you scored low in all three criteria. In short, there is a very high correlation between DevOps and financial performance and that has been proven even without doing all the complicated DevOps calculations. Stop using that hammer!

Peter Drucker has said, “you can’t manage what you can’t measure.” When it comes to DevOps, management needs to take a more aggressive role in quantifying DevOps events. This may seem unimportant when you are fighting a deployment nightmare but when it’s over the damage needs to be assessed. When we measure, we create accountability and when people become more accountable they immediately seek ways to improve. Without this, you become a victim of DevOps Groundhog Day where you wake up every day repeating the same tasks as the day before until you feel hopeless. But if you do measure, learn, and adjust, then the next day will be different. Just ask Phil!