Lesson 2: Technical and Non-Technical Communication

1 Modelling context

A modelling project produces two audiences. The technical audience — analysts, modellers, review committees — needs the full detail of the model, its assumptions, its verification, its validation, and its limitations. This audience evaluates the work. The non-technical audience — decision-makers, stakeholders, executives — needs the bottom line: what the model says, what it does not say, and what the recommended action is. This audience uses the work.

The two audiences are not served by the same document. A technical report written for the analyst is unreadable to the decision-maker; an executive summary written for the decision-maker is inadequate for the analyst. Both are required, and neither substitutes for the other.

The two audiences serve different purposes

The technical report is the record. It must be complete enough that another analyst could reconstruct the work. The plain-language summary is the message. It must be clear enough that a decision-maker can act on it. The two documents share a source but serve different functions.

2 Learning objectives

By the end of this lesson you will be able to

Identify the two audiences of a modelling project and their distinct needs.
Structure a technical report so that it is complete and reviewable.
Write a plain-language executive summary that communicates the finding and the recommendation.
Translate technical uncertainty into terms a decision-maker can act on.
Write an accessible presentation suitable for a non-technical audience.
Avoid the common failure modes of technical and non-technical writing.

3 Prerequisite review

Technical report: A structured document written for a specialist audience. Complete, precise, and reviewable. Its purpose is to record and defend the work.
Executive summary: A short document (usually one page) written for a non-specialist audience. Its purpose is to communicate the finding and the recommendation.
Plain language: Writing that a general audience can read and understand on a first reading. Avoids jargon, defines technical terms when they must be used, and prioritises clarity over completeness.
Claim-support statement: A statement of what a model can and cannot be used to claim. Introduced in Module 1 and revisited throughout.

4 Structure of the report

The technical report

A complete technical report for a modelling project has the following structure. The order is not rigid; some sections may be merged or reordered, but every section should appear somewhere.

Sections of a technical report
Section	Content
Executive summary	One page: the question, the answer, the recommendation, the caveats
Purpose and question	The decision the model supports and the question it answers
System and boundary	What is inside the model and what is outside
Model formulation	Variables, parameters, units, assumptions, mathematical form
Data	Sources, treatment, calibration split
Implementation	Architecture, software, files delivered
Verification	Tests performed, results, acceptance criteria
Validation	Held-out data, metric, disconfirming evidence, result
Sensitivity and uncertainty	Sensitivity of the output to each input; output distribution
Results	Principal findings with confidence intervals or uncertainty ranges
Discussion and limitations	Interpretation, assumptions, robustness, what the model does not address
Recommendation	The recommended action, conditional on the model's assumptions
Claim-support statement	A precise statement of what the model can and cannot support
Appendix	Additional figures, code listings, technical derivations

The executive summary

The executive summary is a single page that answers five questions. It is not an abstract; it is a complete, self-contained communication.

What was the question? State the decision the model was built to support.
What was done? One or two sentences on the model and the study.
What was found? The principal result, with an indication of the uncertainty.
What is recommended? The action the model supports, conditional on its assumptions.
What are the caveats? The limitations a decision-maker should know about.

Figure 7.7. The two audiences of a modelling project. The technical report records and defends the work; the executive summary communicates the finding and the recommendation.

Writing about uncertainty

A common failure of non-technical communication is to suppress the uncertainty in order to sound confident. This is the wrong tradeoff. A decision-maker who is told a point estimate and later discovers a wide interval will lose trust in the analysis. A decision-maker who is told an interval and acts on it can incorporate risk into the decision.

Ways to communicate uncertainty in plain language:

"The most likely outcome is around X, but it could plausibly range between Y and Z."
"Under the assumptions in the model, there is roughly an N percent chance of [outcome]."
"The result is sensitive to [input]; if [input] turns out to be higher, the outcome would be closer to [value]."

Each of these is a plain-language translation of a technical result. None of them hides the uncertainty; each of them makes it actionable.

Accessibility in the presentation

A presentation to a non-technical audience should be designed for accessibility:

Large, high-contrast text. Readable from the back of a room.
Charts with plain-language labels. No unexplained axes, no acronyms without definitions.
Colour is not the only signal. Use shape and position as well.
Text descriptions of key charts. Provided verbally and in handouts.
One idea per slide. The message is the point.

5 Worked example

Executive summary for the emergency department study

Return to the emergency department study from Lesson 1. The study compared the current triage policy (A) with the proposed policy (B) across three arrival rates and two physician counts, using a full factorial design with 30 replications per treatment.

Technical findings.

Policy B reduces mean time from arrival to first treatment by 14.2% under the low arrival rate (95% CI: 11.8% – 16.6%).
Policy B reduces it by 18.7% under the medium rate (95% CI: 15.9% – 21.5%).
Policy B reduces it by 12.4% under the high rate (95% CI: 9.1% – 15.7%).
The effect is present under both physician counts, with a slightly larger reduction at 6 physicians (interaction: β = 2.1%, 95% CI: 0.3% – 3.9%).
The results are robust to a ±20% variation in the assumed service-time distribution.

Plain-language translation.

The proposed triage policy reduces the average time a patient waits before seeing a physician. The reduction is between 12% and 19% depending on how busy the department is, with the largest reduction when the department is moderately busy. The result holds whether the department has 4 or 6 physicians, and whether the department is quiet, moderately busy, or very busy.

Draft executive summary.

Question. Should the emergency department adopt the proposed triage policy in place of the current one?

Approach. We constructed a simulation model of the department, calibrated to two weeks of arrival and service data. We compared the two policies under three arrival rates and two staffing levels, with 30 replications per configuration.

Finding. Under the assumptions of the model, the proposed policy reduces the average wait from arrival to first treatment by between 12% and 19%, depending on how busy the department is. The reduction is statistically significant in every scenario tested.

Recommendation. Adopt the proposed policy. The estimated reduction is larger than the 10% threshold that motivated the study, and the result is consistent across all scenarios.

Caveats. The model assumes that service times and arrival patterns are well represented by the calibration data. If either changes substantially, the estimated reduction may differ. The model does not include patient outcomes beyond time to first treatment, and it does not account for the training cost of the new policy.

Why this works.

The summary is one page. It answers the five questions. It states the uncertainty (12% to 19%, not "about 15%"). It gives a recommendation conditional on the assumptions. It lists the caveats that a decision-maker needs. It does not include the technical detail — that is in the full report.

6 Verification check

Checks to perform on your communication

Does the executive summary answer the five questions? Question, approach, finding, recommendation, caveats.
Is the executive summary self-contained? A reader who sees only this document should understand the finding.
Is the uncertainty communicated? A point estimate without uncertainty is incomplete.
Is the recommendation conditional? It should be stated in terms of the model's assumptions, not as an absolute fact.
Are the technical terms defined? Any term that would not be familiar to a general audience should be defined on first use.
Can the technical report be reviewed independently? Another analyst should be able to verify the work using the report alone.
Is the presentation accessible? Large text, high contrast, plain-language labels, one idea per slide.

7 Interpretation

The two audiences of a modelling project have different needs, and the analyst's job is to serve both. The technical report is the record of the work; it protects the analyst if the work is later questioned, and it enables another analyst to build on it. The executive summary is the message; it enables the decision-maker to act on the work.

Three interpretive points:

The two documents are not versions of each other. They are different documents written for different purposes. A technical report with the executive summary tacked on is a technical report; an executive summary with technical appendix is an executive summary. Both are required, and they should be written to their respective purposes.
Uncertainty is a fact, not a weakness. Communicating uncertainty does not undermine the analysis. Suppressing it does.
Accessibility is a design choice. A presentation that is unreadable to a member of the audience fails its purpose, regardless of the quality of the underlying analysis.

The reader's question

Before writing any section of either document, ask: what is the question this section exists to answer, and who is asking it? The technical audience and the non-technical audience are asking different questions, and the writing should reflect the difference.

8 Uncertainty and limitations

Every communication carries a risk of misinterpretation. Two common risks deserve attention.

Risks of misinterpretation
Risk	Mitigation
The point estimate is treated as exact	Always report uncertainty intervals alongside the point estimate
The recommendation is applied outside the model's scope	State the claim-support scope explicitly in both documents
Technical content is read by a non-technical reader	Make the executive summary self-contained
Assumptions are hidden in technical appendices	Summarise the key assumptions in the executive summary

Plain language is not simplification

Writing for a non-technical audience does not mean omitting important content. It means translating the content into language the audience can act on. Uncertainty, assumptions, and caveats are all part of the message, not optional extras.

9 Common implementation errors

Watch for these

Writing only one document. A technical report without an executive summary is not usable by the decision-maker. An executive summary without a technical report is not reviewable by the analyst.
Burying the finding. The first paragraph of the executive summary should state the finding. Do not save it for the end.
Suppressing uncertainty. A point estimate without an interval invites overconfidence.
Using jargon in the executive summary. Terms like "homoscedastic," "autocorrelated," and "Lipschitz" do not belong in a non-technical document.
Not stating the claim-support scope. The reader needs to know under what conditions the recommendation applies.
Inaccessible presentations. Small fonts, low contrast, colour-only signals, and unattributed charts all fail parts of the audience.
Assuming the audience has read the other document. Each document should stand alone.

10 Independent modelling task

Your turn

Choose a modelling result you have produced — from a previous assignment, a project, or the capstone work in progress.
Write an executive summary for the result. One page, five questions, plain language.
Draft the outline of the technical report. List every section you would include and one sentence describing what goes in each.
Prepare a five-slide presentation for a non-technical audience. Each slide should be readable at a glance and should carry one idea.
Have someone unfamiliar with the work read the executive summary. Ask them to state the finding and the recommendation from memory. If they cannot, revise.
Have someone with a technical background review the report outline. Ask whether any section is missing.

This exercise forms the communication component of the capstone.

11 Reflection prompt

Reflect before continuing

A decision-maker asks for "just the number." What do you give them?

Two or three sentences. Consider the tradeoff between simplicity and honesty, and the risk that a point estimate without uncertainty will be over-trusted.

12 Lesson summary

Key takeaways

Two audiences require two documents. The technical report records and defends; the executive summary communicates the finding and the recommendation.
The executive summary answers five questions. Question, approach, finding, recommendation, caveats.
Uncertainty is part of the message. Communicating it honestly is more useful than suppressing it.
Plain language is translation, not simplification. The content is preserved; the language is changed.
Accessibility is a design choice. Presentations and figures should be usable by the full audience.

Coming next

Lesson 3 integrates the full modelling cycle into the capstone project, including the archive that makes the project reproducible.

§ Self-quiz, practice, and homework

Practice exercises

Rewrite the following sentence for a non-technical audience: "The 95% confidence interval for the treatment effect was 12.4% to 15.7%, with p < 0.001."
Given a technical result "mean reduction 14%, SD 5%, N = 30," write a one-sentence plain-language summary.
List the five questions an executive summary should answer. Draft one sentence for each based on a result you know.
For an inaccessible slide (small font, colour-only signals, dense text), list three specific changes you would make.

Homework problems

Executive summary. Take a modelling result you have produced and write a one-page executive summary that answers the five questions. Ensure that uncertainty is communicated in plain language and that the recommendation is conditional on the model's assumptions. 400–500 words.
Full technical report outline. Produce a detailed outline of a technical report for the same result, listing every section you would include and one sentence describing what goes in each. Justify the sections you include and any you omit.
Plain-language translation. Take three paragraphs from a technical report you have written or read and rewrite them in plain language for a non-technical audience. Preserve the content; change the language.

Mini project

Produce both documents for a modelling result: a technical report outline and a one-page executive summary, plus a five-slide presentation for a non-technical audience. Submit the three documents. This is the communication component of the capstone.