Scaling Your Developers Team: When and How to Start?

Scaling the Team While Keeping up Productivity and Quality

Doist has two products, “Todoist,” an established market-leader and “Twist,” a new communication platform. At the time of this story, only three frontend developers were working on these.With the growth of both products, a sudden demand to scale became crucial. That’s when the challenges of building and scaling a team came into place.

How to Scale Your Team Without Breaking Your Culture or Productivity

To begin with, we decided to hire more developers. Strategically, we divided the newly hired developers into two different products, but at that point, we also noticed that they were working in silos. There was no knowledge sharing or cohesive bond to all these developers. What could solve this challenge?

The next thing we knew was that we needed a leader who’d guide the five developers. That’s when I stepped up. Leadership at that company is very hands-on; even though I became a team lead, I was still expected to read, review and write codes.

It wasn’t much about shipping new features, but I had to level up to learn the product and the processes. There were two challenges — technical and people management. We did not have one-on-one meetings, a product roadmap, or a planning process initially, but as we grew and scaled, these processes became a prerequisite.

As soon as we identified the issues, we knew that we had to introduce all these processes. However, we also had to keep the team’s velocity and the speed at which we shipped our features while time was short.

On the one hand, I was lucky to work with talented and intrinsically motivated professionals, but I gave them all a vision that together we could work towards. Being straightforward about what would work out and what could be improved enabled them to work towards a mission. In the meantime, it’s also essential to give them autonomy and let them figure out the details and how they would want to approach specific tasks.

As the team lead back then, I helped them look at the bigger picture, provided them with some guardrails, and let them run the processes.

Work on Improving the Processes

• Our codebase was 10years old, and we came up with the idea of renewing to newer technology. While doing so, I was super-mindful about the processes and costs that it may come with. Regardless, don’t be afraid to bring changes and new approaches for improvements. While your team is working on the goals and targets, as the lead, look for improvements.