Milestone map
Milestone map
3 milestones
Audit Your Current Technical Explanations
1–2 weeks (2–3 hrs)
Gather 4–5 examples of technical communication you have produced in the last 12 months: code comments, technical documentation, design documents, architecture decisions (ADRs), technical emails, Slack messages to non-technical colleagues, or verbal explanations you can reconstruct. For each, assess three criteria: audience fit (is it pitched at the right level of technical knowledge?), context provision (does the reader know WHY before the HOW?), and actionability (is it clear what the reader should do or understand next?). Write a 200-word diagnosis naming your single most consistent weakness.
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')
Resources
Foundationstart here
Depthgo deeper
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
- 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
Explain One Complex Topic 3 Ways
4–6 weeks (3–4 hrs total)
Choose a technical topic you understand well but that non-specialists struggle to grasp. Produce 3 distinct explanations of the same topic, each targeted at a different audience: (a) a colleague in your field who is not an expert in this specific area, (b) a manager or business stakeholder with no technical background, (c) a 14-year-old with no domain knowledge. Each explanation must be complete and self-contained (not a fragment) and use a different structure — analogy-led, example-first, or problem-first. Separately, document your process: what changed between versions and why.
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'
Resources
Foundationstart here
Depthgo deeper
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
- 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')
Present a Technical Topic to a Non-Technical Reviewer
1–2 weeks (1 hr session + brief prep)
Present a technical topic of your choosing to a qualified reviewer who is non-technical in your field (e.g. a senior business leader, an HR director, a journalist, or a colleague from a different discipline). The reviewer's role is to ask every question that occurs to them during and after your explanation and to note every moment they felt lost, every assumption they did not share, and every term they did not understand. The session should last 30 minutes: 15 minutes explanation, 15 minutes unfiltered Q&A.
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
Resources
Foundationstart here
Depthgo deeper
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
- 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