Photo by Tierra Mallorca on Unsplash

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.

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    Architecture & Process Review

    Built a serverless app on AWS, but struggling with performance, maintainability, scalability or DevOps practices?

    I can help by reviewing your codebase, architecture and delivery processes to identify risk areas and their causes. I will then recommend solutions and help you with their implementation.

    Learn more >>

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>