6 Things I wish I knew before becoming VP R&D at a big startup

Lessons you don’t always learn from previous experience in tech

When I started my position as VP 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 pace environment.

A few mistakes straight into the position, made me realize very quickly that leading an R&D of over 20 employees requires a whole different set of skills and focus. Just to clarify, my team was constructed of five divisions — Front End, Back End, Mobile, Research (mostly machine learning) and QA. So here are 6 lessons I wish I knew when starting this positions:

1. 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 be the ones solving complex problems, or in other words, being the hero. As the leader of your R&D, 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.

You’re only as successful as your team

I found this rule to be very hard to accomplish since sometimes it feels much more effective to bring out a solution from experience, than have your team research for days on days. 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 only you are capable of.

2. Get to know your people

Understanding what empowers and motivates your team members is power. 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.

Get to know what motivates each of your team members

I schedule a weekly 1on1 meeting with each team leader and a monthly 1on1 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.

3. Never be a Bottleneck

The first mistake I did into the position, was took 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 yourself tasks such as deployment, 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. Always strive to be clear and aggressive about estimates

We’ve all been asked this questions before — “how long will this take?”, “why is it taking so long?”, etc. Surprisingly, we are often asked this kind 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 aggressive 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 aggressive 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 may be 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 R&D, it is a process my team can probably build better than me. Since they face the daily challenges of deployment, 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’d focus on external processes. Also, by having your team lead such internal processes, you’d increase overall engagement, sense of responsibility that would 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 Product, 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.

6. Be the technical voice

Although you should understand and pursue business requirements as a leader in the company, there are enough people in high ranks prioritizing business and marketing needs over your R&D needs. You should trust that others will try and push needs which might contradict your teams’ needs. Your job is to be the technical voice within the staff. You should make sure all R&D requirements and needs are considered with the staff while taking other requests into consideration. In the end, if you don’t, your internal priorities will be constantly pushed down and your team will feel neglected.

For example, my team and I greatly wanted to migrate our services to AWS, from a private cloud. This would require a 40% capacity of my team for 3 months. It was immediately translated within the staff to 3 months of time that could be focused on building more product and marketing features to help the business grow. Then how do you prove what’s more important? If I was to take their approach, I would risk retaining my top talent engineers, have challenges acquiring new talent, suppress innovation and eventually decrease team motivation. By politically succeeding in selling the business advantages of the migration (it’ll reduce costs and speed up development) it was finally approved. Six months later, my top talent is still retained and motivated, deployment speed has risen by 50%, costs have been reduced by 65% (by taking advantage of AWS services such as Spot instances) and we’ve even got $100K in credits.

Despite requiring several skills that are different from other technical roles, there are also some similarities. For example, just like in engineering, where each task brings on new unexpected challenges and constraints to deal with, so is here. In my opinion, the main skill for success in such a role (and I guess in almost any other role) is being able to embrace new, unexpected and dynamic challenges, while constantly striving to provide out of the box efficient and analytical solutions.

I have no doubt many more lessons are to be learned as I continue my journey in such roles, 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!