The problem with TCO

After twenty years of building software products professionally, I’ve come to place high value in engineering approaches, practices and technologies that make software systems sustainable and enjoyable to work in over the longer term.

Because of this, I love the concept of Total Cost of Ownership (TCO), and have referenced it frequently in my writing. I used to (naively) assume that CTOs, architects and engineers would have TCO close to front-of-mind when making decisions and just needed a gentle prod to remind them.

But I’ve found that this assumption often doesn’t hold and appealing to TCO can be a hard sell for a few reasons.

Firstly, the concept is abstract and fuzzy and probably impossible to objectively measure. Without concrete examples relevant to a person’s context, it’s like telling them they should eat healthier if they want to live longer. A vague aphorism that they can’t do much with.

Secondly, there’s the “we need to survive before we can thrive” mindset particularly prevalent with startups. Their main priority (rightly) is to find product-market fit and keep the lights on. But this can be used as an excuse for false trade-offs or other forms of flighty short-term decision making while they bat away any appeals to TCO.

Thirdly, there’s the hyperbolic discounting bias of human nature which favours immediate payoffs over later ones. Behaviours which are good for TCO often fall into the important but not urgent quadrant.

Finally, related to this (and most insidious IMO), is the insufficient “skin in the game” of many engineering decision makers. The Total Cost of Ownership by definition is only relevant to the owner. So unless the decision-maker is the founder or has significant equity, for most people in today’s job-hopping market the incentives to consider what’s best in the long term for a particular product are decreasing.

So what’s to be done here? If you want to persuade an engineering decision maker to take a more long-term approach in a certain area, rather than just invoking TCO here are a few things you can try:

• Use concrete examples of how their future will be better (e.g. if proposing a serverless transformation to a larger org, make calculations of cost savings that removing need for dedicated infrastructure engineers on their team would give).
• When citing any benefits, use a time horizon that’s relevant to them personally.
• Emphasise that many practices which are good for TCO can also have a noticeable positive effect in the short term and that you do not always need to trade-off quality for speed.