Technical Communication
Design docs, READMEs, runbooks, and being understood by people who aren't you.
5 topics
Writing a design doc
A design doc exists to get disagreement out early and cheaply, so it leads with the problem and the options you rejected, not the solution you like.
core25 minDocumentation that survives
Split docs by what the reader is trying to do, keep them next to the code, and delete anything you can't keep true.
core20 minRunbooks & operational docs
A runbook is written for a tired person at 3am who didn't build the system — so it lists commands to run, not concepts to understand.
core18 minAsync updates & visibility
Write updates that let someone decide something without asking you a follow-up question — status, risk, and what you need, in that order.
core18 minCommunicating with non-engineers
Translate technical facts into consequences the listener already cares about — cost, risk, timing, user impact — and give options instead of verdicts.
core18 min