On Becoming a VP of Engineering, Part 1: The Path to VP

This post is part of a short series about my experience in the VP of Engineering role at Honeycomb.

In February of 2020, I was promoted from Director of Engineering to Honeycomb’s first VP of Engineering. Although Charity wrote an extremely generous public announcement, I hesitated to talk about this new role for quite a while as I was figuring out the job. But since 2020, I’ve noticed how little candid writing there is about paths to the VPE role or what the job is really like.* 

I understand why: the stakes for public comment become higher as you move up the ladder, every social media post has the potential to be interpreted as a subtweet or request, and your highest-priority work is often deeply entangled with confidential company and personnel matters. 

Nonetheless, I think it’s useful to share what I can about my experience in the hope that it might encourage others to seriously consider this role, especially those from backgrounds, identities, and genders poorly represented in the VP of Engineering ranks today. VPs of Engineering often have a lot of influence over both company culture and policy, and the decisions our companies make ripple outside of the companies themselves. The whole tech industry would benefit from more perspectives in this role.

Not the plan

I didn’t join Honeycomb with the goal of becoming an engineering executive. I joined to be an engineer (employee ~12), with the understanding that I might go back to a management role when there was a need. 

I had enough experience at early-stage startups to know that, if the company is successful, you’ll probably do a whole host of things as the company moves through different phases. Being attached to a particular job was more likely to be a hindrance than a help to either my success or the company’s. I was curious about moving up the engineering management ladder eventually, but I assumed a VP opportunity would be out of reach for a long time, if ever. 

Instead, I joined Honeycomb because the team seemed incredibly smart and kind, I thought I would learn a lot, and the product seemed like something I’d wanted at past jobs but could never find. Happily, all these things turned out to be true and are still true to this day. 

If you hope to grow into a specific role sooner rather than later, I suspect joining a startup at a later stage (series B+) might be the most efficient route. Nonetheless, I loved joining Honeycomb at series A, even though it has meant working through some of the wandering-in-the-desert phases of the company. (I’ll save writing about those for my post-IPO Honeycomb screenplay.)

The path

In the early days of the company, co-founder and then-CEO Charity Majors managed basically everyone, from execs to individual engineers. In what was mostly a happy accident, Charity and I turned out to be philosophically aligned on most things management, and I have long admired how her insights shape many conversations in our industry. However, we have fairly different backgrounds and skill sets. While Charity has deep experience in the domains of infrastructure & operations, databases, and backend engineering, I come originally from design, frontend, and product engineering, and I take a particular joy in collaborating with product management and ux design. 

We share a lot of experience with metrics and monitoring technologies, although she kind of despises them and I feel a profound affection for them. I’m also a rules and process person — my daily work and even my hobbies often revolve around planning things and managing risk — whereas Charity has a more intuitive, spontaneous style, often shines brightest in a crisis, is allergic to checklists, and is quick to spot when things aren’t working, including when a particular rule or process isn’t serving us.

As Honeycomb grew and the management workload within R&D increased, I was able to load-balance more and more management work with Charity, usually picking up areas where the work matched my background better than hers. I wish I could call out specific milestones on the path, but the truth is it was done in a thousand small steps. A few title changes along the way were useful backward-looking markers of progress, but they didn’t often denote major changes in scope beyond (usually) new meetings to attend.

If a startup is growing, there are always new gaps in processes & responsibilities opening up, quickly going from tiny pinpricks in the dam to major leaks of time & attention. There are always new problems to level up on, if you’re willing to lend a hand with whatever comes up. But to give credit where it’s due: it’s natural for startup founders to look for ways to get more out of their team, and yet it doesn’t seem to be as natural to recognize successes by granting new titles and roles. I have seen both of Honeycomb’s co-founders support this enthusiastically, both for me and for others at Honeycomb, and it is a rare and lovely thing. If I went looking for another startup to join at some point in the future, I would specifically look for an exec team or founding team that could cite examples of building up high performers for internal promotions — and swiftly recognizing and rewarding those already having impact outside of their role-defined scope.

In retrospect, the most interesting transition along the whole journey for me was probably moving from managing only ICs to also managing managers. I’ll write more about this another day, but I would encourage anyone hoping to make this leap to do it at a company where they already know the team, technology, and business problems, rather than moving to a new company to try it out. 

While many of the line management skills I already had translated over, it nonetheless took me quite a while to learn how to effectively “see” the whole organization (and especially where there was friction or where we might need more support) through an additional layer of management. My prior first-hand experience with the people and problems in engineering tided me over until I could work with my managers to build the practices and skills to assess what was happening on my teams effectively.

As Charity mentioned in her blog post, at a slightly rocky point in the company trajectory, we did also explore hiring a VP of Engineering from outside the company. I was grateful that Charity was upfront with me about considering this, and that she invited me into the process of finding and selecting the right person. 

We talked to a handful of extraordinary engineering leaders, some who didn’t feel like quite the right fit for where we were at, and some who decided we weren’t the right next step in their journey. And then one day we realized we had a fresh new batch of problems to think about, and the old problems that seemed intractable had become… more tractable. I didn’t get promoted right then (it wasn’t the right time) but we also stopped looking for an external hire. 

Nonetheless, I think we were all glad we went through this process. Above a certain level, leadership promotions have to be about what the company needs, not the individual, and it was valuable to imagine together what a great VP of Engineering for Honeycomb might look like.

How to prepare

While I didn’t see myself on the path to VP when I joined Honeycomb, in hindsight I can see some traits that helped me become a fit for the role:

• Holistic thinking. My focus naturally tends toward how to make Honeycomb the company more successful, not just my teams. I thrive where I am rewarded for acting in the best interests of the whole company, not my department, team, or self. (This is more often the case at startups than at large companies  and part of why I gravitate toward early stage businesses.)
• A generalist streak. I find basically all business problems and domains within a software company interesting, and I have always loved that startups let you see how all the pieces fit together. I also don’t mind taking on unglamorous work outside of the spotlight when needed.
• Happiness at varying levels of abstraction. I can work at many layers of abstraction and can quickly pick up concepts of a higher-level layer without needing to grok the layers below — but I also enjoy getting into the weeds when it makes sense.
• An overgrown sense of responsibility. I have a bad habit of walking into a room with five problems and walking out owning six. This is helpful at a startup where lots of important work falls into gaps between functions. However, it needs to be counterbalanced with a constant effort to wrap up or hand off jobs to others to avoid getting bogged down or stifling the growth of the rest of the team.
• A knack for systems thinking, paired with equal interest in both human & technological systems. I believe this is a super common and normal thing but have had at least one great coach insist that it is not, so I’m putting it on the list. 
• A genuine joy in seeing teammates level up. As a manager, nothing brings me more energy than finding a match between a person ready to take their next step and an important problem at the edge of their abilities that needs to be solved — and then building the plan to help them do it.
• Good relationships up, down, and sideways. People all around the company had to be more excited to have me in the job than to roll the dice on an external candidate. 

These work experiences also helped me out:

• Working at other startups of a variety of stages and sizes, especially B2B SaaS startups. B2C and B2B startups often deal with relatively distinct categories of problems and have each cultivated their own techniques for solving them. It’s good to see both sides at some point. However, there’s a lot of value in specializing in either B2B or B2C. The go-to-market motions, org structures, engineering problems, and scaling challenges you’ll see at a B2B company often will differ from what is popular in the B2C world; it’s useful to know the common patterns for the type of company you’re at. 
• Working across the stack. While my engineering experience is deepest in frontend technologies, I am very grateful to have built early experience in a number of shops that did pair programming and brought a DevOps mindset to their work. I was able to learn from great backend, infrastructure, platform, and ops engineers and get a sense for both how they thought and what problems were important to them. (It delights me that two of the engineers who taught me the most, Eric Saxby and Blake Irvin, are now regular Honeycomb users who I bump into sometimes in our community Slack.) While you don’t need to be an expert in every area of engineering to be an engineering executive, a little empathy and high-level domain understanding across all your teams goes a long way.
• Having experience in the dev tools and monitoring space; being a tools nerd. I’ve worked for three dev tools companies in a row, and I have a hard time imagining doing something else. I genuinely love the Honeycomb product and feel great affection for many other products in the observability, monitoring, and dev tools space. My knowledge of our domain and enthusiasm for these tools can be useful to my colleagues and be a source of energy when we otherwise might get discouraged.

An element of luck and a great team

Despite the long preceding section about how to prepare for this role, there was a lot of luck involved in being the right person for this role at the right time.

I’ve talked about how Charity’s complementary skills and experience were part of what made me a fit for this role, but that’s not the whole picture. I was also able to take on the job because we had a deeply experienced team of early senior ICs who had key engineering challenges more than handled, especially Ben Hartshorne and Ian Wilkes. 

VPs of Engineering from frontend backgrounds are relatively rare, and it’s partly because the most pressing technical challenges a startup faces are often around scaling, reliability, and backend architecture. If we had been dealing with nonstop incidents, constant struggles with scaling, and major architectural challenges with our query and storage engine, someone with deeper backend and operational experience likely would have been chosen for the job, not me. 

Because of Ben, Ian, and other incredibly talented ICs on our team, and some of the solid design decisions the founding team made that bought us a lot of technical runway, these concerns were not top of mind for our leaders. Goals like executing well against our product strategy and leveling up our user experience were instead the concerns of the day, and there I could be more helpful. 

Our executive team also already had some accomplished, seasoned external hires within our go  to market functions. Even the execs you might describe as company-grown leaders (Christine and Charity) already had founder or leadership experience from prior companies, and Charity was well-known as a talented manager long before starting Honeycomb. If the exec team had tilted more heavily toward new execs or those promoted from within, there might not have been space to grow one more exec into their role, which takes both months of runway and patience from other leaders on the team. I’m very lucky to have had such a strong crew of exec peers who generously shared their wisdom with me as I stepped into the role and extended some grace as I figured it out.

Conclusion

The most important thing I learned in hindsight is that the right VP of Engineering for a company is contextual. Before Honeycomb, I would have thought I could list off a set of canonical traits that make a great VP of Engineering. Sure, some roles might call for a larger helping of one strength or another, but I thought the basic template would be unchanged from company to company. This is much less true than I first thought.

Generally, the same basic things need to get done in most software companies, but the shape of the executive needed to guide those things can change dramatically depending on the current set of problems for the organization and who is already there, whether exec, manager, or IC. And once you’re in the job, the requirements also don’t stay static, especially in a growing company. The role may morph and shift over time just as other startup roles do.

Read part 2 now: On Becoming a VP of Engineering, Part 2: Doing the Job

*Camille Fournier’s The Manager’s Path is one good exception to this. The book covers many different engineering leadership roles and how one might work toward preparing for each. I also like these two posts as high-level descriptions of the role.