Those of you bored enough to read the weekly stream of vitriol consciousness that constitutes my blogs may have been bemused by the seemingly endless list of jobs I claim to have done across IT. Obviously, as some of these were in sales, you’d be foolish to believe anything I wrote – I certainly don’t.
Having said that, one of my favourite IT roles has been as a Chief Technology Officer (CTO). Given that there are a variety of CTO variants out there (ignoring Chief Transformation Officer and, er, Certified Television Operator), here’s my i-SPY guide to CTOs.
Start-up CTO (Confusing Techie Oddball?)
Lots of tech-focused new businesses start with a programmer having a light-bulb moment when they spot a gap for piece of technology or app that doesn’t yet exist (or they haven’t found the app store). They will then beaver away on their own at all hours, not all on company time, to hack together a demo system. On the basis of this demo, they either self-publish in the hope of being the next Angry Birds phenomenon or tout it around to people with more money than sense to get some seed funding. A hardcore start-up CTO will insist on continuing to cut the code on their own, on their hand-built monster PC or in their personal GitHub account. They might grudgingly share code and tasks with other minions until it all blows up in an angry ball of suspicion and jealousy.
Dev CTO (Container Troubling Operator?)
DEV CTOs exist in companies developing major technology products or services, particularly software houses. Here the CTO is part architect, part lead developer, part development manager, and part visionary – responsible for the technobabble used by marketing to peddle the snake oil. Dev CTOs invariably came up the coder route, and are reluctant to let go, but at least have the social skills not to growl at anyone else looking at their code. Typically, a key player in PE or VC funded tech companies, with a lot of the IP remaining in their heads. This can be embarrassing when they suddenly leave to set up a competitor.
Large Company CTO (Can Terrorise Operations?)
Big companies with lots of IT, most of it legacy, have a need for someone to govern the IT risks of the old stuff falling over, the new stuff not working, the connect-i spaghetti that joins them all together, and some idea of a better future state where the IT is perfect and cheap as chips. Apparently. Welcome to the classic big company CTO, usually working for the CIO and arguing with them whether it is a dotted reported line or not. These CTOs have their own private hit squad of architects, write and govern the IT vision, strategy, architecture, standards, patterns, etc., for the business. They run the Technical Design Authority and programme reviews to ensure no one is putting stuff on AWS when the CTO has mandated Azure, or Ruby not Python, or trying to take design shortcuts to meet impossible deadlines. Can be used as a disposable shield by the CIO.
Group CTO (Cantankerous Trying Oldie?)
Typically, a retirement role for a large company CTO that just wants to play at IT and attend expensive Anal-yst and Vendor events, in exotic locations. This is mainly a self-important role, in that no one else cares what they do as long as they don’t get in the way of real work, and they stay in their ivory towers (or home garden offices) for most of the year. Needs careful monitoring from time to time to check they are still alive.
Field CTO (Can Talk Obsessively?)
Field CTO is a new inflated job title I mentioned in Pre-Sales Con-sultants, referring to a senior vendor techie sent out to sell to new prospects or shut up existing customers. Needs to be proficient in the supplier’s technical strengths and weaknesses, and also how to explain (or hide) these factoids appropriately with clients. Can be either a semi-retired CTO, or an annoyingly noisy, bright techie that no one can stand to be around.
So, when the tempting job ad pops up for a CTO, check which one it is and whether it is really matches you.
John ‘Curiously Tiresome Otaku’ Moe

Leave a comment