Design in Every Team Doesn’t Kill Design. Bad Operating Models Do.
Last year I had the pleasure of debating the motion: “Design in every team kills design.” This was during 2025 Service Design Global conference in Dallas in partnership with Pixel Debates.
I argued against it.
Not because I believe design should be scattered randomly across an organisation. Not because I think everyone should suddenly become a designer. And definitely not because I think craft, standards, mentorship, or design leadership no longer matter.
I argued against it because the statement points to the wrong enemy.
Design in every team doesn’t kill design.
Bad operating models do.
That distinction matters.
There is a useful principle for this. Blame the context, not the people. Daniele Catalanotto names it directly in his Service Design Principles, drawing on James Clear’s Atomic Habits: when something keeps failing, the problem is usually the system, not the individuals inside it. Designers are no exception. When embedded design fails, do not start by questioning the designers. Start by questioning the model that surrounds them.
Because the real risk is not that designers get closer to the business. The real risk is that organisations distribute designers without giving them the structure, protection, leadership, and shared practice they need to succeed. This experience is too close to home as I have been in this situation over my careers and comes up when I catch up with peers.
That is when design gets ‘diluted’.
Not because it is everywhere.
But because it is unsupported.
There is a difference between embedding design and abandoning designers.
One is strategic.
The other is negligence.
The Valid Fear Behind the Argument
During the debate, the strongest argument for the motion was that when designers are embedded across multiple teams, they can lose their craft community. They may report into leaders who do not understand design, or at least not its full potential. They can become isolated, mirroring the metrics of whichever function they sit within instead of holding the end-to-end user experience together.
That concern is real.
I have seen designers placed into teams without enough air cover, senior sponsorship, a shared design system, clear career pathways, or a community to return to.
That does not create embedded design.
It creates design loneliness.
And design loneliness is dangerous.
When designers are left alone inside teams that do not understand their craft, they become translators without a home. They spend their energy explaining why research matters, why problem framing is critical, why the first solution is rarely the right solution. Over time, that emotional labour becomes exhausting.
I worked with a designer once who was the only designer in a team of twenty engineers and product managers. She was good. Genuinely good. But after eighteen months she had stopped doing research, stopped sketching, stopped pushing back. She had quietly become a wireframe service for ideas. Nobody in her team thought anything was wrong. Her tickets closed on time. The problem was invisible to everyone except her, and eventually she left. The organisation lost a strong designer and never understood why. This example is too common when I mentor other designers that face issues being the only designer in their teams or organisations.
That is what design loneliness looks like in practice. It is not loud. It is slow.
This is where many organisations confuse proximity with maturity.
Just because a designer is close to a team does not mean design is embedded.
Embedded Does Not Mean Unsupported
Embedding design properly means creating a system around the designer.
It means there is a central practice. Somewhere designers come together, quality gets discussed, standards are held, lessons are shared, and people grow.
That could be a centre of excellence, a design guild, a chapter model, or a formal design operations function. The shape matters less than the intent.
The intent is to create coherence.
Designers can work locally, but they need to grow collectively.
This is where the debate often becomes too binary. Centralised or distributed. Embedded or protected. Business-facing or craft-led.
But mature organisations rarely operate in binaries.
They operate in tensions.
The question is not whether design should be centralised or distributed. The question is: what kind of design operating model does the organisation need at this stage of maturity?
A startup of 50 people does not need the same model as a bank of 50,000. A government department does not need the same model as a SaaS company. A design team of three people does not need the same rituals, governance, or career structures as a design organisation of 300.
Let me be concrete.
In an early-stage organisation, design is usually one or two people working across everything. The model is proximity. Designers sit close to founders, ship quickly, and carry the craft in their heads. There is no design system because there is barely a product. The risk at this stage is not isolation. It is burnout.
In a scaling organisation, design is five to thirty people, often spread across two or three product areas. This is where most operating model mistakes happen. Leaders copy a model from a company three sizes larger, install rituals nobody has capacity for, and create a design system before the team has agreed what good looks like. The right model here is usually lighter than it feels. A small central practice. Embedded designers. Weekly critique. One person who owns hiring and standards. Nothing more elaborate than that.
The lesson is not that one model is better. The lesson is that the model has to match the stage. A scale-up running an enterprise design operation will collapse under its own weight. An enterprise running a scale-up model will produce inconsistent work and burn its best people.
Context matters.
Maturity matters.
Politics matter.
And this is where design leaders need to become much more precise.
The Problem With Vague Design Language
Saying “design should be in every team” is not enough.
We need to define what we mean.
Are we talking about designers embedded full-time in product squads? Service designers working across strategic programmes? Design thinking capability shared with non-designers? Design leaders influencing executive decisions?
These are not the same thing.
The more generic the language, the easier it becomes for people to attack the idea.
So here is the clearer version.
Get Daniel Tuitt’s stories in your inbox
Join Medium for free to get updates from this writer.
Design should be close enough to the work to influence decisions early, and connected enough to the practice to maintain quality over time.
That is the model.
Close to the business.
Connected to the craft.
This is not about designers becoming internal consultants who float from meeting to meeting. It is not about designers being reduced to workshop facilitators. It is not about design becoming everyone’s job and therefore no one’s responsibility.
It is about building a system where design can shape problems before they become expensive solutions.
That is where the value is.
The Cost of Bringing Design in Too Late
Too often, design is invited in too late.
The strategy is set, the roadmap is agreed, the technology decision has been made, the budget is locked, and the timeline is impossible. Then someone asks design to “make it intuitive.”
That is not design. That is decoration under pressure.
And then, when the work fails to land, design gets blamed for not proving its value.
This is why embedding matters.
Design needs to be present where decisions form, not just where outputs are produced.
That means working with finance, operations, technology, HR, commercial, legal, and frontline teams. Not because designers know more than those teams. But because designers help make the connections between them visible.
A product team may optimise a feature, operations a process, finance cost, marketing conversion.
All of these can make sense locally.
And still create a broken experience systemically.
Design as the Connector Between Local Decisions and Systemic Outcomes
Design’s value is often in seeing the system.
Not just the touchpoint.
Not just the screen.
Not just the service moment.
The system.
This is where bad operating models kill design. They force design to live in one of two extremes.
In one extreme, design is centralised and protected, but too far from business reality. It becomes polished, thoughtful, and strategically irrelevant. In the other extreme, design is distributed everywhere, but unsupported. It becomes practical, busy, and slowly exhausted.
Neither is good enough.
The future is not centralised design. It is not distributed design. It is orchestrated design.
A model where designers are embedded in the places where they can create value, but supported by the structures that keep design strong.
That requires more than embedding designers and hoping it works. It needs leadership that sets direction, light governance that keeps quality consistent, and shared rituals — critiques, reviews, planning — where designers genuinely work together rather than in parallel. It needs a common language so design is understood the same way across teams, a design operations function that takes friction out of the work, and career paths that give good people a reason to stay.
And it needs a clear answer to one question: who protects the quality of design when designers are spread across the organisation?
Because if no one owns that question, the critique becomes valid.
Final Thought: The Leadership Responsibility
That is the point.
Design does not die when it spreads.
Design in every team can kill design if it is done lazily.
But that is not an argument against embedding design.
It is an argument against poor leadership.
The organisations that will benefit most from design are not the ones that hide it in a specialist department. They are the ones that know how to place it close to complexity, while giving it enough structure to stay strong.
Design leaders therefore need to stop framing this as a turf war.
This is not about defending the design department.
It is about designing the conditions where design can create value repeatedly.
That requires a different kind of leadership. Less heroic. More systemic. Less about being the smartest person in the room. More about making the room smarter.
This is a difficult shift for some designers. Many of us were trained to believe that design is the answer. But in complex organisations, design is rarely the answer alone. It is part of how the organisation finds better answers.
That means we have to work with people who do not speak our language. People who care about risk, cost, policy, compliance, efficiency, operations, targets, and delivery.
Not as blockers.
As partners.
Design dies when it spreads without support.
So the question is not, “Should design be in every team?”
The better question is:
What operating model allows design to be close to the work, connected to the craft, and credible to the business?
Because design in every team does not kill design.
A lack of leadership does.
If you want to see how the argument played out, you can watch the full debate here: https://youtu.be/Sg-zqRqjxeE?si=Ze_79YZ7rvptRd2M
