When to protect your designers from stakeholders, and when to push back on your designers

Design leadership culture has a bias toward protection. You hear it constantly. "I run interference." "I keep the noise from reaching my team." "My job is to shield them." Said with pride. Sometimes earned.

But I've watched the protection instinct cause as much damage as whatever it was protecting against.

The issue isn't that protection is wrong. Most managers just never distinguish between shielding their team from genuinely bad conditions and insulating them from difficulty that would actually make them better.

Two kinds of difficult stakeholders

Some situations designers shouldn't have to navigate alone. A VP who keeps overruling decisions made three levels below her based on personal taste. A PM who escalates every design disagreement to leadership to win. An executive who treats design reviews as a chance to re-litigate strategy settled six months ago.

These are structural problems. Better communication skills won't help your designer if the senior stakeholder has decided their job includes making design decisions. You running interference is the right call because it's the only lever that works.

But there's a different kind of difficult: stakeholders who push back because they don't understand the rationale, who ask uncomfortable questions about tradeoffs, who want to see more options, who are skeptical. That friction is data. Shielding designers from it teaches them that design is something you present rather than something you defend.

What over-protection does to a team

A designer who is never in the room when the hard questions get asked eventually stops being able to answer them. She presents well. She iterates quickly. But she hasn't had to hold a position under pressure, explain a tradeoff to someone who doesn't share her intuitions, or handle the moment a senior voice disagrees with her recommendation.

That gap shows up when she reaches senior designer, or staff, or eventually manager. Suddenly the thing she was protected from is her whole job.

Over-protected teams also tend to have a fragile relationship with product and engineering. When things go sideways (a design gets built differently, a feature gets cut, a direction changes after handoff) they read it as a failure of process or respect. Teams that have been in harder rooms tend to have a more accurate model of how product decisions actually get made. Less surprised by the messy parts.

When to push designers into the difficulty

The threshold I use: is this a situation that will help them grow, or is it someone else's dysfunction landing on them?

Presenting to a skeptical audience? Push them in. Defending a decision to a PM who disagrees? Let them do it. Be in the room, but let them do it. Getting feedback from engineering that their designs are hard to build? Their meeting.

Meeting with a stakeholder who has a pattern of ignoring agreed scope and relitigating fundamentals? That's yours.

Most difficult stakeholder situations are the first kind. A designer learns more from one hard presentation to a skeptical room than from six months of easy critiques.

Ask yourself why you're stepping in

When you step in, ask why. Is it because your authority or your organizational leverage is what's actually needed? Or because watching your designer struggle is uncomfortable?

Protection that comes from "I need to fix something only my position can fix" is good management. Protection that comes from "I don't want to watch them struggle" keeps your team fragile so you feel useful.

Letting the difficulty land somewhere survivable (you in the room, a debrief after, honest about what happened) is different from running interference on every hard thing. That's the version I'm trying to be more consistent about myself.