Like VP Finance & CFO, the differences in the two positions are not just about seniority. In fact, in the case of CTO and VP Eng, seniority is often a non-factor. They are often peers. A VP Eng can report to a CTO. And a CTO can report to a VP Eng (although this last one is less frequent).
A VP Engineering is ideally a great manager and a great team builder. He or she will be an excellent recruiter, a great communicator, and a great issue resolver. The VP Eng’s job is to make everyone in the engineering organization successful and he or she needs to fix the issues that are getting in the way of success.
A CTO is ideally the strongest technologist in the organization. He or she will be an architect, a thinker, a researcher, a tester and a tinkerer. The CTO is often the technical co-founder if there is one (and you know I think there must be one).
When a company has a strong CTO and a strong VP Engineering that trust, respect, and like each other, you have a winning formula. The CTO makes sure the technical approach is correct and the VP Engineering makes sure the team is correct. They are yin and yang.
Startup companies in their earliest stages will have neither position. The ideal web/mobile startup will have a CEO/founder who will also wear the VP Product hat. It will have a technical co-founder who will wear both the CTO and VP Eng hats. And it will have a few more engineers. And maybe a community manager.
But as the startup grows and the engineering team needs a layer of management, these two roles come into play. If the technical co-founder is a great manager/leader, they will naturally migrate into the VP Engineering role and eventually seek to hire a CTO or promote a CTO from within. But it is more common for the technical co-founder to migrate into the CTO position and seek to hire a VP Engineering to run the engineering team on a day to day basis. Either model works. It just depends on the skills and personality of the team that is in place.
It is very rare to find a person who can do both the VP Eng and CTO jobs at the same time. They require very different skills and very different time allocations. I’ve seen it work a few times, but it is the exception that proves the rule in my mind.
I have always compared them as that a VP of Engineering wakes up each morning concerned whether he/she has the absolutely best engineering team and the CTO wakes up concerned whether they have the absolute best technology.
But there are many different roles for CTOs. I have written about what I see as the four major categories some time ago:
Following are a few more posts on this from a few years ago. Two are from Todd Vernon, the CTO (co-founder) of Raindance, and the co-founder / CEO of Lijit (now part of Federated Networks). The other is from me. All saying similar things – just different nuances.
If you don’t feel like clicking through, here’s a preview:
This led us to the definition of CTO and VP Eng that I was working with. I started with VP Eng and thought of some of the great ones I’ve worked with. They are process / management gods (and goddesses) – totally focused on building and shipping products. Most of them are “medium technical” – strong enough to stand up to the engineers they manage, but not necessarily the best coders on the team. A few were rock star developers; a few were non-programmers (although I think that’s more like me saying I can’t program – where the key word that is missing is “anymore” which implies I could if I didn’t have other things to do.)
In contrast, the great CTO’s usually can’t manage their way out of a paper bag, but have huge vision, the ability to pull an all-nighter and crank out a rough prototype of the thing they are thinking about, have the unique ability to translate complex / abstract thoughts into simple English that a non-technical end-user can understand, and a willingness (or even desire) to get up in front of 1,000 people and talk about the latest greatest thing they are working on / thinking about. They are also perfectly happy to work collaboratively with the VP Eng while leaving the engineering team completely alone.
This article was originally written by Fred Wilson on October 31, 2011 here.