Scaling from 1 to 100 engineers
Lessons learned at a fast-growing SaaS company
Scaling forces your organization to evolve. That is a challenge, especially when you’re growing faster than you’re able to remember names.
Over the last eight years at Showpad, we grew our product development department from 1 to over 100 engineers. Roughly doubling in size each year. While we were growing at this fast pace, we’ve repeatedly hit the limits of our organization.
This article focuses on how we’ve scaled and adjusted our organization to cope with this growth. The common thread in the whole story: continuously inspect and adapt your organization as you grow.
The early days
As long as the total number of people in a department is within single digits, organizations form without a formal structure. Simply because it isn’t needed, the number of communication lines is low and people take up work where needed. There is little need for explanation as ideas are created together and problems are tackled as they arise.
At Showpad, we managed to continue at this level for slightly longer than three years.
Mainly because we have restricted ourselves to only hire authentic good-natured ass-kickers living up to our values. Passionate about our vision and willing to move mountains to accomplish it.
Due to these shared values, the majority of these people are still working at Showpad eight years later. A very valuable characteristic as they have a background in how the department, company and even our market space has evolved.
The first split
At a certain level, even with all noses pointing in the same direction, it starts to become time-consuming to align with everybody. When we reached around 15 engineers it was time to split up.
Welcome Team A and B!
The impact of this physical split was huge. In fact, looking back at it we waited too long to do it. We were able to postpone this for that long because we had an informal split upfront. In the years following, our team sizes typically were between three and nine people.
The first effect was that these teams evolved towards the different personas in our product. One team taking care of features for the administrator, the other taking care of the end-user. This strengthened the connection with the customer and helped them in making decisions. In other words, they had the ability to focus again.
The second effect was the reflection of our organizational structure in our codebase. Better known as Conway’s law:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin Conway (1967)
Up until then, we had grown a monolithic architecture aligned with our team structure. Almost all our functionality was contained in one repository, conveniently called the “central station”.
As we split up the team, it became clear that this architecture was not scalable. In the coming months, similar to what happened to our teams, the application for our end-users was split off from our monolith. Meaning the first steps were being taken into the world of microservices.
Team leads
In each group one of the best engineers was given the role of a team lead, empowering them to give direction to the team.
After evaluating this for a couple of months, we noticed they didn’t like to take up career conversations or planning initiatives. What they really liked was coding. Next to that, they were also the best in class to help others to become better developers. Therefore, we changed the title to team coaches, an important nuance as this was making it clear for the team that they served as role models. The other activities related to people management or planning only occurred a couple of times each year and were taken up by others who were better fitted for this.
Jobs To Be Done
Only a year after the first split we’ve doubled our team in size again.
We realized that the current structure based on personas wasn’t scalable to handle our growth as we only had two user personas at that time. We needed to come up with a system that would last longer than a year.
One of us got to know a framework called Jobs To Be Done. The framework forces you to look at why customers hire your product to get a job done. If your product helps your customers to accomplish their jobs, they will use it again. Otherwise, they’ll start to look for an alternative.
As our product team looked into our product they could identify 10 Jobs To Be Done (or JTBD).
We started to bundle these jobs based on the amount of work that was planned for it, allowing us to come up with a structure that had a well-balanced workload.
This was a way for us to scale at least a couple of years, and our team structure could easily adapt to the demands of the market. If the market demanded more focus on a specific job, we could focus on optimizing that team.
It also allowed us to plan our growth better. When a team became too big to stay productive, we split up the group of JTBD together with the team. Narrowing their focus and reducing communication lines.
It was a perfect moment to move our product managers into the teams as well. But, as we tried it we realized our product team wasn’t big enough yet. Too many projects were being handed over between PM’s multiple times, surfacing the need for more stability to succeed. Something that we were only going to solve in a year or two when our product team doubled as well.
Tech To Be Done
A struggle with JBTD is that you can’t fit core services in these jobs. Like authentication for example. Each job that we had required the user to be authenticated.
For this reason, we did an adjustment to the framework and added: Tech To Be Done. These are services that multiple jobs require to be able to complete their work.
We followed the same approach as we did with JBTD: bundle the tech jobs based on the amount of work planned for it and map it to a team.
Insourcing QA
A team that was grown outside of our engineering team was our QA team. The main reason was that it was originally outsourced and they functioned as a gatekeeper. They gave a thumbs up (or down) when things were about to be shipped.
When moving to JBTD they clearly became the bottleneck. The single QA team struggled with the fluctuating output of the teams, which was typically peaking when a big release was nearing.
To solve this we merged the QA team in the other teams and made each team responsible for their own quality.
Suddenly, by solving the scaling problem we also shifted the focus towards producing high-quality features, hitting two birds with one stone. As a team became responsible for the quality of their domain, they started to take initiatives to improve it.
A side effect was that we had cut the flow between QA engineers to share knowledge and best practices, also known as the silo effect. We opened up these flows again by applying the guild model, something that is well explained in this article.
Product lines
By doing strategic acquisitions in the last years our product grew aggressively as well. Therefore our latest change was to introduce product lines on top of our organization. These are mapped on parts of the product that are being sold separately and are capable of functioning on their own while integrating with other parts of the product.
Together with this change, we are taking steps towards having fully autonomous teams. In other words: teams that can build out an entire flow within our product: from idea to the smile of the customer.
This means:
- Adding a product owner to each team
- Adding a designer to each team
- Bringing DevOps ownership into the teams
- Creating processes to allow teams to update marketing material
At the moment similar challenges start to arise as we had when we started to insource QA. Overarching layers are needed to get alignment, share knowledge, and optimize processes.
Summary
Over the past eight years, as we grew, we continuously adapted our organization to align with the demands of the market. Always starting from our customers, whether it was through personas, JTBD or product lines. This allowed them to focus on the priorities of the customers.
As stated by Conway’s law, every organization structure we had is reflected in our product and architecture. Keep this in mind when you iterate on yours, mistakes will be costly to revert.
Finally, as a guideline, keep team sizes from a minimum of three to a maximum of nine people. Smaller teams have the benefit of being more focussed, the larger ones are more stable. If a team is heading towards ten or more people, it’s a signal to split them up.
Got interested?
- Contact me on LinkedIn
- Learn more about us by visiting our engineering blog
- Clap for this article 👏
