by Assaf Elovic

What I wish I knew before becoming a VP at a large startup

When I started my position as VP of R&D at a growing startup, I thought my biggest challenges would be mainly technical. That is, provide state of the art architecture solutions, conduct code reviews, help solve complex algorithmic challenges and maybe even push some code. That’s because my previous technical leading positions were at small startups, where anyone who can code is needed when dealing with limited resources in a fast paced environment.

A few mistakes straight into the position made me realize very quickly that leading R&D for a team of over 20 people requires a variety of skills. Just to clarify, my team is constructed of five divisions - Front End, Back End, Mobile, Research (mostly machine learning) and QA.

So here are 5 lessons I wish I had known when starting this position:

1. Get to know your people

Understanding what empowers and motivates your team members is powerful. It’s important to remember that every person is different: they need different things, have different communication styles, and focus on different things.

Get to know what motivates each of your team members and what are their passions and career goals. This way you can leverage tasks and responsibilities based on it and maximize productivity and motivation within your team. It’ll also help retain your employees and make them feel more resourceful and self-fulfilled.

I schedule a weekly 1-on-1 meeting with each team leader and a monthly 1-on-1 with the rest of my team. In these meetings, I try to focus mainly on the personal level. Some meetings are very short, and some suddenly take hours. This policy provides me with a constant pulse of my teams’ status and motivation level, allowing me to prioritize who and when needs that extra push and attention. And believe me, there was always someone who needed it.

2. Don’t be the Hero

I truly agree with the saying “You’re only as successful as your team”. As engineers, we are constantly striving to solve complex problems, or in other words, be the hero. As the leader of your team, your job is to have a capable team that can solve any challenge on their own, without you. The more you try and solve for them, the more they’ll rely on you for future challenges.

I found this rule to be very hard to follow since sometimes it feels much more effective to bring out a solution from experience, than have your team research for days on end. However, down the line, it’s proven to be the most valuable lesson I’ve learned. With an independent and capable team, you’ll have much more time and focus to push and improve areas of your R&D that you are mostly capable of.

3. Never be a Bottleneck

The first mistake I made going into the position was to take on a coding task. Coding is my comfort zone which is why I probably fell back to it. Very quickly I was flooded with unexpected top priority issues to deal with, hours and hours of staff, business, and product meetings, not finding almost a single hour to focus on the coding task. Even when I did find some time, we all know coding requires getting “into the zone”, which was hard when constantly getting interrupted. In the end, I was creating a bottleneck in my own team, which almost delayed deployment.

I am still amazed at how many unexpected issues can occur on a daily basis. From HR and external relations to technical and political company challenges. As a leader, you should make sure you’re always available to deal with urgent issues. If you take on tasks such as deployment yourself, you’ll either be risking being a bottleneck or not have enough time to deal with urgent tasks that only you can help solve effectively.

4. Strive to be clear and assertive about estimates

We’ve all been asked questions such as “how long will this take?”, “why is it taking so long?”, etc. Surprisingly, we are often asked these kinds of questions when things are not taking any longer than estimated. We are often asked these questions when our peers either didn’t really like the original estimation or didn’t ask for it in the first place, and now they’re upset, despite nothing going wrong.

Therefore, you must always be assertive about sharing estimates and updating accordingly, even when people don’t ask. It is your job to make it clear, as best you can, what “long” actually is by providing your best view into the timescale of a project, and proactively updating that view when it changes.

Nonetheless, you should also be assertive about getting estimates from your team, and constantly strive to improve their estimation process and instincts. Try to take part in estimation meetings, and don’t be afraid to challenge their input and cut scope toward the ends of projects in order to make important deadlines. Your role in these meetings is to play a tiebreaker and make decisions about which features are worth cutting, and which features are essential to the project’s success.

5. Focus on building processes and strategy

As someone who’s constantly aware of both the high-level business needs, and internal requirements and pains, you’re in the best position for focusing on building external processes.

When I started the position, the first process I focused on was how to conduct code reviews. While this is something that might be expected of a VP of R&D, it is a process my team can probably build better than I can. Since they face the daily challenges of deployment, and understand each other’s styling preferences and coding standards, this was definitely an internal process I could give my team leaders to build while I was focusing on external processes.

Also, by having your team lead such internal processes, you’d increase overall engagement and sense of responsibility that will ultimately lead to more initiatives within your team.

An example of an external process would be the delivery process between the product and R&D team. Each division has its own requirements, culture, and needs. I’d conduct meetings with the VP of Product, and interview product managers and my team leaders to fully understand how to build a process that’s aligned with everyone’s needs and maximize delivery productivity.

Only you have the time and resources to fully understand and see the high-level picture of what’s needed to accomplish such cross-functional external processes.

I have no doubt many more lessons are to be learnt as I continue my journey in my role, so I hope to continue sharing them with you.

If you’ve enjoyed this piece, go ahead, give it a clap ??! You can also share it somewhere online so others can read it too. If you have any questions, feel free to drop me a line in the comments below!