Scaling Purposefully

Problem

This story recalls a time where I was asked to grow an org from twenty people to more than one hundred and thirty in about a year and a half. Adjusting to this change in scale was a phenomenal experience. I learned so much and made a lot of mistakes along the way.

Looking back, I have a 20/20 perspective on what I would have done differently if I had the chance to do it all again.

Actions taken

I found myself leading a single team of twenty people on my own. We were responsible for one product within the company.

Around this time, one of my peers ended up leaving the company. I inherited the team that they had left behind. That team was much larger than my own, and there were only two junior managers on it. I was given this entire org to deal with on top of the people that I was responsible for to begin with. I had no intermediary leaders to fall back on when it came to my original team of engineers.

During this transition, one of these junior managers ended up quitting, as well, leaving me with fifty people to take care of nearly single-handedly. All of this had happened right in the middle of one of our product release cycles, to make matters even worse. We needed to maintain our pace despite all of the chaos happening at our level.

Our leadership wanted me to scale this team from fifty people to around one hundred within a year’s time. We had the headcount and the budget, everything that we needed to proceed. I found myself balancing between the people already given to me to lead and finding those who would be joining us later on. We did not want those currently on the team to see the transition as a disruption to their work.

I decided to really take my time when hiring new managers. I didn’t want to rush through this; hiring managers is much more complex than hiring individual contributors. The impact that they stand to make on the company is much greater. If you hire the wrong manager, the entire team is impacted. If you hire the wrong IC, only their own work will suffer, in a general sense.

This would take time, but I vowed to take any resulting burden onto myself in order to make this possible. It was a mess at times and often very difficult, but, thankfully, I had many great technical leads on the team who were able to help me run things on a day-to-day level. I brought in program managers to help me organize everything. They were able to introduce some process and some rigor to our workflow.

As if all of this were not enough, I was later given a third team to manage. Luckily, this one came with a manager already on-board. By this point, I was already very familiar with how best to assimilate teams under one unified charter. I was able to create synergy between all of the products and services that we were building alongside one another.

Lessons learned

• As a people organizer, I initially had a very tough time figuring everything out. Looking back, this may have been because I was very particular about how my engineering teams operated; I wanted to make sure that the work was truly being done right. I got too personally involved with the complex technical work that they were tasked with. After six months, it really got to me. I had to slow down and ask for help.
• By the time that I was actually hiring managers, we were already a team of seventy-five. In retrospect, this may have been too long to wait. Yes, hiring managers is more difficult and takes more time. Taking the time to do all of this footwork at the beginning of the initiative would have been a better choice in the long run, however.
• All of this happened during the pandemic, which only made things more challenging. The virtual thing was completely new to me. It threw us off a lot and made it difficult to connect to all of these new colleagues. In person, people naturally get together to share knowledge and to ask questions. We hosted a number of virtual bootcamps in order to mimic these in-office chances to get to know one another. We also use a monthly newsletter to celebrate our wins as a team.