Cross-functional work: speaking other teams' languages

It was a Thursday afternoon planning meeting. A product manager was trying to get a privacy-flow redesign prioritised for the next sprint. She presented the user-research rationale — drop-off rates, NPS scores, session recordings — to an audience of engineers, a legal counsel, and the head of sales.

The engineers asked how long the redesign would take. Legal said nothing until the end, then flagged a GDPR (General Data Protection Regulation) concern in the current flow almost as an aside. Sales pointed out that enterprise procurement teams had been asking for a Trust Report for two quarters. Everyone agreed the redesign mattered. Nobody agreed it should be next.

The meeting ended with a follow-up action item. Which is where most cross-functional initiatives go to die.

The problem was not that anyone was obstructing. The problem was that the PM presented only one version of the case — the user-research version — to four audiences who each needed a different version to say yes.

Why functions diverge

Every business function is an optimization engine. It gets measured on specific outcomes, which shapes what it notices, what it worries about, and what a “good outcome” looks like.

Engineering is measured on velocity, reliability, and technical debt. A feature request lands as: how long will this take, what does it break, and does it pay off the complexity it adds?

Design is measured on craft and coherence — whether the product feels intentional and whether the system holds together as it grows. They see requests through: does this fit the patterns we have, or does it fracture the experience?

Sales is measured on revenue and cycle length. They hear every internal initiative as: does this help me close faster, open a new segment, or reduce a reason deals stall?

Legal is measured on risk avoidance. They scan every proposal for: what is the worst case if this goes wrong, and is the company exposed?

Finance is measured on unit economics — margin, return on investment, payback period. They ask: what does this cost, what does it return, and when?

None of these lenses is wrong. They are each locally rational, given the incentives the function operates under. The friction is not bad intent. It is that each team applies its own filter to a shared problem and gets a different answer.

The cross-functional skill is recognising which filter is active and reformulating your message to pass through it.

The Translation Framework

Think of any initiative you need to move forward as a single object — a business goal, a product change, a process improvement — that must be encoded differently for each audience that needs to act on it.

The diagram below shows a privacy-flow redesign expressed in the native language of five functions. The initiative is identical. The currency changes.

The PM in our opening story had only the user-research version. She needed all five.

Step 1: Learn what each function is scored on

This is the groundwork, and it takes deliberate effort. Most people never do it because it feels like someone else’s job.

Spend one hour with someone in each adjacent function — not to pitch your project, but to understand their world. Ask: what does a good quarter look like for your team? What is the most common reason something gets blocked or deprioritised? What did you last push back on, and why?

You are building a mental model of their incentive structure. Once you have it, you can run any future ask through their filter before you bring it to them.

A few reliable patterns:

Engineering prioritises work that is scoped tightly enough to estimate, isolated enough not to create regressions, and proportionate in complexity to the benefit. Vague briefs are not just annoying — they are genuinely harder to prioritise because the engineer cannot know what they are agreeing to.

Sales prioritises anything that shortens the deal cycle or removes a recurring objection. If your initiative does neither, it is competing with things that do. If you cannot connect it to a named deal or a pattern of lost deals, the connection is not yet made.

Legal prioritises risk reduction. The most useful thing you can give them is a clear statement of the current exposure — what is the worst case if we ship this without changing — alongside the risk profile of the proposed change. They will do the comparison themselves if you give them both sides.

Finance prioritises investments with a clear payback timeline. This does not need to be a formal business case for every initiative. It does mean you should be able to say: this costs roughly X in engineering time, and we expect it to reduce Y — which we can measure — by Z percent.

Design prioritises coherence. The strongest case you can make to a design team is that your initiative extends an existing pattern rather than creating a new one, and that not doing it is creating debt in the design system they maintain.

Step 2: Frame the ask in their currency

Once you know the filter, you can rewrite your request to pass through it.

This is not spin. You are not changing what you are asking for. You are identifying which aspect of the initiative is genuinely most relevant to each audience, and leading with that.

The privacy-flow redesign is a user-experience problem, a compliance problem, a sales-pipeline problem, a design-system problem, and a unit-economics problem — all simultaneously. The PM who presents only the UX framing is leaving four legitimate arguments on the table.

A practical structure for each functional conversation:

Lead with their problem, not yours. “Engineering has two sprints of capacity before the next big release. I have a scoped piece of work that fits.” Not: “I need the privacy flow rebuilt.”

State the outcome in their metric. “This closes the GDPR gap legal flagged in the Q3 audit.” Not: “This improves user trust.”

Make the cost of inaction legible. “The longer this stays in the current state, the wider the audit exposure.” Not: “Users are unhappy.”

Ask for a specific, bounded thing. “Can you review the component spec by Friday so I can get it into the sprint planning queue?” Not: “Can you support this initiative?”

Step 3: Find the shared goal

Translation does not mean telling each function a different story. It means helping each function see how their goal connects to the same underlying outcome.

The shared goal is what makes the initiative legitimate — it is not a rebranding for each audience; it is the actual business outcome. In the privacy-flow case, the shared goal might be: close the compliance gap while unlocking the enterprise segment and reducing churn. That outcome is genuinely good for engineering (meaningful work), design (coherent system), sales (new segment), legal (risk reduced), and finance (revenue plus churn reduction).

When you surface the shared goal, you make the trade-offs explicit. Legal may need to accept a slightly longer timeline to give engineering space to scope properly. Sales may need to be patient for a quarter in exchange for a solution that actually works. The PM’s job is to hold that shared goal steady while helping each function understand its piece.

This is also what earns trust across functions over time. People remember when you demonstrated that you understood their constraints — and when you delivered something that accounted for those constraints rather than just routing around them.

What fluency actually looks like

There is a practical difference between people who are merely polite across functions and people who are genuinely fluent.

Polite means: you listen, you do not talk over people, you thank them for their time.

Fluent means: you walk into a conversation with engineering and you already know the current sprint load and the open technical debt tickets. You walk into a conversation with sales and you know which deals stalled on security or compliance last quarter. You read the quarterly finance review before you ask for a budget reallocation.

This level of preparation is rare, which is why it is disproportionately effective. Most people prepare for the meeting they are running. Fluent cross-functional communicators prepare for the meeting from the other person’s point of view.

It takes longer upfront. It almost never requires a follow-up meeting.

The mistake to avoid

The failure mode in cross-functional translation is optimising for each audience so aggressively that you tell them what they want to hear, rather than what is true.

This breaks when the functions talk to each other — which they will. If you told engineering the work was two sprints and told finance it would take one quarter, someone is going to notice. If you told sales this feature would be ready in Q2 and told design you had not locked the spec yet, those two conversations will collide.

Translation must be honest. You are finding the angle of a true thing that is most relevant to each audience — not constructing a different truth for each. If a function’s goals are genuinely not served by the initiative, the right move is to say so clearly and explain why the broader business goal takes precedence, or to modify the initiative until it does serve them.

The people who build lasting cross-functional credibility are those who say hard things plainly, not those who smooth everything over. Fluency without honesty is just politics.

---

Back to that Thursday meeting. If the PM had prepared five framings — not five pitches, but five honest translations of the same initiative — the meeting would have looked different. Legal would have heard their risk framed as the reason to move quickly rather than carefully. Sales would have heard the enterprise procurement unlock. Engineering would have heard a scoped, estimable piece of work. Finance would have heard a payback timeline.

The follow-up action item would still have been scheduled. But it would have been about execution, not conviction.

That is the difference the translation makes.