How to scale up your R&D team quick but not dirty
Congrats! You’ve started your new role as an R&D team leader, the business has decided to focus on your product and they want your team to scale. Not just scale, massive-enormous-ultra-rapid-gigantic scale. The team has neither a regulated onboarding process nor documentation, and the base code has suffered from a lot of quick fixes in the past year.
How the hell are you going to do this?
One year ago that was my reality — my team scaled from four to fourteen team members in only seven months.
In this blog post, I’m going to share my three keys to success — it’s all about your fundamentals, tailormade onboarding and maintaining the process.
So if you are a manager
- of a fast-growing team
- who’s building a new team
- who’s a new first-line manager
- expecting your growth to be based on Junior engineers
- who wants to evolve and rethink your team’s processes
Ticking one or more of the boxes means this article is for you.
It’s all about your fundamentals
My first and most important rule is to invest in your fundamentals. Before the thunderstorm hits, invest time in building the processes, knowledge hub and the current team members.
Building the current team knowledge and knowledge hub
You know what your knowledge expectations of your team members are, in terms of technologies, infrastructure and product.
Your goal is to align and expose all your team members to this knowledge. Create an alignment and use it to build your knowledge hub:
- Map the features and technologies that each of your team members have been involved in
- Hold lectures on every subject
- Record them
- Let other team members summarize in your favourite wiki tool
These actions will lead you to achieve the following:
- Your team members will practice how to display and explain their work and technical knowledge to others.
- Your team will gain more knowledge on their past tasks — when you prepare a lecture you recognize your knowledge gaps.
- In order to summarize a lecture you need to deep dive into the theme — your team members will become familiar with features and technologies they may not have known before.
- You’ll freely gain two different ways of transferring the material to new team members.
Know your team
During this process, you’ll gain the ability to spot different behaviours and skills in your team that you might not get to know in your day-to-day routine.
You’ll notice who has the ability to explain technical things with clarity, who understands the product needs and who is familiar with the infrastructure.
Add this to your team members’ growth aspirations, and you will figure out who the people are that you should rely on in this process, or in other words who should be defined as “Buddies”.
Invest in your infrastructure
Have you ever found yourself over and over again commenting on different MRs in the same coding style guideline?
Do you need to manually roll up for the last working build version every time your deployment or health check breaks?
And do you have five different Wiki’s to follow when your local environment stops working as expected?
All of the above are real problems from different engineers in different companies that have been solved by open-source tools and automation.
Tackle your pain points.
Choose up to two or three pain points that are repetitive and time-consuming/production risky/nerve breaking and deal with them ASAP!
While you’ll increase your peace of mind, this will also make your new teammates feel more comfortable in making mistakes — or on the other hand, it’ll save them a significant amount of time.
Free Bonus — you’ll increase your current team velocity, quality and confidence.
Tailormade onboarding
You have a spotless Wiki, your staging and production environment are like two peas in a pod, and your mentors are more excited than ever.
Now it’s time to ask yourself… What is a good onboarding process?
There is no one person equivalent to another: Seniors VS Juniors, Deep divers VS Get the thing done, Infrastructure lovers VS Product-oriented, and this list goes on and on.
Your current goal is to customize a process that fits and hits most of your audience, while preparing them for the actual day-to-day routine.
Here are five ground rules to follow:
Bound the skill set from below and above
Divide the skill set into different groups, for example, coding skills, infrastructure & tools, and product knowledge. Define the must-haves in each group, in order to be able to succeed in the first task. Later define the nice-to-have and advanced material, so people with previous knowledge and experience in one of the groups will spend their onboarding time in a valuable way.
Acknowledge that different paths can lead to the same destiny
Different people gain knowledge in different ways. Try to grant your new members the widest range of ways to learn. If you followed the “it’s all about your fundamentals” section, you’ll already have video records and articles in your toolbox. Adding hands-on coding exercises will complete the circle for you.
Make your team members’ time count
Keep it simple for your team members, and don’t let them spend their valuable time on non-valuable knowledge. Arrange all relevant data in one organized place, and define which tools and practices are unique to your company. This way your team won’t get familiar with “Snowflake” — cloud-data warehouse-public-traded-company, instead of a service that was developed internally that shares the same name 😭.
Set clear goals
Even though you’ve followed the previous rule uncompromisingly, your new team member is still looking for the difference between EMR 5.6.1 and EMR 5.35.0, when you’re actually using EMR 6.5.0. Oops! Definitely non-valuable knowledge.
Be clear and precise with your expectations. There is a massive difference between “Learn Spark!” VS “Learn how to use window and aggregation functions and differ between inner, outer and left join”, “Be familiar with docker!” VS “What are the goals of docker, which problems does it solve? Get to know docker build, run and docker file.”
Avoid being vague — it will lead your team members to lose context, and you’ll be surprised how far away they can get from what you actually imagined.
Define concrete timelines
This will frame the onboarding process and add the essence of how much time they need to devote to each section in the process. Keep it realistic and not too tight, so your team members won’t be overwhelmed and will be empowered to maximize their time.
Be agile — you won’t make it on the first shot, but if you are responsive to your team members’ feedback, you will master the timeline to perfection.
The last, but not least, stage in the onboarding process is choosing the best first task.
Keep in mind that the goals of the first task are to:
- gain confidence
- use and practice part of the new skill set they have just gained
- learn at least one new practice, skill or product detail
For your sake, this task should not be in your team’s main delivery path, so you can give the new team members a decent amount of time to learn and explore. While you will remain calm and focused on understanding the level of skills they’ve gained so far.
Maintaining the process
Two months have passed, your new team member has finished their onboarding process, and your job is completed successfully.
Building a strong, independent and knowledgeable team is a never-ending process. Hold onto events that will maintain the knowledge sharing and be a safety net for the quality of your features.
Professional forums
Divide your team by their professions (Frontends VS Backends, Data Engineers VS Data Scientists) and hold a professional meeting for each of the groups once a week.
In this meeting you’ll present new features and the unique way they’re implemented, you’ll discuss problems from your day to day life, and hold lectures to present advanced methodologies.
Please note, this is a different and independent meeting from the general guild meeting. It’s intended to be a small and “safe” place to discuss what is really bothering your own team members. Of course complicated challenges can be discussed in the guild meetings.
Review, Review, Review
Remember — fresh eyes can make all the difference.
Reviewing is your strongest tool to guarantee quality and it can come about in many ways, the most popular one is Code Review. If it’s not in your team’s routine — buckle down and push forth, it is time for a change. Security bugs, edge cases that weren’t handled, or spaghetti code… these and many many more can be found in a good review. Here’s a great article that points to the 5 code review best practices.
But writing code is not always everything. Be innovative and think about your team’s process, point out the events that are important for success along the way and hold a meeting with stakeholders who can ask challenging questions.
Here’s an example of my team’s process, each square represents a point where we should meet and review.
Self development time
Invest between 5%-10% of your quarter on self development time for your team members.
It can be divided to 2–4 hours a week, or a full and continuous couple of days. Map, with your team member, their opportunities to grow and their lowlights, and build a studies plan .
You will gain a happy team member who feels that you care about them and their personal growth, and you will get the opportunity to build an educated and open minded team.
Wrapping up
Now it’s your time to build your own process, which suits your team and adopts the points you believe in.
What is your golden tip for scaling up a team?
