Cross-Context Communication for Engineers 3: Different Audiences Need Different Language

That time I synced the project with senior executives, I was actually quite well prepared. I had drawn three logic diagrams and written two pages of technical selection plans. But after 15 minutes of discussion, the other party didn't ask "Should we choose A or B?" Instead, they asked: "So will this help with Q4 customer engagement?"

I froze for two seconds.

Not because I didn't know the answer, but because I didn't expect them to ask it that way.

This wasn't the first time I got stuck in a communication where I answered but no one understood.

We often say "speak human language," but the biggest difficulty isn't translation—it's that you don't even know which language to translate into.

Talking to different people is like entering different chat rooms:

Some care about user experience, others only look at numbers and risks;
Some want to know "how to do this," others only care about "what impact does this have on me";
Some hear "component design," others hear "brand consistency."

We're not really bad at expressing ourselves; we just get the "subject" wrong.

Executives Don't Want to Hear About Technology; They Want to See You Decode Strategy

The mistake we most easily make with executives is "assuming they care about details."

I once pushed a Node.js service migration in a team, made a technical roadmap, and even tested a lot of RPS performance comparisons. When reporting to the VP, he interrupted me at the seventh minute and said:

You're being very detailed, but I actually want to know whether this is positive for our November growth target, or just cleaning up the infrastructure.

At that moment I realized I had been talking about "what we did," but what he wanted was "why you deserve my support."

Since then, when I speak to executives, I've gotten into the habit of organizing it like this:

We now face two options:

Option A is more stable, but it will compress the launch timeline;

Option B has slightly higher risk, but it can seize the exposure window before the quarter ends;

From a strategic priority perspective, if this round is mainly about growth, I lean toward recommending B, but with a one-week canary mechanism for risk control.

You don't need to dumb down the technology; you need to clearly lay out the path options, and then link them to the strategic goals, time windows, and competitive landscape they care about.

In other words, let executives do subtraction, not help you do a review.

Talking to Product: Not Confrontation, but Choosing the "Least-Cost Compromise" Together

Honestly, my communication with product used to feel like arguing.

I would say this thing is too complex to develop, and she would say users just need this feature. In the end, we both felt the other didn't understand us.

Later I realized the problem wasn't the opinions, but that we hadn't visualized the trade-off mechanism between "cost vs. user experience."

Once we were optimizing the registration flow. Product wanted to add dynamic phone verification plus a referral code logic, but that would introduce new third-party dependencies and require reworking permissions.

I didn't directly say "too complex." Instead, I said:

Your solution, if fully built, would indeed be more secure. But technically, we'd need to integrate two new SDKs and go through a permission approval, which could delay the release by two weeks.

If we first launch a simplified version with only the referral code logic, the user-perceived difference is at most one less security prompt, but we can ship two sprints earlier.

At this stage, which cost do you think is more worth it?

This isn't compromise; it's finding together the optimal zone where the impact on users is minimal and the technical burden is controllable.

Product isn't afraid of being challenged; they're afraid of being blocked by ineffective resistance.

Facing Operations Teams: Don't Say "Slow Queries," Say "Users Are Dropping Off"

The role that's easiest to overlook but hardest to communicate with is operations.

They have a fast pace, heavy metrics, and focus on real results, but we often toss out a line like "the backend is stuck on this feature," and they have no idea what to do.

I later found a very useful approach—translate the problem into the language of the "user perception layer."

For example, with slow database queries, I used to say:

The order query API P99 is at 2.8s, and the slow query ratio is 3%.

Later I switched to:

Right now, about 800 users a day experience the order page freezing for more than 3 seconds during the midday peak. More than half of them are first-time buyers, and they might churn directly.

At this point, operations immediately feels the severity, because what they care about isn't slowness, but "losing users" and "churn."

What we need to do isn't to simplify the technical problem, but to find the seam between technology and business goals, so the other party can "catch it."

Communicating with Designers: Don't Say "Code Isn't Reusable," Say "Users Will Be Confused"

For a while, I always felt the designers' styles were inconsistent. Every delivery came with a bunch of special states, edge treatments, and pixel-level tweaks.

I said component reuse was low, and they said it was for better aesthetics.

Later I changed my phrasing:

This button has inconsistent interaction logic across five pages: some show a popup on click, some navigate, some give no feedback. Users have to relearn it every time.

If we unify the interaction, we can encapsulate this component as a type in the UI library, reducing error rates and helping users remember the pattern.

Designers' language isn't function calls; it's "user habits, aesthetic consistency, brand atmosphere."

You need to show them that high reuse isn't about technical efficiency, but about lower user cost.

The Last Group: Our Own People

The most ironic thing is that sometimes the hardest people to communicate with aren't other roles, but ourselves.

Once in a cross-team collaboration, I assumed the other side would understand the document we sent. But before launch, I found they hadn't integrated the core API at all. Looking back, I had written:

Please submit the payload according to the config schema, refer to demo.md

The other side didn't understand the schema and had no idea what the payload looked like.

I rewrote it:

The JSON we expect looks like this:

{ "user_id": "string", "feature_enabled": true, "context": { "source": "web" } }

If you're using the default SDK, just pass user_id when calling sendEvent() and it will be wrapped automatically.

Then the other side got it instantly.

Don't overestimate engineers' reading comprehension, and don't underestimate the power of a concrete example.

What we think of as technical alignment is often just "jargon bumping into jargon."

Final Thoughts

Every role has its own worldview:

Executives look at risk and bets;
Product cares about experience and path choices;
Operations focuses on metrics and immediate feedback;
Designers pay attention to consistency and user cognition;
Engineers care about clear interfaces and integration costs.

We want to be understood not because we want to please anyone, but because: truly complex projects don't depend on whether the technology works, but whether the context works.

The more you can explain the same thing in the language of different roles, the more others will be willing to hand complex problems to you.

Because you're not the person who speaks the most correctly, but the one who can make things move.