Scaling a development team is hard. 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.
Touchpoint is a much more complex software than TextMagic, with 5x more functionalities (support, marketing, sales, and collaboration). 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 grow 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:
Number of developers: 51
We have separate teams for each of our projects:
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.
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.
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.
The actual development started after we onboarded four back- and front-end developers.
After that, we started a full-scale 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.
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:
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.
We decided to put in place two extra steps to make sure we did not disqualify promising candidates:
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.
That’s how we started our HR team, which grew from 1 to 3 members in half a year.
Their responsibilities included:
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.
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.
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.
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:
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:
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.
Here’s what we learned after growing our team to over 50 developers:
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 when scaling our development team:
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 the development team. Together with our other departments, we are now 92 employees strong! 🎉
Want to become part of our team? We are always looking for talented self-starters to join us on our journey. Check out all our job openings on the career site.
Joined in 2013, Dmitry improved the TextMagic product as a back-end developer. With the new Touchpoint product a new challenge has arrived, and he moved to a VP of Engineering position to build a bridge between the product team and developers.
From omnichannel to personalized onboarding, these seven customer onboarding trends will help you improve your customers' first experience with your product.
If you want to improve customer experience and customer loyalty, you should take a closer look at your CSAT and NPS. In this article we compare CSAT vs NPS to help you measure CX more effectively.
We use cookies on the website to collect information about the use of our website and to personalize the experience of using our website. You can find more information about cookies in Touchpoint.com Cookie Policy.