Today I attended a London CTO Clinic – a meet-up where putative CTOs can get together and share common interests and concerns.
Since the ‘CTO’ label is not as well established as other ‘C’ role labels (e.g., CIO, CEO, CFO, etc, etc), there is a lot of opportunity for CTOs to liberally interpret their role, the only requirement – as best as I can determine – being to maintain the trust and support of the other ‘C’ level roles.
So, what is the responsibility of a CTO?
From the session, the following broad topics were discussed:
- (Engineering) Talent acquisition and performance incentives
- Dealing with legacy technology
- Controlling ‘unnecessary’ innovation
- Managing technical debt
- Maintaining agility/delivery ‘velocity’
- Keeping a lid on total cost of ownership (TCO)
As can be seen from this list, there is a lot of fuzziness in terms of how to do all this: all of the above has to happen in the face of (usually) aggressive business timelines and drivers, which makes for a very challenging role if the CTO is to avoid becoming the ‘Ministry of No’.
In the early days of a technology effort (be it an independent startup or a product team within a larger organisation), the CTOs job (or their equivalent) is predominantly creative: the tactical need to design and deliver technology solutions in a tight timeframe/budget. Over time, this responsibility passes onto senior developers who become development managers, or application/product owners. Eventually you end up with a portfolio of stuff where decisions as to what functionality goes into each application largely rests with the relationships each application owner has with their business counterparts.
In this scenario, the CTO must act as referee and arbiter across and within applications; in the end, nobody (not even their direct manager) can directly control what an individual developer does on a day to day basis – especially when that developer is seen to be delivering business value. Repeated, flagrant violations of generally agreed principles and practices will require bold moves to correct, and this is where the CTO’s authority is realised in practice: it is the nuclear option which (depending on the culture) may need to be exercised at least once to demonstrate that, yes, sometimes only focusing on what (you think) the client wants and not what the team/firm needs as a whole can be detrimental to ones career.
But most sensible, outward-looking, collaborative folks should ‘get’ the role of the CTO, and respect it accordingly. However, this is far easier said than done for startups than for mature organisations. In healthy organisations, the role of the CTO is to be a rod for the developer’s back, to support them in ensuring the right thing is done at the right time.
I suspect that this has only scratched the surface of the challenges CTOs will be burdened with going forward..
For those interested, here are the details of the meet-up (in London):
