What’s the difference between a CTO and a vice-president of engineering (VPoE)? According to Jason Hoffman and Bryan Cantrill of Joyent, the lines are blurry. At the Monki Gras conference in London on February 1st, Hoffman (CTO) and Cantrill (VPoE), shared the stage and talked about the differences in their roles.
In keeping with the generally boisterous nature of Monki Gras, the conversation with Hoffman and Cantrill was a bit more bare-knuckle than your average conference presentation. Perhaps it’s a result of their joint suffering under Sun Microsystems’ “Somali warlord style of management” (as Hoffman put it).
Hoffman and Cantrill’s session was sort of like watching a drive-time radio program. They’d frequently speak over the other, so rather than attempting to attribute quotes to one of the other and getting it wrong, I’ve just left the quotes unattributed.
Difference Between CTOs and VPoEs
Particularly for startups, it can be difficult to tell when to bring on a VPoE and how the job should differ from the CTO role. When a company is small, one person can do the job. As the roles split, you have to decide what each person is going to do.
One thing to note is that one the VPoE isn’t necessarily subservient to the CTO (or vice-versa). The pair needs to work together. Most likely the CTO will be the technical co-founder of the company, and will establish the “vision and culture” of the company. The CTO also needs to be “as technical as required to validate the vision and culture” for the company.
The CTO, say Hoffman and Cantrill, is outward facing and should be extroverted enough to enjoy traveling and meeting customers. In general, the CTO will also be the one explaining the company vision to press and the rest of the world. The VPoE, on the other hand, should be an engineer that the team feels comfortable talking to and looking to for advice. They’ll be responsible for building the team and take responsibility for distilling the company vision into products and making sure they ship.
Anti-Patterns for CTOs and VPoEs
Having suffered under the yoke of Sun management, Cantrill and Hoffman had a lot to say on the wrong way to be a CTO or VPoE. The broad strokes? CTOs fail when they think they’re “engineers and not communicators.” VPoEs fail when they think “they are managers of people, not creators of useful things.”
It’s hard, they say, to proscribe the exact way to do the jobs. However, they have several “anti-patterns” for the roles that represent “common failure modes.”
- The Critic – This CTO anti-pattern is always explaining why things won’t work.
- The Process Queen – “Is there a ticket? We can’t have this conversation without a ticket.” Process can be good, but too much is deadly. As they say “funny story, process doesn’t write software.”
- The Control Freak – Pretty self-explanatory. Micro-managing people is just no way to run a business.
- The “No-Op” – Non-technical middle management types that have lots of ideas about what others should be building. They don’t understand what they’re doing “and can be toxic.”
- The Xenophobe – You can’t be a CTO and not visit customers. If you’re not eager to visit customers on their turf, you’re probably not CTO material.
- The Upward Manager – “When you manage up, you’re disconnected from reality.” Here Cantrill reminded the audience to pick two of the following: schedule, quality, features. You can’t have all three.
- The Space Ranger – Some CTOs “lose track” or “lose their tethering” and “achieve escape velocity” when it comes to what they think the company can do. Hoffman and Cantrill suggested Bill Joy as an example of the space ranger.
- The Nay Sayer – Sort of the opposite of the upward manager. Says no to almost every request. While the VPoE should be protecting engineers and keeping them focused, they need to be “optimistic enough to help out” without telling everyone no.
Most of this seems like common sense, but if you’ve worked for a company of any size you probably recognize some (if not all) of these management types. In fact, you might have a few more. Any anti-patterns that they missed?
