Tips for translating engineering to executives
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 quotes here about the struggle or the cold sweat in the middle of the night and you’d be right.
But there is one position that can be even crueler than being CEO. Being VP of Engineering is harder and lonelier. In fact, your VP of Dev is probably the loneliest person in your company.
Good VPEs act as the Rosetta Stone between Engineering and Execs
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 the VP of R&D of 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 a human error and I was fighting side by side with the team throughout the weekend to restore the situation to the 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 and, if that wasn’t enough, I had to deal with 3 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 and 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 would 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 on what would help drive more business. But every time I tried explaining back to them and to my boss (the CEO) how building software at scale is a complex mission that has to maintain a delicate balance between the delivery of new value and the investment in non-functional infrastructures and quality initiatives that will enable the business to keep on moving forward with fast and reasonable pace, I felt that they nodded their head with (fake) understanding and went back to ask about feature delivery dates the next week.
Even in good companies with good culture, there is not a strong desire from either side to understand the other.
So 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.
Building the bridge
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. 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 awards celebrations.
Check out Sharon in action at the Oscars
What many people did not 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.
Successful VPs of Engineering are great translators
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 that develop software to the people that directly interface with customers.
Here’s how the best VPs of Engineering translate on a day-to-day basis:
They 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 Software Development have their own dashboards. And 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 even how many bugs were found.
They draw a clear connection between dev KPIs and the overall goals for the business.
Want to predict how fast we are shipping new value to customers? They show cycle time.
Want to predict how satisfied customers are with the quality of the product? They show you the quality of the process with PR review coverage and review depth.
Bringing consistent metrics to the staff meeting each week will help elevate the development process from being an enigma to being a well-understood function in the business.
They teach the CEO and their 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 her. 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 Devs job is to teach the CEO and the other business leaders to look at their department in the same way. And although forecasting is a tough task if they want to know if feature XYZ is on time, they can look at the dashboard.
Over time the CEO and the peers will develop the data-driven intuition (yes, this is a thing – just read Malcom Gladwell’s Blink) to understand whether we are currently in hitting / missing / over achieving trajectory. So instead of asking “are we going to hit our date” they’ll say “It looks like you are slightly behind schedule compared to last week / iteration. 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 VP of Dev will shift resources to handle risk 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 so they can be a more active participant and so they can start measuring the process of software development, not just the outcome.
They meet 1:1 regularly with their 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 10 years later you forgot everything you knew.
The best VPs of Dev know they can’t let this happen. They build strong relationships with their peers and use the rapport to constantly reinforce the message.
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 email quickly.
They also learn from their peers. To be a great partner we have to understand what motivates those teams and what KPIs they care about most.
They start every morning by looking at data to determine the health of their business. Not just any data. The best VPs start with cycle time which is the most accurate indicator of process efficiency, then look at the team WIP to validate that the team is not in overload. They also look at other leading indicators like PR pick-up 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.
They translate business to their team. Seeing the customer perspective and the big picture are critical skills for developers to acquire. The best VPs of Engineering help her team acquire these skills several ways:
Creating a common lexicon:
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 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 to see that the rest of the business thinks about their day-to-day work in 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 Dev create opportunities for the team to visually see how customers use the product they are building.
Translation is lonely. And also rewarding.
When the VP of Software Development masters this translation, not only do they deliver more value to customers, but 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 Dev really gets it.”
The starting point to translating engineering to execs is finding these key metrics and understand your performance. We can help.
If you have 5 minutes, you can see your team’s performance now with a free trial of LinearB.
Top comments (5)
That's a great article, thanks!
I think that we need translaters that speak both languages in multiple areas.
For example the hiring market would be much less broken if developers and recruiters could understand better each other.
This is such a great point!
If you're a successful engineering leader, scaling your team will naturally follow. The ability to do that well will dictate your continued success.
Having the right data can help bridge the gap between the dev leader and recruiter. "Our time to release is slow. We need more devops people to manage that process."
We wrote an article on scaling software teams a while back. Check it out: linearb.io/blog/how-to-scale-softw...
I've read it, it seems that you are doing some pretty advanced stuff at linear B :)
Now maybe I have an additional challenge for you.
Something I try and most often fail to communicate is how crucial learning is for programmers. I have lines like: "you know, programming is in fact easy when you have everything figured out. Figuring things out is the part that is hard. I think we should allocate time and money for experiments, learning, training and education".
I believe what I say but it's mostly my educated guess as a guy who has done programming for a long time.
Hard to communicate in numbers to C-level executives.
How would you tackle this - admittedly tricky - challenge?
That is a good challenge. The answer is probably more nuanced than can be captured in a comment board :) but I'll try.
Our community of users has reported that bringing metrics about their team on a regular basis build a new level of trust with the c-level, so that their requests for more "non-functional" or research work are better received.
Metrics can actually uncover areas of your process or teams that could potentially benefit from research time.
Metrics can also serve as a baseline to prove the benefit after the fact. For instance, "Before our research project, our cycle time was 3 days, but since we implemented the changes we found in the research, cycle time is down to 2 days. This means we can deliver faster."
Certainly lots more to discuss in this area. Let me know if you'd be interested in connecting with our team. Our co-founders were both former VPs of Engineering and have lots of experience trying to bridge the gap between engineering and executives. I can connect you with either of them, or you can visit linearb.io and click "Get a Demo" to meet with our team.
Excellent article, like pretty much all the posts from LinearB. As a developer who wants to move into a VP of Dev role one day, having this breakdown is valuable. It helps with roadmapping personal goals to grow into this position.