Communicate Technical Work to Any Audience

Proof required

Submit your audit: 4–5 real examples of your technical communication with three-criterion ratings (audience fit / context provision / actionability, each 1–5) and a one-sentence specific observation per criterion per piece. Append a 200-word diagnosis naming one recurring weakness with evidence from at least 3 pieces.

What gets checked

• 4–5 real examples from your own work — not sanitised or polished for the audit; representative of your actual output
• Ratings vary across pieces and across criteria — uniform scores indicate the rubric was not applied with real attention
• Diagnosis names a specific recurring failure (e.g. 'assume the reader already knows the context', 'explain implementation before purpose') not a generic category ('I am too technical')

Common mistakes

• Selecting only documentation that was well-received — the audit must include representative examples, not a best-of collection
• Applying the audience-fit criterion without identifying who the actual audience was at the time of writing — the criterion only makes sense relative to a specific audience
• Diagnosis that is identical to the M1 diagnosis of a 'Become a Better Writer' audit — the technical communication weakness is specifically about translating technical content for specific audiences, not general prose quality

Resources

What a verifier looks for

• Ask the submitter to identify the intended audience for each of the 4–5 pieces — the audience-fit rating is meaningless without knowing this
• Read one of the pieces without the submitter's annotation first and form your own rating — compare with theirs to calibrate
• Check that the diagnosis is specific to technical communication, not just general writing quality — the specific failure should involve the translation of technical content to a specific audience
• If all pieces are the same type (e.g. all code comments), ask why the other types of technical communication were not included — variety of type reveals breadth of the weakness

You'll sign in first, then come straight back here.

Proof required

Submit all 3 explanations of the same topic (minimum 300 words each) plus a 300-word process document: what changed between the expert / business / 14-year-old versions, which structural choice (analogy / example / problem-first) you used for each and why, and what the hardest translation decision was.

What gets checked

• All 3 explanations address the same technical topic and are complete and self-contained — a fragment or outline does not qualify
• Each explanation uses a genuinely different structure (analogy-led, example-first, problem-first) — not the same structure with different vocabulary
• Process document is specific about what changed between versions and why — not just 'I simplified the language'

Common mistakes

• Writing 3 versions that differ only in vocabulary rather than in structure and emphasis — the 14-year-old explanation should use a completely different explanatory strategy, not just simpler words
• Choosing a topic so abstract that a 14-year-old explanation is impossible — pick a topic with a concrete real-world analogue
• Process document that is vague ('I made it simpler for each audience') rather than identifying specific decisions (e.g. 'I moved the outcome before the mechanism for the business version because stakeholders need the why before the what')

Resources

What a verifier looks for

• Read all 3 explanations without the process document first — the differences in structure should be apparent before being explained
• Ask the submitter to explain a different technical concept on the spot in 60 seconds for a non-specialist — this tests whether the three-way skill has transferred beyond the specific topic prepared
• Confirm the 3 explanations use genuinely different structures, not just different vocabulary — ask the submitter to name the structural choice for each and where the switch happens
• The 14-year-old version is the hardest marker — if it uses jargon the 14-year-old would not know, the audience analysis has not landed

You'll sign in first, then come straight back here.

Proof required

Submit the written version of your technical explanation (used during or as the basis for the presentation) plus the reviewer's written assessment: every moment they noted confusion during the explanation, the terms they did not understand, the questions they asked with your responses, and the reviewer's sign-off confirming they are non-technical in your domain and that the session was live.

What gets checked

• Reviewer is genuinely non-technical in your field — a junior colleague in the same technical discipline does not qualify
• Reviewer assessment names specific moments of confusion and specific terms that were unclear — generic assessment ('it was mostly clear') is not sufficient
• The full Q&A record is included — not a summary; the actual questions and your live responses

Common mistakes

• Choosing a reviewer who is too close to your field (a technical colleague from a related discipline) — the non-technical requirement is strict
• A reviewer who says 'it was all clear, no questions' — a genuinely non-technical reviewer should always have questions; a question-free session suggests an over-prepared reviewer who agreed not to challenge
• A written explanation submitted for review without a live component — the questions from a live audience are different from questions after reading alone; both the written artifact and the live session are required

Resources

What a verifier looks for

• Confirm the reviewer is genuinely non-technical in the submitter's specific domain — a software developer explaining machine learning to a product manager counts; explaining it to another software engineer does not
• Count the number of questions in the Q&A record — fewer than 5 questions from a non-technical reviewer suggests they were too polite to challenge or were over-briefed
• Ask the submitter what they would change about the explanation now that they have seen what confused the reviewer — this tests learning from the session
• A reviewer who only asks factual comprehension questions ('what does X mean?') is easier to satisfy than one who asks conceptual challenge questions ('but why would you do it this way?') — note which type appears in the Q&A record

You'll sign in first, then come straight back here.