Every designer’s CV says it. Cross-functional collaboration. Works effectively with engineering, product, and stakeholders.It’s become so universal it’s stopped meaning anything. The problem isn’t that people are lying. It’s that there are two completely different things hiding under that phrase — and only one of them is actually hard.
The first kind is coordination. You attend the right meetings. You hand off specs on time. You present work clearly and incorporate feedback. This is table stakes. It matters, but it’s not a skill — it’s a minimum.
The second kind is influence. You change the direction of something before it’s decided. You surface a problem that nobody had named. You make an engineer care about user confusion, or a PM care about interaction cost. You shift what gets built, not just how it looks. This is what “working cross-functionally” actually means at senior level — and most portfolios never touch it.
Here’s the uncomfortable truth about influence in cross-functional teams: where authority ends, influence begins [1]. Designers rarely have formal authority over roadmap decisions, engineering priorities, or what gets scoped out. Which means everything that matters — the upstream decisions that determine whether the design problem is even the right one — has to be won through something other than title.
Research on cross-functional team dynamics consistently identifies the same gap: giving teams accountability without authority — telling a team they “own the outcome” but not giving them the authority to change the roadmap or shift the budget [2] — is one of the most common structural failures in product organisations. Designers live in this gap permanently. The question is what you do with it.
The designers who navigate it well aren’t necessarily more persuasive or more extroverted. They’re more deliberate about when they show up and what they bring. They understand that the moment a decision gets made is rarely the meeting where it gets announced. It’s three conversations earlier, in a hallway or a Slack thread, when someone is still uncertain and the framing is still open.
Practically, this looks like a few specific habits.
The first is translating. Every function has its own language for what matters. Engineering talks about implementation complexity and technical debt. Product talks about metrics and roadmap sequencing. Business talks about risk and commercial opportunity. A designer who can speak all three — and translate user insight into each — is infinitely more influential than one who can only speak design. Not because they’re compromising their perspective, but because they’re making it legible to people who need to act on it.
The second is making the invisible visible. Most misalignment in product teams isn’t disagreement — it’s different mental models that have never been surfaced. People think they’re aligned until a prototype exists and suddenly everyone’s surprised by what the other person meant. The most influential design work I’ve done wasn’t a screen. It was a shared model — a diagram, a prototype, a framework — that made a disagreement visible early enough to resolve it cheaply, before it was baked into code.
When teams genuinely work cross-functionally, the entire product reflects it: technical architecture reflects actual usage patterns because engineers participated in user research; interface design anticipates technical constraints because designers participated in architecture decisions [3]. This is what genuine cross-functional work produces — not a series of handoffs, but decisions that carry the perspective of the whole team because the whole team was present when they were made.
The third habit is the hardest: being willing to be wrong in the room. Influence without authority depends entirely on trust. And trust, in a cross-functional context, is built not by being right every time, but by being honest when you’re uncertain — and by demonstrating that your goal is the best outcome, not winning the argument.
Cross-functional collaboration at its best isn’t a soft skill. It’s a strategic capability. The designers who have it don’t just work well with others. They change what gets built.
References