When to split your engineering team into squads (and when not to)

Every growing engineering org hits the same wall. Coordination gets harder. Delivery slows down. And leadership starts looking for a fix.

Most of the time, the fix they reach for is squads. "Spotify did it. Why not us?"

Here's the thing. Sometimes that's exactly right. When a team has truly outgrown its structure, splitting is the smartest move you can make. But when the real problem has nothing to do with structure, a reorg doesn't fix anything. It just pours fuel on the fire.

So the question isn't whether squads work. It's whether they're the answer to your problem. This guide is about telling the difference. When to split your engineering team into squads, when to hold, and what it actually takes to make the split pay off.

What is a squad, actually?

A squad can be defined as a small, cross-functional, semi-autonomous team working around a product domain, customer outcome, or system area.

The defining characteristic of a real squad is outcome ownership. Each squad manages its own backlog, owns its technical direction, coordinates directly with stakeholders, and is responsible for delivering results within its domain.

The engineering team squad structure suggests having a technical lead, a PM, and a full-stack engineering capability in each unit. Shared functions like QA and DevOps can work across squads on a project basis. But the squad itself must be able to ship without dependencies on other units.

It's important to distinguish a squad from a functional team and a feature team.

While a squad is a small, cross-functional team that owns a specific product area end-to-end, a functional team is a group created based on expertise or technical layer, such as a backend team focused on writing backend code. A feature team, in turn, is still cross-functional, but it delivers specific features rather than owns a broader product area long-term. These distinctions matter even more in outsourcing setups, where ownership boundaries are easier to blur across distributed teams.

More details are in the table below.

The squad concept became particularly popular thanks to Spotify's engineering model, which Henrik Kniberg and Anders Ivarsson described in their article Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. The structure emerged during a period of rapid growth, as Spotify's team scaled from 30 to 250 people over three years.

An important nuance is that the "Spotify model" was never intended to be a fixed framework. The original authors described it as a snapshot of how Spotify was working at that particular stage of growth, not a template for other companies to use as-is. That is why the squad model in software development works best when adapted to a company's actual architecture, delivery model, product structure, and organizational maturity.

Three organizing principles of splitting

When deciding how to organize engineering squads, companies usually take into account the main source of complexity in their environment.

The most common approach is splitting by product domain, where each squad works on a specific area of the product, such as reporting, notifications, or billing. It makes sense when different parts of the product can evolve relatively independently.

Some companies organize squads around customer segments or journey stages. In this case, teams focus on business outcomes like acquisition, activation, or retention rather than on individual system components. This is more common in B2C products, where funnel metrics make a great impact on product strategy.

As organizations grow further, many switch to the Team Topologies model (stream-aligned + platform teams). Here, product squads focus on delivery, while platform teams own shared infrastructure, internal tooling, CI/CD, and common services. This approach helps reduce friction and prevent every squad from solving the same infrastructure problems independently. In fact, Gartner reported that by 2026, 80% of large software engineering organizations are expected to have platform engineering teams.

Which model works best depends on the product architecture, team composition, operational maturity, and where coordination overhead is concentrated.

Key organizing principles of splitting

Signals that it's time to split

When to reorganize the engineering team? If your current structure isn't efficient anymore, you'll see the signs. However, just like one drop doesn't make rain, one signal alone isn't enough to start a reorganization. When several appear together, it's definitely a call to action.

Signal 1: The team is too crowded

As new engineers join the team, not only does coordination become more challenging, but also people get less productive.

Research in group dynamics shows that as team size increases, individual contribution can decrease when it comes to tightly coupled collaborative tasks.

Therefore, engineering companies often aim to keep teams small enough to ensure short communication loops and clear ownership.

Amazon, for example, realized this idea in its well-known "two-pizza team" principle: teams small enough to feed with two pizzas maintain better speed, focus, and innovation.

So once a team exceeds cognitive manageability, splitting is a structural necessity.

Signal 2: Stand-ups exceed 20 minutes and are useful to fewer than half the room

The shift toward remote and hybrid work has made coordination much more communication-heavy for many companies. According to Clockwise data, the average software engineer spends around 10.9 hours per week in meetings.

In unstructured teams, that number can grow even higher. But the real problem arises when stand-ups stop serving the people in the room. If engineers attend meetings that are only partially relevant to their work, discussions drift across unrelated domains, and synchronization takes more time than execution itself, it's a sign that the team has become too large to function efficiently as a single coordination unit.

Signal 3: Regular context switching between product areas slows individual output

Research by Prof. Gloria Mark found that knowledge workers require 23 minutes and 15 seconds on average to regain focus after an interruption. For engineers tackling three unrelated product areas in a single sprint, each context switch is an interruption that takes time, as well as a cause of stress.

When the total overhead cost becomes visible in sprint velocity, product domain ownership is the solution. Splitting into squads provides it.

Signal 4: Different product areas need different delivery cadences

Customer-facing features, platform work, integrations, analytics, and infrastructure don't usually move at the same pace.

When engineers who handle different areas with fundamentally different delivery rhythms are forced into the same planning cadence, this creates problems.

Planning becomes overloaded with competing priorities, release cycles become harder to align, and some engineers' urgency continuously disrupts other engineers' workflows.

A squad structure can solve this by enabling engineering groups to work according to the cadence of their own domain.

Signal 5: Coordination takes more time than execution

When engineers spend more time coordinating work than doing it, that's a strong sign.

The existing coordination model is a delivery bottleneck when small changes require multiple approvals, dependencies need regular synchronization, and engineers frequently pause implementation work to clarify ownership or agree on priorities across different stakeholders.

This often happens when too many product areas, services, or workflows are managed inside the same team. Splitting the development team into squads ensures narrower ownership boundaries, which reduces the amount of coordination required for everyday work.

Signal 6: Delivery slows down even though the team expands

Extra engineers are expected to improve capacity. However, in growing teams, you often can see the opposite: as headcount grows, output remains the same or becomes less predictable.

Fred Brooks described this phenomenon in The Mythical Man-Month, claiming that adding people to an already complex software project can negatively impact productivity instead of improving it due to the communication and onboarding burden.

When delivery slows down despite team growth, it is often a sign that the company lacks the right structure and coordination model to enable further scale.

Conditions for splitting a team into squads

Spotting the signals is only half the battle. A squad split works well only when a company is ready for teams to work with a higher level of independence. Here are the conditions that need to be in place first.

1. Large enough team to be split into functional units. A squad of two engineers is not a squad. The minimum feasible squad size for real autonomy is four engineers, which is why an original team needs at least eight people before splitting creates two functional units.

2. Separable product domains. Squads are beneficial when different areas of the product — for example, payments, analytics, search, and internal tooling — can evolve more or less independently, with their own priorities, stakeholders, goals, and delivery pace.

3. Opportunities for architectural separation. When everything under the hood is tightly connected, it's impossible to create independent squads. If engineers across squads modify the same services, share databases, or rely on the same deployment pipeline, coordination overhead isn't reduced but spread across more teams.

4. Sufficient seniority and leadership. To work semi-independently, every squad needs enough experience. That's why a company should have technical leadership and engineers who can own delivery without pulling upper management into day-to-day discussions.

5. A relatively stable product roadmap. Squads are created around long-term ownership. If priorities majorly change every few weeks, teams have to continuously reorganize around temporary initiatives instead of building expertise within a domain.

6. Operational maturity. In the squad model, things like documentation, onboarding, CI/CD practices, monitoring, and cross-team communication are much more important. Without them, squads can easily turn into isolated silos.

7. Clear ownership of shared areas. Before splitting, the company should define who will own shared infrastructure, platform tooling, DevOps processes, architecture governance, and other cross-cutting concerns. Otherwise, those responsibilities often stay in a gray zone after the reorganization.

When all these conditions are in place, squads bring plenty of advantages:

• clearer ownership

• faster decision-making

• fewer management bottlenecks

• deeper domain expertise

• lower coordination overhead.

Without these basic foundations, the reorganization won't reduce complexity but add to it.

A split readiness checklist

To avoid failure and disappointment, you need to be fully ready for a split. To help you, we've prepared a checklist you need to use before initiating a squad reorganization. If each of the following has a clear yes, go on. If more than two are unclear, you'd better address them first.

Organizational readiness

• Each squad can be given a clear, durable product domain unlikely to change in the next 6 months.

• You can assign a tech lead to each squad.

• There is engineering management capacity to run multiple backlogs, rituals, and stakeholder relationships.

• A decision has been made about how shared infrastructure, tooling, and platform work will be owned.

Technical readiness

• The codebase has sufficient boundary separation — or a plan to create it — for squads to deploy independently.

• CI/CD pipelines can be configured per squad without major rework.

• Shared services have documented APIs that squads can consume without intimate knowledge of internals.

Process readiness

• A plan exists for cross-squad alignment — guild meetings, architecture reviews, shared retros — from day one.

• Onboarding documentation is sufficient for a new squad member to reach productivity without full-team context.

• Success metrics for each squad have been defined before the split, not after.

What to expect before you see the value of splitting

Most split recommendations ignore the fact that a short-term productivity loss follows every team split. Understanding it in advance allows engineering leaders to plan better.

Yet, it's quite common when leadership splits the team and, a few weeks later, claims the reorganization is a failure due to delivery slowdown.

An initial productivity drop isn't evidence that the split is wrong. It's the expected cost of establishing a new coordination model. All you have to do is give it more time to work.

After structural changes, productivity often suffers at first but then stabilizes and improves. That aligns with Bruce Tuckman's stages of group development:

forming → storming → norming → performing

A company that takes it into account when planning an engineering team restructuring is in a different position from one that discovers it mid-sprint.

The table below shows what you should be ready for.

Squads in a distributed or outstaffed engineering setup

The squad model in software development was originally created for co-located teams, while today, about 38% of developers work remotely, and 42% have a hybrid model.

However, the model can also be absolutely effective in a distributed or outstaffed environment, though it requires additional discipline.

What changes in distributed squads:

• Async-first communication is a structural requirement. Decisions that usually take just a few minutes in an office take several hours in remote squads unless there is a written artifact to anchor them.

• Strong documentation discipline must be introduced and emphasized. While all key information shared must be written down, the survey found that 44% of developers still point to knowledge silos as a top barrier to effective work.

• To keep everyone in sync across time zones, tech leads in remote squads need to have better async communication skills than their co-located peers.

• In a distributed environment, cross-squad coordination is harder because there are no casual talks that members of different squads have in an office. Guilds and chapters need to be scheduled to fill the gap.

• Time zones are an important part of the squad structure. When creating squads, not just expertise and seniority but also overlap in working hours should be taken into account so that members of a squad can be accessible most of the time.

In general, with well-defined ownership boundaries, documented processes, asynchronous communication, and enough time overlap, distributed squads can be even more resilient than conventional team structures.

Wrap-up

Splitting into squads isn't a scaling strategy. It's a response to a specific set of conditions. When your product, your architecture, and your organization are ready for distributed ownership, squads make coordination easier and delivery faster. When they're not ready, the split doesn't solve the original problem. It just hands you a second one.

But knowing when to split is only half of it. You also have to know when to expect results. And the truth is, they never show up on day one. Even under perfect conditions.

New squads need time to settle into their boundaries, find their rhythm, and learn how they make decisions. A little turbulence early on is normal. Give it time, and what you're left with is a structure that scales without fighting you.

Devico helps companies build distributed engineering squads with the seniority, role balance, and technical leadership each unit needs to own delivery from day one.