Software Engineering  

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

By Emily Nakashima  |   Last modified on July 14, 2023

Charity once said an off-hand sentence that became a mantra for my transition into the VP of Engineering role: “Directors run the company.” This was said in the context of thinking about how the various management roles around the company interact: line managers run teams and projects, directors run the day-to-day work of the company, and execs (including VPs) focus above all on strategy, external-facing matters, and longer-term planning for the company’s future. 

There’s an aspirational component to this — as a VP at a startup, I’m still often involved in helping with the day-to-day workings of the company — but nonetheless, it was a crisp statement of how I had to change my focus to take on this role. My priority number one had been to “run engineering well.” Now it had to be something else. But what did that look like, in practice? 

Alignment is your most important deliverable

Most execs — at least the good ones — spend a lot of time on something that can be completely invisible to their teams: building alignment at the executive level.

Early in my career, I had the experience of working for a company where everything felt broken but it wasn’t clear why. The people were smart, the ideas were good, everyone was trying hard, and yet nothing ever came together. Cross-team interactions felt fraught; focus was constantly shifting; nobody was ever sure what bar we were being measured against. 

I realize now that the big broken thing at that company was a lack of executive-level alignment. The exec team needs to have a shared picture of where the company is going, crisp agreement on the company’s priorities, and a ton of shared context about how the current state stacks up against where you want to be. 

Sometimes (if you are extremely lucky), the exec team is mostly aligned when they start working together. More often, the team has the same shared goal but the opinions on how best to get there and the context behind those opinions diverge wildly. It takes months to build trust and shared context, propose and refine company-wide strategy, and plan department-specific strategy and implementation. 

The work doesn’t stop there either; you also have to sell those decisions to your team and address their questions about the strategy and its implementation. A good strategy will always require saying yes to some opportunities and no to others. Departments or teams can burn through an infinite amount of energy re-litigating these decisions with stakeholders if the exec team doesn’t tell the story of these tradeoffs from above and make clear that the avenue for strategy concerns is mostly up, not sideways. 

Strategy is also not one-and-done. There’s ongoing and often painful work to create adequate focus to actually implement the strategy. This is particularly hard on engineering teams, where we always have to balance multiple priorities: security, reliability, performance, UX, shipping new features, iterating on existing features, internal developer experience, maintainability/tech debt, quality, scaling, etc. A successful startup engineering team has to say no to tantalizing opportunities constantly. As a VP, a key part of the job is helping your teams gracefully say no, even when it may feel painful to the team, customers, or others in the company. 

Doing all of this work — strategy creation, exec alignment, strategy implementation — is perhaps the most important responsibility on any executive’s plate, and yet much of the work is necessarily done behind closed doors. ICs may only come into contact with the outputs of this work in the form of an annual presentation or a summary document. 

The further you go on the management ladder, the more doing a good job in your role can become decoupled from appearing to your team to do a good job in your role. Managing and making management visible turn out to be two mostly distinct groups of skills. Our exec team works to mitigate this by providing a window into the strategy creation process and cascading context about team discussions to our ICs and especially our managers, but it takes ongoing effort and there’s always room to get better.

If you’re interested in exec team dynamics and the craft of strategy, these three books have been particularly formative for our exec team:

But what do you actually do all day?

While engineering teams often thrive on routine and ritual (sprint planning, on-call rotations, recurring retros, etc.), my work has become more varied as I have moved up the ladder.

There are some recurring touchpoints in my schedule, but they aren’t the core of my work:

  • Quarterly board meetings
  • Weekly exec team meetings
  • Weekly meetings with my directors
  • Monthly meetings with all engineering managers
  • 1:1s with direct reports, skip-levels, boss, peers
  • Quarterly OKR creation with monthly scoring
  • Recurring status reporting (yes, even for execs!)

The purpose of recurring meetings also changes somewhat: the most valuable signal I listen for in many recurring meetings is information about how and when we need to deviate from our plans, rather than how we can best stick to them.

Depending on the day, I might also spend time doing any of these tasks:

  • Writing, reading, updating, or providing feedback on strategy, at a variety of levels (company, department, domain, team, project/component) 
  • Digging into data and talking to coworkers to assess “how it’s going” at the company, department, or team level, and working with stakeholders on a plan to improve, if needed. Are we executing against the strategy as planned? Is it having the desired impact? Is there friction? Are our teams thriving? Are we preparing adequately for an uncertain future?
  • Budgeting and longer-term planning
  • Researching our competitive space and industry trends
  • Meeting with customers and prospects, for a variety of reasons: to help a key prospect get excited about Honeycomb, to share best practices, or even to apologize for downtime or issues and communicate our plan for future improvement (thankfully rarely needed) 
  • Public speaking at conferences, meetups, webinars, and other events 
  • Performance management support and planning for reviews, recognition, & rewards season (somehow always around the corner)
  • Building hiring plans & talent strategy; recruiting and interviewing senior candidates; playing the long game with key talent
  • Writing or updating policies
  • Dealing with the unexpected
  • Supporting and mentoring other leaders within engineering
  • Peer support for others on the exec team and leaders around the company 

Unlearning

One thing I had to unlearn in my role was doing scrappy heroics to move a particular project forward. There is still an important place for this in a startup environment — we’re always looking to do more with less — but I have come to realize if I do it now, it usually works against my team.

For example, right as I was transitioning into this role, I did inhumane things with my own schedule to quickly build out our SOC 2 and HIPAA compliance programs at the request of our go-to-market leaders. 

There wasn't enough bandwidth to have a team take this on, but I was able to do it by putting in hundreds of hours of stealth evening and weekend work, and by putting my thumb on the scale to solicit help from a few teams. 

While the outcomes of these efforts were valuable to the company, I ultimately realized I couldn’t approach projects like this in the future. I had inadvertently shown the company that we could have these programs without planning for sustainable staffing, created hidden process debt, and suggested that we could take on major new efforts without making the tough tradeoffs that these efforts truly call for. And worst of all, I allowed my focus to be pulled away from the highest-priority problems of the company. It would have been easy for me to miss incipient issues that needed a rapid response, and it was only through luck that a major crisis didn’t brew while I was occupied elsewhere. 

We’ve now been able to build a great team around these efforts, but it took time behind the scenes to unwind the consequences of the initial push. Being a good VP requires not getting lost in the weeds and risking losing sight of the bigger picture, even when it feels like there is a tantalizing opportunity for fast impact. 

A note on VP of Engineering comp 

You see a lot in the news about “skyrocketing executive compensation,” as well as consistently high Bay Area tech company pay, especially at larger shops like Google and Meta. Perhaps surprisingly, those two trends don’t usually translate to making a startup VP of Engineering job one of the most lucrative in the Bay Area. 

Honeycomb has long taken a principled approach to compensation and sticks to relatively narrow comp bands shaped by industry data from similar stage companies. My band is effectively one ladder level above director, overlapping liberally with the senior director band, which is itself parallel to the principal engineer comp band. While our comp bands generally get wider at the high end of the ladder, the change is not especially dramatic when compared with FAANG bands. 

Industry data shows that Honeycomb is about average in this as a series D startup, not an outlier. I have friends who are line managers at larger companies who take home more than I do in my current role. To be clear, I’m not complaining — I am paid well for what I do, and I’m always, always grateful to be extremely well compensated relative to most American workers, who are well paid relative to the world median. I’m also one of the higher-paid people at Honeycomb, which is, person by person, the most accomplished crew of coworkers I have seen in my career. 

My point is just that in the current compensation climate, someone who wants to maximize compensation may do better by joining a large company known for good comp rather than a startup, even if that means taking a lower-level role. (This assumes that most startup equity won’t pay off with a large jackpot, which the data consistently says is a reasonable assumption.) 

You have to leave yourself more slack time

As an engineering IC, I used to fill every sliver of my calendar with something. Of course, there is engineering work that only fits into extended, quiet blocks of time and requires deep focus, but there was so much other stuff too. I was always able to find something to squeeze in between meetings or at the end of the day: convert a file to typescript, look at a dashboard, read a document, refactor a test, do a code review, check in with a teammate, answer a question in slack, etc. If I was feeling drained in some way — short on focus, over-socialized, under-socialized — I could shift gears to some other kind of useful work that allowed me to replenish that energy. 

As a manager, this sort of energy balancing felt harder, but still doable — as long as most things were going according to plan. However, I learned to leave myself more slack to respond to unexpected things. Where being an engineering IC required a range of different kinds of energy throughout the day, as a manager the list felt shorter: almost everything required emotional energy, and the consequences of running short on that when it was required were always bad, both for myself and for coworkers. I couldn’t pack every minute of my calendar and still expect to show up patient, emotionally generous, and curious whenever a situation called for it.

I assumed being a VP would require the same amount of slack as my past engineering manager and director roles, but in practice I’ve found that it really helps to leave even more slack time. I not only need to show up to conversations with emotional energy; I need to be able to do strategic thinking and provide directional clarity. There are a few small pieces of useful glue work I can do when I’m short on these kinds of energy, but most of these now fit better into someone else’s role. If I go searching for more busywork, it’s sometimes there, but it can be hard to avoid stepping on toes or inadvertently taking away an interesting opportunity from someone better suited for it. 

For whatever reason, I also lost my ability to recuperate during evenings and weekends by doing professional development activities. I used to be able to take a computer science class, write code, or read a management or startup book as a form of recreation — and I loved that I could combine something that felt productive with relaxing. 

While I still do those things, they are no longer activities that replenish the energy I use during the workday. Sports and athletic activities, non-work-related reading, creating art, time with friends and family, immersion in nature, religious services, quiet contemplation, and non-tech volunteer work are the most effective ways to refresh myself now. 

It also helps to find places where I can completely remove my work persona and especially practice being small, just one more person in the crowd. This sharpens my ability to see when professional interactions are being shaped more by my status than by how I’m actually showing up and treating people, which can be easy to lose sight of in an exec role. (See my old post Power Bends Light for more on this phenomenon.)

How you’re perceived will change, whether you want it to or not

I feel lucky to have been so warmly welcomed into this role, both by current coworkers and by industry friends, former colleagues, acquaintances, and strangers out in the world. As I stepped into the role, the reception I received showed me something I wasn’t certain of before: there are so many people in software who are hungry to see leaders who don’t 100% fit the demographic norm for the role and who can bring a new perspective. 

That said, the role comes with an increased public profile, and that can be both very neat and very weird. Tech-famous people I followed on Twitter for years suddenly followed me back. People were more likely to listen to what I had to say on social media, whether it was interesting or not. But I also had to be more careful; it was so easy for whatever I said to be taken as a request or suggestion.

(I still cringe when I remember a throwaway viral tweet about how I wanted a dashboard to see, of all mundane things, weather and local news headlines near my distributed team members. Random people showed up in my DMs weeks later trying to sell me products and prototypes they had put together based on the tweet.) 

People also start to see you less as an individual and more as a general avatar for “management” or “leadership,” with folks in your replies sometimes taking you to task for past bad experiences with other leaders.

While this new public role can be disorienting, nonetheless there’s an aspect of it that is fair. A VP’s words can travel further and carry a heavier weight, and this power has to be wielded with care. We have an obligation to understand the larger trends and context we are a part of, even if we don’t fit them 100%. Many of the people who show up in my replies are scrupulously committed to only “punching up,” and it’s on me to remember I’m “up” now in many ways.

The way I expressed my emotions at work also had to change. I’ve heard overrepresented leaders describe learning to tamp down or control their emotions to avoid the distress that their anger or disapproval can cause their teams, but I had the opposite issue. 

My earlier career and educational experience as a queer woman of color taught me to mostly mask my emotions to fit in better and be taken more seriously. This is still mostly my default mode at work. I spent years learning to decouple my outer projection of emotions from my inner feelings, and it’s hard to unlearn that. 

While this skill can still be handy — for example, hiding frustration when you know patience is the better route to helping someone succeed — some types of emotion can be helpful at work, and this is doubly true as a leader. If you are reasonably well-liked in your workplace, your coworkers are generally motivated to do things that bring you happiness or joy, but they can only know that if you express those feelings. 

As a VP, things that bring me joy at work are strongly correlated with things that help Honeycomb succeed. When someone, for example, ships an awesome product enhancement, learns something mind-blowing about customer behavior, finds a great way to make our team more productive, designs a great technical solution to a hard problem, goes out of their way to help a team member level up, or successfully responds to an on-call escalation for the first time, those things genuinely bring me joy and put a smile on my face. Expressing this can help my teammates understand what’s rewarded in our workplace and feel appreciated when they do great work.

There’s one last mental shift this role has called for: some subtle changes to what I will and won’t put up with. Early in my career, there were plenty of moments where I felt marginalized, disrespected, underestimated, or excluded as a woman, a mixed-race and Asian American person, and a gender nonconforming LGBTQ+ person. I learned, as most people — especially underrepresented folks — do, how to carefully pick my battles and sometimes live with bad behavior. 

The nature of these tradeoffs has changed though, as I have moved up the management ladder. What I put up with becomes what I ask my whole team to put up with. If I accept the pickle juice, I’m telling my whole team to drink the pickle juice. I’ve had to unlearn certain behaviors that were essential to my survival early in my career and replace them with more assertive behavior. 

The hardest thing

I said at the beginning of this post that the most important thing I deliver is alignment. It’s not the hardest thing I have to deliver though: that is focus

Focus is a struggle at every startup, but I’ve found it particularly hard at companies where you have a disruptive, highly differentiated, or next-generation product, rather than one that is tightly clustered with similar competitors. 

Sometimes it feels like the ratio of things we’d like to invest in to those we have time for is 100 to one. This struggle is true up and down my reporting chain, felt no less acutely by ICs or line managers on our teams. A huge part of my job is politely saying no to opportunities and distractions that don’t match our priorities, ideally before they are pitched to my teams. 

Without focus, strategy doesn’t matter. 

Missed part 1? Read it now: On Becoming a VP of Engineering, Part 1: The Path to VP

Is there anything you’d like to know about my role as VP of Engineering at Honeycomb? I’m taking suggestions for Part 3 of this series at emily@honeycomb.io / @eanakashima / @eanakashima@hachyderm.io.

 

Related Posts

Software Engineering  

What Is a Feature Flag? Best Practices and Use Cases

Do you want to build software faster and release it more often without the risks of negatively impacting your user experience? Imagine a world where...

Software Engineering   OpenTelemetry  

Rescue Struggling Pods from Scratch

Containers are an amazing technology. They provide huge benefits and create useful constraints for distributing software. Golang-based software doesn’t need a container in the same...

Software Engineering  

Experiments in Daily Work

In high school chemistry and then college physics labs, we learned a strong definition of "experiment." Experiments are tied to the Scientific Method, responsible for...