My good friend, Matt Aimonetti, posted a tweet a few days ago that motivated me to share some ideas bouncing around my head publicly.
Still working on it but my current view: VP of eng = people/now, CTO = tech/business/future https://t.co/ZRVqhrb97A
— Matt Aimonetti (@mattetti) August 27, 2016
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. However, it can 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 different stages will have varying definitions of the VPE role. If you’re going to use this list as a reference, consider your company’s size and particular team structure. By no means do I claim to have a single source of truth. Enough disclaimers, let’s get to it.
Measuring Performance & Optimizing
While most 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 depends greatly on how happy and motivated they are. A leader can’t make the team more productive by simply asking people to work 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 first to sit and listen.
An important part of the VPE’s job is to optimize the process and ensure high-quality 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 every couple of 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 of months back. VPE’s job is to channel the team’s inherent values in a concise, digestible format. Notice I said, ‘channel.’ Acting like 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 them.
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
Undoubtedly so, the job requires you to be highly technical, architecture software solutions, and build out infrastructure. Initially, I had an entire section dedicated to the role’s technical aspects, 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 extensive features but keep both feet in. You must 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 a 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 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 tasks of the VPE: Invest in people. Your team and products’ success 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 on the success of the company.
Engineering Software is as much about people as it is about code.
Thanks for reading.
