Empathy is a core design skill. Understanding users’ needs, wants, and behaviors unlocks better products and experiences. Designers know this. It’s foundational to everything they do.
So it’s worth asking: why do so many design teams withhold that same empathy from the people who sign their paychecks?
The empathy gap
Designers are trained to understand users. They are not trained to understand executives. And that gap creates a predictable pattern: the design team builds a thoughtful, research-backed recommendation, leadership overrides it with a top-down solution, and the designers walk away frustrated, convinced the process wasn’t respected.
The frustration is real. But it’s also incomplete. Because the same empathy framework that helps designers understand why a user abandons a checkout flow can help them understand why an executive pushes for speed over rigor — if they’re willing to apply it.
Chess vs. poker
Andy Budd framed this tension perfectly: designers are playing chess while the business is playing poker.
Designers see waste — if 70% of new features have no measurable impact, the instinct is to slow down, expand research, and improve the hit rate. The business sees the same data and draws a different conclusion: move faster, churn through the misses, and get to the 30% that moves the needle.
Neither approach is irrational. But designers don’t get to pick the game. The business does. And sitting at a poker table insisting on chess rules doesn’t make you principled — it makes you irrelevant to the hand being played.
The cost of being “right”
Something else that Budd surfaced that designers rarely want to confront: resentment flows both ways.
Designers resent leadership for handing down solutions. Leadership resents designers for slowing things down. And executive resentment is far more actionable. Teams that push too hard for the “right way” get labeled as obstructionists. Those solutions they wanted to intercept and improve start going directly to engineering. The design “speed bump” gets bypassed entirely.
This is the unpleasant math: a good solution shipped in alignment with the business will always outperform a great solution that never gets built because the team couldn’t get out of its own way. And it’s not unreasonable to consider that executives might also know their users and their needs — they just arrived at that knowledge through a different path than a design sprint.
What alignment actually looks like
I’ve sat in plenty of meetings where designers vent about leadership overriding their process.
The frustration is valid, and I don’t dismiss it.
But after listening, I try to reframe: the executive’s solution isn’t the end of the conversation — it’s a starting point. Demonstrate willingness to align, then refine from within. That’s not capitulation. That’s the same iterative approach designers already believe in, applied to a different relationship.
The hardest part isn’t the reframe itself. It’s accepting that even the best design process doesn’t work if it isn’t aligned with the goals of the business — and that alignment is the designer’s job to build, not the executive’s job to grant.
Disclaimers: This post was inspired by two threads from Andy Budd that crystallized something I’d been seeing for years. All connections to my own experience are my own, and this article does not speak for anyone else, not Andy Budd, or my current or former employer, my mailman, or my dog, no one but me.. All thoughts — the accurate ones and especially the inaccurate ones — are mine alone.