The Squad Model: How Highfive does engineering

Highfive’s engineering team has recently gone through a transition to a new organizational model, one structured around cross-functional teams we called squads. Our squad model draws influence from a variety of other organizational models such as Spotify’s squads & tribes, Uber’s programs & platforms, and Yammer’s 2–10 & initiatives.

What is the squad model?

The squad model is a cross-functional organizational structure of a set of teams, each with a mission to solve specific product challenges. Each squad is composed of individual contributors from different disciplines and led by an individual contributor.

This model differs from traditional cross-functional teams that typically focus on a single project, as squads are essentially small startups that take on multiple projects to build a part of the product, or even a new product. Since each squad has contributors from every domain — from design to product, or mobile to backend — any squad has the breadth and the depth necessary for end-to-end ownership.

Why move from the traditional model?

Highfive’s engineering team started from a small flat generalist team and evolved to a traditional hierarchy split by domains: product, design, clients, core, devices, server, and QA. As we added domains, coordinating each of them to work fluidly together began adding overhead. The traditional hierarchy led to specific engineering challenges: decision-making, predictability, quality, and velocity.

Decision-making became costly as engineering managers needed to coordinate who would work on which project, how much time each project would take, who from which teams would be available on which timelines, and even make technical decisions based on these assumptions.

Most of Highfive’s coordination costs come from feature complexity. For example, a small feature can span five different platforms across the Highfive app (Android, iOS, web, desktop, and our embedded device), which also means product specs, designs, code, and testing across five platforms. With our small team, people were usually on multiple projects at the same time, suffering the expensive cost of constant context-switching.

This led to unpredictable planning and variable throughput for everyone.

Fortunately, we have a team composed of individuals who all exhibit collaborative, proactive, and leadership qualities. We wanted to ensure that all of these individuals continued to perpetuate and imprint those qualities onto the rest of the organization — and what better way than to have them work autonomously together on squads?

Why the squad model works for us

Squads decentralize much of the decision making within our organization, allowing teams to accelerate and focus on building the best product. This decentralization removes managers from technical implementation details and puts them in a position in which they focus on facilitating the communication and alignment between squads.

Squad leads, who are individual contributors, are selected based upon their prior successes in execution and managing cross-platform projects. Our squad leads are selected because they not only exhibit seniority and technical depth, but also strong cultural values that we want to imprint onto and perpetuate throughout the rest of the organization. These values include collaboration, empathy and humility, tenacity and resilience, and a desire to teach and learn. Squads also cultivate and amplify leadership qualities in the squad leads, making them responsible for project management, direction, and ultimately an understanding of how to run a team.

Squad members are selected to balance experience and disciplines. Squads themselves are granted full autonomy, empowering squad leads and their teams to make hard product decisions and act on them immediately. It may seem daunting if day-to-day decisions aren’t handled by a single product committee or overseer of roadmap, but truthfully, having strong alignment and providing upfront context to our teams has solved that. We can trust that individual contributors are making the right decisions for the customer while continuing to improve the product.

This additional focus within each squad also provides technical mobility for our teammates, who can work on different platforms or disciplines that they’re interested in. This flexibility promotes cross-functional development and technical diversity.

Our squads run for 10–12 weeks — long enough to make an impact across multiple facets of the product, but short enough to provide a healthy and necessary context switch. We’re heading into our second sprint soon, and not only has team feedback been overwhelmingly positive, but we’ve also been incredibly efficient in delivering.

Has your organization tried this model, or are you thinking about it? I’d love to hear your thoughts!

Think the squad model could work for you as an engineer? We’re hiring! Check out our careers page for more info.