It depends. In my opinion, for the first year it is the CTOs role – a.) because there are not enough developers usually b.) because otherwise he doesn’t get a real grip of the architecture and code.

Over time coding will become less and less until there is no time left for writing code.

1. Leading team which contributes to OSS we use if any
2. Integrating with third party apps and understanding how this will work.
3. Proof of concepts on new technology under consideration

and so on.

If I have luxury of affording CTO + VPE, I will have VPE focus on functional aspects and CTO on technology aspects for now and for future only.

Worst: Dedicated QA in a different floor.

“Also role of CTO changes drastically if you have a VPE in the team. In that case I would much rather have my CTO take up responsibilities which are outward completely.”

Depends on the company I think. If you’re doing software sales, I totally agree.

For web startups I’m not sure how much you should turn outward (what percentage of work)

I always prefer a team which has horizontal responsibilities including QA. Having dedicated QA often (if not controlled very well) leads to behavior where dev think that finding bugs is problem of QA. If a dev can not find edge-cases then he can not optimize code for them and thats not so good IMO.

Also role of CTO changes drastically if you have a VPE in the team. In that case I would much rather have my CTO take up responsibilities which are outward completely.

The reason it’s better to hire 90% of the time is that the company needs to have ownership and control over its IP and that IP stems from the creative minds of engineering team. Some QA work (most notably defining test plans) requires a high level of creativity but much of it (executing the plans) requires less. It’s not that being a good tester is an easy job, and good testers are unfortunately all to rare. But one good tester can be replaced by another good tester with little ramp up. Outsourcing companies specializing in testing will often be able to provide some good ones. Lose a key developer, however, and the whole project may lose its spark.

1.) Devops is the way to go with continouus deployments. But until there are enough devops with ops experience I’d hire an ops guy. Devs could do his job, but do not have the incident experience and experience in behaviour of apps.

2.) You should automate QA – but you can only think of the things you think of. Meaning: You can’t find the bugs and think of edge cases you don not think of. QA has a different point of view, they WANT to find bugs in edge cases. As with ops, devs could do the job, but might not have the right mindset.

* 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.