How we scaled our software development team from 5 to 50+

It’s no easy task to scale a development team. Many things can (and will) go wrong without proper planning.

Chaotic expansion. Failure to deliver according to the product roadmap. Unclear internal processes. Wrong hires. These are just a few examples.

Back in 2019, we were operating with a self-contained team of 7 developers. Our flagship product, TextMagic, was becoming more popular. After analyzing our customers’ usage patterns we found an incredible opportunity. So we decided to build a more robust product for business communications: Touchpoint.

Multitasking to scale development team

Touchpoint is a much more complex software than TextMagic. Initially, the goals we set for ourselves felt insurmountable. But with careful planning and the right hiring processes in place, we were able to see progress.

Developing Touchpoint also helped us see significant improvements that we could bring to TextMagic

We didn’t just scale our existing development team.

We also built a new team from scratch.

If you want to scale your development team, this article will give you the tools you need to succeed, based on our own experience. We will take you through our biggest pain points, the solutions we found, and our main takeaways. But first, some context:

Our dev team structure and dynamic

Number of developers: 51

We have separate teams for each of our projects:

Team #1: TextMagic project

The TextMagic development team previously consisted of 2 units: the full-stack development team and the DevOps team (which handles every server-related issue, deployment, and monitoring). At that time, we only had one product (TextMagic).

Because we had a global interface redesign planned and a huge feature list in the backlog, we decided to split the full-stack team into separate back-end and front-end teams.

Team #2: Touchpoint project

We decided on separate teams for the Touchpoint project right from the start. We ended up with the following structure:

A separate layout team is a must if you are as focused on UX/UI, as we are. Every single project or feature starts with the creation of the Flow and User stories. We imagine how the end-user will act in different scenarios and what the final UX/UI will look like.

Our product managers work closely together with the design team to create prototypes. This allows us to test every new feature interface’s final look and feel.

Once we agree on a feature, it goes to the layout team. They transform the Figma file into a clickable Vue prototype (e.g., prototype of the new TextMagic) with all the components needed by the front-end team.

This approach allows us to perform internal and external user testing before starting any real code development. This approach is invaluable because it saves us time and money.

Scaling pain points and how we overcame them

Once we started Touchpoint, we realized that such an ambitious project would need a separate development team. Strictly speaking, several development teams.

We used our existing team’s knowledge and experience to hire the first people. This allowed us to create a foundational backbone for the code that would sustain it.

We started to scale our development team after we onboarded four back- and front-end developers.

After that, we started a full-on hiring process to grow these teams. The plan was to expand the development team along with the product team. There were only two people on the product team at that point.

Problem #1: Filtering candidates from hundreds of applications

Our challenge was going through hundreds of applications and making sure we did not disqualify candidates that have potential, despite lacking skills on their CVs:

• 445 applicants for our Front-end developer position (65 eligible candidates),
• 417 applicants for our Back-end developer position (16 eligible candidates),
• 312 applicants for our Full-stack developer position (12 eligible candidates).

We rejected some candidates at the CV screening stage, but even then, we had to conduct many interviews. We were aware that our requirements are high and also that 42% of applicants don’t meet the skill requirements (but can still make great hires).

If we’d only invited fully qualified candidates to the interviews, we would have only hired 5-6 people by now. Some of our best hires didn’t tick all the boxes on their CV. Still, they had the right practical experience to help us develop our products.

Solution: Qualifying candidates through additional steps

We decided to put in place two extra steps to make sure we did not disqualify promising candidates:

• Technical screening interview. This interview consists of project-based questions. We tested the skills we actually need for the development of our products. A dedicated developer performs these screenings. They have the knowledge to filter out candidates based on their skillset. We only hire mid-level and senior developers. That’s because we need a team that can perform from the start, fully remote. The screening step is mandatory to assess the candidate’s level.
• Test task assignment during the early hiring stage. As more people applied to our positions, it became difficult for our developers to perform screenings. We decided to add a short test task to identify relevant candidates before moving to the next stage.

Problem #2: Lack of dedicated personnel

As we continued to grow, we realized that we needed a dedicated person (or more than one person) to assist candidates through the hiring pipeline.

Solution: HR team expansion

That’s how we started our HR team, which grew from 1 to 3 members in half a year.

Their responsibilities included:

• Holding the initial intro call
• Replying to candidates
• Assisting with the signing of the contract
• Ensuring the right equipment and logistics for the teams, etc.

We established procedures for the hiring and onboarding process. We also created contract templates and assigned a contact person for each onboarding procedure.

By taking these steps, the candidates and HR team shared a common understanding of procedures and were able to implement them according to plan.

Problem #3: Resource-consuming onboarding process

It is tricky to take on more people all at the same time because we rely on existing developers to onboard them. This can take up a lot of time they could otherwise spend on business tasks.

For example, bringing in three people in the same month registered a spike in the duration of onboarding meetings and pull-request reviews.

Solution: Separate onboarding timeframes for each candidate

We started adding new hires at a slower pace, spacing out onboarding processes. The amount of time developers took to onboard new hires remained the same, but it was more evenly distributed over time.

Another thing that helped was preparing clear onboarding documentation for the entire team. This made it easy to assign supervisors, assign tasks, and handle administrative tasks like facilitating office access for new hires using the building access control system.

Finding right people to scale a development team

A good plan is half the battle won. For this reason, we started with a very detailed description of our hiring procedures. This helped us take candidates through every stage of the hiring process, from initial screening to contract signing.

Then, we considered the following questions:

• What kind of experience do we consider mandatory?
• Are juniors an option?
• How fast do we need to get things done?
• How much time can we afford to allocate for the onboarding process?
• How will a new hire impact our development framework?
• Can our technology strategy support multiple new hires at the same time?

We proceeded to source candidates on different platforms with the answers to these questions in mind. We also implemented recommendations from other team members. 

Here are a few strategies we used to find and attract new talent:

• Posting answers for dev-specific questions on dedicated sites (StackOverflow, for instance);
• Sharing our job ads on multiple channels;
• Raising awareness about our brand on social media (Facebook, VK, LinkedIn);
• Using Upwork and similar platforms to hire developers;
• Publishing technical content in the form of articles and videos created by our product and development teams.

Improving workflows to scale development team

As our team grew from 5 to 50+ people, we adapted processes to suit our expanding structure. At first, we started with front-end and back-end teams. We now have functional product teams covering dedicated sections of our product.

As the team grows, so does its specificity: each product team specializes in distinctive product features.

In TextMagic, we use the Kanban method. In Touchpoint, we started with Kanban but swapped to the Scrum-based method. We operate in 2-week sprints for faster feedback cycles. This gave our team a clear understanding of the goals and the sprint’s scope.

A step-by-step approach

• MILESTONES: The highest level is a milestone (“version” in Jira). It is a big part of the product’s functionality, containing one or multiple business features. A milestone is usually 2-3 months long. Once the team completes a milestone, we present it to shareholders.
• EPICS: A milestone consists of several epics. These represent a single functionality area you can break down into smaller tasks (called stories).
• STORIES: A story describes each action the end-user can perform within our application (like adding a new contact, receiving a ticket, etc.). To convert these stories into code, our development team creates sub-tasks. They then perform research, write code and finally release them.
• Communication rules. One of our most significant challenges was sharing information in a way that works for everyone. Many of our developers work remotely. We set up team Slack channels and integrated them with Jira for real-time updates. Any change to a ticket is also posted in the relevant Slack channel. This makes it easier to share information in real time without overwhelming the team.

Four crucial lessons to scale a development team

Here’s what we learned after growing our team to over 50 developers:

• Grow your team gradually. Hiring the right people is as essential as onboarding them. When companies provide a solid onboarding, employees are 69% more likely to stay with the company for even three years. Limit and space out your onboarding processes to avoid increasing team workload.
• Set up clear, trackable procedures, deadlines, and guidelines for hiring and onboarding.
• Involve team members. Use their expertise and feedback to source, select, and onboard the right candidates.
• Focus on both hard and soft skills. While technical skills are more measurable and quantifiable, soft skills are also essential. They help your candidates integrate into your team and enhance collaboration between members.

To scale consistently, you need Continuous Integration and Continuous Delivery pipelines. As your team expands, you will add new CI pipelines, so communication between teams might be affected. 

Image Source: PEGA Academy

As a result, DevOps practices must be periodically revised and implemented according to schedule. You will need to use the infrastructure as a code method to scale your processes as you take on new projects. This way, you’ll be able to add separate infrastructure for each project without affecting the mainframe.

Here are some other practices we found useful to scale our development team:

• Shorter sprint durations. 2-week sprints allowed us to identify roadblocks before they turned into significant impediments. They also reduce time-to-market and unpredictability and decrease risk-specific costs.
• Avoid being generic. Break down codes into VERY specific pieces. If you share your codebase with the entire team, keep it simple. Avoid complex calculations and stick to more discrete functions. E.g., Obtain every info. regarding X project step is too generic; replace it with request sequences like Obtain user info, Obtain connection status, and Obtain server URL.
• Stay consistent with your denominations. Use only one name for the same concept; for ex., obtain, get, and retrieve all mean the same thing. If someone searches tasks using keywords, they will miss out on relevant info if they only search for “get.” To avoid confusion, agree on a single term that the entire team will use exclusively.
• Make room for extension, not constant modification. Your system is constantly improving. This happens because of innovation and code extension, not because you continuously “repair” old code to support new structures. Modifying old code will make way for unexpected system behaviors, while using new extensions will be more predictable.

Conclusion

The processes we developed through trial and error helped us grow our dev team to 50+ members. We hope it also enables you to scale your development team.

Since we started writing this article, we have added four new members to scale our development team. Together with our other departments, we are now 92 employees strong! 🎉