Bruno Miranda
Published in

Bruno Miranda

The Role of a VP of Engineering

My good friend Matt Aimonetti, posted a tweet a few days ago that motivated me to publicly share some ideas bouncing around my head.

This post isn’t about the role of the CTO vs. VP of Engineering. Defining the duties and responsibilities of a VP of Engineering is something I’ve been thinking about for a while. I was selfishly pleased to find out I am not the only one who finds this subject nebulous. I did a bunch of reading and talked to people smarter than me. What follows is a non-comprehensive list of responsibilities I believe the VP of Engineering (VPE) needs to keep close to their heart.

Disclaimer: A title should not define a person. It can however be used for good when it serves as a tool to provide direction and focus. The following list is by no means comprehensive. You may agree with the responsibilities, but not particularly my approach to fulfilling them, and that is totally fine.

Doximity, my employer, is about 6 years old, ~200 employees. The engineering team is roughly 60 people. Companies at difference stages will have varying definitions of VPE role. If you’re going to use this list as a reference, consider the size of your company and particular team structure. By no means do I claim to have the single source of truth. Enough disclaimers, let’s get to it.

Measuring Performance & Optimizing

While the majority of employees are measured by their individual performance, VPs are typically measured by how well their teams are doing. Engineering is no exception. How productive a team is depends greatly on how happy and motivated they are. A leader can’t make a team more productive by simply asking people to worker harder. I’d rather avoid turning this into a “How to make your team productive” sort of thing. Just know that if you’re going into a VPE role, your number one priority is to ensure everyone in your team has what they need to get good work done.

Before you can optimize or fix anything, you must first listen. There is nothing more infuriating than an executive joining a team halfway through a marathon and demanding immediate changes. Regardless if you are new to the organization, or walking into this role in the same company you’ve been with for a while, you need to first sit and listen.

An important part of the VPE’s job is to optimize the process, and ensure high quality of code and deliverables. To spice things up even more, they’ll need to do this across teams. There’s a lot more to building software than just writing code.

Built a Team

I bet we can all agree hiring is hard. Building a qualified team is one of the most important things you can do. This can’t be overlooked, it can’t be something you spend a few minutes on every couple weeks. Remember a VPE is nothing without a solid team (see ‘Measuring Performance’ above). I can’t recommend this enough, invest time crafting an interview process. Decide what type of people will be valuable assets in your team, what type of culture you’ll embody. Note that when you begin hiring, good candidates will want to know the team’s values, which brings me to…

Set the Team’s Values

I wrote about this a couple months back. It is the VPE’s job to channel the team’s inherent values in a concise, digestible format. Notice I said, ‘channel’. Acting as a dictator here and creating a set of ‘rules and regulations’ will get you nowhere fast. If your team is new and does not yet have values defined, you'll have to work with them to define it.

Think about each principle not from a “what we must do” perspective but “why we do what we do”.

You want to capture and translate the team’s modus operandi into text in a way that feels natural. How do you know if you’ve got this right? If you show the list of values to a teammate, they’ll nod and agree with most of the items without raising a hair. Think about each principle not from a “what we must do” perspective but “why we do what we do”. This content serves two purposes. Firstly, it acts as a guiding manual for the current team. Secondly and most importantly, it clearly communicates to newcomers the guiding principles from which the team operates. As I mentioned a few paragraphs ago, hiring is hard, this will hopefully give you an edge.

Code, Your Job is to Code

Undoubtedly so, the job requires you to be highly technical, able to architecture software solutions and build out infrastructure. Initially I had an entire section dedicated to the technical aspects of the role but it felt gratuitous. What I will say is, you must still code. Don’t give that up, remember the “clueless executive” I described above? Yeah, don’t do that. If your team is larger than a dozen people, you’ll probably want to avoid taking on very large features, but keep both feet in. It is very important that you stay in touch with reality, write tests, write code, deploy servers and fix bugs. You’ll need to help others solve complex technical problems, without keeping a finely honed skill-set, this will become increasingly hard over time.

Manage Up and Down

I can’t remember where I read these words in this order. I do remember it immediately caught my attention. Managing, by no means is telling other people what to you. It is however being able to — at minimum — partially understand people’s needs and try to accommodate them and enable progress. This includes the people in the engineering team as well as other executives running the company.

Mediate & Help Others Succeed

We talked about listening and optimizing. In that process, you’ll hear problems that need solving. The VPE’s job is to listen. Most simple problems will be solved before you hear about them. It is very likely you’ll have to deal with the hairy ones. Never — and this is very important — never sweep them under the rug.

Your job is to help others succeed. Sounds self-explanatory doesn’t it? It partially is. However simple of a concept, one aspect that can’t be forgotten is that the VPE’s job is also to enable auxiliary departments within the Research and Development realm. The process of building software goes beyond writing code. A lot of collaboration happens between Data, Product, Ops, and QA teams. Your job is to ensure communication is flowing smoothly in all directions. Having regular one-on-ones with all team members will help you collect enough insight to be able to help.

Uplift & Invest

Motivation doesn’t grow on trees. You also can’t motivate by asking people to be motivated. It is the VPE’s job to be a positive example to the rest of the team. This will go a long way to inspire others. Listening and fostering other’s ideas is the best way to motivate.

I’ll close out with what I think is one of the most important task of the VPE: Invest in people. The success of your team and products is closely tied to how happy, productive and motivated your team is. Investing time and attention to listen, provide resources and guidance to your team. This will have a huge impact in the success of the company.

Engineering Software is as much about people as it is about code.

Thank you for reading. To learn about new articles, follow me on Twitter.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store