Thinking

What "Working Cross-Functionally" Actually Means

ProcessCareer·March 17, 2026·2 min read

Every designer’s CV says it somewhere. "Works effectively with engineering, product and stakeholders." The phrase covers two very different things, and only one of them is hard.

The easy one is coordination. You go to the right meetings, hand over specs on time and take feedback well. That’s the minimum. It’s good, but nobody should hire you for it.

The hard one is influence, which means changing the direction of something before it’s decided, like getting an engineer to care about a confusing flow. That’s what senior designers are hired for, and you almost never see it in a portfolio.

Coordination keeps you in the room, and influence changes the decisionWhat hides under "cross-functional"
Coordination: table stakes
Attends the right meetingsShows up, follows the process
Hands off specs on timeDeliverables land when expected
Presents work clearlyWork is legible to the room
Incorporates feedbackRevises based on what stakeholders said
Influence: the actual skill
Changes direction before it's decidedIn the hallway, three conversations earlier
Surfaces problems nobody namedMakes the invisible disagreement visible
Shifts what gets builtWhat it is, as well as how it looks
Makes engineers care about confusionTranslates user insight into what each function values
Portfolios mostly show the left column. Senior roles are hired for the right one.

The tricky part is that designers rarely have formal authority. We don’t own the roadmap or the engineering priorities, so anything that matters has to be won some other way.

Decisions are almost never made in the meeting where they’re announced. They get made a few conversations earlier, in a Slack thread or a corridor, while someone is still unsure and the framing is still open. If you only show up to the official meeting, you’re usually too late.

When do you join the decision?

Partners kept asking for something new. Here’s how the answer got decided.

Pick where you join

"Decision: benchmark toggles ship next sprint."

Slide

What’s still open

  • The problem framing● Settled
  • The options● Settled
  • The details● Settled

What you can still doAsk questions. Changing anything now means reopening a decision everyone thinks is done.

You joined at the review meeting. Nothing is still open.

Illustrative example

Translation helps more than anything. Engineers think in complexity and product people think in metrics, and if you can explain a user problem in their terms, they can actually act on it.

The same insight lands when it’s said in each function’s termsOne user insight, as engineering, product and business hear it
Engineering
"This confuses users"→ "This will increase support volume and create rework cycles after launch."
Product
"This confuses users"→ "This is a retention risk. It's the exact pattern we see in week-2 drop-off."
Business
"This confuses users"→ "This is a liability in enterprise demos. It's the first thing prospects will ask about."
Same finding, three ways of saying it. Each version gives that team something they can act on.

It also helps to make disagreements visible early. Most misalignment is people with different pictures in their heads who think they agree, until a prototype shows up and everyone is surprised. On a monetisation project, the most useful thing I made early on was a list of four questions the product had to answer, in order, every time a partner opened it. After that, every feature debate had something to point at.

And you have to be willing to be wrong in the room. Influence without authority runs on trust, and people trust you more when you can say "I’m not sure" than when you defend every pixel.