One Yardstick to Rule Them All: How Gamifying Marginal Cost Could Be a Game Changer

Introduction by Mark Schwartz

Back around the end of 2018 we ran a series of blog posts on the implications of the cloud on cost structure, where we discussed some of the interesting and more subtle consequences of changing fixed costs to variable. In particular, as I pointed out, the cloud and DevOps let you make decisions based on marginal costs and marginal returns. You can also do the equivalent of activity-based costing within a digital transaction. We also published several guest posts by Aleksander Simovic on how you might do so using AWS serverless services. Taloflow is a startup that has built on this idea of managing marginal costs. In this post Todd Kesselman explains why understanding your marginal costs is so powerful for cost management.

—Mark
Twitter | LinkedIn | Blogs | Email

In the Words of Todd Kesselman,
Chief Technology Officer and Board Chair, Taloflow

Todd Kesselman, CFA, is the CTO and Board Chair at Taloflow, a startup focused on cloud cost optimization, cloud cost accounting, and explaining the relationship between cloud costs and business metrics. Todd is a hands-on technologist, financier and cloud economist with 3 decades of experience bringing technology to market, and the inventor of the unique economic approach to cloud costs on which Taloflow is built. Todd is also a very early adopter of AWS, building large systems on the platform as early as 2007 and presents at AWS Meetups on the topic of cost optimization.

Here’s the good news. The modern development environment that we now all take for granted—the agile, cloud-based, microservice, serverless, pay-for-what-you-use, remote-teamed, machine-learned, distributed framework regime that now characterizes so many organizations—imbues the entire tech team with more autonomy while amplifying the ability for any one individual to impact the bottom line. Think about it. The organization is in a better position than ever, with the correct controls and monitoring tools, to create the type of “cost culture” that results in continually reducing its product delivery costs. Greater autonomy with better control is a rare combination that should be exploited by the forward-thinking organization.

So how does an organization keep everyone aligned while meeting its corporate objectives? How do you empower developers to make the deployment and purchase decisions that reflect the objectives? How do you take “coders” and make them agents for the bottom line without them wading through spreadsheets and getting lost in financials that they aren’t interested in or trained to understand?

Developers already monitor performance metrics and routinely assess the performance of their deployments and code. It’s built into their DNA. Does it meet the service-level objectives (SLO)? Does it eat CPU or memory? How long does it take to run? What’s the data throughput? You know…tech questions.

However, the company will ask different questions. Does this deployment or feature increase or decrease our profitability? How does it impact our ability to serve customers within our capital constraints? Are we getting the best “bang for our buck”? Does it let us take on new customers? What does this deployment say about the customers we should be marketing to? You know…business questions.

Now the really good news: There is already an economic concept that provides all that. It’s widely used by the marketing and finance departments of most sophisticated corporations. And, if simplified, gamified, and implemented correctly, it can easily be deployed as the perfect KPI to keep marketing and tech on the same page. The economic name—marginal costs—usually gets you a glassy-eyed stare from the tech team. That’s why we prefer to use one of the many alternative names (activity-based costing, KPI, yardstick). However, the basic concept is the same: for a given increase or decrease in the amount of units of work (see below) that passes through the system, what is the impact on cloud costs?

Here are some reasons why marginal cost is the perfect measure for managing a tech team today:

1. It’s easily understandable. How much does it cost to produce a given quantity of units of work (UOW), and how does this change as the quantity goes up and down? UOW is an identifiable end product that the company sells to its customer that is subject to an SLO. It might be packaged and priced in different ways and it might not be perfectly homogeneous between customers. Our experience has been that most companies know what their UOW is even if they can’t express it. When the all-hands meetings are held, it’s often the UOWs that create the bragging rights.
2. It’s relevant. Marginal cost can be directly tied to almost any business objective and can be easily constrained by an SLO. For example:
   • Growth focus: Process as many UOWs or add as many new UOWs as possible for a given marginal burn rate.
   • Profitability focus: Maximize the profitability of current customers at the current volume or maximize profitability as the company grows.
3. It differentiates key cost factors automatically. It contains both a quantity and a cost component. When properly calculated, marginal cost can control for the difference in unit input costs. For example, if Amazon Web Services halves the price of an EC2 instance or if your customer volume of UOW doubles. Developers actually like the fact that they can separate out an increase in demand (e.g., from a lack of cost control) when discussing performance with management.
4. It’s a useful factor for marketing and operational decisions. Marginal cost provides a direct path to customer profitability and maximizing profit margins along the demand curve. When you know your UOWs, customers can be segmented into usage patterns. Marginal costs can be applied against those usage patterns to determine the profitability of the customer segments or lack thereof.
5. It has level-setting powers. It provides a way to compare two things that appear to be very different. Marginal cost would be useful if you deployed in two different regions with two different architectures, for example. The exact deployments might be very different. But in the end, the marginal costs provide a direct measure of impact on the organization.

How to Calculate Marginal Cost

At Taloflow, we have worked with many companies to help them better understand their marginal costs. We follow the steps listed here:

1. Identify the units of work that are being sold to customers. Marginal cost is best used when it relates to the actual products being sold rather than some set of internal measurements that, while they may drive costs, are themselves only proxies for the customer relationship. In most cases, the correct UOW measure comes from outside the tech team and is not created by the deployment itself. An analogy might be an apple farm using the number of trees planted as their UOW rather than the number of apples shipped. The former, while possibly a proxy for sales, does not have a direct link with the corporate objectives and is itself a reflection of a production function (now or in the future) and not the end product. The latter is actually a UOW.
2. Let the data tell you how your deployment relates to the unit of work. The first thing we normally do with our customers is run several correlation studies. There is a tendency for development teams to believe that they have all the answers. We like to work with them and the data so that no one is surprised if the results don’t match expectations. Ultimately, the results may reflect on the nature of the deployments, so it helps in the long run to let the conclusion percolate from the tech team based upon data, rather than top-down analysis.
3. Whatever you do needs to be easy to implement. We try to avoid strategies that require extensive tagging regimes. Developers dislike the task, and it requires a strong organizational culture to implement. In most cases, we can infer all we need about cost relationships from state changes. Tagging certainly helps. But it’s not an absolute requirement in order to get started.
4. View it as experimental, until it isn’t. It takes a bunch of playing around to get to something reliable and usable. We don’t rush the process.

Armed with your UOWs and marginal costs, your organization is now ready to implement a cost culture based on an objective measure directly related to its goals.

More on this topic

AWS Cost Management
Decisions at the Margins
Micro-Optimization: Activity-Based Costing for Digital Services?
FinDev and Serverless Microeconomics: Part 2 – Impacts
Finance and Investment on Executive Insights