Do you need to justify your infrastructure spend to your CEO? In this article, we’ll equip you to communicate clearly and in CEO language about how the infrastructure investment you seek will benefit the business.
How does a CEO know if the infrastructure team is delivering value or just spending money?
First, let’s give your CEO some credit. She already understands that infrastructure has limited capacity. She knows if you get too many customers on your platform, it will slow down, negatively impacting your customers who are trying to log in and use the software. Nevertheless, saying to her, “we’ve got more customers, so we need more infrastructure” is a poor way to communicate the need.
And let’s give you some credit too! Chances are, you are already measuring and monitoring your infrastructure, gathering data to identify specific infrastructure needs and help you prove your case for funding. However, don’t be surprised if your CEO takes one look at your measurements and says, “Monitoring tells me nothing.”
The problem here is that your CEO speaks a different language.
What matters to your CEO are the questions depicted in Figure 1. Are we keeping customers happy? Are our cloud operations efficient? Are our digital services driving revenue growth? Frame your monitoring data in these terms.
If you are asking for $5 million more to spend on the cloud infrastructure line item, you must be able to express how that investment translates into reduced customer churn and positive marginal revenue.
Unfortunately, monitoring tools aren’t designed to speak CEO. Just looking at dashboards provided by a Vice President of Infrastructure doesn’t tell the CEO anything about the relationship of the request to business outcomes. Monitoring dashboards don’t show the impact on margins, costs of running the business, customer satisfaction, etc. How does a CEO know if the infrastructure team is delivering value or just spending money?
What you need is a “translation machine” programmed with business logic to convert your infrastructure monitoring data into business terms that your CEO can understand.
Translating monitoring into business outcomes.
Such a translation device exists today. It’s called SRE—software reliability engineering.
The principle concept behind SRE, as introduced by Google, is that the objective of the infrastructure team (and arguably the company as a whole) is to deliver the service the customer is expecting at the lowest cost. The main idea is to preserve “customer happiness,” and that is something that CEOs understand—the value of keeping a customer happy (or, conversely, the cost of losing one) is bottom-line quantifiable. However, SRE also takes a very practical approach that delivering 100% perfect service is not worth the cost. In many cases, slightly less than perfect service is just as acceptable to customers and can be delivered at a much lower cost. Service Level Objectives (SLOs) are used to achieve the optimal balance.
SLOs are analytical tools used to define in measurable terms what is important to the customer and the level of tolerance customers have with service variations. SLOs can be applied to each of the components that comprise “customer happiness.”
For example, an e-commerce application customer cares about whether they can log in instantly, skim good-quality product images quickly, and rapidly select items and complete purchases without glitches. Similarly, a gamer cares about real-time streaming and high-quality video. Each of these service components—latency, responsiveness, video quality, etc.—can be defined by SLOs.
Once customer-centric SLOs are in place for critical indicators of availability, latency, and overall quality, SLOs become the business logic processor we need to translate the performance of infrastructure into business outcomes. For example, when a particular service has elevated errors that put an SLO at risk (i.e., approaches a critical threshold), business executives and board members can see the problem in context, understanding that customers will be lost if the issue is not addressed. In a sense, SLOs formalize the “squinting at metrics” exercise and elevate the discussion above technical jargon to business outcomes.
If Only We Were a SaaS Startup
SLOs essentially let every company look at infrastructure the way a Software-as-a-Service startup does. When you are building a SaaS startup, you have a base set of infrastructure that has to scale, and as you scale, the cost of delivering the software goes up. When that’s the core of your business, you can simply and directly correlate infrastructure costs to bottom-line business measurements (Churn, ARR, COGS, EBITDA, etc.).
In “real life,” when your non-SaaS business is far beyond startup stage, things get a lot more complicated and the connection between infrastructure spend and business outcomes becomes murkier. Too many times, CEOs are faced with making subjective decisions, relying on what people are telling them, rather than making decisions based on unbiased metrics truly tied to customer experience.
You can change that. The next time you take a spend request to your CEO, speak her language. Let her know how SLOs affect the cost projections and gross margins on the delivery of new, revenue-generating services. This time, she’ll say, “Now you’re talking.”