All writing

Work & Career

Translated from the original Chinese essay · Read the Chinese original →

How many projects die not on technical difficulties, but on peer communication.

Everyone is busy. No one cares how urgent you are.

You ask for support, and they reply, "I'll take a look." You send a message, and two days later they respond with just "Got it."

It's not that we didn't express ourselves clearly. It's that we didn't hit the point they care about.

We often talk about cross-department collaboration, but the essence of collaboration is never "I need you to do something." It's "How do I lower the cost of you saying no."

In this article, let's talk about how to make your words land and get things moving in peer communication.


Doing the right thing doesn't mean others are willing to cooperate

—but we can shift the angle and make them feel this is worth doing too.

Once, our team was doing a platform overhaul and needed to integrate a data interface. The other side was the tech lead of another business unit. The moment he heard "interface overhaul," his face changed, and he said there was no room in the schedule.

I didn't say we urgently needed to launch, nor did I emphasize the OKRs set by the boss. I simply said:

"This interface will eventually connect to third-party data streams. We'll use your side as the validation standard. When we produce the test report, your stability metrics will stand out. Later, if this can be promoted as a platform case study, it'll also be a plus for your reporting."

The other person thought for two seconds and said, "Then package the test scripts too. I'll have someone take a look first."

This isn't persuasion. It's interest alignment. It's not throwing a requirement over the wall, but writing the other person's gains into it.

We call it "altruistic phrasing."

It doesn't mean you have to humble yourself to please others. It means you have to make clear: why this matters to them too. Only then can cross-department collaboration become the same side of the line.


A well-run meeting can save a project three weeks. A poorly run one only deepens misunderstandings.

Many people think the most important thing in communication is getting everyone in the room. But the real challenge is making people understand, speak to the point, and finally make a decision.

I've summarized three keywords:

Goal: Before every meeting, write one sentence stating the purpose. For example: "Today we decide only one thing: whether to start the canary release." This keeps everyone focused on whether we can begin, rather than drifting into launch methods or metric details.

Agenda: Assign each agenda item to a specific owner in advance, so the meeting is not a discussion but a decision-making session.

Outcome: Whether or not consensus is reached, write down the conclusion. Even if no decision is made, clarify "what information is still missing" and "who will follow up," rather than everyone leaving with no idea what the next step is.

Meetings are not about checking a box. They are a small closed loop of collaboration.


Not everything can be done in one shot, but we can start with a pilot, iterate quickly, and lower the barrier to collaboration.

Once, we wanted to automate a new process, but the other department was reluctant to cooperate. Asking directly didn't help, because they worried that once they cooperated, they'd have to take on long-term responsibility.

We changed our approach and said: "We won't change your existing process. We'll just run a parallel validation for one week. We'll handle the test data cleaning and write the report. You only need to provide an API access point."

Within a week, we produced a demo. Data quality improved by 50%. The other department came to us on their own and said, "We want to use this process too."

This is called the "minimum consensus loop": don't ask others to commit to the entire process all at once. Just ask them to take one step first. Once there are results, people will naturally follow.


When you hit resistance, the most important question is not how to persuade, but how to understand.

There's an old problem: integration testing delays affecting the launch schedule.

In our meeting, we didn't say "your side is too slow." Instead, we used nonviolent communication: "Our last three integration tests were delayed. Our team has been under a lot of pressure these two weeks. We'd like to get the test environment two days earlier. Could you confirm the schedule by this Friday?"

Structurally, this is: observation → feeling → need → request. It's not an emotional attack, but a factual, specific statement. This kind of phrasing isn't about pretending to be gentle. It's about keeping communication from being misunderstood or derailed by emotions.


Many people say, "I expressed myself clearly, but the other side still drags their feet." But collaboration is never a one-time expression. It's the accumulation of long-term trust.

Have you noticed? There are people who, when you reach out, are always willing to help. It's not because they're smooth talkers. It's because they respond quickly, spot problems early, proactively report, and never shift blame. These people, in others' minds, have collaborative credit.

This credit is an asset we build up every time we help someone.

Over time, when you have an urgent need, the other side is more likely to free up resources for you.

This is the strongest underlying capability in collaboration: being trusted.


Finally, let me share our team's "peer collaboration checklist":

  1. Before sending any request, first ask: What value does this have for the other person?

  2. Before every meeting, think clearly: What is the ideal outcome of this meeting? What is the unacceptable bottom line?

  3. When the other side hesitates, don't push. Instead, design an easier entry point (like a pilot or a small-step validation).

  4. If conflict arises, don't react emotionally. Quickly turn the issue into facts and requests.

  5. If you want to increase your influence, start by proactively supporting others. Build collaborative credit and become someone others see as reliable.


Cross-department collaboration is ultimately not a game of persuasion, but a joint construction of trust.

Next time you face a situation where the other side is stuck and not moving, try shifting your perspective: it's not that they're deliberately stalling. It's that we haven't yet found a way to make them willing to move.

May we all become the kind of person who can get things moving.