Most large organisations have a CX strategy, but it’s not always the case that delivery teams can see it. Design leadership has a role in helping to close that gap, through translation.

The planning department

In 1911, Frederick Winslow Taylor published The Principles of Scientific Management, and with it an idea that shaped the twentieth-century workplace: the thinking and the doing should be done by different people. Managers, armed with stopwatches and a planning department, would work out the one best way to do a job, and workers would carry it out. It was efficient, measurable and, for a long time, enormously influential.

That is, until Toyota famously showed what that separation cost. On a Toyota production line, anyone can pull the ‘andon’ cord and stop the line when something's not right. The people closest to the work are trusted to spot problems and help solve them. Thinking and doing were put back together, and quality followed.

We’ve come a long way, but I suspect many organisations still have a whiff of Taylor’s thinking running through them.

Two teams and a gap

Most large organisations have a CX strategy. Principles, frameworks, measures, and a clear line of sight to NPS - excellent, valuable and thoughtful work. What's less common, though, is a designer in a delivery team who can tell you how their work connects to any of it, or helps to move the dial.

I’ve noticed a common pattern: a strategy or CX team owns the experience vision and NPS goals, but not the work. Delivery teams own the work, but not the CX measures. Designers sit inside those delivery teams, focused almost entirely on getting things shipped. They're rarely involved in shaping the frameworks, and often not even measured against them.

Two teams, and a gap.

No-one is doing anything wrong here. The CX team is doing what it was set up to do, product owners are understandably focused on delivery deadlines, and designers are doing the work that is asked of them. The trouble is, it’s hard for designers to make a connection to goals set by a team that sits apart from day-to-day delivery, let alone get behind them. And it runs the other way too: the CX team might not be aware of what the delivery teams know best - what customers actually do when they meet the product.

The gap is wider still if delivery teams work in ‘feature teams’ - the label Marty Cagan coined for teams that are handed features and dates, and measured on output rather than outcomes. Designers in these teams aren't just removed from the experience goals; they're designing pre-ordained solutions that were decided somewhere else, for reasons they may not even know. Peter Merholz has written about how design "succeeded its way into irrelevance" by embedding itself in delivery, and this is one of the ways I see it happening. Designers are in the room where things are built, but not in the rooms where the problems are defined and the goals are set.

More communication won't close this gap on its own.

What good looks like

I worked with a medium-sized enterprise a few years back. They had no separate CX team. The strategy came from the product team and was handed down to the designers (so this isn't an argument against strategy coming from above). The strategy came as an objective with a measure attached: move customers to capable, self-serve digital experiences, and reduce the cost to serve. It was then up to the product design teams to do the research, find the opportunities and work out the best solutions to meet the objective.

Our teams found a number of opportunities, and because we could see the measures that mattered, those measures shaped every decision that followed. Rather than committing to solutions straight away, we tested our hypotheses with customers first, and a few ideas changed shape entirely once we saw what people actually did rather than what we’d assumed they would. The solutions we eventually built each made a meaningful difference on their own. But it was the cumulative effect that counted - more customers choosing to self-serve, real savings for the business, and no compromise on our experience standards.

Looking back, the connection between strategy and delivery was almost seamless. The team was small enough that it happened by default. As organisations grow, they specialise - strategy becomes a function of its own, delivery splits into teams - and the connection that used to happen naturally now has to be made on purpose.

Translation

This is where I see strategic design leaders making the biggest difference. Not by owning the strategy, or the delivery, but by being the translator between them - turning a CX principle into an actionable decision, and communicating what delivery learns back the other way. Translation becomes the bridge between the two teams.

In practice, it’s a set of fairly simple activities. Some a design leader could start tomorrow, while others might need allies.

Things design leaders should be able to do without permission

1. Ask "what is this meant to change?" Encourage designers to ask this of every solution they're handed, and name the CX measure or NPS driver it should move. Even when the solution is fixed, asking the question brings the strategy and goals back into view.
2. Bring the customer's voice into delivery. Make sure each team sees the NPS comments and complaints about the part of the experience it owns. A designer reading detractor comments about their own feature sees the connection straight away - and has evidence to share with their stakeholders.
3. Look back after launch. A light review a few weeks after release - did it move what it was meant to move? Even an informal one starts to build a habit of measuring outcomes.

Things that need the CX team on board

4. Support teams as well as set targets. A CX partner who works alongside a few delivery teams, helping them connect their work to the measures, can do more than a framework on its own.
5. Share rituals both ways. CX people join team showcases and research sessions; designers join CX insight reviews. It's easy, and it closes the distance from both sides.
6. Map the line of sight. Using a framework like Teresa Torres's opportunity solution tree, running from CX goal to customer opportunity to the solution being built, means any piece of work can be traced back to why it matters.

Things that need a CPO

7. A shared measure. Alongside the delivery targets most teams already have, include CX key results that both the CX team and the delivery team are accountable for.
8. Briefs that carry the outcome. Every request into a delivery team says what it's meant to achieve, not just what to build.

None of these is radical. Most organisations already have the pieces. What's usually missing is the connective tissue that binds them.

The harder work

Let’s not pretend translation is the whole answer, or that it’s easy. Even the first three points - the ones a design lead can make without anyone's permission - depend on someone being willing to listen. Asking what a piece of work is meant to change, or putting customer comments in front of a team, is easily seen as friction when there's a date on the wall, and parked as “something to come back to after launch”, which in practice often means never. Fair enough, in a way. Product owners are doing exactly what they're measured on, and a designer asking them to pause, however gently, is asking them to take a risk their own scorecard won't reward.

That isn't something a design leader can solve alone. I think most organisations trade quality against speed every week without ever saying it out loud, and the choice quietly defaults to the date. Deciding that whether something works matters as much as when it ships is a call for the people who set the deadlines. Translation can start the conversation, but it needs someone with authority to protect the questions.

Beyond that, some of the gap is structural, and structural problems eventually need structural fixes: giving teams problems rather than solutions, planning with CX and design in the room before solutions are decided, measuring teams on outcomes as well as dates. Those changes are slower and harder, and they usually need people with more authority than most design leaders have.

It's also worth being fair to the way things are. Separating strategy from delivery isn't always a mistake. Ben Erez made a thoughtful case in Lenny's Newsletter for feature teams as a legitimate choice - when a founder has a clear vision, or a company needs to catch up quickly, handing teams a roadmap can be the right call. Specialist CX teams also bring depth and a view across the whole experience that no single delivery team could hold.

So I see translation and structural change working together rather than as alternatives. Translation is where a strategic design leader can start now. And done well, it builds the habits, the relationships and the evidence that make the case for structural change much easier to argue later.

Pulling the cord

Toyota's andon cord worked because it trusted the people closest to the work to see problems and help fix them - and because leadership made it safe to pull, even when stopping the line cost time. I think delivery teams deserve the same trust, and the people asking "what is this meant to change?" deserve the same protection.

I'd love to know how this looks where you are. Is your CX strategy understood and connected to the teams doing the work? What made the difference - and which of these would you suggest trying first?