Defining roles: CTO and/or VP Engineering

Over the years, I have experienced the confusion of title/role mismatch — especially when a founder/recruiter is on the hunt for their “technical guy” and they call me. Depending on the company’s age/recruiter’s experience/founder’s battle scars, the person usually creates a job title that often misrepresents their needs and requirement. Often, the words say one thing and the needs/responsibilities call for another.

Some cases in point:

• A CEO contacts me saying they want a “CTO” that they can “bounce product ideas with” and then expect the person to not only code, but manage an outsourced team and be mentally in sync with the CEO at any time so the product stays within the mental assumptions of the founder.
• A recruiter contacts me with a VP Engineering role with a bullet point saying “not afraid of getting your hands dirty” which is British for “we need you to code” as well as “manage the team, develop the organizational culture and keep us on schedule”.
• A friend asks me to meet with their friend because they are looking for a “Chief Architect” for their new web and mobile application. When the meeting occurs, a few minutes into the conversation unveils the real goal — which is to convince me to be the lead developer (read: only developer) and build up with the development team (read: convince some other coders to join for equity).
• A COO confers the role of CTO — managing the entire product, design and development teams (40+ staff), but then expects that anything having to do with IT (internal IT service, operations, networking, business integration) all to fall under your remit, but expects you to manage them all with no support staff.

So what title is what?

In the years I have taken these roles, the title is absolutely not “the issue”. The real question should be “what are the agreed upon responsibilities for the role?” And these collection of responsibilities are often clustered around the age, funding stage, number of developers/engineers and other leaders within the company.

There are all sorts of great discussions on these titles — check out:

• VP Engineering vs CTO from Fred Wilson
• Want to Know Difference Between a CTO and a VP of Engineering? from Mark Suster
• CTO vs VP of Engineering slideshare from Jason Hoffman and Brian Cantrill

What is great about these three articles is that they simply encapsulate the the responsibilities of each of these roles.

And please note, these descriptions are for software-based companies, not hardware startups which have a different milieu of definitions (more on this in another article).

Defining a CTO

Mashing up feedback from Fred and Mark and remembering that this is for startups with less than 10 people, not for corporates (or startups staffed by corporate-denizens):

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). And, if the tech cofounder is young, they are the Chief Architect, not the CTO.

When you think of the CTO of a startup, you are thinking about the artist — the person who is the maestro with the codebase. The person who understands the vision of the company and is creating art with the code they create because it is in line with the solution achieving the vision.

This CTO is about culture, about technical direction and about understanding how the product will meet the needs of the customer since they are at the knife’s edge of the use of the product in the beginning.

They are often the worst manager, and the best coder. But the title of CTO is a fallacy here — it means that they are the producer of the solution, not the team leader. They are the person who is referred to (or incredibly hated) when new coders come to the table and ask about what part of the code does what.

Do not expect the founding CTO to be the all-singing, all-dancing person — allow them to be what they are best at being: the coding artist. Chief Architect is a great alternative to CTO, because of the focus it provides in the area of responsibility, rather than the diversion of what a CTO “should be.

For corporates, or startups that have more than five developers — then the role you are seeking is NOT the CTO — if your goal is focusing on the delivery of software solutions. That role is a VP of Engineering.

Defining the VP of Engineering

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.

The VP Engineering is all about recruiting, management, internal communication and delivery — getting the product out the door, while ensuring the team is hitting their mark.

One conversation I had with the former CTO of Vodafone provided me with his definition of a corporate CTO. His role definition was in keeping the balance between recruiting and departures in sync. Never lose too many staff while never taking on too many new staffers. While I understand the concept, I would argue that is not about building a high-performing team, it is about a responsibility of a VP of Engineering in an organization.

VP of Engineering are often not the visible ones. They are focused on the tasks of internal delivery, keeping the team moving. And when management begins to overwhelm the startup CTO, then the VP of Engineering is the next logical staffer.

To wit, I highly recommend watching Jason and Brian’s presentation on the Anti-Patterns since people can take these responsibilities to the extreme. The goal is both the CTO and the VP Engineering are to work together to bring about the product, not one over the other.

Often the VP of Engineering will keep only the delivery date in their windshield because development bandwidth is a very fleeting commodity. This may make them seem more belligerent since they are focused on the delivery — perceived as not considering the future direction, but they are charged with timely delivery and team morale. Diversions into vision discussions are fun, but can often distract from the timely delivery.

At times, the CTO will find themselves diverting into new, uncharted product directions which, while interesting, can cause the team to get distracted from their product delivery date. Keeping these two functions aligned on their responsibilities is key.

Constraints Make the Role

But what makes these roles important and how they should be fit should be by the team they are being implemented within. Having a CTO and a VP Engineering is not necessary for the success of a company.

If one of the developers also happens to be a great project manager and is anal enough to ensure delivery happens no matter how shiny the next solution is, then you have a chance to have a Program/Engineering Manager. This could obviate the need for a VP of Engineering for a time, but recognize that this could hamper your development bandwidth — which is all about focus and team.

If one of the developers is highly respected by the other developers within the team for his/her architectural skills, then you might be looking at your CTO (or Chief Architect), but the challenge often is — who had what title first. And for that, I offer a focus on responsibilities, not titles.

So, what title should I be offering to the “technical guy”?

Funny thing — if this is the question you still have, then I somehow did not convey the point.

Titles are shit.

Roles and responsibilities are key.

Transparency is important since the team needs to function well together and clarity of roles and responsibilities are what matter. It is why Google still (after being founded a decade ago) still does OKRs and works to clarify what the team is doing and who has what responsibility.

Everyone seeks clarity because everyone wants to do a great job. Yes, even those other guys you are thinking about.

By the way: “guys” is my gender, non-specific way of being inclusive of men and women. Too much time in the Bay Area, mind you.