The Ambiguity of the CTO

I attempt to sell myself as an "Interim CTO", even, sometimes, flirting with the word "Fractional", which sounds like perhaps my leg has a level of CTO-ness, and maybe part of my thought processes, but not the entirety of my somatic and insubstantial presences.

I usually translate this as someone who has been around the block a bit and knows what good looks like in a technology-driven organisation from both a strategic and tactical perspective.

But, I won't be there to set up your email servers, for example, or to fill out racks of servers. I don't know how to execute on data centre networking goals. Nor will I write a ton of Typescript to impact your front- or back-end roadmaps. That code phrase for that is "hands-on CTO" - that's the role where you write all the code and show all the other developers what to do. That's a team lead role, and the usage of "CTO" is saying is that you have all of responsibility and all of the accountability for all of the code and technology production. The other side of the coin is that you may have little in the way of strategic input and you will not get to go to a board meeting.

For me, the "C" means you get to see what's happening at the board, as an observer if nothing else. Otherwise, sparkling team lead.

That's ok though. Board meetings are a special kind of interesting, ranging from button-down formality to Gaelic-football-match levels of aggression and posturing. They are not for everyone. Also you get jobs like being on The Compensation Committee - super important and also very challenging. Sometimes it's fine just to set up the FinOps Centre of Excellence and send reports on a monthly basis, waiting for the time you get formally asked to "do more with less" and have the invidious action item to clear out a percentage of your staff.

It is mostly the case that business follows profit, and the CTO will always be challenged to support the profit motive. The CTO has a responsibility (I believe) to help increase margin--this is an explicitly-driven goal. From my perspective, a performing CTO understands that margin increase must not occur by compromising safety. Safety in this case means longevity for the business, and some level of business performance predictability. Unfortunately, statements from other leadership commonly contain little gems like these: "no-one wants to pay for quality", "we can revisit that interim solution in Q4", "that security scanning seems very expensive", "why do we need three of everything", "what do you mean we have to pay for a warm standby and it's not even being used". In the face of challenges like these, the CTO needs to devote their time and energy to explaining risk. Being able to understand and communicate risk is something for CTO to get good at.

This short piece will get a new paragraph whenever something comes up that annoys me relating to the CTO role and I feel I have to write about it.