How to Scale an Engineering Team – Lessons from a Growing SaaS Company

Most SaaS companies grow out of good ideas nurtured by a collaborative culture and an evolving set of processes that are learned, refined, and remade. It can be a fun, exciting time of growth and possibility.

However, with successful growth comes the need to scale and (re)structure ways of doing, best practices, and entire teams. While this is true of nearly every growth-stage SaaS organization, the challenges are unique for engineers, who rely on quick collaboration and iteration to grow. In early stages, they need to build from the ground up to make the Founder’s vision come true.

Each SaaS company is unique, but the challenges and lessons learned from scaling can be fairly universal. This is the story of how I, as the VP of Engineering at ThirdPartyTrust (a third party risk management or TPRM company), quadrupled my team while trying to retain our core strengths (and my personal sanity.)

The challenges of growing an engineering team

When I joined ThirdPartyTrust, you could count the entire Engineering team on one hand. We started as a team of five, with one or two people for each bare bones specialty: front end, back end, and QA. There was no hyper-specialization or unneeded overlap, just a group of busy people focusing on what needed to be done.

This made it easy for everyone to know what was going on, and we could help each other out anytime. The number of moving parts was small enough that you could track everything in your head. It was a very dynamic, collegial approach.

However, it didn’t come without limitations. We quickly realized these included:

• Lack of formal processes – no set way of doing things because we were more concerned about getting it done than getting it done exactly right
• Different priorities – no clear hierarchy of needs or deadlines driving our workflow
• Desynchronization – everyone working on their own project(s) without pooling resources
• Constant distractions (i.e. fires to put out) – no clear guidelines on when to prioritize certain “emergencies” over others 
• Severe multitasking – no clear boundaries on what our singular focus should be at any given point

Perhaps the biggest challenge was making sure we were growing in the right direction. When rushed by deadlines, feature requests and hot fixes, it’s easy to perpetuate some old habits. These few people were so used to doing their thing in their own way that we had to be very careful not to grow as separate islands.

Spoiler alert: We successfully scaled the Engineering team from 5 to 20 people and counting, in a way that set the example for the rest of the organization.

Here are 3 lessons learned from our experience that will hopefully help other growing SaaS or tech startups.

#1 Multitasking does not allow you to do more

When everyone was doing everything, there was a constant back and forth with the same projects that made it difficult to focus on new ones. It was closer to an orchestra where every single instrument was playing their own tune.

With that came the challenge of stopping the severe multitasking and putting all the necessary resources to a common goal. There will always be a fair amount of multitasking in a growth-stage company, but we managed to minimize it. 

We assembled a multidisciplinary team, removing the noise and distractions so we could work with a common goal. Which brings us to the next topic: adding bodies to the process.

#2 Recruiting and nurturing the right people is often underrated

The specialty team structure proved to be successful, so we kept it and added one more area of expertise: DevOps. Every new bottleneck meant readjusting processes and, more importantly, identifying gaps in the team structure.

Attracting and securing the right hires is a huge, time-consuming task, especially when you’re heading to your next round of VC investment. Growing stage companies simply can’t afford to make hiring mistakes.

The SaaS market is known, among other things, for having high competition in recruiting. I’ve heard colleagues complain about long hiring processes, friction between recruiters and hiring managers, and miscommunication around expectations on both sides. Recruiters often work independently and technical leads often feel their needs are not being met.

So how did we succeed in our recruiting efforts? We trusted our own instincts and have always resorted to our great network of referrals to find the right people. Every time we identified a new vacancy, someone from the team knew exactly who to call. By now, a network of 20+ engineers with rich backgrounds always knows where to find our next hire.

Another important aspect of the people component is mentoring. Engineers who join a scaling team have some learning to do about the software, the culture, and the codebase.

While some leaders fret over how to balance mentoring with getting things done, I’ve found collaborative work between the most experienced team members and the new hires has often enriched the process with positive outcomes and interesting suggestions. 

#3 Frameworks are much needed, but so is being flexible

By now, using Scrum is a must in the Engineering world, but for us, it only made sense when we were truly organized and structured as sub-teams with a clear goal. Frameworks only work when you’re ready for them, not when you’re following a trend. 

You also need a certain degree of flexibility to adapt the methodology to your own environment, so as to make it work for you. As many other organizations, we split into different multidisciplinary squads, mixing talent from our different areas. These teams work independently on core feature development, product roadmap, bug fixes and technical debt.

We also build dynamic, temporary teams for specific projects that are later dissolved. While the squads do ‘business as usual’, we might build a new mixed subteam that is specifically adequate to solve a specific problem or situation that may arise. Once they find the quickest and smartest solution, we dissolve this specialty team and everyone goes back to their squad’s plan.

The goal is to use frameworks and methodologies as a tool or guideline, not as a constraint. Allow your team the right amount of flexibility and spontaneity and you’ll be pleased with the results.

Setting the example for other teams

In a way, the Engineering field enjoys a more mature set of frameworks and methodologies than other areas, such as Sales, Marketing or Operations. Our journey on how to scale the Engineering team was the first of its nature at ThirdPartyTrust. Once the results were visible to the rest of the organization, it served as an example for other areas and business goals.

I’m proud to say our learning experience set an example in terms of processes, team building, work dynamics, and collaboration. Once the Engineering team was organized, we were able to find other gaps across the organization’s structure and push to make a change. A clear example was the need to create a Product team somewhere along the way, when we realized our input for product development was missing something.

We now have a scalable ‘copy & paste’ model that we can replicate whenever we need it. We’re no longer stopping everything to put down a fire, because our structure allows us to put down the fire while we continue our original work plan.

Forming new teams or divisions, or adding bodies to the process, are not a challenge anymore: we know what works best for our growth and we simply replicate it. 

It wasn’t always easy and it required a lot of fine tuning, learning from our pitfalls and redefining what we thought we knew. But thanks to that, 5 years later, we can now safely say our multidisciplinary squads are ready to keep making ThirdPartyTrust grow.