Over the past year, the VGS team has doubled; to support that growth, we’ve had to evolve how we structure our engineering team. Here we detail the choice to adopt the squads structure as the one to scale with our team.
Silos, slowdowns and lack of autonomy
Historically, VGS relied on the functional framework, a widely used standard, and not just in software development. It’s an organizational model found in various sectors, from pharma to manufacturing – and is a frequent go-to for startups.
In the functional model, teams are split up according to function. In our case, a back-end team, a front-end team, a security team and a devops team all working on their own respective functions as part of our wider development goals. In the early stages of VGS’ journey, this enabled us to ship code with little overhead.
Starting from no structure at all, introducing the functional model was a step in the right direction. As we began to grow and scale, however, this model started to become less and less efficient.
When a startup is still small, the functional model makes ownership feel apparent and decision making quick. As the team grew, so did the number of ongoing projects and priorities making it challenging to focus teams.
The functional model caused us to run into a number of problems as the company expanded:
- Siloed Functions: Teams were working fractionally on the same larger goal meaning that ownership of one feature was shared across several teams. Frequently we ran into issues when engineers from different teams worked on the same goal separately, this meant that if the backend team completed a task in one iteration, it might take weeks to get it prioritized for the frontend team to finish their component.
- Development Slowdown: The siloed and layered nature of our team structure led to unnecessary slowdown in the development journey – primarily due to strained communication among teams serving different functions.
Communication across teams became difficult to manage as we increased the scope of our product and hired new engineers to build it out.
- Lack of Autonomy: On top of longer product delivery periods, it was challenging for engineers to feel true ownership of the products they were working on.
Instead of feeling ownership of the entirety of a feature, teams owned just one area of the stack and thus only pieces of any feature This sparks a sense of passive – rather than active – ownership of the collective mission.
Ensuring that engineers have the space and autonomy to innovate is critical to building software in a fast paced environment. It’s especially critical for us because our product is built for developers, so our own engineers are one of the best sources for new ideas for how to grow the product.
Ownership is motivating, and autonomous creators build superior products more quickly by empowering engineers to make decisions locally.
Choosing the squad model
To support rapid growth across new and existing customers, the VGS engineering team has delivered more and more complex features. To complement this growth in our product, we similarly had to grow our engineering team.
As the team grew, we realized it was time for a change to address the problems that we’d observed.
Our CTO, Marshall Jones, set out to research how other start ups addressed these pain points and structured their engineering teams to enable hyper growth. The squad approach prevailed as a well tested model that was designed to address the very issues we’d observed. Our initial model for how to implement squads comes from the team structure designed by Spotify. We took that approach and adapted it to fit our team and needs.
How does the squad model work?
A squad is a small, cross-functional group of engineers and product people that come together to solve a particular problem.
We split our teams into squads of 8 or fewer team members, each comprised of engineers across all necessary functions (e.g. back end, front end). Each squad has autonomy over their own mission, with full ownership of the processes and outcomes.
Squads are organized based on their responsibilities, such as“identity and access management” or “integrations”. Individually, each team has the autonomy to figure out what to create, how to create it, and how to work together in order to achieve their objective.
So, how did we assemble our squads and figure out who goes where?
We started to solve this puzzle by crafting a comprehensive map of our engineers, categorizing them within their respective responsibility zones. We then grouped these into logical teams based on areas of ownership. Where we identified holes in the team structure, a missing front end engineer on one team, a product manager on another, we opened the necessary requisitions and hired either internally or externally to complete the teams.
While every squad retains a high level of ownership over their focus area, their work must align with the product strategy, short-term objectives and long-term goals of VGS as a whole. As long as all squads are aligned on these fronts, they individually are able to impact our wider mission.
The impact of switching
By empowering each of our teams to take full ownership of an end-to-end feature or solution, we’ve realized a number of benefits, including:
- Self-sufficiency: Each squad has the right people and skill sets, so they don’t need to constantly rely on other teams.
- Flexibility: Squads are super easy to build, tear down, rearrange and generally switch up, based on the immediate needs of our business.
- Replicability: Their flexibility makes them easily replicable, too. When we decide to add a new product or feature, we simply make a new squad.
- Shorter, more efficient meetings: Meetings can be brief and easily-managed, as day-to-day open communication is elevated by a cross-functional dynamic with fewer team members. The frequency of meetings is also lightened because of the tight feedback loop.
What we learned over time
The benefits of switching to the squad system were immediately obvious. As we started to grow accustomed to the squad structure, though, there are a couple of lessons that have been critical to our successful adoption of this framework: the importance of alignment and customization.
Alignment
It’s crucial that all team members clearly understand the company mission and values. The stronger our company-wide alignment is, the more effectively squads can operate autonomously.
Customization is essential
While several tech companies have already implemented their own version of the squad model, we’ve customized our squad framework to make sure that it works for us.
As a security first organization, we’ve opted to create one squad outside the normal model: our security team.
Data security is what we do and what our customers rely on us to provide for them. We need to guarantee that security is always our top priority as an organization.
We did this by making our security team its own department that reports straight to the CEO, separated from the collection of squads that comprise the rest of VGS engineering– though still constantly working closely alongside the other teams.
Looking Back on Our Squad Journey
As a tech startup that suddenly had to navigate the choppy waters of needing to rapidly expand our development arm, there are so many lessons we learned along the way.
Beginning by dividing our engineering teams by function, wasn’t a mistake – simply a step in our growth as a dynamic organization that’s ready to roll with the punches.
The squad model and all the benefits it has provided us is undoubtedly the right direction to take VGS in, and we can confidently recommend this flexible approach to growing tech startups in a similar position.
But, like us, there will be a learning curve to overcome, and each startup will need to customize their squad structure to meet their company’s unique needs.
As long as autonomy and ownership are encouraged, and everyone is on the same page, any startup can enjoy the flexibility, replicability and efficiency that the squad model provides.
Interested in joining our team? Check out our careers page here or complete our technical puzzle.
