Your engineering team writes Architecture Decision Records. RFC documents. Postmortems. Technical design docs.
They sit in a wiki. Nobody reads them unless forced by a PR review. Six months later, a new engineer makes the exact mistake the ADR was designed to prevent.
#The Institutional Knowledge Problem
Technical documentation exists for institutional memory. But institutional memory requires CONSUMPTION, not just STORAGE.
- ADRs: Decision + context + consequences. Average: 1-2 pages. Read by: the author and maybe 2 reviewers.
- Postmortems: What went wrong, why, and how to prevent it. Average: 3-5 pages. Read by: people in the incident. Not by the team that’ll cause the next one.
- RFCs: Proposed changes with trade-offs. Average: 5-20 pages. Read by: invested parties. Not by the broader team who needs context.
#Engineering Docs as Audio
Save ADRs, postmortems, and RFCs to a team audiclip station. The daily podcast discusses each one.
Two hosts walk through the document:
- “The team decided to use Postgres instead of DynamoDB. Here’s why.”
- “Last Tuesday’s outage was caused by [X]. The second host asks: How do we prevent this in our service?”
- “The RFC proposes changing the auth flow. Here’s the trade-off the team is evaluating.”
#Why This Changes Engineering Culture
- New hires absorb institutional knowledge during onboarding — by listening to past ADRs and postmortems
- Cross-team awareness — the platform team hears about product team decisions, and vice versa
- Postmortems actually prevent recurrence — because the whole team heard about the incident, not just the people in the war room
- RFCs get broader input — engineers who wouldn’t read a 15-page doc DO listen to a 10-minute podcast about it
#Keep Reading
The best engineering decisions are informed by past decisions. Make them hearable.
Create your station →