What Does It Really Mean to Speak Plainly? How Technical People Can Translate What They Say

That day, when the other person said, "So you're saying we have to wait for you to finish this before we can go live?" I was momentarily speechless.

I had just spent ten minutes explaining the dependency chain between services, data integrity checks, and monitoring fallback plans. In the end, the product manager on the other side only latched onto "wait for me."

It wasn't that I was long-winded or wrong. But no one could follow. I could even sense that the other person was getting more irritated as I spoke.

This wasn't the first time I'd encountered this.

The more complex and important the occasion, the more I wanted to "explain clearly." Yet the result was always being misunderstood, interrupted, or even ignored.

I later realized this wasn't just a problem of expression. From start to finish, I had been speaking in the "technical person's context" while expecting others to understand in the "business person's context."

In other words, what I said was correct, but I wasn't speaking "plainly."

We often interpret "speaking plainly" as "speaking more simply," but the real world isn't that simple.

Not all technical content can be compressed into a single sentence like "this API is down." And not all non-technical colleagues only want to hear the bottom line.

The real question is: have we translated our expression so that it makes sense in the other person's context?

Here's an example.

Once, during a system launch, I raised a risk point: "This ETL logic doesn't have an idempotent mechanism. With the current scheduling approach, duplicate processing is likely."

The other person shot back, "So will it blow up when we go live?"

I froze for a second, then replied, "It won't blow up, but data might be duplicated. It depends on the volume."

A few days after the meeting, sure enough, problems occurred. The other person asked me, "Didn't you say it wouldn't blow up?"

That's when I realized: it wasn't that he didn't understand "idempotent." He simply had no way to judge whether this was something that had to be solved right now.

From his perspective, what he wanted to know was:

Will this affect users?
Is the consequence a one-time thing, or something we'll have to fix every day?
How long will it take to fix now, and what's the cost of not fixing it?

In other words, in his context, the focus wasn't on the logical mechanism, but on "impact + options + outcome."

If I had phrased it differently, like:

This logic currently has no duplicate prevention mechanism, which could lead to larger data volumes and duplicate writes. Fixing it now would take about three days. If we don't fix it, every future run will require manual intervention and cleanup, which will block the launch.

He probably would have nodded immediately.

Speaking plainly isn't pandering; it's translation.

We're not giving up on expressing technical details. We're making sure those details are received.

Now, whenever I prepare to communicate with non-technical roles, I first ask myself three questions:

What level is the other person concerned about regarding this point? (Risk, decision, impact...)
Is there any prerequisite knowledge they might not have? (Terminology, context)
If I were in their position, how would I judge whether this information is worth paying attention to?

These three questions help me quickly shift contexts, so that what I say is not just correct, but useful.

There's another little trick I often use, called "keyword substitution."

When I catch myself using words like "call chain," "transactional consistency," or "performance bottleneck," I pause and try to replace them with language closer to the scenario:

"The call chain is too long" → "When something goes wrong at this step, it's hard to trace the root cause"
"Transactional consistency" → "There could be a situation where money is deducted on one side but the goods aren't shipped on the other"
"Performance bottleneck" → "Users will be stuck on the submit page for a few seconds and might think the system crashed"

These substitutions don't weaken my professionalism. On the contrary, they make me look more in command of the big picture.

Because if you can explain complex things in a way the business understands, it shows you truly understand the essence.

Going further, sometimes communication stalls not because you're unclear, but because everyone hasn't aligned on the goal.

The most typical situation I've encountered is: I'm explaining that "technically, this approach is safer," while the other person is thinking, "Will this feature's launch date be delayed again?"

At that point, even if I explain the details perfectly, the other person will only think I'm making excuses.

Later, I learned a method for adjusting the order of communication, called "align on the goal first, then give options."

For example, I'll start by saying:

We can launch on time, but there are two options: one is faster but riskier, the other is slower but more stable. I lean toward the latter because...

This way of expressing puts the other person's top concern (launch time) up front, while also preserving my stance on technical quality.

Sometimes expression isn't about saying the right thing, but about saying things in the right order.

Many people think speaking plainly means "using fewer technical terms."

But I now increasingly believe:

True expressive power is the ability to switch freely between multiple contexts.

You can talk to technical people about mechanisms, architecture, and tradeoffs. You can also talk to non-technical people about risks, choices, and consequences.

You can not only get things done and done well, but also take others into account—not by forcing them to follow your pace, but by first making yourself understood and heard.

When you speak up, others are willing to listen and follow, not because you're loud, but because your words have direction, results, and judgment.

Finally, let's leave a question for ourselves:

The next time we need to present a technical solution, can we try asking:

Is this sentence, for the other person, information or noise?

If it's noise, how can we turn it into a signal?

We don't lack content to express. We're just too used to speaking on our own channel and forgetting to tune the frequency.