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

    ☎️ Serverless Clarity Call

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>