In the context of businesses, the ultimate goal of innovation for technology companies is to drive a profit. This means that even though many software engineering problems can be solved with enough time and budget — just because a business can solve a problem doesn’t mean that they should. Sometimes, even once a team has figured out how to solve an engineering problem, it doesn’t make sense to deploy the solution — because it costs so much to operate.

Every year, I look forward to the release of the annual State of DevOps report (that’s the kind of exciting life I lead!). The evolution and adoption of DevOps in the past decade has been incredible — and this report always helps show what’s the next big thing that high-performing teams are adopting. The 2020 State of DevOps report was just released a couple weeks ago and as usual, it was filled with all kinds of insights.

If your business is growing, your AWS bill is probably growing with it. Yet, in conference rooms all over the world (or Zoom calls, these days), CFOs are asking “we’re spending how much?!” — while engineering leaders try to explain that the platform is twice as fast and they’ve added some machine learning that is going to absolutely change the game.

On a day-to-day basis, both engineering and product management in software companies involves constant trade-offs. Everyone has a long backlog of tasks and needs to make decisions about what to prioritize on a daily, weekly, and monthly basis. Figuring out what to tackle first, what to put off for later, and what to say no to is critical both to managing daily workloads as well as to creating product roadmaps that reflect what customers want.

This month, I made the decision to join CloudZero as their new chief revenue officer — a choice I’m incredibly excited about. In the past week, a number of colleagues have asked me to share why I joined the company. After answering the question a few times, I decided to take a minute to collect my thoughts and explain why this incredible company is the next step in my career.

It’s safe to say that cost per tenant (also known as cost per customer) on AWS has been a challenging metric to obtain. Until now, your best bet has usually been to either make a best guess or build some sort of homegrown system. As of November 4, 2020, when you google “cost per tenant,” you get a few things at the top of the page. The first is a couple of blogs by AWS, where they describe an extraordinarily complex system, which you can build yourself.

Do you know how much it costs to operate your software per customer, at each pricing tier? The past six months have been highly unusual to say the least. For some companies, the disruption and shift to work from home meant 100x in usage almost overnight; for others usage completely collapsed in the same time period. These sharp swings in utilization have been disruptive to cloud unit economics. Both scenarios are risky and require extreme elasticity from the technical infrastructure.

If you’re a SaaS business — especially B2B — you know that your profitability can vary significantly from customer to customer. We all have a sense of our “expensive customers,” who use the product heavily and push things to the limit. That also means there are more profitable customers. Who are they? And how do they use the product?

At CloudZero, we talk to leadership teams at SaaS and companies every day. When it comes to individual customer profitability, the vast majority of them fall into two camps: they’re either taking their best guess — or they have no idea. Typically only the largest companies - those with the resources to dedicate a 5-10 person engineering team to calculating cost - have this level of insight. And you can be sure they yield that knowledge to their competitive advantage!

Every decision that an engineer makes in the cloud impacts cost. Yet we know that engineers aren’t cost experts, and many worry that asking them to care about cloud cost will slow them down and distract them from delivering customer value. Top cloud-native companies dedicate entire teams of engineers to build custom tools to measure unit cost and deliver cloud cost to engineering teams. But I’m guessing you don’t have eight engineers you can spare to build internal cost tools?