Cross-functional influence starts before the design review

The design review is not where cross-functional alignment happens. By the time you're in the room presenting, your PM has already told engineering something about the direction. Engineering has already formed a view. Legal, if they're involved, has already flagged a concern in a Slack message somewhere. The review is where those views collide in front of you.

This is why design reviews that should go smoothly often don't. The designer prepared a thorough presentation. The work is good. But someone raises a concern that feels like it came from nowhere. It didn't come from nowhere. It came from a conversation the designer wasn't in.

The real work of influence

Influence over how a design decision lands isn't built in the presentation. It's built in the weeks before the presentation, in one-on-one conversations with the people who will be in the room.

Those conversations don't have to be long. A fifteen-minute sync with your PM on which direction you're leaning and why. A quick message to the engineering lead asking if there are any constraints you should know about before you go too far down a path. A check-in with the product manager on the downstream impact of one design decision over another. Each of those conversations does something the formal review can't: it gives the other person a chance to engage before they're on the spot.

When someone has already seen a direction informally and had a chance to raise objections privately, they don't need to raise them in the room. The concerns either got incorporated or got addressed. Either way, the person walks into the review with existing context.

What you learn from pre-conversations

The other thing early conversations give you is a more accurate picture of what the room will care about. Your sense of what matters is shaped by the design problems you've been solving. The PM's sense of what matters is shaped by the roadmap pressure they're under. The engineering lead is thinking about the sprint.

If you don't talk to those people before the review, you present a design optimized for the problems you've been solving, which may not map to the problems the room is currently preoccupied with. You get feedback that feels tangential to the work, because it's about the context you weren't carrying.

Talking to people before the review gives you information that makes the work better and makes the presentation more relevant. You find out the PM is worried about the edge case you didn't design for. You find out engineering is planning to rebuild that component anyway, so your design constraint was wrong. You surface the thing that would have derailed the review while there's still time to adjust.

Why designers skip this

The honest reason most designers skip pre-conversations is that it feels inefficient. You haven't finished the design yet. Why go talk to people about a direction you might change?

But the purpose of those conversations is to gather constraints, not to seek approval. You're not presenting half-done work and asking "does this look right?" You're asking about the context you don't have full visibility into before you finish.

The distinction matters because it changes what you're doing in the conversation. You're not looking for permission. You're gathering signal that will make the finished design better and the formal review faster.

When the review still goes sideways

Even with good pre-work, reviews go off course. Someone new joins the project and has no context. A stakeholder raises a concern that was never in scope. Someone in the room decides this is the venue for a different conversation they've been wanting to have.

In those moments, the pre-work pays off differently. You know which concerns were already addressed and can say so. You have a PM or engineering lead who was part of the earlier conversations and can help anchor the group. You're not starting from zero.

The review that goes sideways without pre-work feels like a failure of the design or the presentation. The review that goes sideways with pre-work is a specific, containable problem you can usually resolve in real time.

Cross-functional influence is largely about reducing the surface area for surprise. A surprised stakeholder is a stakeholder who has to figure out what they think in front of everyone, which is the least efficient way to get alignment on anything.