After explaining a system, revisit every 'obviously'…

When This Fires

• After onboarding a new team member by walking them through a system
• After explaining your architecture to someone from a different team or discipline
• After any teaching or knowledge-transfer session
• When reviewing a recording or transcript of yourself explaining something

Common Failure Mode

Treating "obviously" as a conversational filler rather than a diagnostic signal. You say it, the listener nods (because they don't want to reveal they don't understand), and the assumption remains undocumented. Weeks later, the newcomer builds something that violates the "obvious" constraint, and everyone is confused about how this happened — because the constraint was never written down.

The Protocol

After explaining a system to someone with zero context: (1) Recall or review each point where you said "obviously," "of course," "naturally," or "as you'd expect." (2) For each, write down the unstated assumption: what exactly is "obvious"? (3) Ask: is this assumption documented anywhere? If not, document it now. (4) Ask: is this assumption still valid? The act of explaining often reveals that what was "obvious" five years ago is no longer true.