Being VP of Engineering is Harder than Being CEO
Being VP of Engineering is harder and lonelier than being CEO. In fact your VP is probably the loneliest person in your company - here's how to make it better.
A lot has been said about how lonely it gets being a founder/CEO of a startup company. You can probably pick any Ben Horowitz quote here about the struggle or the cold sweat in the middle of the night, and you’d be right.
Right now, it is especially hard to be a CEO. Every single person in the organization needs more and different support than they did a month ago. I'm personally going through this right now as a first-time CEO, and doing the best I can for all of our people.
There is actually one position that can be even crueler than being CEO. Being VP of Engineering is lonelier. In fact, your VP of Engineering is probably the loneliest person in your company.
I remember exactly where it hit me and probably where the seeds of starting LinearB were planted in my head.
It was one of those Monday mornings after a tough week before. I was just appointed to be VP of R&D at a great security startup and was walking into a Monday-morning CEO staff meeting. One of the latest deployments exploded (and not in a nice way) because of human error, and I was fighting side-by-side with the team throughout the weekend to restore the situation to its normal state.
When I think back to it, I can still feel the wrath of the CEO in that meeting. I did not get a single day of grace in my new role. If that wasn’t enough, I had to deal with three frustrated developers that told me how stuff is broken because all the execs care about is delivering new features and how they will never understand what technical debt is and how if you slow down to build things right you will eventually move faster.
The picture was clear in my head then…
As VP of Engineering, we spend most of our time translating between two groups of people in two parallel universes. We’re citizens of both, while not fully belonging to either.
I was not really one of the developers. I was once, but not anymore. I constantly had to remind the team of the realities of developing software inside a business with goals that are a lot more around revenue, customers, and deadlines. Some of them got it. But to many, I was now just another executive. If they had assigned me an avatar, he would probably have been wearing a suit, even though I always wear T-shirts.
I was not really an executive, either. I certainly tried to be. I tried to fit in with my new peers. I spent hours listening to the VP of Marketing and VP of Sales about what would help drive more business. But every time I tried explaining to them and to my boss (the CEO) how building software at scale is a complex mission, I felt that they nodded their head with (fake) understanding and went back to ask about feature-delivery dates the next week. Building software to scale has to maintain a delicate balance between the delivery of new value and the investment in non-functional infrastructures as well as quality initiatives that will enable the business to keep on moving forward at a fast, reasonable pace. I could tell they would never grasp or even listen to this.
Even in good companies with good cultures, neither side has a strong desire to understand the other.
This big gap exists, and that gap is where we VPs of Software Development live. To close the gap, you need to build a bridge. Speaking both languages is not enough to build the bridge. You also need to understand both cultures. When you have both, you have a chance to earn the respect you need from both sides to close the gap.
Tips for Building the Bridge between Engineering and Executives
A great translator brings two worlds together that would otherwise never know each other.
The 2020 Academy Awards showed us a beautiful example of this. It seems like a lifetime ago, and yet the image stays fresh in my mind.
A Korean film called Parasite cleaned up several of the major awards, including Best Motion Picture. It is the first time in the ceremony’s 90+ year history that a non-English language film won the big award.
Earlier in the night, Parasite’s director Bong Joon Ho was on stage accepting the award for Best Director. He was accompanied by his translator Sharon Choi.
Sharon was applauded for her job representing Bong’s wit, sarcasm, and humor. And not just at the Oscars. She had been translating his acceptance speeches for months at numerous award celebrations.
What many people didn’t realize until later is that her qualifications for the job went far beyond her ability to translate Korean into English. Sharon Choi is a movie director herself. This subject-matter expertise allowed her to communicate nuance that another translator might have missed. She understands Bong because she is just like him, and she had the respect of the movie-industry audience because she, too, makes movies.
The best VPs of Software Development embrace their role as a translator. They know their company won’t reach their potential if they don’t create a bridge between the people developing software and those directly interacting with customers.
Here’s how the best VPs of Engineering translate on a day-to-day basis:
1. Bring Data to the Weekly Management Meeting
The VP of Marketing has dashboards from Marketo or Hubspot about the number of MQLs and SQLs. The VP of Sales has reports from Salesforce about how many deals are in each phase of the sales cycle. The VP of Customer Success pulls up Gainsight to show customer engagement and renewal metrics.
Great VPs of Engineering have their own dashboards. They focus on leading indicators that monitor the quality of the process rather than focusing on outputs and trailing indicators like how many lines of code the team wrote or how many bugs were found.
They draw a clear connection between dev KPIs and the business's overall goals.
Want to predict how fast we’re shipping new value to customers? Show cycle time.
Want to predict how satisfied customers are with the quality of the product? Show the quality of the process with PR-review coverage and review depth.
Bringing consistent metrics to the weekly staff meeting will help elevate the development process from being an enigma to a well-understood function of the business. To solve this problem, I built LinearB’s free engineering metrics tool.
2. Teach Your CEO and Peers How to Understand the Development Process
The most common question a VP of Dev gets is, “Is feature XYZ shipping on time?” This seems like a fair and obvious question to ask, but look more closely. After a while, the CEO would stop asking the VP of Sales, "Hey, are we going to hit our number this quarter?” because they already know the answer to that question. They can look at the revenue dashboard and see:
The number of days left in the quarter
The number of deals and amount of revenue already closed
The number of deals left open and the total contract value
The number of deals open across each phase of the sales process
Then they can compare this data to previous quarters to see if they are on, ahead of, or behind schedule.
Part of the VP of Engineering's job is to teach the CEO and the other business leaders to look at their department in the same way. Although forecasting is a tough task, they can look at the Project Delivery Tracker dashboard if they want to know if feature XYZ is on time.
Over time, the CEO and your executive peers will develop the data-driven intuition (yes, this is a thing - just read Malcom Gladwell’s Blink) to understand whether we’re currently in hitting, missing, or overachieving trajectory. So instead of asking, “Are we going to hit our date?” they’ll say, “It looks like you’re slightly behind schedule compared to last week. What can I do to help?”
Instead of saying, “Customer XYZ really needs the new feature to work, so no bugs this time,” they can gain confidence that their VP of Engineering will shift resources when there are too many high-risk items open that generate more technical debt.
That’s the goal. To help the CEO and their peers understand how they see their business in your team so they can be more active participants.
3. Meet 1:1 Regularly with Your Peers
It takes a long time to teach someone to speak a new language. It requires patience and constant practice.
Remember how good you were at speaking French in 12th grade? Then you never used it again, and ten years later, you forgot everything you knew?
The best VPs of Engineering know they can’t let this happen. They build strong relationships with their peers and use rapport to reinforce the message constantly.
When they ask only about outcomes like feature-delivery deadlines or bugs, great VPs teach them about the world of software development, like how to quantify the impact of changing priorities last minute and why devs don’t reply to emails quickly.
They also learn from their peers. To be a great partner, we must understand what motivates those teams and what KPIs they care about most.
4. Start Every Morning Looking at Data
Data can help determine the health of the business. Not just any data, though. The best VPs start with cycle time, which is the most accurate indicator of process efficiency, and then look at the team WIP to validate that the team is not in overload. They also look at other leading indicators like PR-pickup time and PR-review time to detect bottlenecks that can affect the team’s current sprint and their performance over time.
By using consistent metrics to measure the dev team’s process, they are ensuring the entire team speaks in a consistent language about what they do. This is the first step in being able to speak a common language with the rest of the business.
In times of extreme change, they focus on the process. Your outputs metrics may be down. Measuring the process helps your team focus on what they can control and gives you the ability to celebrate a lot of little wins to keep morale high.
More Tips to Translate Business to Your Team
Seeing the customer perspective and the big picture are critical skills for developers to acquire. The best VPs of Engineering help their teams acquire these skills in several ways:
Create a Common Lexicon
Cycle Time: Sales’ cycle time is the length of time it takes a sales rep to close a deal on average. Engineering cycle time is the length of time it takes a dev to deliver a work item on average.
High Risk: High-risk deals are important deals to the company that may not close. High-risk branches are important work items to the company that may not get finished.
A lot of this stuff is the same, and it helps devs see that the rest of the business thinks about their day-to-day work the same way they do.
Connecting the Dots Between Code and Customers
Developers should talk to customers. Directly. If that sounds scary to you, think of how much scarier it is to rely on a developer to create a product for someone they don’t understand. At the very least, great VPs of Engineering create opportunities for the team to visually see how customers use the product they are building.
Translation is Lonely, But Rewarding
When the VP of Software Development masters this translation, they deliver more value to customers, and the whole company thinks and feels differently.
The CEO gains confidence that forecasting software development is possible or at least with the same accuracy you can forecast marketing MQLs or sales revenue.
The executive team shows interest in the software development process and metrics and understands the implications and trade-offs of their requests.
Developers feel like they work for someone who truly has their back.
The business as a whole thinks, “Our VP of Engineering really gets it.”
The starting point to translating engineering to execs is finding these key metrics and understanding your performance. We can help.