Chapter 5 — Engineering communication
Lesson map
Lesson 05 published. Map, example, EX013.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Writing for engineers"]
N2["5.2 Writing for managers"]
N3["5.3 Presenting uncertainty"]
N4["5.4 Decision records"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX013"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Writing for engineers"]
N2["5.2 Writing for managers"]
N3["5.3 Presenting uncertainty"]
N4["5.4 Decision records"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX013"]
[Learning outcomes]
|
v
[5.1 Writing for engineers]
|
v
[5.2 Writing for managers]
|
v
[5.3 Presenting uncertainty]
|
v
[5.4 Decision records]
|
v
[Worked example] --> [Exercise EX013]
Learning outcomes
You will (1) write clear technical notes about data; (2) present data quality findings to non-specialists; (3) document decisions.
5.1 Writing for engineers
Kofi writes a technical note on the unit error from Chapter 3. Prof. Varga asks for a fixed structure: summary, background, method, findings, impact and recommendations. The summary states the problem and its consequence in two sentences: one district's readings were stored in litres, inflating its demand in the monthly report. Engineers reading the note can then decide quickly whether to read further. Clear structure makes notes easier to find and reuse when a similar problem appears years later. Notes are stored in a shared index.
5.2 Writing for managers
For Tidewater's operations manager, Kofi writes a one-page version without code or formulas. It explains what went wrong, which reports were affected, what has been fixed and what decision is needed: approval to add unit validation to every data feed. He includes one chart comparing reported and corrected demand. The manager approves the change the same day. Kofi learns that managers need the decision and its consequences, not the full technical journey that led to them. The chart uses plain axis labels.
5.3 Presenting uncertainty
When Kofi presents leakage estimates affected by sensor drift, he shows ranges rather than single numbers and explains in plain words why the range exists. Some managers prefer a single figure, so he gives a central estimate while keeping the range visible. Prof. Varga notes that hiding uncertainty can lead to poor decisions, while overwhelming people with technical detail can lead to no decision at all. The skill is to show enough uncertainty to be honest and useful. The range appears on every slide.
5.4 Decision records
Kofi starts a decision record for data governance decisions at Tidewater: the date, the decision, who made it, the options considered and the evidence. The first entry records the approval of unit validation. He explains that DAMA-DMBOK2 stresses documented policies and decisions, because organisations forget why rules exist. Months later, when someone asks why a feed is rejected for wrong units, the record answers the question without depending on anyone's memory. The record lives in the same repository as the validation code, so code and reasons stay together.
Worked example
Kofi writes a structured technical note, a one-page manager version that wins approval for unit validation, presents leakage as a range and starts a decision record.
Synthetic case. Notes are synthetic; DAMA-DMBOK2 is real.
Errors and limits
Short summaries can lose caveats; keep the main limitation visible.
Exercises
- EX013 — Note structure. What structure did Prof. Varga require? Rubric: 3 = summary, background, method, findings, impact, recommendations;; 2 = most;; 1 = few;; 0 = none.
- EX014 — Manager decision. What decision did the manager make? Rubric: 3 = approve unit validation for every feed;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX015 — Record contents. What does a decision record contain? Rubric: 3 = date, decision, maker, options, evidence;; 2 = most;; 1 = one;; 0 = none.
Continue studying — lesson 05 (chapter 05 of 50)
← Chapter 04 · Course chapter index · Chapter 06 →
Continue to the next authored lesson.