Everything you need to know about scaling an engineering team

During my first year as an engineering leader, I encountered an extreme scale-up situation.

The scale-up was a perfect example of hypergrowth, taking place within a short period of time around an aggressive deadline. When welcoming new talent and building new teams, we were trying to cram a year’s worth of experience into a couple of months. It was a crash course in what to do and not to do as you scale.

Having learned the hard way, here I’m going to walk you through my scale-up story and share my do’s and don’ts along the way.

The risks of scaling up your team

Before we scaled, my team was part of a fast-paced startup, we were on the highway to success, everything was happening quickly, and things were working well. Soon enough, the number of features grew so big that we needed to scale up the team. It was inevitable.

Ok, so let’s hire more developers. Make the team bigger. No problem here, hey?

Spoiler alert: this simply doesn’t work. Have you ever heard the saying, ‘throwing more people at the problem won’t solve it’? Well, I’d heard that saying a lot but I’d never really understood it. Not until it happened to me.

Scaling comes with several risks. Firstly, when your team has an amazing culture, and they work in perfect synergy together, you don’t want to lose it. Not only is it addictive, but it produces brilliant results. One of the biggest risks of scaling is losing your team’s special DNA.

There’s also another substantial risk: that of having your core team members lose their broad impact within the company, which can cause severe degradation of motivation. This is a team leader’s biggest nightmare.

Spoiler alert #2: if your process for scale doesn’t include a plan that will empower your team members, it simply won’t work. The easiest thing is if you have a promotion to offer them during the hypergrowth period. But what if you don’t? How can you still make sure they grow and not lose them along the way?

Overcoming the challenges

I had to be careful to empower my existing team members while we were scaling, particularly one member of the team. They were my go-to person and knew every corner of the product and codebase. As the team scaled, this person was at risk of losing their impact and influence in the team.

To overcome this challenge, I made sure they were paired with new team members for the upcoming projects. The new team members would be able to learn the ins and outs of the product from my go-to person. And on the other hand, this person could benefit from learning new technical skills and methods from the new team members. It also created a tight partnership between this key person and some new team members that had benefits for the long run. It was beautiful to watch from the outside!

While I was busy trying to find the best way to scale my team at a fast pace, another curveball was served to me. A challenging technical project came along that simply had to be completed within an impossible timeline. This called for an extreme solution, so we decided to ‘loan’ engineers and engineering managers from within the company. My team practically doubled its size overnight.

The do’s and don’ts of scaling an engineering team

Looking back at this challenging time, I definitely learned some do’s and don’ts along the way:

Do:

• Make your core team members your partners. Make sure they don’t get lost in the scaling process. Ensure they know what their part in the process is, and if they don’t have one, create one for them. Do what’s needed for them to feel impactful.
• Be flexible. Change processes, task assignments, and workflows frequently. When your team is in an extremely unstable period of time, revisit these things weekly and make the adaptations needed to find what works.
• Make time in the daily routine to explain these changes to the team. I found that using visual aids helps to get points across clearly.
• When using external help (from outside the team), give them a defined scope. Take the time to specify it and see they are aligned. If possible, give them a core team member. It’s better to disrupt one team member than the whole team.
• Invest time in good matchmaking. Assign new team members with old ones, experienced folks with less experience, and business logic experts with newbies. This will help reform the larger team’s DNA to be as similar to the old one as possible.

Don’t:

• Throw more people at the problem. It won’t solve anything. Bigger teams move slower. Create smaller teams that have a well-defined scope.
• Assume your team understands the bigger picture. They don’t. Be overly transparent and overly communicative. See to it that everybody in the team knows what’s going on today, this week, and in the long term. Also, be sure to let them know how you’re going to achieve it.
• Compromise on leadership power. Make sure you have enough leadership roles, that there is a defined hierarchy, and that everybody knows their place.

Ultimately, scaling one step at a time is the right thing to do. Implement small changes more frequently rather than doing big changes rarely. It doesn’t matter if the change needed is an HR restructure, a system design refactor, or a change in the team’s internal processes. As long as they are not done all at once.

I find that breaking up the change process into three steps helps simplify it and make it more streamlined:

Three steps for implementing change in your team

1. Detect when the change is needed.
Try to anticipate it as early as possible. These changes take time, the sooner you can start planning and getting ahead of them, the easier it will be.

Don’t be afraid of change and the unknown. Changes are always hard, and you will never have the perfect solution. Don’t let hesitation stall decisions.

2. Identify a solution that works best for the team
Map out the possible solutions and scenarios of change, and find the best one. Take into account your team members; make sure they each have an important role in the transition, and that their new place in the diagram will help them grow.

(On that note, never underestimate the power of encouraging less experienced folks in the team. While we were experiencing our aggressive scale, one of my devs was pretty new and still quite insecure in their role. The first thing I did when the team started growing was to give them as much responsibility as possible. It was nearly too much for them, but I kept encouraging them and letting them know I truly believed they could be successful. This dev quickly grew into one of my main go-to people!)

3. Act on your solution
Roll out your chosen scenario with sensitivity and intelligence. I can’t emphasize this enough. Make your team partners in the act of change. Be overly transparent, sharing the changes with them as early in the process as possible. Make sure you know exactly how this change will advance their career. And do whatever is needed so that they can see it clearly.

Your team is your core; they are the most important asset and they are key to your success. Look them in the eye, believe they will grow from this change, and help them do just that.

Reflections

Creating change at the right time and at frequent intervals is easier said than done. As an inexperienced manager, creating change of any sort seemed impossible to me. I was caught in the notion that my perfect team deserved a perfect plan for scaling up, and that only that perfect plan could create the certainty I felt I needed in order to navigate them through this challenging process.

But this state of mind paralyzed me from taking action at the right time. What I actually needed was to think of them – my perfect team – and how they would grow from this process. This partnership empowered me to have the confidence to try and error by implementing imperfect plans until we got it right together. If you’re in a similar position, I recommend you do the same.