Squads vs Professional Groups: How You Structure Your Team Shapes What It Builds

There is a structural decision that most product organisations make early and rarely revisit: do you organise people into stable, dedicated squads — a fixed team owning a specific area of the product — or do you organise by discipline, with engineers and product managers re-assigned to features and initiatives each sprint? Both models are defensible. Both fail in predictable ways. The choice reveals something about what a company actually values, even if it was never framed that way.

What a Squad Is and Why It Works

A dedicated squad is a persistent team with a defined domain. The same engineers, the same product manager, the same designer — sprint after sprint, quarter after quarter — working on the same part of the product. The model is associated with Spotify, but it is older than that, and more widely practised than the brand name suggests.

The case for it is straightforward: depth. A squad that has worked on the same codebase for a year knows where the landmines are. They know why a decision was made three sprints ago, what the edge cases look like, and which parts of the architecture cannot be touched without breaking something three layers down. That institutional knowledge is genuinely hard to acquire and genuinely easy to destroy. When you rebuild a team, you lose it.

Speed is the other argument. A squad that knows its domain can move faster not because the individuals are more capable, but because they spend less time rebuilding context. The cognitive overhead of understanding a system before you can change it is real, and it compounds. A team that has already paid that cost works differently from one that is paying it fresh every sprint.

The cognitive overhead of understanding a system before you can change it is real, and it compounds. A team that has already paid that cost works differently from one that is paying it fresh every sprint.

Where Squads Go Wrong

The failure mode of the squad model is not obvious while it is happening. It builds slowly, and it looks, for a long time, like productivity.

A squad that has worked on the same area long enough starts to develop a shared mental model of the product that is increasingly disconnected from how users actually experience it. They know the system too well. They stop noticing the things that a first-time user would find confusing because they have not been a first-time user in two years. The onboarding flow that ships confusing microcopy is not catching anyone's attention internally because everyone on the team already knows what it means.

There is a parallel problem on the engineering side. A codebase that is maintained by the same small group develops idioms and conventions that make sense to the people inside it and are increasingly opaque to anyone outside. Code review, when it happens within the same squad, is not really external scrutiny — it is the team validating its own assumptions. Bugs that an outside pair of eyes would catch in ten minutes survive for weeks because nobody fresh is looking.

The deeper issue is one of alignment. The longer a squad operates independently, the more its decisions optimise for its own domain. The experience of moving between two different parts of a product — the seams, the inconsistencies, the places where a design language breaks down — becomes someone else's problem. Not out of malice. Out of the natural narrowing of attention that comes with sustained focus.

What Professional Groups Offer Instead

The alternative is to organise by discipline. Engineers belong to an engineering group. Product managers belong to a product group. Each sprint — or each initiative — the relevant people are composed into a working team for the duration of that work, then return to their vertical when it is done.

The argument for this model is breadth. A product manager who has worked across four different parts of the product in the last year carries a map of the whole system in their head. They know how the onboarding decisions affect the engagement metrics two weeks later. They know which engineering team made a choice that created a constraint the payments team is now working around. That cross-system understanding is not just useful — it is the kind of thinking that prevents a product from optimising each part while the whole slowly degrades.

Fresh eyes are also a genuine advantage. An engineer encountering a piece of code for the first time is not going to skip the parts that seem odd because they remember why the oddness was introduced. They are going to ask the question, and sometimes the question reveals that the original justification no longer applies. The outsider perspective that feels like a slowdown in week one often pays off in week three.

There is something less tangible but equally real: the cross-pollination of ideas. A product manager who spent the last quarter working on onboarding brings something different to a conversation about monetisation than one who has spent three years in monetisation. Different exposure creates different intuitions. That diversity of perspective is one of the things that keeps a product team from arriving at the same solution to every problem.

The Costs of the Professional Model

None of this is free. The ramp-up cost every time a team is composed for a new initiative is real. There is a period — sometimes brief, sometimes not — where the team is getting oriented before they can move at pace. If you re-assign teams frequently enough, you can find yourself in a state where the organisation is always in that period, never quite reaching the efficiency that depth would produce.

The nuances of a specific product area — the user behaviour that makes a particular flow difficult to change, the technical debt that constrains certain approaches — take time to understand. A team that rotates through will always be somewhat less fluent in those nuances than one that has lived with them. In high-stakes domains, like a financial protocol with real capital at risk, that gap matters. A squad that knows exactly what happens when a pricing function is modified incorrectly is a different kind of team from one that is learning that for the first time.

There is also an accountability question. When everyone is responsible for everything depending on what sprint they are in, it is easier for ownership to become diffuse. The squad model, for all its failure modes, is clear about who is responsible for a given part of the product. The professional model requires more deliberate investment in making accountability legible.

Where I Come Down

I have worked in both structures, across organisations at different stages and in different domains. My preference is for professional groups, and I hold it with genuine conviction — but I want to be specific about why, because the reasoning matters.

The deepest risk in product development is not moving too slowly. It is moving confidently in the wrong direction. Squads are very good at the former; they are structurally vulnerable to the latter. A team that has built deep expertise in a domain is also a team that has built deep assumptions about that domain — and the most dangerous assumptions are the ones nobody has thought to question recently.

Professional groups, by rotating perspective across the product, build in a structural corrective. The person who just came from a different part of the product is going to ask the obvious question. That friction, managed well, is not a tax on efficiency. It is how an organisation stays honest about what it is building and whether users actually want it.

The deepest risk in product development is not moving too slowly. It is moving confidently in the wrong direction.

That said, the honest answer is that neither model is universally correct. A product in an early, exploratory phase — where the goal is learning fast and the cost of being wrong is low — benefits enormously from the fresh perspective that professional groups encourage. A mature, high-stakes system with deep technical complexity — a trading protocol, a payments infrastructure, a medical device — may genuinely need the depth and continuity that only a stable squad can provide.

The more useful question is not which model to choose and defend. It is what your product actually needs right now — and whether the structure you have in place is protecting the kind of thinking that matters most in this moment.