“We’ll fix it later.” 4 words that make even the most battle-hardened FinOps (financial operations) professionals sweat.
Most in the software world have heard of ‘technical debt’ (thorough exploration here by Martin Fowler) but a short definition from Wikipedia is: the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
For many early-stage B2B SaaS companies, this occurs in both their software development efforts and their FinOps.
An example of creating technical debt:
A software developer needs to write a bit of code to do something. Some code already exists that does X, but the developer needs to do X + <some other stuff under certain conditions>. The “right” way to do it would be to create a common function or micro-service that behaves consistently and can handle the different permutations.
But our developer has a deadline tomorrow. Doing it “right” could take days to code and test all the different permutations and ensure backward compatibility (not to mention pass code reviews, QA, etc). So, our developer copies the code in X and pastes it into his code in order to add the logic to do the other stuff. In the future, anytime a developer has to do anything with X or the new X+stuff code, it will be much slower to work with. Worse still, if there was a bug in X, the copy/paste spread it around, and now there is a bug in 2 places. And the vicious cycle continues…
What creates FinOps debt?
As in the software example above, compromise creates FinOps debt. Almost always, compromise over people, processes and/or technology. The FinOps team is usually the most under-resourced team in the shop, and especially in a startup, there are always initiatives competing for resources. An expedient decision today that might cause overhead later can usually be rationalized. At Maxio, the one we see most often is “We’re spread too thin. We don’t have time to implement (or think we can’t afford) a Subscription Management or financial operations platform, just cobble together several tools (the most common trio we see – SFDC, QBO, and endless spreadsheets) with lots of manual effort for now. We’ll fix it later when we’re on better footing.” If you have a FinOps person in your life, I guarantee you, they are nodding their heads right now, and possibly gritting their teeth.
Worse than the FinOps debt itself created by the above compromise; it is buried inside a rational business decision. Delaying an expense until you are on better footing (i.e. more growth) makes perfect sense. But, the compromise creates finops debt and when the growth comes, the solution that felt good/rational at the time (e.g manual spreadsheet work) becomes the problem, and with growth, those problems will accelerate and multiply. As bad as that is, there is something worse…
The Worst Part
As with Financial debt, sooner or later you have to pay up. While technical debt feels messy and frustrating to the developers that have to deal with it every day, technical debt can go for years without issue. And, it rarely shows up when everything is riding on it. Not so with FinOps debt.
FinOps debt usually shows up at the worst possible time…in due diligence. Either while you are trying to raise money or work through M&A. The fragile spreadsheets and manual processes that you kept limping along, break down in the crucible of due diligence and appear in the form of incorrect revenue numbers and/or metrics/KPIs. The result? Lower valuations, bigger holdbacks, more unfavorable terms or just a dead deal. Sooner or later, you have to pay. Contact us to stop going deeper into FinOps debt today.
– Clayton Whitfield, Co-founder & SVP Revenue Programs
