Earlier this month, we introduced the concept of the total cost of ownership (known as “TCO”) of digital products and how this is an essential factor in CTO decision-making. Here, we delve further into the total cost of ownership, how and why CTOs will approach it differently, the impact of CIO involvement and how you can prepare for TCO (while also being aware of hidden costs).
TCO and various CTO flavours
The total cost of ownership means CTO accountability. But the way CTOs approach it might be different depending on the CTO flavour.
- A Big Thinker CTO preparing new business lines or working on new business models will need high-level TCO estimates.
- The Infrastructure Manager kind of CTO who’s trying to enable technologies across business units and departments would base its decision-making process on 3-year TCO estimates with an important level of detail.
- The Visionary CTO running the technology as an expert in product and/or development, usually a co-founder, tends to disregard TCO in favour of Vision.
- The External-facing technologies type of CTO quickly engages with the TCO concept as it becomes an interesting selling point or an essential part of her/his advisory duty.
No matter what flavour of CTO you have, TCO remains important. If decisions CTOs tend to engage with are great, TCO will just better support them.
CTO, CIO and TCO
Sometimes, the CTO shares the technology space in the company with the CIO. A key challenge here is to ensure the company doesn’t find itself having two competing architectures (inverse Conway’s law). If they are at the same hierarchical level, this could lead to different TCO definitions.
There should be only one definition of TCO. TCO insights need to be the same and available to all executives, and both the CTO and CIO should ensure there is only one architecture of the information system. However, even if TCO seems to be a great tool to calibrate expectations between CTO and CIO, I can’t recall seeing a fully happy implementation of such an organisation.
Another scenario is to have the CTO report to the CIO. Without debating if this is a good or bad approach, it should land TCO accountability in the CIO role. This could be good news as many CIOs are trained and familiar with cost-benefit analysis. Expanding CIO’s knowledge to TCO shouldn’t be a challenge.
Framing TCO
| TCO is | TCO isn’t |
| An exercise that should improve long-term decision-making (ask the right questions at the right time) | The only required ingredient for great decision-making |
| An accelerator for decision-making | A slow and long process (doesn’t have to be) |
| A responsibility under the leadership of the CTO (for technology initiatives) | Collective accountability (for technology team the CTO keeps accountability) |
| An estimation requested also during due diligence | Useful just for investors |
| A forecast | A commitment |
| A forecast reviewed regularly | An estimate at the beginning of a project/initiative or updated before audits |
| Information that contains:· (usually) 3-year estimate· a collection of assumptions that led to the estimate· a collection of alternative options that were discarded· auditable trace log with costs included during estimation· expiration date (to trigger review)· a reference to the used methodology | About:· stories or story points· product backlog· release planning |
| Integrated systematically in solution architecture discipline | Mystic knowledge for the few |
| The opportunity to make things right as you can’t estimate TCO without · engaging it with relevant people,· doing properly the architecture,· tracing decision-making,· etc. | Only an informative process |
Preparing for TCO
| TCO requires | TCO doesn’t require |
| Special expertise (planning, incrementing, cost-benefit analysis, 360° IT knowledge) to start experimenting with it | Only managers (on the contrary, the more DOers present, the better) |
| Radical candor | Experience in cost-benefit analysis (even if it can help) |
| Reasonable presence (more than one person) | Involving everyone (3-5 contributors are usually enough) |
| An actionable framework (TCO equation + checklist of questions) | Tremendous upfront preparations (just enough, just in time) |
| A facilitator (typical Scrum Masters could do that) | CTO blessing (the CTO needs to ensure these estimates still fit with the company’s means, can stress the estimate, but shouldn’t change experts’ answers) |
| A conversation | A sophisticated specialised tool |
| Minimum teaching and some mentoring for the teams (to do it right from the start) | Formal training or special certification to start estimating |
| Teams that understand the value proposition of TCO estimates | Only filling-in data in a template |
| Regular reviews (as part of any functional governance) | Preparation before audits (if preparation is required for audits TCO estimates might not work well) |
| Observation (we update our estimates the more we learn) | Documents and slides (it is much better to automate reporting) |
| FinOps leadership | Coercive approach to leading teams |
Unveiling hidden costs
Most technology leaders find it hard to answer what systems, subsystems and data flow they have in the company. The complexity is high enough, and it is not very difficult to lose control. Choices need to be made regarding cost structure.
Here is an example: depending on tariffing consumption of your public API Gateway, you reallocate costs of that infrastructure to client apps, subsidiaries, partners, or companies. This requires continuous stewardship.
More budget options
Here is another example; if during funding rounds your company was constrained to keep EBITDA in a specific range, understanding cost structures and how they will eventually be amortised will turn out to your advantage as a CTO.
FinOps
We need to acknowledge that the complexity is high enough for a new discipline to emerge: FinOps. FinOps reality nurtures TCO estimates, and TCO practice increases FinOps awareness in the company. The FinOps maturity model should be enriched with TCO best practices for a fully FinOps alignment.
Category of costs
Depending on the context (purchase vs develop), one might find it hard to fit the costs in the right columns. Especially when we talk about DevSecOps or when acquiring SaaS solutions instead of development. What matters first is to see the costs. Second, whatever the rules that fit costs per column are, they need to be explicit and consistent (don’t change from TCO estimate to estimate).
Costs to quantify risk impact
The better you become at risk analysis, the more you would want to see their associated costs in TCO. We can name “technical debt” or “external technology dependencies” as relevant examples.
Emphasis on architecture
Solution architecture done right should include TCO. This point is even more relevant for the CTOs as some still consider themselves the architect in chief. Regardless of who does the job, the CTO remains accountable for the architecture.
If costs analysis, in general, wasn’t always an explicit concern in architecture, the budget is present in the solution architecture body of knowledge. We have seen the evolution from Architecture Trade-off Analysis Method (ATAM) to the Cost-Benefit Analysis Method (CBAM), not to mention the FinOps movement. These are all signs that cost analysis is omnipresent in architecture today.
Architecture decision record, governance, and real spending
We’ve started talking about Due Diligence. Due diligence is an audit. Experienced auditors investigate the Architecture Decision Record, look for TCO and how these estimates evolved over time based on actual progress and spending.
Optimises outcome, not output
Making TCO estimates discourages the organisation from rushing into new initiatives. Everyone wants new features, new systems, new technology, new organisations, etc. But the most challenging part is to optimise existing stuff, make them work and connect them with business valuators (EBITDA, Revenue scale, industry diversification, Upsell, CLV).
In my products team, we score roadmap initiatives covering factors such as growth objectives, operational problems, decreasing security risks, solving technical debt, etc. The newer the initiative, the lower the score. The larger the TCO, the score decreases even more. The higher the score, the higher it gets in quarterly priorities. We haven’t touched the score algorithm in two years!
Use TCO estimates during your own purchasing process
It should be straightforward by now that you may use TCO estimates during the purchasing process to better compare offers.
Pressure on costs drives a different type of innovation
Imagine there was a time when studies were published to convince tech leaders they need to virtualise. But tech leaders didn’t improve. The whole industry improved because of cost pressure; that’s TCO in action. This pressure on costs led the industry to virtualisation. We are greener in IT than before.
No TCO, no CTO legacy
At a Paris meetup on CTO leadership, I talked about business as an infinite game. We shouldn’t see ourselves forever in current positions. The company will continue its game, and we move on to another journey. What do we leave behind? What will the next CTO find? Will that newcomer say: ‘Wow! I have a foundation I can continue building with.’ Or will the reaction be more like, ‘I need to start all over again!’
Of course, to leave a proud legacy as a CTO, TCO estimates aren’t enough. But they are a great leap forward in a holistic technical and business strategy.
***
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.