Studio 53°

Building a system of systems: What we didn’t see coming

hello@53degrees.studio (Shaun Bent) — Mon, 02 Nov 2026 00:00:00 GMT

I spent nine years at Spotify leading design systems and accessibility. During that time, I learned as much from what failed as from what succeeded. I’m sharing these insights not to critique decisions made at the time, but because I believe they’re valuable and can help others navigate similar challenges. This article is part of a series exploring those lessons.

Part one of this series covered the gap between what we pitched in 2019 and what the model became: an org chart embedded in the architecture, the brand we gave away, and a single-system promise that both failed and succeeded in equally awkward ways.

This article is about what caught us out.

A common thread runs through all the stories here: people. We’d built the model on assumptions about how they’d behave. Local system teams would maintain their systems. They’d contribute components. They’d stay aligned with the programme. They’d protect the brand. Sitting in a room, in Stockholm, in 2019 with all the founding teams, all of that felt reasonable. We even found time to recreate a Renaissance painting.

Stockholm, 2019. The founding teams, a lot of optimism, and our take on The Last Supper.

In practice, teams had other priorities, real priorities, and the model had no answer for what happened when they won.

The hidden load on the core team

When we designed the model, we were focused on what it would enable. Flexibility for local teams. Autonomy. A design system that worked with the grain of the company rather than against it. We spent little time thinking about what running a system of systems would cost the core team.

This showed up in three ways.

Support was the most immediate. Our positioning was that everything was one system, so customers shouldn’t have to think about which team owned which part. They used the system and asked for help when they got stuck, so when someone had a question about a local system, they asked us. We were the public face of the design system. We took the request, figured out which local team owned it, and brokered the handoff. A handful of requests a week sounds like nothing. The interruption cost adds up fast. And local teams, who were running their design systems as a part-time responsibility alongside everything else, couldn’t always respond quickly. We often found ourselves stuck between a customer who needed help and a team that didn’t have time for them.

Maintenance of the shared infrastructure was quieter but more persistent. Putting all the web systems in a single monorepo was a deliberate decision. Local teams got shared infrastructure for free. They could stand up a system without building their own tooling, pipelines, or release processes. The core team owned it all, and local systems inherited the benefit. We hadn’t fully thought through the consequences. The core team also owned the cost. Initially, it wasn’t too bad, but over time the scales tipped, and the team was spending more and more time maintaining the shared infrastructure. When something broke or needed updating, it came to us. If a change touched a local system and that team was busy, we absorbed it. Again, not dramatic on any given day. Cumulatively, it was enough to notice.

Clean-up was the most expensive part, and we never anticipated it. Over time, a number of local systems were quietly abandoned. The teams that created them moved on, interest faded, staffing changed. The systems didn’t disappear. They just stopped being maintained. And because they carried our brand, they became our problem.

Leaving abandoned systems attached to the design system brand wasn’t an option. The reputational risk was too high. So more than once, we carved out roadmap time to decommission these abandoned systems, migrate remaining active users, tear down the infrastructure, and remove the association. Each decommissioning took anywhere from a few weeks to a month of engineering time. Work we hadn’t planned, on an already full roadmap.

Add it all up, and the core team was routinely pulled away from the work we were actually there to do. Every hour spent on unplanned support, maintenance, and clean-up was an hour we weren’t spending moving the system forward and solving real business problems.

Whatever you think a distributed model will cost your core team, it will cost more. Budget for it, or build something simpler.

Local priorities always win

Our model assumed local teams would stay committed to their systems over time. That turned out to be optimistic.

The pattern was consistent, and it repeated across multiple systems. Someone created a local system because they believed in it. A design lead, an engineering manager, a particularly engaged individual. They made the case, secured buy-in, and got the work started. While that person was there and engaged, the system moved.

When they left, or shifted focus, or got pulled onto higher-priority work, it stalled. Slowly, rituals became less regular. Documentation stopped being updated. Components stopped being added. Eventually the system was being used but not maintained. Then it was barely being used either.

If you’ve worked in a large organisation, you might recognise this. Work that depends on individual advocacy is fragile. The moment the advocate stops driving it, it’s at risk. What made it acute here is that local system ownership was structural. These weren’t informal side projects. They were listed on the documentation website, carried our brand, and were presented to the whole company as functional and supported. When maintenance stopped, the gap between what they appeared to be and what they actually were became a problem for the customers relying on them.

I wrote about one example in detail in the federated design systems article. In that case, the drift went deeper than shifting priorities. The local team’s leadership never understood the value of the design system work, so they pulled the team onto other projects. The system work never got the focus it needed because the people setting priorities didn’t believe in it, or understand it enough to protect it.

This is what I refer to as the local priority problem. Local systems lived inside product organisations with their own goals, roadmaps, and leadership. Those leaders hadn’t been part of the conversations that established the model. Local system teams were accountable to their own departments first. When local system work competed with product work for time and attention, product work won. It will always win.

Was that really a problem with the model, or a problem with our version of it? We put enormous effort into building a cohesive family: shared branding, shared documentation, a programme designed to keep everyone rowing in the same direction. That ecosystem depended on every local system staying engaged. The moment one drifted, the consequences were visible. Brand damage. Support gaps. Abandoned systems. If we’d built something looser from the start, with less shared identity and fewer expectations about alignment, would a local system quietly running out of steam have mattered as much?

Probably not. Which suggests the local priority problem had less to do with the nature of local systems and rather more to do with how tightly we’d bound them to the core.

What happened to the programme

We knew from the start that a design system spread across multiple teams in different parts of an organisation would need dedicated coordination. So we built a programme layer above the individual systems: shared governance, shared rituals, shared planning. And we hired a brilliant programme manager to run it.

It worked. For a while, it worked really well. The system of systems was made up of teams from four separate parts of the organisation, but we felt like one entity. We had visibility into each other’s work, processes for surfacing conflicts early, mechanisms to enable greater alignment, and the kind of cross-team relationships that make collaboration feel natural rather than effortful.

Then three things happened in quick succession.

COVID moved everyone to fully remote working overnight. A wave of leadership changes brought new people into the local system teams, people who hadn’t been part of the founding conversations and who took their direction from their own managers. And our amazing programme manager, the connective tissue holding it all together, received a well-deserved promotion into a different role.

We could have absorbed any one of those. Together, they pulled the programme apart.

The remote transition hurt us in a way that was easy to underestimate. We’d built relationships with local system leaders in person, over years. Conversations that started about something else and ended up being about the design system. Small moments of alignment around the coffee machine helped keep everyone pointing in the same direction. None of that survived the move to a screen automatically. With the original group of local leaders, there was enough shared history to hold things together. But that group had mostly moved on, and we were working with new leaders with no relationship or history to fall back on.

When our programme manager moved on, running the programme fell to the design system leadership team. People who already had full-time jobs running teams, managing their reports, and driving their own roadmaps. The programme didn’t get the attention it needed, and we knew it. Rituals gradually fell away. Cross-team planning stopped. Communication between the core and local teams became patchy and, in some cases, stopped entirely.

We repeatedly argued for backfilling the role. Leadership decided not to backfill. The gap lasted nearly two years. I believe this was the single most consequential decision of the whole period. The impact was invisible to the people making the call, and by the time it became obvious, the damage was done.

Not backfilling the role was the wrong call, but we’d also made it far too easy for one departure to do this much damage. So much of the programme lived with one person: the relationships, the rituals, the knowledge of who needed to talk to whom. We’d never built it to survive them leaving. That was our failing.

At the scale we were operating, programme management in a system of systems is what makes the model viable. Take it away, and you’re left with a collection of separate systems that happen to share a name. The coordination overhead doesn’t disappear when you stop funding it. Everyone else absorbs it, less efficiently and at compounding cost.

The coordination overhead doesn’t disappear when you stop funding it.

When a local system succeeds

Not every local system story ended in abandonment. The most successful local system in the programme’s history was still going strong when I left. It served the advertising platform. Smith Schwartz and Tyce Clee, who led design and engineering, discussed the work in detail on the On Theme podcast. It’s worth a listen. Here’s what set it apart, and what it delivered:

Strong design leadership, with buy-in that went all the way to the top of the business unit
An engineering manager who had come from the core design system team and understood the model deeply
A full product redesign delivered over the course of a year
A 20% reduction in the time it took to complete a campaign booking, measured with support from data science
Dark mode shipped quickly, on the back of proper investment in tokens

This is what a local system was supposed to be. Close to the problem, moving fast, and delivering outcomes the core team could never reach on its own. When people ask me whether the model worked, I reach for this example.

It also exposed a major gap in the model.

A team delivering at that level builds credibility and confidence, leading to bigger questions. Their products had needs the core system served poorly: denser layouts, tighter spacing, patterns and components that business tools needed. So they built for those needs, and what they ended up with was a complete package, a system genuinely well suited to business experiences.

People who work on design systems instinctively want to make good work reusable. That instinct is where Encore began. So, after building something that worked, the team started thinking beyond their own products. An idea began to form, informally and at a high level: perhaps the core system and core team should focus on consumer experiences, while this ads local system team focused on business experiences.

The trouble was our model gave that instinct and their success nowhere to go. Some of the individual pieces could travel, but the whole, proven, system-level way of doing business experiences had no path upward. So the only way the team could see to spread their success was to widen the boundary around it.

Our model gave that instinct and their success nowhere to go.

We had no answer to this, because our model had never contemplated the question. It described how local systems were created, what they could build, and how they related to the core. It said nothing about what should happen when a local system got so good at serving its corner of the business that owning that corner outright started to look reasonable.

Looking back, a team with ambition wasn’t the problem. We designed our governance structures around the things we feared: fragmentation, drift, systems going quiet. We spent almost no time designing for the outcome we should have wanted most: a local system doing so well that it starts asking for more.

The promotion pipeline that never was

Which brings us to the idea we were most excited about in 2019, and the one that let us down hardest.

Component promotion was the mechanism that made the whole model make sense. Local systems sit close to the problem space. They move fast. They build things the core system hasn’t got to yet. When a local team builds something with wider value, it gets promoted into the core, so everyone can benefit. Local systems become the design system’s research and development arm. Good ideas travel up and into the core system.

In six years, this happened fewer than a handful of times.

The reason was pretty straightforward. A local system component solves a specific problem for a specific audience. The core system serves everyone. To make that jump, a component has to be generalised, documented to core standards, aligned across design and code, reviewed for accessibility and localisation, and shipped through a release process that touches every team using the system. That’s weeks of work, and it competes with everything else on our roadmap.

Component promotion lost almost every time. It was easy to agree with and hard to justify what it cost.

So useful components stayed where they were, got used outside the audience they were built for, and created the dependency problems I described in part one. The pipeline we’d imagined was an aspiration dressed up as a process.

Component promotion lost almost every time. It was easy to agree with and hard to justify what it cost.

This is the thing I’d most want to fix, and it’s where part three of this series starts.

None of this was anyone’s fault

It’s worth specifically stating that every team in this article was doing their job well.

The local teams that let their systems drift had product roadmaps to deliver. The leaders who deprioritised design system work were accountable to their own organisations. The team whose ambitions outgrew their remit had earned the right to think bigger. The people who chose not to backfill a programme manager were making a resourcing decision with the information they had. And we’d built a programme that depended on one person without realising it.

That’s the lesson I’d give to anyone building a system of systems today. Design your system around how people behave inside your organisation, with the incentives they actually have. Not around how you’d like them to behave once they’ve read your documentation.

Part three is about what I’d change and do differently today.

Building a system of systems: What we didn’t know in 2019

hello@53degrees.studio (Shaun Bent) — Mon, 12 Oct 2026 00:00:00 GMT

In November 2019, I stood on stage at Design Systems London and introduced Encore, Spotify’s new design system, and the approach we were taking to build it. The recording has been watched nearly 35,000 times. The article we published alongside it became the most-read post on the Spotify Design blog before the blog was shut down. People still ask me questions about it today.

Our approach was a system of systems. Instead of the typical monolithic design system owned by a single central team, we proposed a family of design systems, owned by different teams across the organisation, all operating under a shared framework. It was a direct response to the landscape we were building for, and the cultural realities of how the company worked at the time.

Six years on, I want to tell you what actually happened.

The model did its job. By any measure, the system we built is the most successful design system the company has ever had. It gained traction quickly, outlasted every previous attempt, replaced 22 competing systems, and became established as Spotify’s design system. But a thing can succeed and still be full of decisions you’d do differently, and there’s a lot I wish I’d known in 2019.

This is the first of three articles sharing my experiences building a system of systems. Here I want to cover what the model actually became in practice, where the original vision held, and where it gave way.

What a system of systems is

A quick definition first, because there’s still surprisingly little written about this in a design systems context. Nathan Curtis was exploring this territory around the same time, most notably in Design System Tiers and Consolidating Design Systems, and has since published a collection of writing on the subject. If you want the theory, start there.

In simple terms: multiple design systems coexisting within a shared framework. Different teams own different systems. Each system has its own scope and audience, and each builds on a shared foundation.

Our implementation had three layers:

Foundation was the core of everything. Tokens, colour, typography, spacing: the shared building blocks every product needed regardless of platform. Thin by design, and it went everywhere.
Core systems sat on top. Platform-specific systems for web and native mobile, owned centrally by the design system team, built with the rigour you’d expect from a traditional design system.
Local systems were the outermost layer. A local system serves a specific team, context, or domain. It builds on the core systems and extends them with components and patterns too specific to belong anywhere else. One for consumer mobile, another for creator tools, and so on.

A shared framework tied it together. Tooling, infrastructure, a single documentation website, shared rituals, and a programme of work to keep everything aligned.

Inheritance is what held it all together. Each layer inherited from the layer below it. A local system carried the components from the core systems, and those components carried the tokens and guidelines from the foundation. Pick a local system, and you get everything underneath it, whether you know it or not.

This made the pitch to our customers simple. You only need to know about one system. Find the one closest to your use case, use it, and we’ll take care of everything underneath.

A good pitch; it turns out achieving it would be a lot harder than we anticipated.

The org chart got into the architecture

You can’t talk about building systems in tech without dragging Conway’s Law into it at some point, so let’s get it over with. Conway’s Law is the observation that organisations create systems which mirror their own communication structures. We all know this; we all nod along and agree this is bad, yet it always finds its way in.

Our system mirrored the org chart beautifully.

The local systems mapped directly onto it. Each one was owned by the department or product area it served, and scoped to it. Components built for one product belonged to that product. Teams in adjacent areas had no clean route to reach them.

Technically, this was by design. We wanted the people closest to the problem to own local systems. We didn’t plan for the walls that came with this.

The same pattern showed up inside the core systems. The foundation and the web component library were separate packages and separate Figma libraries, owned by separate teams. From an organisational ownership perspective, that made sense. From a customer’s perspective, it meant installing two packages and connecting to two Figma libraries just to build a web page. The split existed because of how we were organised, and for no other reason.

The internal architecture can reflect team ownership. The experience of using the system should hide it. We didn’t get that quite right; it’s one of the first things I’d fix.

The brand we gave away

Building a strong internal brand for the design system was deliberate. Before Encore, we had 22 competing systems, each with its own name and identity. Getting people to rally around a single name took real effort, and once it was established, the name carried weight.

Local systems were part of our brand-building strategy. Each one carried the core system’s name. Our goal was to reinforce the idea of family, make everything feel like part of the system, and reduce the cognitive load on customers who just wanted to know which system to use.

It worked. One name became the thing people associated with design systems across the company. It also created a problem we hadn’t thought about.

When you hand your brand to another team, you hand over control of what it means.

One of our local systems took a non-traditional approach, which I covered in detail in the federated design systems article. It served the company’s biggest and most rapidly iterated platform, and its architecture made reuse hard. Something as simple as reusing a component from one view to the next wasn’t easy. Asking that team to adopt the design system as it stood in 2019 would have turned an app architecture problem into a design system problem, and that was never ours to solve.

So rather than providing reusable components, they encouraged developers to duplicate code under a specific naming convention. The intent was traceability and speed, backed by a real belief in the team that more reuse didn’t automatically mean better engineering outcomes. The challenge was that customers arrived expecting what a design system normally gives them: configurable components that match the designs they were handed, and found the opposite.

The same question appeared in the support channel almost daily. “I’ve got this component in my design, how do I implement it?” The answer was always the same: “You build it yourself”. And when people talked about that frustration, they talked about the design system.

We could see it in the data. Our quarterly satisfaction surveys across design and engineering showed most of Encore sat somewhere in the 70 to 80% range. The problematic local system hovered around 30 to 40%, survey after survey. It was consistently, measurably the worst experience anyone had with something carrying our name.

The nuance between the core system and the local system was lost, exactly as we’d intended when we designed the naming strategy.

We’d made everything feel like one thing, so when one part of it failed, the whole brand took the hit.

It got bad enough that leadership asked: should we rebrand entirely? Start again with a new name and put some distance between ourselves and the damage. The core team had done nothing to cause it, but that was beside the point. We ultimately decided against rebranding, figuring repairing the damage was less work than starting over.

Looking back, we should have been clear from the very start that what this specific local system team built was a naming convention for a hard architectural problem. A sensible one for its context, but it was never designed to meet the expectations our name set for it. When I spoke to Encore’s former Design System Lead about this, he summed it up:

A perfectly designed system cannot resolve imperfectly designed architecture.

Rob Simpson, former Design System Lead for Encore

Your brand is an asset, and you’re accountable for it. If other teams want to use your name, you need real governance over what that name gets attached to. Handing it out freely might buy you a sense of family today but risks becoming a liability tomorrow.

So, a question for your own system: if another team put your design system’s name on something you had no control over, what could you actually do about it?

The promise of a single system

Our model’s central pitch was that customers should only ever have to think about one thing. All the complexity underneath, the different systems and teams and layers, was ours to manage.

We put real effort into delivering on it. We redesigned the documentation website several times to reduce friction. We removed an upfront landing page where customers had to pick a system before they could see any content, moving the system picker inline to get people into content faster. Eventually we flattened the whole site to expose less of the structure underneath.

We never truly got there. At some point, customers had to understand the internal architecture to navigate the system correctly. Which system do I use for this project? Is this component on mobile as well as web? Why are these two things in different packages? The questions kept coming, because the system kept reflecting our organisational complexity at the people trying to use it.

When it worked too well

There’s an irony buried in our failure to truly resolve the promise of a single system. In the places where we did succeed in hiding the complexity, where customers genuinely experienced everything as a single system, we created a different problem.

When everything feels like one system, component ownership becomes invisible. Customers browse the documentation, find a component that solves their problem, and use it, without noticing or caring which system it came from.

The most extreme example of this was a local system’s player component. It was built for a high-density, web-based advertising management tool, and it ended up inside the native consumer mobile app. A web component, designed and maintained for one very specific context, was embedded in the main Spotify app, sitting alongside the native player, creating two distinct player experiences inside the same product.

From the customer’s point of view, this made complete sense. They were moving quickly, found something that worked, and they used it. From the local team’s point of view, they’d built something for a small, known audience and suddenly found themselves supporting a much larger one they’d never planned for.

The consequences go beyond support load. A local system is deliberately built with less rigour than the core, because the assumption is that its components will only ever be used in contexts the local team controls. Once those components escape that boundary, that situation changes. Does the team now need a more careful release process? Deeper accessibility and localisation reviews? All the overhead the local system model was designed to avoid.

The better we got at making everything feel like one system, the more we eroded the boundaries that made local systems viable in the first place.

What stayed true

For all of that, our original goal held.

The model achieved what nothing before it had managed at the company. It created a stable, shared foundation across dozens of platforms, thousands of engineers, and hundreds of designers. It stopped the proliferation of competing systems. It gave the organisation a real source of truth, and it’s still there.

The local systems, for all the problems in this first article, gave teams genuine autonomy without forcing them to choose between moving fast and using the design system. Every previous attempt had forced a choice, and every previous attempt had failed.

A system of systems might be the right approach for organisations operating at this scale. The specific shape we gave it in 2019 needed to change and evolve, and understanding why means understanding what we underestimated along the way.

That’s what part two is about.

Read part two: What we didn’t see coming.

Design handoff belongs in the bin

hello@53degrees.studio (Shaun Bent) — Thu, 23 Apr 2026 00:00:00 GMT

We spend a lot of energy trying to improve design handoff. Better documentation, tighter specs, more thorough annotations. And yes, if you are going to hand off, doing it well is better than doing it badly. But what if we aimed to remove handoffs entirely?

Design handoff is a remnant of waterfall workflows. It made sense when design and engineering operated as sequential phases, with designers working in isolation until they were done, then throwing their work over a wall for engineers to implement. Most of us have moved beyond waterfall workflows, yet the handoff has somehow survived. It has been accepted as the norm, the way we work, when it should not have been.

Handoff exists because we continue to treat design and engineering as distinct problems to be solved separately. The moment you start treating them as a single product problem to be solved together, the handoff no longer makes sense.

The conditions for change have never been better. AI tools are putting designers closer to code than ever before. Prototyping in code, generating working components, and iterating in the same medium that engineering builds in. The gap is closing naturally. The question is whether teams are being intentional about it or letting it happen by accident.

Closing the gap

So what does being deliberate about it actually look like? In practice, it requires changing how teams are structured, how work flows through them, and how disciplines relate to each other day to day. For many teams and organisations, this can be a significant cultural shift.

A good place to start is rethinking the assumption that design must be largely complete before engineering gets involved. Two disciplines working in sequence is not a law of nature; it is a habit. And like most habits, it can be broken with will and the right structures in place.

What if we involved engineering right from the start and throughout the design process? Once we have a clear outline of what we’re building, whether it’s a new component, a feature, or an update to something existing, we can start working in parallel. Whilst design focuses on visual and interaction design, and user experience, engineering can begin prototyping, exploring the more technically challenging aspects, and testing feasibility. Both disciplines, working simultaneously, sharing back and forth, continuously.

Juli Sombat, Encore’s Design Lead, created this diagram to visualise exactly how that parallel approach plays out across the length of a project. It shows something that is difficult to put into words: as the work progresses from discovery to delivery, engineering gradually becomes more involved whilst design effort naturally decreases. The lead shifts, but both disciplines remain present throughout.

This parallel approach can surface things early that would otherwise be discovered much later. Sometimes, engineering discovers that something they initially believed would be technically challenging is straightforward, or that the platform provides it out of the box. Sometimes they uncover that something is not feasible, and the design needs to change. The crucial difference is that this discovery happens alongside design, not after a leader has signed off on something that cannot be built.

Design doesn’t have a monopoly on good ideas.

Early engineering input isn’t just about catching technical problems before they become expensive. Engineers bring a different perspective to how something could work, and some of the best ideas come from that collision of disciplines.

There is a practical bonus here: prototypes and early engineering thinking sometimes feed directly into the final implementation. Work done in the exploration phase does not have to be thrown away.

When this model is working well, each phase has a lead discipline, but both are present throughout. The transition between discovery and delivery is a gradual shift in which discipline leads, not a cliff-edge where design stops and engineering starts. By the time engineering is in the delivery driving seat, they have been involved from the start, and they have as much knowledge as design; there is nothing to hand over. ✨

The adjustment period is real

Ok, I made that sound straightforward, like flipping a switch. I’ve led teams through this cultural shift, and I won’t pretend it’s easy. But when it clicks, you can’t imagine working any other way.

In the beginning, it can feel really awkward. Early engineering input can initially feel stifling to creativity. An engineer pointing out that something is technically challenging or goes against a platform convention can feel uncomfortable for a designer who is not used to this kind of feedback so early in the process. It takes time to reframe it as saving a designer time rather than constraining their work. Why invest significant effort in a design direction that’s not feasible?

As more designers begin to use AI tools to prototype and work in code, they are already operating in the world of engineering to some degree. The shared context makes early technical feedback feel less like a challenge to the design and more like a natural part of the conversation.

In my experience, this only works when there is mutual respect and understanding between disciplines. When engineering genuinely understands and respects what design is trying to achieve, and the processes designers follow. When design understands that there are technical tradeoffs which need to be balanced, early collaboration becomes a strength rather than a source of friction.

A culture where engineers dismiss design nuance, or close down ideas prematurely because they seem time-consuming to implement, makes early collaboration counterproductive. Both disciplines need to develop an understanding of each other’s worlds. A shared design vision can help considerably, something everyone is working towards together, so that engineering input serves the same goal rather than pulling against it.

When leaders get in the way

Depending on your organisation, your team’s maturity, and the attitudes of the leaders around you, this way of working can take years to feel natural rather than forced. We are talking about changing ingrained behaviours, and your organisational environment will shape how quickly that happens.

I’ve worked with design leaders who place tremendous value on keeping design a centralised, protected function, separate from engineering. Almost as if keeping design isolated as its own independent function is a measure of success. At the same time, engineering leaders want their engineers to focus entirely on code output rather than spending time working alongside designers. Both of these mindsets create walls between disciplines that slow teams down and introduce waste that better collaboration would prevent.

Good leaders create the conditions and set expectations that enable cross-disciplinary collaboration. Shared boards where design work sits alongside engineering tickets. Open design critiques where engineers are not just welcome but expected to attend, present, and give feedback. Processes that require both disciplines to be involved in the problem from the start. And when someone is struggling in isolation, a gentle nudge: Have you spoken to an engineer about this? A culture shift isn’t something you mandate. It happens gradually, through practice, until one day teams cannot remember working any other way.

Small steps towards a better world

Not every team is ready for this kind of change. The organisational environment, the maturity of both disciplines, and leadership appetite all affect what is possible right now. That is fine. Wholesale transformation isn’t the only option, and suggesting it is can make teams feel like they have failed when the reality is that this takes time.

Small steps can compound. Invite an engineer to your next design critique. Ask a designer to sit in on a technical feasibility conversation. Put one piece of design work on the same board as the engineering tickets. Each of these things is modest on its own. Across a year, they start to shift how a team thinks about the relationship between design and engineering.

Pay attention to where the gap is already closing in your team. Designers who prototype in code or use AI tools to generate components are already working closer to engineering than they might realise. That’s a foundation worth building on.

What is one step you can take today to make the handoff irrelevant?

Header photo by SLNC on Unsplash

Design systems are platform problems, not feature problems

hello@53degrees.studio (Shaun Bent) — Mon, 23 Feb 2026 00:00:00 GMT

This article is part of a series exploring lessons from my time leading design systems and accessibility at Spotify over nearly 9 years.

When I published my piece on leading through a design system reorg, Dave House highlighted this section:

Design systems are platform problems, not feature problems. By placing platform work within a feature organisation, you’re fundamentally misaligning incentives and ways of working. Feature teams optimise for speed and shipping. Platform teams optimise for consistency, scalability, and long-term health. Those aren’t compatible, and you can’t just will them into compatibility by reorganising.

In my reply to Dave, I pointed to differences in planning cycles as a concrete example of how that tension shows up in practice. This article expands on that.

Different functions, different rhythms

In his article, Ship Faster by Building Design Systems Slower, Josh Clark argues that different parts of a product organisation should deliberately operate at different speeds. Feature teams move fast at the outer layer, experimenting, innovating and shipping. Design systems sit at the centre, moving slowly and deliberately. As Josh explains:

Successful design systems move more slowly than the products they support. That’s a feature, not a bug.

Josh Clark

The relationship between the two layers is what makes it work. Feature teams innovate, and the design system curates and standardises proven patterns. In talking about characteristics of these different layers, Stewart Brand explains:

The fast parts learn, the slow parts remember.

Stewart Brand

One way organisations optimise for these different rhythms is through their planning processes.

The planning cycle problem

Feature organisations design their planning processes to drive user value and deliver on high-impact, high-visibility company initiatives. That makes complete sense for them. When you place a design system team inside those same processes, the incentives shift immediately.

When the team from my previous article moved into the feature organisation, that department explicitly required each team to be actively contributing to at least one high-priority company initiative. For feature teams, that’s a natural fit. For the design system team, it meant immediately deprioritising the broad, horizontal work they’d been doing and picking up short-term, feature-specific work instead. From macro to micro, overnight.

In practice, that means shifting from platform thinking, “build component X because it serves multiple teams across multiple use cases”, to bespoke UI development, “build this specific thing because a specific team needs it”. That’s the transition into what I’d call a “UI feature factory”. The team is producing output, but they’ve stopped solving design system problems.

When the planning cycle consistently pushes your design system team from macro thinking to micro thinking, that misalignment compounds until the system stops functioning as a platform.

I saw this scenario play out three times at Spotify. Each time a design system team was placed within the same feature organisation, the same shift occurred, and the same outcome followed. The first time, I caught it early enough to course-correct. We moved the team into a platform organisation, and Encore eventually grew from that. The second time, the consequences were severe enough that the team was disbanded entirely. The third time is the story I’ve been telling across these two articles.

These teams didn’t fail because of the people. The people were great. The environment and the structure made the work impossible.

Why platform organisations align better

A platform organisation has a fundamentally different mandate. Its customers are the teams building products, and its success is measured by how well it enables those teams rather than by the features it ships directly to end users.

That mandate fits naturally with what a design system needs to do. Josh describes design systems as “critical front-end infrastructure,” and infrastructure needs the right conditions to operate well. A platform organisation provides those conditions, letting the design system move at its natural pace, thinking at the macro level, and serving the whole organisation rather than a single part of it.

In my experience, being inside a platform organisation gave us more freedom to largely set our own planning agenda and decide how we interacted with company priorities, without being beholden to them.

It’s not without its challenges

Platform organisations are not a perfect answer. Engineering-heavy organisations don’t always have natural context for design systems work, and you can find yourself repeatedly explaining the value and complexity to leadership.

The separation from product teams requires active relationship management. Without deliberately maintaining strong relationships with your customers, that distance becomes a liability, and you can end up building things nobody needs because you’ve lost sight of what product teams are focused on building.

These are real challenges, but you can work on them. The misalignment that comes from sitting in a feature organisation is structural and much harder to work around.

Can feature organisations work?

Could I see a design system team operating successfully within a feature organisation? Absolutely, but it requires deliberate structural protection.

The team needs to be shielded from the delivery pressure that defines life in feature organisations. That means holding them to different planning expectations, not requiring them to attach to high-priority company initiatives in the same way feature teams are. It means protecting their ability to think at the macro level, to plan for broad impact across the organisation rather than solving one team’s immediate problem.

In my experience, this can’t happen without leaders who genuinely understand how design system teams need to operate. Without that understanding, the path of least resistance is to treat them like any other team in the department, and that’s where the problems start.

Without those conditions explicitly in place, the gravitational pull of the feature organisation takes over. The planning processes, the metrics, and the incentives all point in the same direction. And over time, the design system team follows.

Positioning is a strategic decision

Where your design system team sits deserves deliberate thought, not an arbitrary decision based on available headcount.

I believe design systems are infrastructure. They exist to serve multiple teams across multiple use cases, to solve common problems once rather than many times, and to raise the quality and consistency of multiple experiences. That work requires a planning horizon, a mandate and an environment that feature organisations are generally not set up to provide.

If you’re making this decision, or if it’s already been made for you, it’s worth being honest about what the structure you’re operating in is asking your team to optimise for. Because eventually, the structure wins.

When the Decision Is Made, and You Can't Change It

hello@53degrees.studio (Shaun Bent) — Mon, 16 Feb 2026 00:00:00 GMT

It’s a cold Monday morning in Stockholm at the start of December, a few years ago. I wake up, check my phone, and see a text from a fellow EM: “Oh my god, check your email.” I know exactly what it means without looking. I’ve been here before.

I opened my email, and there it is. Layoffs are happening today. “Your role is not affected, but people on your team are.”

My heart sinks. I feel sick. Today is going to suck.

I joined a meeting with my manager and their lead to discuss the layoffs and what would happen throughout the day. I’ve been through this before, I know what to expect. Oh, and you’re getting a new manager. Oh, and just one more thing. The team you lead, the team you’ve built from the ground up over the last few years. It’s being broken up and moved to another department. They’re taking one engineer, the codebase, and the squad name, leaving you with two engineers, no code, no product, and no idea what you’re going to work on.

The rest of that day is a blur. There are conversations with the engineers, discussions with other managers, and conversations with my own management about what happens next. I don’t have answers to most of the questions. I don’t know what my role is anymore. I don’t know what these two engineers are supposed to work on. I don’t know how long this will last. I’m exhausted and emotionally drained.

What I do know is that this decision is wrong. Everyone with any real context of this problem space, both in my department and in the department taking ownership, knows it doesn’t make sense. But in that moment, I also know something else: I’m going to have to lead through this.

What we’re actually talking about

This article is about what happens next. About how you lead when you’re powerless. How you navigate a structural decision that you fundamentally disagree with, that you can’t prevent, and that you now have to make work anyway?

These kinds of decisions happen in organisations all the time. Sometimes they barely touch your day-to-day work. Sometimes they require a shift in approach. And sometimes, like this one, they’re seismic. They change your team, your work, and impact people personally.

When you’re in that third category, your response matters. Not just for the immediate fallout, but for what comes after. For your team, for the people now scattered across the organisation, and for your own credibility as a leader.

In this case, the structural decision affected a design system team. I’d spent years building and leading this team, creating a unified design system that hundreds of designers and developers across the organisation depended on. The decision was to break up that team and move the system to a different department. One engineer, the codebase, and the squad name would go to a feature-focused department. There would be no dedicated designer on the new team. A design system without a designer. That’s what we were dealing with.

This is the story of how I navigated this and what I learned.

Trying to understand

My first instinct was to stop it. The decision was so obviously wrong, it had to be a mistake. Maybe there was something missing from the thinking. Some context that, if explained properly, would make leadership see that this was wrong.

So I started asking questions. Why are we doing this? What problem are we trying to solve? Was there something we’d missed? The reasons came back, each sounding plausible on the surface.

“You are too slow.” A common reason I heard was that the team wasn’t moving fast enough. By placing the team in a different organisational structure, we’d speed things up.

But the data showed the opposite. We were delivering faster than ever. We had the metrics to prove it.

“You’re too focused on other team problems.” I was told this move was happening because we were spending too much time on other teams’ priorities, so the new department was taking ownership.

We knew exactly who our customers were. 90% of them worked on a single product. We built our entire roadmap around that 90%. As seasoned practitioners, we knew that with minimal consideration, we could support the remaining 10%. A quick check would confirm our components were suited to their use cases, too.

“This aligns with our current org structure.” This one was about efficiency. The thinking was that if the primary consumer took ownership of the design system, things would be more aligned, and we could move faster.

What this ignores: design systems are platform problems, not feature problems. By placing platform work within a feature organisation, you’re fundamentally misaligning incentives and ways of working. Feature teams optimise for speed and shipping. Platform teams optimise for consistency, scalability, and long-term health. Those aren’t compatible, and you can’t just will them into compatibility by reorganising.

I could go on. There were more reasons, and they all followed the same pattern.

These weren’t the real reasons. They were the reasons people were comfortable stating publicly. The real reason was simpler and more frustrating. I wouldn’t uncover it until much later, after I’d pieced things together over weeks and months.

After the disbelief faded

When it became evident I couldn’t reverse this decision, and after the disbelief, frustration, and anger subsided, I had to make this work.

I had to think clearly about what mattered most. What were my priorities?

The People. Always my first priority. We’d just uprooted a bunch of people. They needed stability, clarity, and support.
The Product. The design system itself. I’d spent years building and shaping this system; I knew it was working; I didn’t want to see my efforts go to waste. Continuity mattered. Customers couldn’t afford for the system to falter - and the primary customer was the very department now taking ownership, whether they fully grasped that dependency or not.
The Vision. The direction we’d been building towards was sound. The data showed this. My experience as a design system practitioner told me this was the right solution. The vision needed to be preserved, even if the team was scattered.

These priorities shaped how I approached what came next.

How I navigated it

1. Disagree and commit (but don’t abandon your belief)

Once I’d accepted that the decision wasn’t changing, I made a choice. I was going to disagree and commit. But I want to be really clear about what that means, because there’s often a misunderstanding here.

Disagree and commit doesn’t mean you abandon your position and suddenly stop believing the decision is wrong. It doesn’t mean you pretend everything is okay or that you’ve changed your mind. It means you accept that the decision has been made, you’re going to make it work, and you’re going to stop trying to reverse it or prove the decision-makers wrong.

For me, that meant stopping the conversations about undoing this. No more case-building. No more “if you just understood the data” arguments. That era was over. Now I needed to focus my energy on something I actually had control over: how I responded and how I helped the people affected by this decision.

This distinction freed me from having to convince anyone I’d changed my mind. I didn’t have to validate the decision publicly. I didn’t have to pretend I thought it was brilliant. I just had to stop actively resisting it and start actively making it work.

2. Be a positive partner

The alternative is becoming the person who’s bitter about the decision. The person who resists, who’s challenging to work with, who makes it clear they think the whole thing is a mistake. And yes, in this case, it was clearly a mistake. But that approach gets you nowhere. It gets you labelled as someone who doesn’t play well with others. Someone who’s a blocker rather than a partner. Any resistance risks giving them a scapegoat: “We tried to make this work, but they wouldn’t get on board.”

I took a different approach. I was going to be the most helpful, most positive partner in this transition, someone they could rely on and learn from. Not because I’d suddenly decided the move was good, but because being difficult would only damage the people, the system, and the vision I was trying to protect.

This is what I think of as “kill them with kindness.” You show up, you offer support, you make yourself available, you share what you know. You demonstrate commitment to making this work. And in doing that, you protect yourself and your team from being seen as blockers or problems.

3. Ensure continuity

Newly formed teams take time to get up to speed. The question was how to maintain continuity while that happened.

The new team was taking over ownership of an existing, adopted design system, and its customers needed continuity. At the same time, the two engineers who stayed with me needed focus and purpose as we figured out what came next.

I proposed an embed. The two engineers would temporarily rejoin in the team they’d just been separated from to support the transition and shorten the new team’s ramp-up time. They’d share knowledge, provide continuity for customers, and help the new team get up to speed on how the system worked and what we’d been building towards.

This addressed all three priorities at once:

People: The two engineers had stability and a clear focus, even if just temporarily. They weren’t floating in limbo. They were part of something concrete, helping their former team get established.
Product: The design system had continuity. Customers didn’t lose access to expertise or institutional knowledge overnight. The transition was managed.
Vision: By embedding experienced people who understood what we’d been building, we had a chance to influence how the system evolved in its new home. To advocate for the standards and direction we’d established.

We ran the embed for six months. During that time, we transferred knowledge. The design system continued to serve customers. Continuity was maintained. When the embed ended, the two engineers came back to work with me on what came next.

4. Build trust with the new manager

The team got a new leader I didn’t know. Someone with little context and experience in the design system problem space. Someone who was inheriting a team, a codebase, and a set of responsibilities that were entirely new for them. It was also something they didn’t ask for.

Building trust with them quickly became crucial for the embed phase and the system’s long-term success. If we didn’t have a good relationship, if they didn’t trust my judgment or value my input, then everything became harder.

I deliberately worked to build that relationship. I made myself available, answered questions, and shared context without making them feel stupid for not knowing things. I acknowledged they were stepping into something complex and respected the challenge they were taking on. But I also listened. I asked them about their vision for the team, what they wanted to build, their priorities, and where they thought things needed to go. I didn’t assume they’d make the same decisions I would have.

What I learned

Look for the wins

Despite the move being fundamentally wrong, some things worked out. They show that even in bad situations, good things can happen.

The new engineering manager who’d taken over the team was impressive. They came in with little context or experience in design systems, but they threw themselves into learning. They asked good questions. They cared deeply about understanding the problem space and the team. They were genuinely committed to making this work. As they became more familiar with the problem space, they became true advocates for design system thinking and the vision we’d been building towards. Over time, a genuine working relationship formed, built on mutual respect.

The senior engineer who moved with the system to the new department really stepped up. They started operating more like a staff engineer, becoming the de facto technical lead, not because they were promoted, but because they understood the system and the vision we’d built. They actively worked to maintain that vision and the standards we’d established. When the team lacked design expertise, this engineer stepped in to solve design problems. It was impressive to watch.

As that senior engineer stepped up, it created space for another engineer to grow into. They began working as a senior engineer, taking on more responsibilities, leading projects, and participating in architectural discussions. This allowed them to build the evidence they needed to be officially promoted to senior engineer.

None of these wins was the point of the move, nor did they address the problems it was supposed to solve. They mattered anyway. They showed me that no decision is entirely bad. People can still do good work and grow, even in a fundamentally misaligned setup.

The leadership transition

One thing I didn’t anticipate about the embed was how much it would change my role and how challenging that would be.

I was no longer leading the team. I became the advisor in the background, watching from the sidelines while someone else took it forward. I had the knowledge and context to shape the future, but I was no longer in the driver’s seat. I couldn’t make the decisions anymore. I could only inform them, share my perspective, and demonstrate the experience I’d built up over the years.

This was my first real lesson in managing up.

Managing up means understanding the constraints your leadership faces, anticipating their questions, and providing context that helps them make better decisions. It means being clear about risks without being a blocker, and building credibility through consistent input rather than formal authority. In this case, it meant understanding what the new manager was trying to achieve and helping them see patterns they hadn’t encountered yet, rather than telling them what to do.

I’d spent years managing down and across, but this required a different skill entirely: shaping outcomes through influence alone.

It’s harder than it sounds. You have to let go of control while staying invested. You have to accept that decisions might be made differently than you’d make them, and you can’t always prevent that.

What happened to the team

In the months and years that followed, things got harder.

Leadership in the new department didn’t know what to do with a platform team dropped into their feature organisation. Over the years, there were multiple reorganisations, new managers cycling through, and a lack of clear vision and direction. The team struggled. Some people found opportunities to move to other teams where they could have more impact.

It was painful to watch. Not just for me, but for everyone involved. Two years of wasted effort, energy, and opportunity. People’s careers were affected. The system stagnated. Customers suffered.

If there’s a silver lining, it’s that the evidence is clear. The costs are visible. I hope someone in a senior leadership position eventually comes to their senses, admits this was the wrong decision, and does something to try to fix it.

The real reason for the move

I mentioned earlier that the public reasons weren’t the real ones. Over months, if not longer, conversations with various people helped me piece together what I believe was the main factor. Nobody ever officially confirmed this.

The real reason was structural convenience. Another team from a sibling department was being reorganised. Someone looked at that move and thought, “We could move the design system team at the same time.” No strategic evaluation. No consideration of whether it made sense for the work. Just organisational efficiency. The justifications I explored earlier felt like they were created after the fact to try and make the move seem rational.

What this revealed was a gap in the organisation’s understanding of our work. The decision was made because that distinction wasn’t visible to those making it. They didn’t know what questions to ask or the impact their decisions would have.

The reality of leading through it

Dumb decisions happen in organisations. They shouldn’t. They don’t make logical sense when you examine them closely. But that’s the reality of how organisations work. People make decisions without consulting their experts. Politics, career aspirations and convenience win over what’s right. Context gets lost in the shuffle of larger priorities.

As leaders, we don’t always get to choose the decisions that affect our teams. Sometimes they’re made for us. Sometimes they’re clearly wrong, and everyone with any expertise knows it.

But we do get to choose how we respond. We get to decide whether we’re going to be bitter about it or try to make it work. We get to decide whether we’re going to protect our people and fight for what matters, even when the odds are against us.

That’s where the real work happens. Not in being right about the decision, though sometimes we are. The real work is in leading through the aftermath. In maintaining your credibility while disagreeing. In staying positive when things are frustrating. In building relationships with people who didn’t ask to inherit your work. In leading through influence, when you no longer have authority.

It’s harder than just making good decisions in the first place. But it’s also where you discover what kind of leader you actually are.

Is There Too Much Design in Design Systems?

hello@53degrees.studio (Shaun Bent) — Mon, 12 Jan 2026 00:00:00 GMT

For a while now, I’ve been noticing a pattern in design system job postings. Designers everywhere. Engineers, not so much.

I needed to see if I was just imagining this, so I analysed 256 design system roles from two sources: the Into Design Systems Jobs Directory and a year’s worth of postings in the Design Systems Slack community, which has over 28,000 members. The split was consistent across both: 70% design-focused, 26% engineering-focused. A 3:1 ratio.

Breaking that down: of the 228 individual contributor roles, design outnumbered engineering 170 to 58. Again, nearly 3:1. The 26 management and leadership positions were also design-focused (15 to 11), though with a sample that small, it’s hard to draw firm conclusions. What’s clearer is the IC picture, and I’d guess that’s where most of the hiring happens anyway.

In the week since I ran this analysis, another 10 roles were added to the Into Design Systems jobs board. 7 designers, 2 engineers, 1 product. The pattern continues.

Which raises an uncomfortable question: if the industry is hiring three designers for every engineer, who’s actually implementing all this design work?

Where the value comes from

Design systems need great designers. A well-crafted Figma library creates shared language, speeds up design iterations, and aligns teams around common patterns. That’s real value.

But that value has a ceiling.

A Figma library, no matter how comprehensive, primarily helps designers. The moment a project moves to implementation, engineers are translating those designs into code. Every time. For every feature. Across every team.

The real value comes when patterns exist in production code. When a component lives in your codebase, every engineer building your product can use it. When you update it, that change ripples across every screen where it’s deployed. When you need to make a sweeping visual change or make an accessibility improvement, you do it once, centrally, rather than hoping dozens of teams all update their local implementations correctly.

This is the promise of design systems: efficiency and consistency at scale. That promise is ultimately delivered through code.

Users don’t interact with your Figma library. They interact with what is shipped in code.

What I saw work

In my last team, our design system team ran with a deliberately high ratio of engineers to designers. Originally around 6:1 and then reduced to 4:1 after a few rounds of layoffs.

Both our design and engineering outputs created value, but not in equal proportion. We understood that a significant portion of our value came from code implementation, and we staffed accordingly. Our system was heavily automated, with algorithmic token generation, sophisticated tooling, and infrastructure that required significant engineering investment to build and maintain.

Our system wouldn’t have functioned without designers, but it needed a significant team of engineers to build and operate it.

If that ratio had been inverted, with four designers for every engineer, we’d have generated plenty of design value. But the larger value, the part that actually reaches users, would have been permanently bottlenecked.

So what’s actually happening?

When I look at that 3:1 figure, I keep wondering what’s going on behind the scenes. A few possibilities (read educated guesses):

These are all new design systems, early in their maturity. If you’re just starting out, establishing design foundations before bringing in engineering capacity might make sense. Design first, implement later. But from reading a lot of these job descriptions, most are for roles working on existing design systems. And how many organisations have been in that “early maturity” phase for a year or more?

Designer roles have higher turnover. Maybe the ratio of open roles doesn’t actually reflect the makeup of our teams. If designers move between positions more frequently than engineers, you’d see more designer roles advertised even if team compositions are more balanced. The job market might be skewed by churn, not by how teams are actually structured.

Feature teams are doing the implementation. Design system designers create the specs, and engineers on product teams build the components. This can work, but it means platform work is landing on people whose primary job is shipping features. That’s a recipe for inconsistent quality and competing priorities.

The systems are staying in Figma. Some organisations might be comfortable with design-only systems, and that’s a valid choice. There’s real value there. But it’s worth being honest about the trade-off: without code implementation, you’re leaving significant potential value on the table. Your organisation could be getting so much more value from your system.

Engineers exist but aren’t being hired as “design system engineers.” Look at the design roles, and you’ll see specialisation: “Design System Designer,” “Product Designer - Design Systems,” titles that acknowledge this as a distinct discipline. The engineering equivalents are rarer. Are organisations hiring engineers to work on design systems, but they’re advertising them as general frontend or platform roles? If so, what does that say about how the engineering side of this work is valued? Is design system engineering treated as something any engineer can pick up, while design system design is treated as a specialism?

Teams are just badly understaffed on the engineering side. Organisations see “design system” and think “design problem.” They hire designers. The implementation backlog grows. The system never delivers on its promise. I really hope this is not the case.

A few bright spots

It’s worth noting an interesting trend I observed among the leadership roles advertised. Reviewing the job descriptions, I found several leadership roles that explicitly welcomed either design or engineering backgrounds. They’re hiring for design systems leadership, not design leadership. 😍

This was encouraging to see. It suggests that at least some companies understand that this discipline spans both worlds and are hiring leadership accordingly.

But honestly, these felt like outliers.

The uncomfortable question

Design work is undoubtedly valuable. But code is where you unlock the most value from your design system. So why are 70% of roles design-focused?

Either most organisations are getting far less value from their design systems than they could be. Or there’s a massive amount of invisible engineering work happening somewhere that isn’t showing up in job titles. Or the industry has collectively decided that design systems are a design discipline, and we’re all just going along with it.

I don’t have a tidy answer. But I do know what worked at scale: investing heavily in engineering capacity, treating implementation as the core work rather than a downstream task, and recognising that the source of truth is what ships to users.

The next time you’re planning headcount for a design system team, it might be worth asking: are we building a design system, or are we just designing one?

Why Federated Design Systems Keep Failing

hello@53degrees.studio (Shaun Bent) — Mon, 08 Dec 2025 00:00:00 GMT

A few years ago, I walked out of a particularly frustrating meeting discussing federated design systems and wrote down a title: “The Fallacy of Federated Design Systems.” I never got around to writing the piece. Then Nathan Curtis published an article with that same title, and he nailed it.

Nathan’s analysis of the myths surrounding the federated model, the way these systems are sold, and the false promises about distributed ownership and community contributions is spot on. He dismantles the theory brilliantly. But here’s what I want to explore: what happens when organisations try to make federated work anyway? Not because they misunderstand the theory, but because the promises sound genuinely appealing.

During my nine years at Spotify, I watched the federated approach fail twice, in two different ways. I want to walk through what actually happened, where it broke down, and why the failures were so stark. Because knowing the theory is one thing. Living through the implementation is another.

The promise: distributed ownership

When everybody owns something, nobody owns it.

Milton Friedman

The federated model suggests that design system work can be distributed across multiple teams without a central authority. It sounds democratic. It sounds efficient. It sounds empowering. In practice, it creates an ownership vacuum.

Who’s responsible for defining the architecture of the design system? Who establishes and evolves the processes needed to scale? Who ensures quality and consistency? Who maintains the infrastructure on which the system depends? Who deals with the unknown challenges that will inevitably occur?

In a federated model, the answer is often “anyone,” which quickly becomes “nobody at all.”

I’ve observed a pattern in organisations that pursue federated models. They tend to underestimate the value of experienced design system practitioners. This is particularly common in organisations that place greater emphasis on backend development, where the complexities of UI development and the effort required to operate design systems at scale are often oversimplified and undervalued.

What this looks like in practice

I’ve seen this play out twice at Spotify in a team focused on owning a specific part of the Spotify ecosystem, operating separately from the core design system.

The first attempt: Was a federated model with a small central team providing support, guidance, and frameworks. The promise was solid. In practice, the organisation struggled to understand the purpose and value of the central team, so they were treated as a free resource and constantly pulled into other projects. The promised support, guidance, and frameworks that would have made the system viable never happened. No one was accountable for the fundamentals. The basic work of operating a design system simply didn’t happen because nobody was clearly responsible for doing it. Even when someone was responsible, they weren’t given the time to do the work. The result was degraded sentiment towards design systems within that department.

The second attempt: When the first attempt ultimately failed, the organisation went even further. They disbanded the central team entirely and pursued a fully federated approach. No transition plan. Zero strategy beyond “teams will figure it out.” The approach was even more hands-off than before. Again, no one was accountable for the fundamentals. Again, the basic work of operating a design system didn’t happen. The result was the same chaos, just with even fewer guardrails.

Both times, the same pattern emerged: lack of clear ownership led to the same outcome. Neither attempt understood that operating a design system requires dedicated expertise and focus. Without it, the system collapses.

The promise: contributions from multiple teams

Our teams are already stretched. Pressure to deliver, meet deadlines, add new features, fix bugs, and address tech debt. When does a team actually have time to contribute a component to a shared system?

Creating a quality design system component isn’t as simple as moving a feature implementation into a shared repository or Figma library. It requires real effort to ensure a component can scale to different use cases, meet accessibility and localisation requirements, and follow a consistent API that aligns with other components in the system. And that’s just the component itself. You also need documentation, design-code alignment, and ongoing maintenance. These are specialisations.

Designing for reuse, scale, and consistency are skills that take time and experience to develop and require leadership. Feature teams aren’t trained in this work, and frankly, they shouldn’t have to be. Their expertise is in shipping features, not in building foundational systems and having the broad context required.

The federated model assumes that teams will find time for this work in addition to their existing commitments. They won’t, and they don’t.

What happened instead: duplication without reuse

The first attempt encouraged duplication with the promise of later consolidation. Engineers would copy and tweak code, creating new components regardless of how similar they were to existing ones. The system followed a defined naming strategy that enabled traceability; you could see exactly which components were created by which teams and where they were used. The idea behind this duplication-friendly approach was straightforward: prioritize speed by letting teams build exactly what they needed. The bet was that this autonomy would keep teams moving fast, and the central team would consolidate these duplicates later into single, reusable patterns.

But it never happened. As we established previously, the centralized team wasn’t given the time to do this work. The promised consolidation phase never occurred. As a result, the system only ever grew; it never contracted. At one point, it contained over 1,500 individual components.

The second attempt took a different approach. Teams were meant to create domain-specific components; the playback team would build the play button, the team responsible for search would build search components, and so on. Sounds logical.

But there was no discovery mechanism. Teams couldn’t find what already existed, so they built their own. The result? Average component reuse of 1.2 times per component, compared to 200 times for components from the centralised design system. Within 12 months, around 1,000 new components were created. Oh, and these didn’t replace the components from the first attempt; they were net-new things.

Both systems suffered from the same core problem. Teams built what they needed for their immediate use case. Without dedicated effort to consider reusability, make components discoverable, or consolidate similar patterns, you get exponential growth of barely reused components.

The ownership problem escalates

If Team A contributes a component and Team B needs changes to it, who is responsible for making those changes?

In the first attempt, owning teams pushed back on reuse. They didn’t want the dependency. They didn’t want to be responsible for supporting the needs of other teams in addition to their own work. The risk here is that you turn feature teams into pseudo-platform teams, now helping other people’s problems alongside their existing commitments.

This tension is inherent to federated models. You’re asking teams to take on platform responsibilities without giving them the focus, resources, or authority that platform teams need to be effective. And there’s a deeper issue: platform work requires a different skill set entirely. It’s about thinking systematically, how components interact, how patterns scale across use cases, rather than optimizing for a single product’s needs. Feature teams are focused on solving problems perfectly for their context. Platform teams need to solve them adequately across many contexts. That’s a fundamentally different mindset, and you can’t just ask teams to switch between the two.

The promise: no need for a centralised team

This promise is fundamentally about money. The federated model gets framed as a way to get a design system “for free.” You can save the cost of staffing a dedicated team by distributing the work across existing teams.

This thinking is both naive and demonstrates a significant misunderstanding of what’s required to build and maintain a design system at scale. This thinking also tends to emanate from those in leadership positions, often abstracted away from the details and nuances of running a design system.

What actually happens without dedicated ownership

Both of Spotify’s attempts at federated struggled with the same fundamental problems that require dedicated ownership to solve.

The discovery problem: The first attempt had a basic discovery mechanism, but it was inadequate and went unused. The second attempt didn’t bother building one at all - no tooling, no strategy. In both cases, teams couldn’t find what existed, so they built their own. This isn’t surprising - effective discovery requires dedicated effort and investment.

The quality problem: Who ensures components meet accessibility standards? Who maintains consistency in API design across the system? Who handles the unglamorous work of deprecation and migration? In both examples, nobody. These concerns simply weren’t addressed because no one was clearly responsible for them.

The infrastructure problem: The first attempt wrapped components in a framework that required ongoing maintenance. The second attempt bundled UI, behaviour, and instrumentation into complex components that needed dedicated support. Both required significant infrastructure that the feature teams needed to maintain alongside their primary work.

The real cost

At scale, the effort required to support a federated model often exceeds that of a centralised one. You’re just spreading that cost across multiple teams who are less equipped to handle it, and you’re paying the overhead of poor coordination on top.

The second attempt is particularly revealing because it illustrates what happens when the necessary investment is not made. The previous central team was disbanded with no transition plan, and there was zero strategy for component discovery. No tooling or processes. Reuse was positioned as the goal, but nothing was built to actually enable it. Without the infrastructure to support distributed ownership, teams defaulted to what they knew: building their own solutions.

The design-engineering divide: why federated can’t solve it

One consistent failure across both attempts was the persistent divide between design and engineering, a problem that federated models struggle to solve and often exacerbate.

The first attempt created a fundamental mismatch. Designers in the central team operated like a traditional centralized design system, creating a shared Figma library of components. But the engineering side was federated. This meant designers had centralized resources and shared components, but engineers lacked code implementations that matched what designers were sharing. There was immediate friction.

The second attempt didn’t solve this. By removing the central team entirely and making no consideration for design alignment, the divide got worse. The first attempt had design components with no code implementations. The second created code implementations with no mapping back to design. Both ended up in the same place: misalignment.

The core issue is that aligned design and code require more than effort and collaboration; they require a shared understanding that parity between the two is non-negotiable. A federated model distributes this work across feature teams, but no single team sees the full picture or thinks holistically about the system. Each team focuses on its own slice of the experience in isolation. Patterns diverge. What designers expect doesn’t match what engineers build. You end up with multiple implementations of the same design pattern, each slightly different.

This challenge is hard enough with a dedicated team working closely together. Without one, it becomes nearly impossible.

This is why, within Encore, we made parity between design and code non-negotiable. Our engineers were in Figma, and our designers were in code. No handoffs. Designs weren’t thrown over the fence. This type of alignment necessitates a cultural shift, a fundamental change in how teams collaborate. In a small, centralized team, you can implement that relatively easily. But to scale it across an entire organization the size of Spotify? That’s where federated models hit a wall. You can’t mandate culture change across hundreds of autonomous teams.

When might federated actually work?

Despite what I observed at Spotify, I can see scenarios where federated might make sense, but they’re genuinely rare and require specific preconditions most organisations don’t have.

So what would you actually need?

Organisational infrastructure:

Clear governance frameworks that multiple teams actually follow, not just document
A strong cross-disciplinary collaborative culture - no silos
An investment in the appropriate discovery tooling to allow teams to find and reuse what exists
Processes that prevent fragmentation
Accountability structures for quality standards
Dedicated programme management to coordinate across teams

The right conditions:

A mature design system practice that already exists in the organisation
A scale that’s small enough to keep coordination overhead manageable
Multiple teams that genuinely have overlapping needs, who benefit from shared ownership
Teams with dedicated capacity beyond feature delivery to invest in platform work
A culture deeply rooted in distributed, collaborative thinking (organisations with strong open-source traditions sometimes have this naturally)

Most organisations don’t have these things in place, and building them requires significant overhead. At that point, you’re spending the effort anyway, just in a more complicated way.

Here’s what I keep coming back to: at the point where you’ve invested enough time and energy to make federated work properly, would that same investment have been better spent on a well-run centralised team?

A totally made up graph for illustration purposes

What does a centralised model require? A dedicated team. Clear ownership. Processes.

The complexity is lower, the coordination overhead is smaller, the accountability is clearer, and you can show value faster.

In most cases, the answer is obvious. The centralised model is more straightforward. You can always evolve towards more distributed contribution patterns later, once you have solid foundations in place.

Starting with federated means you’re trying to solve the most complex organisational challenges before you’ve solved the fundamental design system problems.

The hard truth

Federated design systems aren’t inherently bad, but they’re significantly more challenging than they appear, and how they’re sold. The promises sound brilliant. Who wouldn’t want distributed ownership and community contributions? But delivering on those promises requires massive organisational investment that most teams hugely underestimate.

Both attempts at Spotify had smart people working on them. Neither was doomed from the start. But both underestimated what was required to make federated work at scale.

The first attempt had a small central team, but they operated within an organisation that didn’t share their view on what their design system should be or how much investment it required. They were treated as a free resource rather than being given the authority and focus they needed. The second attempt removed central coordination entirely, betting that domain expertise and autonomy would solve the problem better than centralisation could.

Both attempts reflected genuine disagreements about priorities and trade-offs. But both created the same outcome: exponential growth in barely reused components, accumulated technical debt, and confusion about what the system was intended to provide. Crucially, this damaged the reputation of design systems as a concept, particularly amongst senior leadership.

If you’re considering a federated model, ask yourself honestly: Do you have the culture, discipline, tooling, and governance in place to make this work? If not, are you prepared to build all of that infrastructure before seeing any value from your design system? Would that same investment deliver better results if put towards a centralised team that can start showing value much sooner?

A well-run centralised team delivers value faster, with lower coordination overhead and clearer accountability. Nathan Curtis was right that federated is a facet, not a model. What I’ve learned from watching it fail twice is how much damage these attempts do beyond just the immediate system. They poison the well, making it harder to secure investment for any future design system work. That’s why starting with a solid centralised foundation matters - it builds trust and proves value, giving you the credibility to evolve towards more distributed patterns later.

Design systems are already challenging. Don’t make them harder than they need to be.

Thank you to those in the Redwood community who helped to review and offering feedback on this article. 💜