What I wish I knew when I became VP R&D of a large startup

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.

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 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.

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. 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.

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.

How to build a code review process

The ultimate guide for building your team’s code review process

After conducting hundreds of code reviews, leading R&D teams and pushing several unintentional bugs myself, I’ve decided to share my conclusions for building the ultimate code review process for your team.

This article assumes you know what is a code review. So if you don’t, click herefor a great intro.

Let’s quickly state some straight forward reasons as to why you should do code reviews:

1. Can help reduce bugs in code.

2. Validate that all coding requirements have been filled.

3. An effective way to learn from peers and get familiar with the code base.

4. Helps maintain code styling across the team.

5. Team cohesion — encourage developers to talk to each other on best practices and coding standards.

6. Improves overall code quality due to peer pressure.

However, code reviews can be one of the most difficult and time-consuming partsof the software development process.

We’ve all been there. Either you might have waited days until your code was reviewed, or once it was reviewed you started a ping pong with the reviewer of resubmitting your pull request. All of sudden you’re spending weeks going back and forth and context switching between new features and old commits that still need polishing.

If the code review process is not planned right, it could have more cost than value.

This is why it’s extremely important to structure and build a well defined process for code reviews within your engineering team.

In general, you’ll need to have in place well-defined guidelines for both the reviewer and reviewee, prior to creating a pull request and while it’s being reviewed. More specifically:

Define perquisites for creating pull requests.

I’ve found that the following greatly reduces friction:

1. Make sure code compiles successfully.

2. Read and annotate your code.

3. Build and run tests that validate the scope of your code.

4. All code in codebase should be tested.

5. Link relevant tickets/items in your task management tool (JIRA for example) to your pull request.

6. Do not assign a reviewer until you’ve finalized the above.

Define reviewee responsibilities

While the reviewer is last in the chain of merging your PR, the better it’s handed over by the reviewee, the fewer risks you’ll run into in the long term. Here are some guidelines that can greatly help:

1. Communicate with your reviewer — Give your reviewers background about your task. Since most of us pull request authors have likely been reviewers already, simply put yourself in the shoes of the reviewer and ask, “How could this be easier for me?”

2. Make smaller pull requests — Making smaller pull requests is the best way to speed up your review time. Keep your pull requests small so that you can iterate more quickly and accurately. In general, smaller code changes are also easier to test and verify as stable. When a pull request is small, it’s easier for the reviewers to understand the context and reason with the logic.

3. Avoid changes during the code review — Major changes in the middle of code review basically resets the entire review process. If you need to make major changes after submitting a review, you may want to ship your existing review and follow-up with additional changes. If you need to make major changes after starting the code review process, make sure to communicate this to the reviewer as early in the process as possible.

4. Respond to all actionable code review feedback — Even if you don’t implement their feedback, respond to it and explain your reasoning. If there’s something you don’t understand, ask questions inside or outside the code review.

5. Code reviews are discussions, not dictation — You can think of most code review feedback as a suggestion more than an order. It’s fine to disagree with a reviewer’s feedback but you need to explain why and give them an opportunity to respond.

Define reviewer responsibilities

Since the reviewer is last in the chain before merging the code, a great part of the responsibility is on him for reducing errors. The reviewer should:

1. Be aware to the task description and requirements.

2. Make sure to completely understand the code.

3. Evaluate all the architecture tradeoffs.

4. Divide your comments into 3 categories: Critical, Optional and Positive. The first are comments that the developer must accept to change, and the latter being comments that let the developer know your appreciation for nice pieces of code.

I’ve also found that a following checklist is a great tool for an overall better and easier reviewing process:

• Am I having difficulty in understanding this code?

• Is there any complexity in the code which could be reduced by refactoring?

• Is the code well organized in a package structure which makes sense?

• Are the class names intuitive and is it obvious what they do?

• Are there any classes which are notably large?

• Are there any particularly long methods?

• Do all the method names seem clear and intuitive?

• Is the code well documented?

• Is the code well tested?

• Are there ways in which this code could be made more efficient?

• Does the code meet our teams styling standards?

There are various effective and different code review approaches that vary based on team’s needs. So assume this is my personal opinion and that there are other ways that might work for your team. In the end, building such a sensitive process should be subjective to your companies goals, team’s culture and overall R&D structure.

If you have any questions or feedback for improving these guidelines, please feel free to add a comment below!