The shape of your teams: When structure fights purpose

This is the fourth in a series exploring design capability as a system. The previous posts looked at why scaling design is harder than it should be, why insights don’t land with decision-makers, and what causes coordination exhaustion. This post focuses on the teams themselves. It is a longer one, but it is worth it.

There’s something I’ve seen trip up design leaders repeatedly: treating team structure as the starting point rather than as an outcome of purpose.

When we talk about “the design team,” we often talk as if it’s a single thing. But as a design function scales, you end up with teams that have fundamentally different purposes. A design systems team and an embedded product designer are both “design,” but they exist to do different things, serve different people, and measure success in different ways.

This matters because how a team is shaped affects everything downstream. When structure doesn’t match purpose, friction follows. Work gets stuck and people burn out. Problems that look like performance issues or personality clashes often trace back to a team that’s configured wrong for what it’s being asked to do.

A vocabulary for thinking about team shape

For the previous posts in this series, I’ve been referring to the Viable System Model, but I find that in this area it actually falls down a little. I treats all delivery teams (System 1) as the same., which doesn’t reflect reality.

To think more precisely about this, I find it useful to borrow from Team Topologies, a framework developed by Matthew Skelton and Manuel Pais for software engineering that applies surprisingly well to design.It’s not a rigid framework you must stick to, but can be a useful way for thinking about how your teams work and collaborate.

The framework identifies four fundamental team types:

Stream-aligned teams are the core delivery teams, which align everyone within it to a flow of work like a product or service, with everything they need to deliver value end-to-end.
Platform teams exist to make stream-aligned teams more effective, providing internal services or tools that others consume. If a stream-aligned team develop a new tool to get their job done, but managing it becomes too unwieldy, it may split off into a platform team so that it can be managed like its own product.
Enabling teams help other teams acquire new capabilities or skills, working alongside them temporarily then stepping back once the new capability is embedded.
Complicated-subsystem teams handle areas requiring deep specialist knowledge.

It also defines three different interaction “modes” that articulate how teams work together:

Collaboration is close, ongoing partnership with high communication bandwidth.
X-as-a-service is one team consuming what another provides, with minimal coordination.
Facilitation is one team helping and coaching another another to build capability, with the goal of transferring knowledge.

The core principle is: team type should align to team purpose, and interaction mode should match the relationship between teams. When these are misaligned, friction follows, and that friction often gets blamed on people rather than structure.

If you want to find out more, there are good resources online and at least one book out there.

Design systems teams

I’ll start here because Design systems teams are one of the clearer examples of a platform team in design. As a design system grows, it often reaches the point of needing dedicated support, rather than being done side-of-desk by people who are busy shipping products. This team’s purpose is to provide consistent, ready-to-use components, patterns, and guidelines that other teams can consume without reinventing them. They treat other design teams as customers, and the design system is a service they’re delivering.

When this works well, the interaction mode is X-as-a-service. The system is well-documented, reliable, and easy to adopt. Stream-aligned teams can pull what they need without waiting for the design systems team to be available. The platform team focuses on improving the system, filling gaps, refining components, keeping documentation current, rather than being in constant conversation with every team that uses it.

This doesn’t mean the design systems team works in isolation. There will be moments of collaboration, like when a stream-aligned team has a need the system doesn’t yet serve, or when a new pattern is being developed. But collaboration should be the exception, not the default.

The common misconfiguration is over-collaboration. It often comes from good intentions. The team wants to be helpful, responsive, connected to real user needs. But when every request becomes a conversation, the team becomes a bottleneck. They’re stretched across too many threads to improve the underlying platform. Everyone is busy, but the system itself stagnates.

The fix isn’t to become less responsive, but to invest in self-service so that most needs can be met without direct engagement. Better documentation. Clearer contribution guidelines. Components that cover the common cases well enough that edge cases are genuinely rare. The goal is to make self-service the easy path, so collaboration can be reserved for work that genuinely needs it.

Embedded product design

Embedded product designers are stream-aligned by definition. They sit within a product squad, working alongside product managers and engineers to deliver value within that team’s scope. This is the most common model for product design at scale, with designers distributed across teams rather than pooled in a central function.

The interaction mode is collaboration. Embedded designers are full members of the team, involved in discovery and delivery, building context over time. They’re not parachuted in for specific pieces of work; they’re present for the ongoing flow of decisions, trade-offs, and iterations.

When this works well, designers have what they need to move independently within the team. They understand the problem space deeply. They have relationships with engineers and product managers that allow for fast, informal collaboration. They can make design decisions without waiting for external approval on every detail.

The embedded model can fail in several ways.

Treated as X-as-a-service. The designer is “assigned” to a product team but the relationship is transactional. Briefs come in, screens go out. There’s no shared context, no involvement in discovery, no presence when trade-offs are decided. The designer is technically supporting the team but isn’t part of it. This leads to shallow work: designers producing outputs without understanding the problem, product teams making decisions without design input, and rework when the gaps become visible.

Treated as a complicated-subsystem team. In less mature organisations, design is sometimes seen as a specialist craft that “normal” teams can’t fully understand. Designers get put on a pedestal, treated as keepers of some mysterious expertise, but that reverence comes with isolation. They’re consulted rather than embedded, working with incomplete context, their input arriving too late to shape decisions meaningfully. The pedestal looks like respect, but it’s actually a barrier.

Nominally embedded but lacking autonomy. A designer can be part of the team on paper but constantly blocked by external dependencies: waiting for the design systems team to provide a component, waiting for research to be scheduled, waiting for brand to approve an approach. When this happens, the designer becomes a coordination bottleneck. The stream-aligned team can’t actually move independently because one of its members is tethered to functions outside the squad.

The fix in each case is to ensure embedded designers are genuinely embedded : present in discovery, involved in decisions, equipped with what they need to move. That might mean changing how work is briefed, breaking down the mystique around design as a discipline, or giving designers more direct access to the resources they depend on.

The isolation risk. The other challenge with embedded designers is losing connection to the broader design community. When designers are distributed across many teams, their practice can drift. They don’t learn from other designers facing similar problems. They may lack mentorship or career development pathways that sit outside the product team’s scope.

This isolation isn’t just a practice problem. It affects how designers experience their work. Without connection to a broader community, designers can lose sense of growth, of being part of something larger than their immediate squad. The work becomes smaller, and so does the sense of purpose.

This isn’t a reason to avoid the embedded model, but it is a reason to invest in connective tissue. Communities of practice. Regular critique sessions. Design leadership that spans across squads. Embedded designers need to be part of their product team and part of a design function. Both relationships matter.

Research teams

Research teams don’t map as neatly to a single topology because research can support so many different purposes. Depending on what the organisation needs, a research team might operate as platform, enabling, or embedded within stream-aligned teams. Each configuration is valid, but each requires a different interaction mode and creates different failure patterns when misconfigured.

Research as a platform team.

It’s relatively common for research to operate as a service. Product teams request research, the research team conducts it, findings get delivered. The team might maintain a repository of past research, run regular foundational studies, or offer a menu of research types that can be commissioned.

The main interaction mode is X-as-a-service. This can work well for a relatively mature research function that has visibility across teams, with well-established, repeatable ways of working with stream-aligned teams and there’s value in centralised knowledge management. This can also be helpful if you don’t have enough researchers to embed in all project teams, as this helps prioritise and manage work, rather than becoming overwhelmed.

A common misconfiguration is treating every request as a collaboration. If the research team is deeply embedded in every project they support, they’re not operating as a platform; they’re a shared resource that doesn’t scale. There may be times of higher collaboration around shaping research approaches, but these should be the minority. The opposing risk is disconnect: research delivered purely as a service can miss the context that embedded researchers would absorb naturally.

Research embedded in stream-aligned teams

In this model, researchers sit within product squads as full members of the team. They’re involved in the ongoing flow of work, building context over time. Research is integrated into delivery rather than handed off.

The interaction mode is collaboration: tight, ongoing partnership with designers, product managers, and engineers. This works well when deep context matters and when research needs to be tightly coupled with decision-making.

A common misconfiguration is embedding researchers without giving them the support structures they need : connection to other researchers, access to specialist methods, time for foundational work that doesn’t fit neatly into sprint cycles. Embedded researchers can become isolated, and their practice can drift.

Research as an enabling team

Here, the research team’s purpose is to build research capability across the organisation. They work alongside stream-aligned teams, helping designers and product managers conduct their own research, coaching on methods, supporting recruitment, helping with analysis. The goal is to raise the baseline so teams can handle most research needs themselves.

The interaction mode is facilitation. The research team doesn’t do the research for other teams; they help others get better at it. This works well when the organisation is trying to scale research practice beyond what a centralised team could deliver.

The misconfiguration is never stepping back. The enabling team becomes a permanent dependency rather than building genuine capability. If teams still can’t run research without the research team’s involvement after a reasonable period, the enabling work isn’t landing.

Choosing a configuration

There’s no universally right answer. The choice depends on how mature the organisation’s research practice is, how much specialist depth is needed, and whether the goal is to scale research broadly or concentrate expertise. The important thing is to be intentional: know what configuration you’re operating in, set up the corresponding interaction mode, and watch for the failure patterns that come with that choice.

Service design

Service design often sits awkwardly in organisational structures. Its value is in seeing across silos, connecting journeys, identifying gaps between teams, facilitating alignment around end-to-end experiences. But that cross-cutting perspective doesn’t map neatly to a single team type.

Service design embedded in stream-aligned teams

Service designers can be embedded within stream-aligned teams, particularly when a product or service area is complex enough to need ongoing attention to the bigger picture. In this model, they’re part of the delivery team but bring a wider lens than other disciplines. Complex or large product teams may have multiple workstreams or journeys within them, or impact on other areas of the business. Service design can help stitch this together so all teams can see how their work enables the bigger picture.

The interaction mode here is likely to be collaboration, working alongside product teams day-to-day. This works well when the team’s scope is broad enough that end-to-end thinking is always relevant, not just an occasional input.

A common misconfiguration is treating service design as a stream-aligned delivery resource. A product team doing delivery work with minor feature changes pulls service designers into project work where they function as general-purpose designers who happen to have “service” in their title. When this happens, the cross-cutting perspective that makes service design valuable isn’t used. The service designer is heads-down in a single team’s backlog, and no one is looking across the seams.

This often happens gradually. A service designer gets assigned to support a product team “for this quarter,” and the assignment quietly becomes permanent. Their time fills with delivery work, and the facilitation, alignment, and systems-level thinking get squeezed out.

The fix is to protect the cross-cutting nature of the role. If service designers are embedded, they need time and mandate to look beyond their immediate team. If they’re enabling, they need to avoid becoming a permanent fixture in any one place. The value of service design is in the perspective it brings, and that perspective requires room to operate.

Service design outside of team topologies

Service Design can often sit outside of a stream aligned team because it needs to work across multiple areas of a business at once. It also doesn’t work as an enabling team because it isn’t temporary, or as a platform team because it’s highly collaborative, or as complicated sub-system team. We’re hitting up against where this model starts to fall down a little, because it’s so focussed on delivery.

If we look back at the Viable System Model, we have System 2 which focusses on coordination across delivery teams and preventing conflict. A lot of Service Design work can fall into this area, which falls outside the Team Topologies model, if you applied it rigidly.

The purpose isn’t to own delivery, but to help stream-aligned teams see beyond their slice of the experience. Service designers can facilitate alignment, bring teams together around shared journey maps, and help product squads understand how their work connects to what happens before and after.

The interaction mode is facilitation and collaboration. Service designers work with teams, not for them. They might run workshops, create artefacts that make the whole journey visible, or run creative sessions to help teams think systemically about the whole journey, or even multiple journeys. The goal is to build that cross-cutting awareness into how teams operate, not to centralise it in a single function.

Centres of Excellence and capability building

Centres of Excellence, or whatever your organisation calls them, can operate in different ways depending on their purpose, but are generally focused on improving standards across an organisation, which could be around design or customer experience. Understanding which mode they’re in helps clarify the right interaction model and where things can go wrong.

Centres of Excellence as enabling teams

In this configuration, the Centre of Excellence exists to embed a new capability across the organisation. The mission might be design thinking, accessibility practices, inclusive design, or integrating GenAI into design workflows. The goal is to help teams adopt something they don’t yet do well.

In this case, the interaction mode is facilitation. The Centre of Excellence doesn’t do the work for other teams; it helps them get better at doing it themselves. That might mean running training, coaching teams through early attempts, providing frameworks, or pairing with designers on real projects until the new practice takes hold.

When this works well, capability grows and spreads. Teams that once needed hands-on support start operating independently. The Centre of Excellence can shift focus to the next area that needs attention, or to teams that are further behind.

Centres of Excellence as platform teams

In this configuration, the Centre of Excellence sets and maintains standards and best practice etc. They define templates, create guidelines, and review work to ensure teams are reaching a consistent level of quality. They might dip into project teams at key moments, like reviewing designs before launch, auditing accessibility compliance, or approving work against brand standards.

The interaction mode is closer to X-as-a-service, with elements of collaboration when they’re actively reviewing work. Teams consume the standards and templates, and engage with the Centre of Excellence at defined checkpoints.

This works well when consistency matters and when the expertise required to assess quality is specialist enough that it can’t be fully distributed. The risk is becoming a bottleneck. If every piece of work needs sign-off, the Centre of Excellence can slow down delivery rather than enable it.

The shelf-life question

When a Centre of Excellence is operating as an enabling team, it should be temporary. The purpose is to build capability to the point where the central team is no longer needed, or at least not in its current form. This is what distinguishes enabling teams from platform teams, which provide ongoing services.

But “temporary” is uncomfortable. It feels good to be needed. The team builds expertise, relationships, and identity around their specialism. Stepping back can feel like losing relevance.

When a Centre of Excellence is operating as a standards function, the shelf-life question is different. There may be an ongoing need for quality assurance, particularly in regulated industries or where consistency is critical. But even here, the goal should be to make standards as self-service as possible, and clear enough that teams can apply them without constant review.

For enabling teams, the misconfiguration is never stepping back. The Centre of Excellence becomes permanent, accumulates responsibility, and creates dependency rather than capability. Teams still can’t act without their involvement. The “temporary” initiative is now in its third year with no end in sight.

For standards functions, the misconfiguration can go in 2 opposing ways. They can become a bottleneck, with every decision requiring review. Teams wait for approval rather than moving independently. The Centre of Excellence is so embedded in delivery that it can’t focus on improving the standards themselves. Alternatively, if they don’t engage with the business enough, they can become isolated, without being asked to step in when needed. In this case, they exist but fail to deliver their function.

In both cases, the fix starts with clarity about purpose. What is this team for? What does success look like? If it’s enabling, when will teams be ready to operate independently? If it’s standards, how do we make those standards self-service enough that review is the exception rather than the rule?

Diagnosing your own teams

The goal here isn’t to prescribe the right structure for every situation, it’s to give you a way to see your teams more clearly and spot where misconfigurations might be creating friction.

Some questions to ask:

For each team, what’s the intended purpose, and what’s the reality? A team might be labelled as enabling but operate as a permanent fixture. A design systems team might be structured as a platform but spend all its time in collaboration. The gap between intention and reality is often where problems hide.

Are interaction modes explicit or assumed? When a team works with another, is the relationship clear? Does everyone understand whether this is collaboration, X-as-a-service, or facilitation? Or are there unspoken expectations that create friction when they don’t align?

Where are the bottlenecks? When work gets stuck, where does it get stuck? Often the answer traces back to a misconfigured team: a platform team that’s over-collaborating, an embedded designer who lacks autonomy, a research team stretched too thin.

Are embedded team members genuinely embedded? Designers or researchers who sit in stream-aligned teams should be full members: present in discovery, involved in decisions, building context over time. If they’re treated as a service or kept at arm’s length, the model isn’t working.

The answers won’t always point to an obvious fix. Changing structures is difficult, politically sensitive, and disruptive. People’s identities can be tightly bound up in their team’s purpose. I’m not suggesting you restructure everything on Monday.

But seeing clearly is the first step. You can’t fix a misconfiguration you haven’t named, and any problems that look like performance issues, personality clashes, or just “how things are” turn out to be structural. Structural problems need structural solutions.

Behind every misconfiguration, there are people trying to do good work in a structure that’s fighting them. Getting the shape right isn’t just about efficiency, it’s about creating conditions where people can actually flourish.

Getting the shape right creates the conditions for good work, but even well-configured teams can struggle to demonstrate their value in terms the wider organisation recognises. In the next post, I’ll look at why ‘speaking the language of the business’ is both necessary and insufficient, and what it actually takes to make design’s contribution visible.