SaaVings and Snake Oil
You might be looking at the wrong number...
In this climate of reducing budgets and increasing layoffs, it can seem logical to reduce your spend on software and tooling. In years past, where focus was on growth, tools with marginal or low value have been bought by teams. This does not mean buying tooling in leaner times is necessarily a bad idea, though.
I know what you’re thinking: “wow a vendor/investor in SaaS advocating for more SaaS spend… what a surprise, pitch me your snake oil, why don’t you…”. Without full observability into my own brain I’m sure there is some bias, but let’s model this out for clarity.
Agriculture is a tough industry with tight margins, but farmers don’t choose to sell their combine harvesters to save cost. They might choose to have some kind of shared lease so they only use a borrowed machine at the right time of the year. Why pay to have a machine 365 days a year, which you only use for a small fraction of the time?
This is the typical path of technology and industrialisation in tandem. Technology makes labour more efficient, allowing for higher productivity. Technology becomes very sophisticated, expensive and requires deep expertise to maintain. So, it becomes economical to just lease the technology when you want to use it. While this is more expensive for the minutes you have it, it’s also easier. You aren’t on the hook for updates, maintenance, insurance, amortisation and security. While the cost per minute used is higher, the overall cost can easily be lower.
The main point here is that tooling should improve productivity. In fact, investment in tooling should be considered before investment in labour. Tooling doesn’t need a healthcare plan. Tooling doesn’t leave for 30% more money once the boom returns. Tooling is available at the weekends and doesn’t need a vacation. Tooling doesn’t add to the burden of line management and it doesn’t keep you up at night when you have to get rid of it…
In many ways, investing in labour should be a last resort for a business. In the next few years, the number of tasks automated with tools will increase faster than ever before. I’m not anti-hiring, as you will have seen many times in this substack. It’s always felt like I’m trying to solve the same problems with a mixture of labour and tooling. When I’ve been a data team lead, I’ve provided the labour and bought the tools. When I’ve been the vendor, I’ve provided the tools instead.
Where layoffs could be imminent, it is better and kinder to buy a tool and stop paying for it soon after, than to hire and lay off. I also know of many small, lean data teams, who haven’t laid off members of their team during company-wide layoffs. They’ve managed to do more with less headcount as they've scaled - operating leverage. This is possible by using their tools in a smart way, maximising the impact of their time. They’ve chosen tools which require fewer people to operate - Snowflake instead of SQL Server, Dagster instead of Airflow. They've added efficiency-boosting tooling like data observability, semantic layers and automated testing. Their SaaS spend is higher, but the cost of headcount is much lower - teams of 4 achieving what teams of 7 to 10 are, elsewhere. This was the whole point of the Modern Data Stack - high leverage, low labour.
It feels like the zeitgeist dictates that, if layoffs have happened, all spending on tooling should reduce... but the opposite could be true. The productivity of a now smaller team could be amplified by tooling.
I really like this model
made in a recent Substack post:If you take a typical mid-sized data team in a scaleup, it’s not uncommon to see the three largest cost drivers be disproportionately allocated as:
Headcount (15 FTEs x $100,000): $1,500,000
Data warehouse costs (e.g., Snowflake, BigQuery): $150,000
Other data tooling (e.g., Looker, Fivetran): $100,000
This is not to say that you should immediately be focusing on headcount reduction, but if your cost distribution looks anything like the above, ask yourself questions like:
Should we have 2x FTEs build this in-house tool, or could we buy it instead?
Are there low-value initiatives where an expensive head count is tied up?
Are two weeks of work for a $5,000 cost-saving a good return on investment?
Are there optimizations in the development workflow, such as the speed of CI/CD checks, that could be improved to free up time?
The $250k SaaS spend above is the wrong number to look at… at least to start with, the $1.5m in headcount is the bigger one. Mikkel’s headcount numbers are a bit skewed by lower European salaries - in the US, the team of 15 could easily cost $3m or more. I know how hard it is to lay people off, especially good staff, and this is why it’s more comfortable to look at the SaaS spend. However, if you get rid of a tool that is increasing your productivity, in order to avoid layoffs, you’re making your team less productive and more vulnerable to further layoffs.
I’m not saying choose layoffs over reducing SaaS spend - I know I’d struggle to do that in reality. What I am saying is that you should try to stay as lean as possible. If you could choose to hire another person or buy another tool to achieve the same end… buy the tool! Hire people only when you really need to, and then you’ll be very unlikely to need to lay them off. If a team member leaves of their own accord too, it’s a great time to consider options. Do you need to replace them or could you replace some workloads with tooling, to offset the lost labour?
Teams also get less efficient as they scale, as the overhead of keeping humans working together well is very high. It is proportional to (team size) ^ n where n is > 1 . In contrast, teams should get more efficient with better tooling. Automation increases output volume or increases focus by reducing busywork.
This is also a good reason to keep central team headcount very lean. Central headcount is much harder to justify than that embedded in profit centres. It is better for central teams to be high leverage with high tool spend, providing infrastructure for the whole org. Profit centres are better at using headcount, as they have revenue to offset costs from. They make business cases for hiring and if they aren’t sound they probably won’t be approved.
I’m not saying that all tool spend is good, by any means. Focus on your critical infrastructure which takes data and makes it available for consumption. Orchestrator, ELT, Data Warehouse, Semantic Layer, BI tool, Reverse ELT… these tools are in your value chain, so are worth investing in. They are also unlikely to be good candidates to build in-house. Automated testing and observability are also tools which pay their way in protecting value. They are also difficult to build well, so are better to buy.
If you are going to reduce SaaS spend, it would be better to do so on ancillary tools rather than those in the critical path. Even choosing an open-source tool on the critical path over an easy to use SaaS tool could be a costly mistake. It can result in using expensive labour on infrastructure work, and to compensate for missing features. On the tooling alone this usually results in a loss, in both money and time.
Losses from tooling are the first loss. Using labour on work, that could be efficiently outsourced to SaaS, also incurs opportunity cost. This opportunity cost is often in other teams which are profit centres. A common trigger is for a central team to use their team’s labour to avoid SaaS spend. This time could have been used instead for delivering a project for a profit centre. Profit centre performance gains are then delayed. This is a big part of why profit centres like Product and Marketing can get frustrated with tech teams. It's also why they sidestep them by buying their own tools which allow them to operate independently.
Data teams are looking at the wrong number - a small cost instead of a big revenue line. Reducing the small cost is how they think they can deliver value, but doing so could be at a broader, greater cost. Knowing how your business generates value helps avoid these decisions. If a tool you use doesn't help you help your business generate value, chuck it... but be sure that it doesn't. If a tool can help you move faster and leaner, it's likely a good investment - especially in hard times.
all good, but why did you use a bubble chart there in the middle?