Explaining Technical Work to Non-Specialists

By the end of this lesson, you will be able to...

• Adapt a technical explanation for a non-specialist decision without removing its causal mechanism.

• Preserve stakes, evidence strength, trade-off, and uncertainty while changing vocabulary and detail.

• Review an explanation for the useful middle ground between jargon and false simplicity.

Idea in one sentence: Explain the decision first, then keep the smallest causal model and boundary the reader needs to make a sound choice.

Core Insight

Rina leads customer operations. She is deciding whether to invite twenty new customers to use the import service next Monday. She does not need to configure a database connection pool. She does need an honest answer to three questions: what failed last week, what has changed, and what risk remains if the launch goes ahead.

The engineering update says:

Increasing worker concurrency from 8 to 16 saturated the database pool, reduced claim throughput, and increased queue_age_p95. We reverted to 8 pending representative load tests.

This is accurate. It is not yet a decision-ready explanation for Rina. Terms such as concurrency, claim throughput, and p95 are compact handles for people who already share the system model. Replacing them with “there was a database issue” would be worse. It removes the reason the launch carries a capacity risk.

The useful move is not to make technical work sound less technical. It is to preserve the part of the mechanism that changes the reader's decision, while leaving out implementation detail that does not.

Look First: What Must Survive the Rewrite?

Before changing a word, look for the load-bearing parts of the specialist explanation.

Everything else is optional until the reader asks for it. Rina does not need the name of a metric to understand that jobs waited in line. An engineer reading a runbook does need that metric. Audience adaptation changes the path into the idea; it does not change what is true.

Plain meaning:

Remove detail that does not change the reader's next decision. Keep the relationship that explains risk, cost, and action.

In Rina's situation:

“The queue got old” is too vague because it hides why the queue got old. “Every importer needed a database connection, and too many ran at once” is a small model she can use to judge the launch plan.

Technical name:

This is a decision-preserving adaptation. The writer changes vocabulary, order, and example while keeping the causal structure, evidence strength, and boundary needed for the reader's role.

The Small Model

The whole import system contains workers, queues, connection pools, retries, storage URLs, and customer files. Rina needs only this part:

more imports started at once
          -> more workers need the same database connections
          -> the shared pool becomes full
          -> some imports wait before they can continue
          -> customers see a longer queued status

The model does not say that every full connection pool causes every backlog. It shows the specific chain that the team observed and the control they changed: fewer simultaneous imports reduce immediate competition for the shared resource.

This is the minimum mechanism. Without it, Rina might hear “we lowered capacity” and reasonably ask why the team would choose a slower service. With it, she can see the trade-off: the lower cap gives the system more room to process each active import reliably, but it may take longer to process a busy day.

Check: Which sentence preserves the minimum mechanism for a non-specialist reader?

Think first, then reveal.

Answer: “When we started too many imports at once, they competed for a limited database resource and some waited in line.” It avoids unexplained metric names but still explains the causal relationship. “The database had a problem” names a component without explaining the decision-relevant failure.

From Specialist Note to Decision Brief

Start with the specialist note again:

Increasing worker concurrency from 8 to 16 saturated the database pool, reduced claim throughput, and increased queue_age_p95. We reverted to 8 pending representative load tests.

The first bad rewrite removes the mechanism:

We had a database issue. Engineering fixed it, so the launch should be fine.

This version is friendly but unsafe. It gives Rina neither a reason to trust the change nor a limit on the promise. It replaces evidence with reassurance.

The second bad rewrite keeps every technical word:

The deployment doubled import-worker concurrency, causing pool saturation above 90%, claim-rate collapse, and queue_age_p95 of 34 minutes; therefore, we have restored the former concurrency setting while assessing representative traffic distributions.

This version is more accurate than the first, but it asks Rina to translate the technical terms before she can decide. It leads with the implementation instead of the decision.

Here is the adapted version:

Decision needed: Confirm whether to invite twenty new customers next Monday.

What happened: Last week, starting twice as many imports at once made them compete for a limited database resource. Some new imports waited in line for up to 34 minutes.

What changed: We returned to the safer limit of eight simultaneous imports. The queue recovered after that change and after temporary database mitigation.

What this costs: At busy times, imports may complete more slowly than they did at the higher limit.

What remains uncertain: We have not yet tested the lower limit against the mix and volume expected from the new customers.

Recommendation: Do not invite the full group until the planned load test shows that new imports stay within the promised wait time. We can invite a small pilot group if support agrees to the slower processing limit.

The translation has an input, a causal transition, an intermediate state, a current output, and a decision. It does not use connection pool or p95, because Rina does not need those terms to understand the risk. It keeps the numbers that change the decision: twice as many imports and up to 34 minutes of waiting.

So far, the specialist and non-specialist versions share the same story. They differ in their entry point and vocabulary. The specialist version helps an engineer inspect the system. The decision brief helps Rina choose a launch plan without receiving a magical “fixed” stamp.

A Preservation Checklist

Use this checklist before sending a technical update to a product lead, customer-facing colleague, executive, or partner.

The checklist is not permission to write a longer summary. It is a way to remove jargon while protecting the reasoning the jargon compressed.

Check: A product lead asks, “Did we fix the incident?” Which response best preserves the boundary?

Think first, then reveal.

Answer: “We restored the setting that stopped the immediate backlog, and the queue recovered. We still need a load test before we know whether the service can safely handle the new customer volume.” This gives a real success signal and the remaining uncertainty. “Yes, it is fixed” converts a temporary recovery into an unsupported guarantee.

A Counterexample: Simplicity That Deletes the Decision

Consider this launch update:

Engineering is improving import performance. We recommend a short launch delay.

It is short, calm, and almost useless. It does not say what users experienced, why a delay helps, what has already changed, how long the team needs, or what evidence will end the delay. A reader cannot compare a small pilot with a full launch because the update has removed the decision model.

Revise it this way:

We recommend delaying the full launch because a recent increase in simultaneous imports made some files wait up to 34 minutes. We have restored the safer limit and will run a load test by Friday. A small pilot remains possible if the team accepts slower processing while we collect that evidence.

This is still brief. It has enough mechanism, evidence, trade-off, and next action to support a decision.

Trade-offs and Limits

Decision-preserving adaptation improves accessibility, trust, and cross-team action. The trade-off is compression: the writer must choose one small model and may leave out details that another reader later needs.

It does not make every technical choice understandable in one paragraph. It does not turn a non-specialist into the system owner. The boundary appears when the reader's decision depends on a detail the short explanation omitted, such as a contractual performance target, a security condition, or a legal constraint. Add that detail, link the supporting technical artifact, or invite the responsible specialist into the decision.

The useful signal is a reader question. If Rina asks “Why would more imports make all imports wait?” the causal model is missing. If she asks “Which database query was slow?” the brief may be correct but too technical for her job; offer the postmortem or engineer contact rather than expanding the main message into a debugging transcript.

Practice and Revision Pass

Choose a technical update you have written or invent one about a rollout, data migration, search result problem, or cost increase. Identify a non-specialist reader who must make one decision.

Write two versions:

1. A specialist note with the exact metric, mechanism, and operational control.
2. A decision brief of 120–180 words for the chosen reader.

Then annotate the brief with five labels: decision, causal model, evidence, trade-off, and uncertainty. Remove one technical term only if the remaining explanation still has all five labels.

A good revision should:

• begin with the reader's decision rather than the implementation;
• retain one causal chain that explains the user or business consequence;
• distinguish a measured result from a forecast or recommendation;
• name what the current control improves and what it costs; and
• point to the next evidence that could change the recommendation.

Resources

• [TUTORIAL] Google Technical Writing: Audience — Focus: Define role, knowledge proximity, task, vocabulary, and the “curse of knowledge” before adapting an explanation.
• [TUTORIAL] Google Technical Writing: Clear sentences — Focus: Replace generic verbs and missing actors with specific causal actions.
• [TUTORIAL] Google Technical Writing: Words — Focus: Choose plain, precise vocabulary without treating plain language as a loss of technical honesty.

Key Takeaways

• A non-specialist explanation must preserve the decision, stake, causal model, evidence, trade-off, and uncertainty.
• Removing jargon is useful only when the reader can still see why the recommendation follows from the observed condition.
• Lead with the reader's decision, then provide the smallest model that changes that decision.
• A short update should state what changed, what it costs, and what evidence is still needed.
• Link deeper technical material when it serves a different reader job instead of making every update carry a debugging transcript.