Lost In Translation

When it comes to design, assume nothing.

I speak from scars, not theory. At Spotify, the engineering culture was thick as sea fog. I once gave a talk on why design needed a seat at the strategy table. Thought it landed well—clean, honest, true. It didn’t. My manager pulled me aside after. People had complained. They heard arrogance where I meant clarity. They sensed disconnection where I sought connection.

It wasn’t a one-off. It was a pattern.

In places like Spotify, engineering sets the rhythm. The language there is hard-edged and certain, valuing the concrete, the measurable, the done. Design works differently—wading into grey waters where we test and listen, framing problems before solving them. Our questions can sound strange to those hunting for answers now, not questions about questions.

This gap isn’t about right and wrong. It’s about translation.

For too long, I thought process would bridge it: UX bugs, design debt, templates with the right boxes checked. All useful, yes, but shallow if deeper understanding stays missing. The truth hit me slow then all at once: if you want design to matter, speak to what matters to others.

Our design system at Spotify—GLUE—struggled at first. Nobody cared until we stopped talking about cohesion and started talking about speed. Not a design tool but a product enabler. Something that cut bugs, quickened builds, made platforms consistent. When people saw their own worries reflected in our work, they moved toward it, not away.

This is the real work of design leadership: not just making good things, but making good things make sense to everyone. Protecting your team. Fighting for your craft. Learning twelve internal languages without forgetting your own.

Most of our colleagues don’t really understand what we do. Not because they don’t care, but because we haven’t shown them clearly. We assume shared mental maps. We assume wrong. That’s not their failure. That’s a design problem.

So we design the bridge.

I learned to build a kind of Google Translate for cross-functional teams. When I said “design quality,” engineers looked confused. So I translated: “Three–hundred P1 bugs in Jira.” When I talked about “deteriorating user experience,” I switched to “increasing UX debt.” Same meaning, different words. The first version bounced off; the second stuck.

The bridge becomes wider when we speak directly to what our partners value most. Engineers want systems that scale, product managers want features that deliver, executives want evidence that matters. We don’t water down our craft—we elevate it by showing how design thinking addresses their deep concerns, not just our own.

I’ve learned that bridging isn’t just about changing words. It’s about changing myself—becoming curious about the world on the other side. What keeps them up at night? What metrics drive their decisions? What language makes their eyes light up with understanding? The strongest bridges are built by those who’ve walked both shores.

When translation works, teams find a shared rhythm. Ideas flow without friction. Products emerge that feel whole, not fractured. The sharp edges of engineering and the empathy of design create something neither could make alone. The work doesn’t just get done—it clicks.

Assume nothing. Learn the language. Build the bridge. And when your words don’t land? Don’t panic. It’s not always what you’re saying—it might just be how they’re hearing.

The best designers I know aren’t just masters of their craft. They’re masters of making their craft matter to people who speak entirely different languages. In a world of specialists, the translators inherit the earth.