Clarifying the role a CTO can fulfil in Startups
As a Chief Technology Officer who has worked for and with numerous companies, ranging from early startups to Enterprise Software vendors, I’m used to be asked to explain what my role is all about. Every role in IT comes with specific expertise and responsibilities, and you can’t expect everyone to just exactly understand what mine are.
Let’s look at the role definition:
“A chief technology officer (CTO) […] is an executive-level position in a company or other entity whose occupation is focused on the scientific and technological issues within an organization. […]
A CTO should be aware of new and existing technologies to guide the company’s future endeavours.” — from Wikipedia
What can we distil from this?
- Executive (hence the ‘C’ in CTO)
- Organization-wide
- Future oriented
While this definition has some challenges, I have to agree with these 3 points: a CTO works directly with the board (or founder/CEO), has organization-wide scope and is always focused on the future.
My personal definition would be something like this:
A CTO governs software development and has a high level, strategic view on technology, architecture, infrastructure, software development process, compliance and quality assurance.
Operation vs Strategy
Working in an executive position, with the board of directors, or (earlier) with founders or CEOs means that the role of CTO is a strategic one. Strategic — as opposed to operational that is.
Some seven years ago, I moved from a Lead Developer & Chief Architect role into a CTO role, but at first, it was expected from me to also keep my previous roles.
Looking back, I can safely say that this wasn’t a tremendous success. As a matter of fact, the CTO role suffered greatly from the fact that I still had (more than) one foot in operations:
You can’t look ahead strategically if you have operational responsibilities
As a CTO, you have to be asking the question of where the company wants to be in 2 to 5 years when it comes to technology. As a Lead Developer/Architect, you’re responsible for your teams’ next deliverables, and if you stretch it, maybe for the next major release (if that is still a thing in a DevOps world).
What should have been a balancing act of strategic versus operational tasks turned into a lesson in reality: you will always be tangled up in day-to-day work if you don’t watch out.
CTO vs Head of Development/VP of Engineering
The CTO looks at operation, but is not operationally focused. While Head of Development (HoD) or VP of Engineering (VPE) roles are entirely engaged with operational excellence, making sure the next deliverable is on time, the CTO is looking at where the company needs to be in a period of 1 to 5 years.
The HoD/VPE is ideally a great manager and a great team builder. ‘On time’ is a difficult concept in Agile times, but HoD/VPE is responsible for delivering on it.
The CTO looks at team, but more from a strategic standpoint, such as in terms of optimising the agile process, improving automated testing and continuous delivery, enhancing code quality or finding better ways to share company knowledge.
CTO vs Lead Developer
As I’ve explained above, you shouldn’t have your Lead Developer act as CTO, except maybe in the absolute beginning (ideation to prototyping phases) of a Startup. The Lead Developer is, by very nature, entirely consumed with the issue of the day, not introducing more technical debt while completing the current sprint, coaching (junior) developers, etc. while a CTO always should reduce engagement with the operational side of things, in order to be able to have a more high level view on where the company wants to be next.
In the many early startups I have worked with, I’ve seen lead devs struggle with CTO tasks such as GDPR, compliance, subsidies, sponsoring, with varying success but always with sad faces, because lead devs want to code. They see onboarding, guiding and assisting other devs as necessary evil: it pulls them out of the flow they’re in when coding, and that gives them a feeling of non-productivity (whether their overall productivity is actually reduced is up for discussion). Having lead devs involved in such non-code related tasks makes most of them less than happy, to say the least.
What about Early Stage Startups?
While working on my ISV Canvas Tech Maturity Survey, it has become increasingly clear to me how the focus of a CTO differs across the phases of Ideation, Prototyping, MVP, Scaleup and Established ISV stages.
Obviously, many tasks a CTO fulfils are less crucial in the earlier stages of a Startup, but does this mean the issues described above are irrelevant for companies in the beginning stages of a Startup’s life?
Yes and no.
There are other things to consider here.
Having your lead dev also fulfil CTO tasks is not a sustainable solution. At some point, if all goes well, the lead dev will be pulled into the production and, as I stated earlier, operation simply floods strategy.
Apart from the gradual slide of strategic focus that I’ve described above, there’s another important issue to consider: if you first have your lead dev think he/she is the CTO (or at least in the highest technical position) and later on, you decide to hire a CTO, this may lead to motivation issues. I have seen this over and over: people simply don’t like to get the feeling of demotion.
Different Stakes
Being out of the line of fire, overseeing tech from a higher perspective, a CTO often has a better grasp of what’s good for the company/product. This may have to do with:
- Cost-efficiency
- Future integrations
- Technology trends
- Tech maturity
- Market direction
- IP thinking
I have seen major issues in all these areas arise in Startups without technical cofounders or senior peers, when there was no one who could challenge the decision making of a lead developer.
Solutions
Budgetary constraints are all too often the main reason for Startups not to engage a CTO at all. Delivering the MVP consumes all the resources and there’s no room for an expensive C-level hire.
However, the overall experience a CTO can bring into a young, inexperienced Startup however is vast. In general, CTOs have 15+ years of experience in everything software development, have gone through the various stages of Startup development at least a couple of times, have a broad scope on Cloud technology and are familiar with the Lean Startup and other efficiency-enhancing software principles.
A CTO, more than anyone else, is able to make judgement calls on what to build versus what to buy, from a IP perspective (focusing on value-build up and exit strategy)
Strategic Advice
If you aren’t among the very few that are so lucky to have a serial tech co-founder with you, and can’t afford to put a C-level executive on the payroll, consider other options.
There is a growing number of part-time CTO offerings out there. Experienced professionals who have made it their specialization to offer short to medium strategic advice to Startups, help set up Native Cloud architecture, hire nearshored teams, know SaaS best practices, and basically do everything an internal CTO would do, as a service.
Even if it’s just for a few hours a week, it helps to have the extra experience of a seasoned CTO in the mix, to challenge technical decision making, help in making build-or-buy decisions, find the weak spots in your architecture, help raising the quality of your product, etc.
