Sign in Subscribe

A common scenario we have seen play out over the last couple of years post ZIRP has been engineering leaders struggling to adapt playbooks developed during the ZIRP era where economics and constraints are very different. In the high growth ZIRP era it was growth at all costs. Engineering bandwidth was the most constrained so it made sense to buy expensive software where it allowed for engineering bandwidth leverage. Now we are in the post-ZIRP era and costs matter and engineering talent is no longer as hard to come by as it was. CEOs, CFOs and boards are all asking hard questions about costs and margins. Where you do an engineering leader tasked with thinking about costs start.

First some definitions that anyone needing to think about costs should be familiar with. If you are well aware of these, skip ahead to the next section.

COGS 

Via ChatGPT - Cost of Goods Sold (COGS) refers to the direct costs attributable to the production of the goods sold by a company. This amount includes the cost of the materials and labor directly used to create the product. It excludes indirect expenses, such as distribution costs and sales force costs.

In typical SaaS businesses this is essentially the amount you are able to charge your user for the product you put out after you have subtracted all the costs of building it but not the ones required to sell or distribute it. It is a whole topic on how to actually calculate COGS for SaaS products which I am not an expert on since it can get pretty complex for e.g. something like observability tooling  will count towards COGS even though it isn’t something your end users necessarily care about but something like internal communication tools might not. Overall COGS is important for revenue and eventual profitability and is the first piece of the puzzle. But as an engineering leader you will have to start understanding these as the basis of being able to reason about other costs in your organization.

Margins

(ChatGPT again) Gross margins is the difference between revenue and the cost of goods sold (COGS), divided by revenue. It represents the percentage of each dollar of revenue that the company retains as gross profit. For example, if a company has a gross margin of 40%, it means it retains $0.40 from each dollar of revenue to cover other costs and profits.

It is usually a leadership decision that is made in conjunction with the CEO, CFO and other members of the exec team on what your product’s margins should be. They don’t typically matter at the very early stage e.g. seed. But once you are past the series A, investors want to know both current margins as well as margins with greater scale. If your business is well understood already and has competitors the expectation will be to benchmark against that cohort. It’s also important to have a clear idea of whether you are building a high margins or low margins business since everything else including engineering costs will follow from this. The way you should build your engineering organization for a high margin business will be fundamentally different from how you should build a low margin business. For simplicity I am ignoring going into the details of metrics such as EBITDA (Earnings Before Interest, Taxes, Depreciation and Assets) because those do matter but you can get pretty far by focusing on the current ones at the very early stages.

Software businesses are very attractive to VC because of their pretty high margins. It is very common for SaaS (but software in general) to have gross margins in ranges greater than 70%. 

Putting things into practice

So now you have an idea of some key business metrics your CEO and CFO care about and you have to backtrack them into engineering metrics. It’s a good idea to work with your CFO or finance partner on next steps and as applicable include an engineer who is familiar with the underlying software being used e.g. someone that understands AWS if that is your biggest expense though you can likely get pretty far with Cost Explorer with some tinkering

For each of your vendors, starting with the ones that are the highest cost.

  1. What are you spending on them?
    1. What do your bills look like for the last few months/over a year? 
  2. What does the growth curve for this look like? E.g. is it relative to per employee you add, per user for your product, some other usage metric? 
  3. How does it affect Gross Margins and COGS? 
    1. Is what you pay for this software something you have to deduct out of COGS or not? All costs are important but they will be in different buckets based on type of cost?
  4. Related to the above. What do you need the tool for? Is it a critical tool vs something that is nice to have? In the very first pass I don't recommend getting rid of software that might impact production or cause additional toil or stress for your engineers without some steps. Understanding the costs first is important before quickly moving on to reducing them. 
  5. How are you paying for them?
    1. Are you paying as you go or do you have an annual contract with them? What are the terms of the contract?

COGS spend vs everything else

Once you have done a quick review of the highest spend vendors it would be a good idea to bucket COGS/Margins impacting software vs non and then sorting by highest impact and going after the largest ones. This is likely the cost that matters the most to your profitability (or eventual profitability). As with many other things, the Pareto principle or the 80/20 rule likely applies and you should spend your energy on the largest costs vs the long tail of smaller ones. 

Start with the biggest spend

Starting with the largest vendor by spend, dive deeper into the structure of the costs. For COGS/Gross Margins software you want to understand both the overall cost and the growth curve of that cost. Since this is tied to eventual profitability your growth costs for this software should grow slower then your own growth. To take an extreme example - if you can only charge your users 1 dollar for a unit of your product but any of the software products you use cost you 2 dollars you are already negative. If the usage of the software grows faster than that of your product you are also in trouble.

What drives the underlying cost? Once you have an understanding of the usage and growth curves you have to start by looking at places to reduce the overall cost. This is where you start working with an engineer if required. Work with an individual or a team if required to map out what current growth looks like and how you can optimize it. Ideally the exercise should result in a 1-pager or a spreadsheet that details some buckets of costs, how they are currently growing and what options you have to mitigate them.

In conjunction look at your contract. This can be done by pairing with your CFO. Most enterprise vendors will give you a discount for contracts and committed usage vs spending the list price/or paying as you go. 

If you have an existing contract you may be locked in to a certain date but it can be worth investigating a re-negotiation of terms even mid-way or trying to change the way you spend. 

If you don’t have a contract it’s time to start thinking about negotiating one. The key levers in a software enterprise contract tend to be

  1. Most vendors will also not want to engage at very low volume rates (of course this depends on the vendor as to what that limit is for them) so you might qualify for a contract below a certain minimum spend on the discounts might not be meaningful - hence doing this for the highest spend. 
  2. Terms - Longer terms tend to have favorable rates
  3. Commitments - The more you commit to spending the better volume discount you will get. Some vendors will have different rates after committed volumes until you hit a list price but overall you want to be sure that your projected spend will be as close to your actual spend so you can get the best rate for as high volume as possible, while also feeling comfortable that you will also spend everything you commit to. 
  4. Also overall at a startup it’s a balance of risk, you want to be in alignment with your CEO and the head of finance on commitments you are making on behalf of the business since those will have a material impact on the overall business. Broadly you don’t want to be committing to spending money you are not sure you will actually be in a position to spend if the business doesn’t grow.

A metaphor for thinking of projections for spend that affects COGS, is that you are eating at a buffet with a slightly eccentric chef. The chef allows you to fill your plate the first time for a discounted price as long as you eat everything on it. However, anything you don’t eat, you pay extra for. And if you have to go for seconds or more, you pay the list price. So you want to get the first serving as closely aligned with your appetite as possible.

The chef is the enterprise vendor, your appetite is your business. If you don’t satisfy your business's needs i.e. your appetite, you pay the list price for overages and if you overestimate spend it’s wasted so you are paying out of pocket.

Combining the 2 steps above 

  1. You want to identify what your spend is but also what your spend can be in the near future if you invest in making some adjustments. You want to come up with a projection of what your costs for a particular vendor will be like, for at least a minimum of a year, inclusive of optimizations before you sign a contract. 
  2. If your own usage plays into it e.g. the software grows linearly with your product’s usage you want to factor that in, and use an estimate that your exec team feels good about for the business e.g. term, volume etc. 
  3. Each vendor will have nuances particular to their product and acceptable amounts of leverage their sales teams have. You should focus on getting the lowest per unit price reasonable prices for overages if they are charged differently.
  4. Some things to consider for vendor negotiations
    1. Support included. What is the amount of support included that you need and that the vendor provides
    2. Is there room for co-marketing discounts? Using them exclusively? 
  5. Lean on finance or other partners for help. If you have someone skilled in these or with a sales background, they can help as well. 

Now you should have

  1. Solid contract you feel good about
  2. Understanding of current cost and future costs
  3. A decision on which investments you are going to make to reduce costs

This should be a repeatable process for each of the largest vendors. However each vendor will likely have nuances based on their business that they prioritize in contract negotiations. So be prepared to spend time understanding those to get the full value and the best contract for each. 

To ensure that things don’t immediately go sideways after this step you want to start some sort of process to monitor costs in an on-going manner

  1. For large costs - you want to be able to review spend on some sort of cadence and it should ideally be automated. Weekly is the goal to aim for but at a minimum review at least monthly
  2. For projects that lead to cost savings - You have to prioritize these based on relative gains but stack ranked against work that adds customer value. A recommended way to staff this work would be to estimate roughly for each project the following and stack rank based on scores you assign.
    1. Savings - higher savings is better
    2. Complexity of work - less complex is better
    3. Risk of work - lower risk of causing customer facing outages or other bad outcomes is better

Now you have a list of work and metrics to track the work against which then leaves it as a prioritization decision to staff work relative to other business goals.

Summary

To wrap up to get a solid understanding of where you are spending money you need to do the following

  1. Review and deeply understand spend impacting margins
  2. Understand the growth curves of various spend relative to business growth
  3. Use the tactics in the following order to reduce spend
    1. Negotiate better vendor contracts
    2. Invest in engineering effort in a prioritized order
  4. Have a system to have ongoing observability and metrics for costs so you don’t accidentally end up losing gains you might have made.

Many thanks to Josh Weiss, Elena Tatarchenko, Brian Stack, Jenni Snyder and many others on the Render team that helped me understand these and more importantly got Render’s margins to an impressive place.

Questions/Feedback/Thoughts? Email me at email [@] uma.dev

Reasoning about cloud costs as an engineering leader