Want to Become a Startup CTO?
During the dot com bubble, I was a founder and startup CTO. At the beginning I wondered what to do as a CTO. There were many conflicting views on that position. From programming to vision, from technology to processes, from tools to people. After some time and more years at managing development teams and departments, my view on the CTO role is much clearer. I’ve distilled the (web) startup CTO job down to:
- Write code – often forgotten, but you need to be able to write code, and if you’re one of the first technical hires, there is not enough work for you if you do not write code.
- Decide if to hire or to outsource. There are reasons for both, but I’d say in 90% of cases one should hire. The CTO needs to decide which way to go, and – especially important be prepared to defend his decision. Buying is usually not the way to go for a technology or web startup. This doesn’t mean there can’t be a mix, there are often projects which can and should be outsourced.
- Hire developers, testers, admins and operators. Several times I’ve been asked to be the CTO for a startup, as in Germany most web startups are founded by ex-consultants or economics majors. They usually have no clue – nor should they have – about good or bad developers. As a CTO you need to provide this knowledge and hire the best you can get for your budget.
- Know how to scale development and processes (from 1 to 10 developers e.g.). Development changes significanty if you go from one to five and then to ten developers. You need some kind of process (I for example prefer Lean and Scrum). As a startup CTO you need to provide this in the first years (certainly not first months).
- Know technologies, craft an architecture and technology strategy.
- Know how to scale an application (from 100 to millions of users).
What do others think about the CTO role? Werner Vogels, CTO of Amazon, defines four roles a CTO can have:
- Infrastructure Manager
- Technology Visionary and Operations Manager
- External Facing Technologist
- Big Thinker
Many people have contributed to shaping the CTO role in startups. Indus Khaitan thinks the “5 Bare Minimum Things A Web Startup CTO Must Worry About” are:
- Security
- Availability & Monitoring
- Application Errors
- Backup
- Source Control
I do agree with them, though I’m not sure Source Control is in my Top 5. Security depends on what you do and what framweworks you use, so this might not be an issue for some time into startup life. Availability gets more and more important when your customers increase and revenue over your plattform increases. Monitoring is a must from the beginning, it’s hard to add later – you lose especially a lot of insight if you have no monitoring, insight which is dearly needed in your first incident. Backup is often forgotten or underrated – do not forget to see if you really can get your site going again from a backup.
Eric Ries writes on the role of the CTO:
The CTO’s primary job is to make sure the company’s technology strategy serves its business strategy.
with five specific skills:
- Platform selection and technical design
- Seeing the big picture (in graphic detail)
- Provide options
- Find the 80/20
- Grow technical leaders
This is a great oversight of the CTO responsibilities, there is much more juice in that article, go ahead an read it.
Tony Karrer ponders the question “Startup CTO or Developer”:
What worries me a bit is how often I read that startups should hire a developer / hands-on lead developer. I understand the desire for hiring someone who is going to product product. But often the result of a Founder hiring a developer or lead developer or even a VP engineering is a gap created between the founders and the developers. [...] By the way, I’m not suggesting that startups should hire a full-time Startup CTO who is not hands-on. Rather they should get a part-time Acting CTO who can help close the gap.
Then there is the open question, after you’ve been some time into a startup, what is the difference between a CTO and a VP of Engineering? A very good answer can be found – at least it was enlighting to me – at Mark Suster blog in “Want to Know the Difference Between a CTO and a VP Engineering?”:
The CTO [...] So I believe that every great technology startup has the technology visionary inside the company. This is the person who lays the foundation of what should be built. [...] And first and foremost a VP of Engineering is a people manager.
The VP of engineering is basically managing people and processes, while the CTO is managing technology and the vision. My take on this:
- In the beginning you better need a CTO that also does a VP/E job.
- Later you can split the position and hire a VP/E for processes – if needed
Coming back to the tilte of the post: “Want to Become a Startup CTO?” – These are skills to have and the role to play. I hope this made the CTO role clearer, technical and non-technical founders. See if this is really for you, perhaps know what your boss should do and focus on. What is your take or experience on the CTO role?
You can leave a Reply here. Of course, you should follow me on twitter here.
Based on the startups I’ve worked at, I tend to think in terms of three roles.
* The CTO is the visionary and communicator, often more focused “outward and upward” toward fellow execs, board/investors, even customers.
* The VPE is the logistical expert, responsible for resource allocations and schedules, personnel issues, the technical side of partner relations, etc.
* The third role is the product architect or chief engineer, who is responsible for the actual hands-on technical content – using the resources of the VPE to fulfill the vision of the CTO.
Obviously these roles require very close communication and camaraderie. The boundaries between them can be unclear, and two or even all three might be performed by a single person when a company is very small, but IMO they’re still distinct roles.
As someone who slots more naturally into the last role than the other two, I’d say that it’s *not* part of the CTO’s role to write code. I’m as much of a development snob as anyone, I absolutely prefer a CTO or VPE who *can* code, but I also want them to realize that that’s not part of the unique value that they’re supposed to be providing in their primary role. They’re effectively performing another role, which might very well be the right thing to do in that situation, but they’re not operating as CTO or VPE. Everything to do with code, from choice of language and libraries to component relationships to review criteria, should fall under the architect unless/until they delegate to a lower-level tech lead. In a mature organization, even if it’s still a small one, the VPE and CTO have enough other things to do.
The danger of this approach is having a VPE and CTO who are less technical (or less technically interested) than they need to be. In particular, I’ve seen many CTOs who seem to be more aligned with marketing than engineering. I worked with one who was entirely in thrall to the VP of marketing, who in turn spent most of his time doing sales work and consistently failed to produce any of the work outputs associated with his marketing role. He was quite an ace at promoting his own personal brand, but not such a sage when it came to strengthening the company’s. I’d hate to see more companies make the mistake of letting such a person define the CTO’s role.
Overall, I find that I agree almost entirely with Eric Ries’s interpretation, except that I think the development methodology belongs more with the VPE and architect. I’d also define his “provide options” sub-role in more aggressive bleeding-edge terms. The CTO should be strongly biased toward saying that something is possible, in part because the VPE and/or architect should be there to say how hard and expensive it is (respectively). There should be a certain tension between all three, so long as that tension creates a positive energy that moves everyone toward shared goals.