Documentation debt is different from technical debt. Technical debt accumulates quietly and shows up in sprint velocity or deployment frequency. Documentation debt shows up at the worst time: when someone new joins, when you're unavailable, or when another team needs to run a procedure themselves at 5pm on a Friday.
The failure mode is almost always the same. A senior engineer writes a runbook. Every step is technically correct. The person following it gets stuck at step three because there's an implicit step zero that never made it onto the page. The author knew it so thoroughly that it stopped registering as a step at all.
In Azure, this happens most often with anything touching Entra ID, Microsoft's identity platform, the system that controls who can authenticate and what they're allowed to do. A runbook for deploying a new application might start at "create a service principal" without mentioning that you need specific permissions on the app registration first, or that conditional access policies in the tenant might block token acquisition during CI/CD if the pipeline's service account isn't correctly excluded. None of this is secret knowledge. It is what gets filtered out when you've run the procedure a hundred times.
The curse of knowledge
Once you know something well, it becomes nearly impossible to remember not knowing it. The information doesn't disappear, but stops feeling like information. It starts feeling like common sense. Every senior engineer has written documentation that seemed complete to them and was impenetrable to the next person who opened it.
The grandma rule
The fix: write your documentation as if your grandma has to follow it. The grandma rule works because it's impossible to misapply. "Write for your audience" leaves room to imagine an audience that already shares your context, knows your tools, and has worked in this environment before. The grandma framing doesn't leave that room.
What this looks like in practice, on a deployment runbook: every prerequisite listed at the top, not as a vague "you'll need X installed" but with the actual commands. Every environment variable named, with a note on where to find its value. Authentication steps written in full, including what to do if an MFA prompt appears or a session token has expired. The expected output after each command, so the reader can confirm the step succeeded before moving on.
This takes longer to write. It also means the runbook works when someone follows it without you next to them, at 5pm when you want to start your weekend, on a new machine, six months from now.
When documentation actually matters
Incident response procedures are followed under pressure, by someone who may not be the author and may be less experienced with the specific system. The time to discover a missing prerequisite is not during an outage.
Offboarding and handoff documentation is different again. When an engineer leaves, or when you hand a system to a client to run themselves, the documentation is the handoff. A document that only works when the author is in the room isn't a handoff. It's continued dependency.
Every gap in a documented procedure eventually becomes a support request or an interruption. Institutional knowledge that lives in one person's head is a business risk: if that person is unavailable, so is the knowledge. Documentation that new people can actually follow is operational resilience, the ability for things to keep running when the person who built them isn't around.
The grandma rule doesn't require a documentation framework. It requires the author to step outside their own expertise long enough to actually write the thing down.