Tips to Scale an Existing Engineering Team
28 December, 2021

COO at ShippyPro
When Ends Don’t Meet Due to Skills Set Gap
As the business expands, it becomes increasingly essential to scale the team to make ends meet. I joined an organization with a single engineering team, where the product was extensive and complex and served customers worldwide. Because of how the product was designed and functioning, it was cumbersome to manage and continue to evolve. I identified that we were starting to create expertise within individuals rather than groups with a single engineering team. For instance, there was a particular subject matter expert for a specific feature. It was causing much trouble from a business continuity standpoint. For that reason, if the individual were on sick leave, it would jeopardize the entire product.
Relax, and Define the Product
First things first, I sat down with the product team and started crafting out the pain points from a customer and product point of view. What were the external and internal boundaries of our solution? Identifying these factors could have made sense for us to speak internally and externally represent it to the customer.
We defined an initial group of four teams based on that, and within that, we defined four potential managers. Although we already had three of them, we discovered the fourth manager in order to start defining the logical grouping of individuals that made sense for the team. However, the structure was very flexible, where the engineers could move between groups as the company kept evolving yet maintaining a long-lived approach where we could expand expertises within the same core of individuals.
Making sure that knowledge sharing came into place, moving from individual experts to group experts. We addressed that having more than 1 person handle the technical challenges and maintain the product was important.
One last thing that I focused a lot on was defining the productivity of each team. When there’s a single engineering position, it’s easier to manage the outcome and performance of the team. However, when there are individual teams, driving metrics and measurements to scale the output becomes crucial. Therefore, finding the missing skill set of each team and focusing on the end-to-end delivery was the key.
Make Mistakes and Learn From Them
- Don’t be afraid of making mistakes. There is no cookie-cutter approach to a reorg. Naturally, whatever you might be producing now is going to be outdated as the company keeps growing and evolving its structure. Avoid getting into the analysis paralysis; instead, work with the team to identify the problems and be on top.
- As an engineering team, as much as you collaborate with the product team, don’t forget to join forces with other groups, such as sales. It will enable you to understand how the product is positioned to prospective customers. Also, it will give you ample insight into how you can define the products, and therefore, the teams in a productive manner.
- Make sure to analyze the skill sets and gaps within each team.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
21 March
Based on an awesome book titled "Deep Work" by Cal Newport we provide provide a brief overview of the Rules for Focused Success in a Distracted World.

Ramesh Dewangan
CEO at Quantum Vision Consulting
20 March
Learn about 10 rules from the wisdom of these long-living residents from Ogimi, a small village in Okinawa, Japan. You could interpret the rules as the lifestyle habits that enable the senior residents of Ogami to live long and enjoy their ikigai.

Ramesh Dewangan
CEO at Quantum Vision Consulting
7 March
3 ways leaders can cultivate relationships that lead to better products.

Guy Jenkins
SVP Global Customer Experience at Salesforce
5 February
Giving confusing direction to team is perilous. But giving clarity is so very important.

Kamal Raj Guptha R
Engineering Manager at Jeavio
3 February
This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.

Alex Shaw
Chief Technology and Product Officer at Hive Learning