During the growth of a tech startup, the founding technical leader will likely make an important change to their organization: They will hire or promote someone to be the VP of Engineering, and redefine their own role and duties as CTO in the process.
When I went through this process, although I sought and received plenty of advice, I didn’t find a perfect playbook for this change. This post is no exception, but collects and summarizes some of the key aspects of the change that helped me.
Usage note: Your strategy may vary
Organizations have different benches of talent and different structural needs. While some practices should be universal, I don’t believe there is ultimately one universal organization design.
In particular, whether your organization needs a CTO, a VPE, and who they report to, varies substantially even among “similar” tech companies. I’ll present one model, but it is by no means the only one that can work. For the reader going through this transition, you should borrow and adapt this advice liberally.
When making a big change like this, it helps to start with a very rough plan. We will break down this work down into 4 different stages:
- Define the broad missions of each role: Why do both exist?
- Spell out the specific responsibilities: What will each role do?
- Create alignment: Does everyone get it?
- Start operating!
Let’s dive in to each stage.
Define the missions
When creating a new role, I like to think first in terms of the broadest mission of that role.
My goal in writing “missions” is that if someone at the company remembered only one thing about someone’s role, it would be this. This process also helps me focus my own thoughts and instincts, too.
The missions I ended up with went something like this:
The VP of Engineering’s mission is to achieve continuous, high-quality delivery of the software product, by developing and sustaining a healthy and high-growth team of builders. Their focus is primarily “downward and inward”, on their team and surrounding environment.
The CTO’s mission is to keep the technology division united and high functioning, and to find and anticipate the next, most impactful technology needs and opportunities for the company. Their focus is balanced between overseeing their own division, and collaborating upward and outward.
I based these missions on where I saw our biggest gaps (responsibilities I wasn’t going to be excellent at), and biggest opportunities (high-impact places I could be spending more time). As mentioned up front, your own approach may vary.
For example, there are CTO roles that are far more focused on external and outward functions (such as evangelizing the company’s product) than on internal functions. Or, there’s the “chief architect” CTO who is a team of 1 and eschews all people management to focus on something highly technical.
The rest of this post cascades from these missions and the org structure it implies, so be sure to understand where yours might vary first.
CTO vs VPE responsibilities
Against broad mission statements, it is time to define the next level of detail: more specific responsibilities that should be evergreen throughout their tenure.
All of each leader’s more discrete work — such as this quarter’s big launch, or creating new jobs and teams — should easily cascade from these main responsibilities. These can also form the basis of the job description and interview content.
The VP of Engineering’s role
The VP of Engineering has three chief responsibilities:
- Deliver the software product. The VPE is responsible for shipping the software, and for the team who ships it. Incumbent in this responsibility is overseeing all aspects of how the team commits to, schedules, designs, builds, launches, monitors, and maintains software; and all the healthy inter-departmental collaboration that is essential to doing this well.
- Maintain and manage the shipped software. We rarely get to throw software over the wall to customers, never to look at or touch it again. The VP of Engineering’s team must also support and maintain what’s shipped, and the VP of Engineering is responsible for making sure that happens. Much of this work is naturally reactive, such as responding to bugs, escalations, and outages. “Defensive” functions, like application security, site reliability, and technical support also fit under this charter, along with rituals and practices that ensure trends are aggregated into a bigger picture.
- The staffing, performance, and health of the engineering team. A VP of Engineering won’t succeed in their prior responsibilities unless their team is well-staffed for their mission, and growing in strength. So a considerable amount of “people” tasks come with the territory. Primarily, the VPE is (or becomes) a manager-of-managers, ensuring there is adequate support for all levels of engineers within their org. The VPE must also plan and anticipate headcount needs against a constantly-evolving roadmap and top-down objectives. Lastly, the VPE must create and maintain the technical ladder and the promotion process, so that engineers seeking growth and deserving of recognition have an unambiguous path to follow.
As you can see, the VPE’s responsibilities are enormous, but also discrete. If the software is shipping on schedule, the team isn’t drowning in maintenance, and folks are generally happy, the VPE is succeeding.
The CTO’s role
Where the VPE’s role is discrete and often similar across the industry, the CTO’s role can seem more open-ended and amorphous. At my previous company, I defined it as having these major prongs:
- Manage, mentor, and support their leaders. One of the CTO’s most important jobs is to make sure the VPE is successful. Everybody needs a good manager, and as CTO you are (in this org structure) that person for the VPE. You must set and monitor clear goals for the VPE; get them and their team the context and resources they need; and step in, where needed or called upon, to assist in moments of escalation or crises. Often peers of the VPE will also report to the CTO, such as a lead of Product, Data, or Infrastructure. Your role as a manager is the same for these people, and should not be overlooked in time commitment.
- Find the next big opportunities for the business. As CTO, you straddle two of the most important teams at a tech startup: The Builders, and The C-Team. Your membership in each should therefore equip you with the strongest perspective on what’s possible in the face of new information: Product ideas coming through the sales team; upward ideas (or demands!) from your own division; economic news from the Finance office; visionary impulses from the CEO or product lead; and so on. You are the person who could have the biggest impact, early, by participation in many different settings. You must make time for this kind of work. Seek out ideas, pain points, and other information, rather than expect it to land neatly on your desk. And beyond just gathering information, this can also take the form of activating and staffing special projects, teams, or prototypes.
- Fill gaps, selectively. An uncomfortable if not exciting reality of growth is that your company isn’t always equipped for everything it needs, the instant it becomes a priority. Part of the CTO’s job can be to pick up ownership that would be “ideally” owned deeper within the division, were resources in abundance or long-term need more certain. For example, a product team could be struggling to complete design on their system’s architecture, and there is no spare Staff Engineer who can assist; you might be the person to take the reigns. Or, the company needs to staff an entirely new practice quickly and there are no in-house experts. You’re an accomplished generalist who can step in and fill these kind gaps, even if there’s a more ideal long-term home elsewhere. You may take on a few of these “hot spots”, selectively, not just because you can, but also to defend and maximize the chance of success of the VPE’s other priorities.
- Oversee the division. Various administrative functions will require you to represent and act on behalf your division. Examples of this are quarterly goal setting; annual planning and budgeting; fundraising and M&A; and external activities like talks or strategic discussions. I tend to think of this portfolio as “administrative”; it’s necessary and important, but ideally the smallest of your time commitments. This responsibility also covers the time you make speaking to and with your division. While ideally much of the context and vision in your head is already cascading down to the team through your direct reports, periodic time directly with the team is not only good for them, it can help you find your own blind spots too.
Explicit balance
Be explicit with your VPE, and with the people around you, what balance each of you are devoting to these responsibilities. While the responsibilities above should be fairly unchanging, the balance among them may vary.
For example, maybe right now what your company needs most is for someone to spike out a crazy new idea that could become a massive change to your business. In this case, as CTO you might be devoting most of your time towards the “find new opportunities” column.
Whatever the mixture is, make sure both the “what” you’re working on, and “why” you’re working on it, is clear to everyone (see Creating Alignment, next).
Creating alignment
Before you start making changes, it’s important to create and confirm alignment around you. Don’t assume everybody already has the same understanding that you have; you’ve spent way more time thinking about this.
Alignment should be confirmed with the C-team, with the VPE, and with your division, each in separate settings. While the prospect of getting everyone on board could sound scary or even bureaucratic, in practice it shouldn’t take more than a couple of hours.
Aligning the C-team
At the C-level, in the best case scenario your peers already understand the two roles well and are pushing you to get the change done already. More likely, they’re swamped with their own world and don’t know exactly why you’re creating a new VP, and why now.
Importantly, your role is changing too. As these peers are no doubt used to you as being the “all things engineering” person, you’re going to need them and their reports to understand that a new leader will become responsible for many of them.
It helps to make time for this early, before you open the JD (or start the promotion). In my case, shortly before opening my VPE role, I used a regular recurring meeting to brief my peers on the “why” and the changes they could expect, get their suggestions, and fielded their questions.
Aligning with the VP
With your VPE, it’s important that the person not only accepts but is excited by the difference between their mission and yours.
As CTO your portfolio might look fun and open-ended. Meanwhile, the VPE finds their plate has no shortage of unglamorous or stressful responsibilities on it. Are they clear that, throughout their growth, this mission will remain relatively unchanged?
In the best case scenario, and frankly the only scenario in which you should be making this change, there should be mutual trust and excitement: You’re both going to be in rooms that the other is not in, and if you trust anybody in that position, it’s your counterpart.
Aligning your division
Your division is used to you as “the” leader. As we’ve already discussed, you’re going to shift some of the responsibilities to someone else, and without additional context such a change can seem frightening.
Two things are important to get across to your division:
- You’re not going anywhere, and will still be at the helm of the division. But,
- Scaling the business (and becoming a stronger team) means scaling yourself; and scaling yourself means entrusting some of your current responsibilities in someone new.
If it’s the right time to hire a VPE, then the response from your division will probably be a resounding “no shit”: Your team has already noticed the cracks. Maybe they’ve gotten progressively less time with you, or are seeing decision-making and core team rituals slow down, because you are swamped.
Talk about why you’re excited. Illustrate to your team how this change will make them more successful. What will move faster, or be better, within the team? And where will you be able to spend more time?
Finally, if you’re hiring externally, make it clear how the team will be represented in that process. You cannot have a dozen engineers in the room interviewing their future boss, but you should have 1-2 respected senior engineers on the slate.
Starting to operate: Together and apart
The VPE is in place, your goals and roles are clearly defined; now it’s time to operate.
If successful over the longer term, I think most folks will be able to visualize CTO and VPE as a modestly-overlapping Venn diagram: You may collaborate interchangeably on a small portfolio, but you spend the majority of your time on different fronts.
I think of this as demonstrating a healthy separation in public, while having a tight partnership in private.
Healthy separation
The CTO is doing everyone a considerable disservice if there is not a well-understood separation of roles. Why?
Empowering the VPE. Your VPE needs to be seen as an authority, especially among their peers (e.g. VP of Product). Success means the VPE “speaks for you”, or more accurately your division, even when you’re not around. If you have a tendency to “help” the VPE by riding along with important discussions with these peers, you’ll implicitly deprive the VP of in-the-room authority. At worst, decisions the VP should be able to make on their own will start hitting your desk instead. This is a recipe for failure for both of you.
Being an effective escalation point. As CTO, you are entrusting many important responsibilities and decisions to your VPE. Occasionally they will fail, and the team (or affected internal partners) may even be upset with and escalate such a failure. If these decisions come across as jointly owned — “We switched to Scala overnight because the CTO and VPE just decided” — you will lack the credibility and distance from the problem necessary to jump in and course correct.
Absorbing some unpopularity. Sometimes the VPE will need to deliver unpleasant news or directives to the team, decisions which are not subject to debate and which may leave some unhappy. A tool the VPE should be able to use is to deliver such news as “carrying out orders” from above, perhaps showing that the VPE sympathizes with the team but that the decision comes from the top. Hopefully this isn’t a tool you need frequently, but for a role who often has to play “bad cop”, it’s helpful if the VPE can occasionally and truthfully assign some unpopular decisions to you.
Early in his tenure my VPE insightfully suggested “we should almost never be in the same room together”, meaning that if we got our roles right, seldom should a decision or discussion really need us both.
In practice, we ended up in plenty of rooms together — but this rule-of-thumb always made us confirm the necessity with eachother beforehand, leading to higher quality uses of our time & preventing us from “helpfully” stepping on eachother’s toes.
In private
Regular checkins between the CTO and VPE are vital for keeping your counterpart filled in.
For the CTO, the VPE should report up clear metrics about their division’s most important responsibilities, as well as emerging trends or situations they need advice about.
As you get started, your VPE may grumble about this kind of upward reporting: “Hey wait, this was your mess last week, and you already know about it anyway. Now I need to provide metrics on stuff you never measured?”
Step past the discomfort and avoid over-sympathizing: For the VPE to become truly successful, you need more systems to read and fewer details to be intimately familiar with. Their job is to help create those systems and some separation.
For the VPE, the CTO should provide essential context about what’s happening in the business, especially with regard to longer-horizon possibilities that the VPE may have interest in (but does not have time for). You can strive for candor and transparency without needing to share absolutely everything: Though you may enjoy very high trust in your VPE, try not to over-burden them with information or drama that’s ultimately not going to positively impact their work.
A quality which all of my best partnerships have is that we can fight: Heated disagreements can be had privately, respectfully, and are brought to a prompt conclusion. Your relationship with your VPE should be no exception. Disagreement and debate between partners is healthy, so long as it is addressed quickly and professionally. If you are spending time tiptoeing around eachother, you are wasting time.
Now, it’s time to act
As you fork your one mission and portfolio into two, you will surely find ways your approach differs from mine; and ways that work better for you, your team, and specific organization.
What matters most in making this change well is to do so thoughtfully and explicitly. Define your roles by writing them down; align the people around you by communicating and seeking feedback; and adapt as you go, by making edits when you need to.
Be excited! It’s a great moment of change for everyone.
Thank you to Derek Parham, Jimmy McGill, and Rajiv Ramanathan for reviewing a draft of this post.