I once talked a designer out of his own design.
Not by going over his head, not by filing a ticket, not by passive-aggressively shipping something different. I pulled up the prototype, showed him what would happen on mobile - the jank, the constraint, the gap between what he'd drawn and what the browser could actually do - and he said: yeah, okay, let's do a full-screen modal instead.
That was it. Five minutes. Better product.
That kind of conversation sounds simple. It rarely is.
The usual prescriptions
The designer/engineer tension in design systems is well-documented. Designers complain that engineers ignore specs. Engineers complain that designers don't understand constraints. Both are partially right, and the usual prescriptions follow: better documentation, shared Figma files, a component API with enough tokens to cover every edge case, a design system team to referee the middle.
None of that is wrong, exactly. But it's treating a symptom.
At Amazon, I was a founding member of the Meridian design system team. By most measures, it worked - components shipped, teams adopted them, the product got more consistent. But what I remember most isn't the system. It's that we almost never fought.
Structure, not culture
The reason was structural, not cultural. Engineering and design both reported up to the same design manager. An excellent one. We sat alongside our UX team - not in separate buildings, not in separate Slack channels, not in separate sprint cadences. We were just… together. Working on the same thing, accountable to the same person, with no incentive to defend territory.
When I flagged that mobile modal problem, I didn't have to convince anyone I was right. I just had to show the thing. The designer wasn't invested in fighting me - he was invested in the product working. Because we were both invested in the same thing.
What that actually changes
Decisions are faster.When there's no org boundary to cross, “we should talk about this” happens in a hallway, not a meeting request. The modal conversation took five minutes because we could have it immediately, informally, without it becoming a process.
Nobody is defending territory.When you're siloed, design decisions feel like design's decisions. Engineering decisions feel like engineering's decisions. Any change feels like a concession. When you're integrated, a better decision is just a better decision.
The system serves the product, not internal politics. This is the quiet killer of most design systems - they calcify around the org chart instead of around user needs. Components get built to satisfy a team's scope, not a user's journey. Integrated teams build differently because they're optimizing for the same output.
The uncomfortable implication
You cannot process your way out of a bad org structure.
I've seen teams adopt every best practice - design tokens, Storybook, contribution guidelines, a governance model - and still ship inconsistent products, still have the same fights, still have engineers shipping things that don't match the comps and designers filing frustrated tickets about it. The tooling was fine. The org was the problem.
If design and engineering report up different chains, they have different incentives. If they don't sit together, they don't build shared context. If decisions have to cross org boundaries, they slow down and get political. No component library fixes that.
What fixes it is a manager who understands both disciplines, who creates the conditions for collaboration instead of just mandating it, and who makes it structurally easy for a designer and an engineer to have a five-minute conversation instead of a five-week process. That's not a tool. That's not a framework. It's leadership. And it's the thing that design systems articles almost never talk about, because it's not something you can sell.
What actually made Meridian work
My design manager at Amazon didn't make Meridian succeed by picking the right technology stack. He made it succeed by making sure the people building it trusted each other - and gave them the proximity and shared ownership to make that trust practical.
The next time your design system is struggling, before you buy another tool or write another contribution guide: ask who everyone reports to, and how often they eat lunch together.
The answer will tell you more than the docs ever could.