How to set up squads that actually work

Most squad design fails for a simple reason: companies start with the boxes before they are clear on the flow of value. Team Topologies: Organizing Business and Technology Teams for Fast Flow is useful because it starts in the right place. Teams should be designed for fast flow, manageable cognitive load, and clear interaction patterns — not for org-chart neatness or agile theatre.

One of the most common problems I see is not that companies lack squads. It is that they have too many squads designed badly.

They look modern. They sound agile. They have a product manager, a designer and some engineers. There is a ritual calendar. There are stand-ups and planning sessions and perhaps even a tribe model somewhere above them.

And yet the product still feels fragmented.

Experiences do not connect cleanly. Dependencies remain painful. Different squads solve the same problem differently. Customers experience one company; the internal structure produces five inconsistent ones.

That is not a squad problem in the abstract. It is usually a design problem.

Team Topologies gives a much better starting point because it asks a more serious question: what does it take to have no handoffs in the flow of value? The answer is long-lived teams with mixed skills, deep domain context, true end-to-end ownership of value streams, and teams that can make decisions safely without constant external dependencies.

That is the standard.

Not "we have squads". But "our squads are designed so value can flow".

Start with value streams, not functions

The first practical rule is simple: do not create squads around internal convenience.

Create them around value.

Team Topologies is explicit that stream-aligned teams are the backbone. They deliver direct value to customers along a value stream and own the outcomes. Teams should own the entire value stream from understanding user needs through delivery and ongoing operation, rather than passing work from development to testing to deployment under new labels.

In practice, that means a squad should usually align to one of these:

• A meaningful customer journey
• A product area with clear user and business outcomes
• A value stream with coherent end-to-end ownership
• A domain where the team can actually move the outcome without excessive handoffs

It should not usually align to:

• A narrow technical layer on its own
• A small feature bucket with no durable logic
• A temporary project
• A manager's span of control

The test is straightforward: can the squad explain, in one sentence, what customer or business outcome it owns?

If not, the boundary is probably wrong.

"Create squads around value streams, not org-chart convenience."

Use the four team types properly

One reason Team Topologies remains so useful is that it resists the temptation to create endless team categories. The official guidance is blunt: every team fits into one of four types, and creating hybrids only creates confusion.

This matters because many companies still make the same mistake: they call everything a squad, then wonder why the whole model feels vague.

It is far better to be precise about which teams are directly accountable for value, which are reducing load, which are teaching, and which are containing specialist complexity.

Squads fail when they are too siloed to produce one coherent product

This is the practical failure mode I see most often.

A company creates a set of stream-aligned squads and then congratulates itself for decentralisation. But the squads are bounded so tightly, and managed so independently, that nobody is really holding the coherence of the overall experience.

Each squad makes locally sensible decisions. The whole product becomes globally messy.

This happens especially when teams are aligned too narrowly to channels, surfaces or features, rather than to properly designed journeys or domains. It also happens when leaders confuse end-to-end ownership with total isolation.

Team Topologies does not argue for isolation. It argues for explicit interaction modes: collaboration, X-as-a-service, and facilitating. The point is not that teams should never work together. The point is that dependencies become expensive when nobody defines how teams should work together.

That is the critical distinction.

A good squad model does not eliminate cross-team connection. It makes cross-team connection intentional.

If the customer experiences one connected journey, then someone needs to hold that joined-up experience. That usually means having:

• Strong product vision across squads
• Design system and service design ownership
• Architectural guardrails
• Clear product and design leadership above the squad level
• Temporary collaboration between teams when a journey crosses boundaries

Without that connective tissue, squads do not create empowerment. They create product sprawl.

"End-to-end ownership does not mean total isolation."

"A squad model without connective oversight usually creates product sprawl, not empowerment."

Make cognitive load a first-class design constraint

This is one of the most valuable ideas in Team Topologies and one that leaders routinely underestimate.

Overloaded teams make worse decisions.

The official Team Topologies guidance says this directly: overloaded teams make poor decisions and move slowly, and leaders often pile responsibilities onto teams until they break, then blame the team for underperforming when the real problem was cognitive overload. Martin Fowler echoes the same core point: the key benefit of a platform is to reduce the cognitive load on stream-aligned teams.

This has direct implications for squad design. A squad should not be expected to:

• Own too many journeys at once
• Learn every specialist discipline deeply
• Navigate dozens of active dependencies
• Hold complex legacy context, new AI capability, data pipelines, infra concerns and UX coherence all at once without support

Small teams do not magically stay effective just because they are small. They stay effective when their scope is cognitively manageable.

So a good design question is not only "what should this squad own?"

It is also: what should this squad not have to carry?

In the age of AI, each squad should not reinvent the stack

This matters even more now.

That has direct implications for squad design. In the age of AI, a poor squad model looks like this:

• Every squad picks its own tools
• Every squad invents its own prompting patterns
• Every squad builds its own evaluators badly
• Every squad handles safety, observability and governance ad hoc
• Every squad ships "AI features" into a fragmented architecture

McKinsey's ERP-for-AI article makes the same structural point from another angle: AI agents should be embedded directly inside workflows, and ready-made agents can slot into cross-functional "agent squads", but only if the architecture balances flexibility with stability and avoids fragmentation.

So yes, AI should change squad design.

But not by making every squad a sovereign island. It should push companies to be more deliberate about shared capabilities, not less.

"In the age of AI, each squad should not reinvent the stack."

Structure for fast flow, but keep the boundaries flexible

Another mistake I see is treating squad boundaries as permanent truth.

Team Topologies is very clear that the organisational diagram is a snapshot in time and that team relationships will change as goals change and teams discover new things.

The right squad structure for a discovery-heavy phase may not be the right one for a scaling phase. A period of intense cross-team collaboration may be necessary when redesigning a major journey, while a more stable service relationship may make sense once the capability matures.

So the practical rule is:

• Keep the destination stable
• Keep the principles stable
• Keep the boundaries adaptable

If a team structure cannot evolve as the company learns, it will become decorative.

"Structure for fast flow, but keep the boundaries flexible."

How I would set up squads in practice

If I were designing squads using Team Topologies properly, I would follow this sequence.

Structure alone will not save you

One final caution matters.

McKinsey's 2025 operating-model research says two-thirds of organisations redesigned their operating models in the prior two years, but also warns that structure alone will not create value. Leaders need a broader system that connects operating model choices to strategy and outcomes. McKinsey also notes a roughly 30 percent gap between strategy's full potential and what high-performing companies actually deliver, often because of operating-model shortcomings.

That is exactly right.

Squads are not magic. Team Topologies is not magic. A new org chart is not magic.

What matters is whether the team design:

• Reduces unnecessary handoffs
• Lowers cognitive load
• Clarifies ownership
• Supports one coherent customer experience
• Makes value flow faster

That is the test.

If the squads look modern but the product still feels fragmented, the answer is not to add more rituals. It is to redesign the structure more honestly.