How to Scale Engineering Teams

When I joined the Picus Engineering team 3 years ago, there was only one development team. We have developed many features and added them to the product. As the product grew, the number of topics that needed special attention increased evenly. This led to the birth of new development teams. Now we are a big family with 8 development teams, 1 DevOps team, and 1 Data team.

In this post, I will try to share our experiences on how we grew our engineering teams, what kind of problems we faced, and how we solved them.

• Creating a team from scratch
• Expanding an existing team and dividing it into two

Since I joined Picus in December 2019, we have continued to grow steadily. As the needs increased, we evaluated the new team requirements and completed these processes by planning. I worked in 4 different development teams at Picus and witnessed the teams growing and giving birth to new teams twice.

In this post, I will focus on the experiences of scaling engineering teams.

At the end of 2021, due to the need for integrating more products faster, we expanded the team that I was part of at that time and later divided it into two. I started to lead the new team and we gradually added new team members.

After completing many new integrations within a year, a new, very large topic is assigned to us. It was clear that this topic needs special attention, it is too large to be handled alongside with other works that are already on the roadmap. A new team has to be created.

When we evaluated the new project requirements, we thought about which team would be the most suitable in terms of know-how and distribution of the workload. When we decided that our team was suitable, we decided to enlarge the team and divide it into 2 teams at the end of 2022.

Like anything else, it is critical to act according to the needs in this regard. It is important to determine a method based on the company’s structure, business needs, team situations, and workloads. We preferred to grow an existing team that was already working well and then divide it into two.

Expanding an existing team and dividing it into two has the following advantages:

• Spreading engineering and company culture
• Starting a new project in a team that works on the foundations
• Each team members get experience in how engineering teams grow
• Working in harmony with two teams
• Train new team leader candidates

Software engineering is not just about developing code. Increasing the number of people to finish a job in a shorter time may seem logical, but it can even cause it to take longer if we do not apply the right practices. It is necessary to create a balance in the teams to parallelize the development and to add more skills to a system. Productivity may decrease when a software development team exceeds 6–7 people. We are thinking about how to scale software. While product features are limited, we start out as a single service. As the product grows, the number of services increases, and communication between services becomes more complex. Similarly, scaling teams is a topic that needs to be considered. There are many steps to increase the team size and divide it into two. Everyone on the team witnesses this growth.

After choosing the team that will grow, it is necessary to continue the current team’s topics and new topics together. We started to determine the team’s needs by considering the appropriate requirements. For a while, we slowed down the current team’s work and focused on new topics. The current team had 6 people. In the first stage, we thought that we should reach 8 people and turn into two teams of 4 people and then continue to grow gradually according to the needs.

To briefly explain the process, we had a 3-month process for the establishment of the new team. At first, we thought about who could lead the team. There are many parameters for this; It is very important to have a strong technical aspect, strong communication, see the big picture, and have sufficient experience and potential.

Then we thought about how the teams would be divided. We considered each team member’s career goals, the harmony of the team, sources of motivation, the team’s needs, and the balance of front-end and back-end developers. We determined which friends in the two teams could continue, but along the way, we made some changes to suit the needs and career plans of the friends. While making decisions, we evaluated the ideas of our teammates, and made joint decisions and talked as a team.

We slowed down the current topics of the team and focused on the new topic for a while. We worked together over 4–5 sprints to establish the framework for the new project. As the team grew and time passed, discussing topics between the two teams increased meeting times. It takes time for 8 people to give a very short summary in the Daily, and the efficiency decreases. When the skeleton of the project that the new team was interested in started to form, we gradually separated their meetings and in the 5th sprint, we turned into two teams. Afterward, as 2 teams, we continue to advance different topics in parallel efficiently. We still do coffee hours together and we have good communication. I always continue to support the new team.

Starting a new project can be challenging due to the design uncertainties it often presents. It may be more challenging to go through this process in a new team than to handle it within an existing well-functioning team because building a new team would become an additional overhead apart from the technical problems to be solved. In addition, since the existing team is familiar with the existing architecture and features, this knowledge is also transferred to the new team.

Adding new colleagues to an existing team helps to establish consistent business development practices and spread company culture.When there is a good system that works well, new colleagues start to be productive quickly. Thus, when the team grows and divides into two, the new team continues with a company culture that has been established.

Two different software development teams don’t have to work completely isolated. Teams that develop different features in the same product family are efficient as long as they can work together in harmony. Complete isolation may cause problems like duplicate work, know-how transfer, and low collaboration. Growing a team and then dividing it into two means creating two sibling teams. Because they advance as a single team for a while, the team members become closer and learn to work together. Some friends from the first team can continue in the second team, thus providing natural interaction. When the teams continue as 2 teams, the tight bond provides an opportunity to work better together.

In development teams, a technical leader usually provides coaching. When an existing team needs to be grown and divided into two, another technical leader is needed. Good coaching by the team leader increases the team’s impact and benefit. The current team leader allows the friend who will lead the second team to coach for a certain period. When I established the team 1.5 years ago, Furkan’s coaching was very beneficial to me. Similarly, when establishing a new team, I tried to coach Berkay on leadership.

We completed this method that we used to expand to 10 teams, and we have developed a beautiful engineering culture that works in harmony.

So, are there any cons to this method? Like anything else, there are pros and cons, including:

Downsides

• The risk of causing a motivational loss
• Meetings start to last longer (daily, planning, etc..)
• Difficulty in allocating balanced time to the agendas of two teams
• Difficulty in organizing as the two teams work with different PM and UX

To reduce these effects, a good transition plan is necessary. Otherwise, having a team work on many issues for a year will lead to more negative effects. Also, one of the most important issues is who will continue in which team. Considering the career goals of each friend and the needs of the teams is important. It is important to take into account the thoughts of the team members.

We did this by planning, determining how many sprints to separate from the beginning, and monitoring the progress. We progressed together for 4–5 sprints. We determined who would continue in which team with great sensitivity. When the new team settled, we divided it into two healthily, and now both well-functioning teams continue.

I would like to thank Osman Osmanlı, Furkan Danışmaz, Berkay Akyazı, PM, UX, and all team members for their contributions and support during this process. We had a good process together and successfully completed it. In Picus, I have learned a lot from working with different teams and different friends. I hope we will go to the moon together.