The senior engineer who doesn't document becomes a bottleneck. They hold context in their head — why the system is architected this way, what the trade-offs were, what the known issues are — and every time someone needs that context, they have to ask. The asking takes the senior engineer's time, it takes the asker's time, and it happens over and over because the same questions come back from different people. I've seen senior engineers whose calendar was 70% answering questions that could have been documented, and the documentation would have taken less total time than the repeated interruptions. The failure mode isn't laziness; it's a misunderstanding of what documentation is for. Documentation isn't about being helpful to others — it's about multiplying your own impact by making your knowledge available without your presence.

The shift in framing — from "documentation helps others" to "documentation scales me" — is what changed my relationship with writing things down. I stopped treating documentation as an act of generosity and started treating it as an investment in my own productivity, because every question I answer in writing is a question I don't have to answer again. The investment pays off quickly: a document that takes two hours to write and is read by ten people saves twenty hours of meeting time, and it saves the senior engineer the context-switching cost of being interrupted ten times. The math is unambiguous, and yet many senior engineers don't document because the payoff is delayed and the cost is immediate, which is the same cognitive bias that makes saving for retirement hard.

The most valuable documentation answers "why" questions, not "how" questions. "How" is usually answered by the code itself — read the function, follow the logic, understand the implementation. "Why" is almost never in the code: why was this architecture chosen over the alternatives, why does this function exist rather than being inlined, why is this dependency necessary. Those "why" answers are the context that lives in the senior engineer's head, and writing them down — in architecture decision records, in code comments on non-obvious decisions, in README files that explain the system's structure — is what prevents the context from being lost when the senior engineer moves on.

The other valuable documentation is onboarding material. A good onboarding guide — "here's how to set up the project, here's the architecture overview, here's where things live, here's who to ask about what" — reduces the time from a new hire's first day to their first merged PR from weeks to days. That reduction is measurable, and it compounds: a team that onboard efficiently grows faster than one that doesn't, because each new hire becomes productive sooner and can contribute to onboarding the next hire. The onboarding guide is the single highest-leverage document a team can write, and it's usually the one that's most out of date, because nobody owns updating it.

The reason documentation goes stale is that it's maintained separately from the code, and separate things drift apart. The solution is to collocate documentation with the code it documents — README files in the repository, architecture decision records in a `docs/` folder, code comments on the decisions they explain — and to treat documentation updates as part of the definition of done for any change that affects the documentation. If you change the architecture, you update the architecture doc in the same PR. If you add a new pattern, you update the patterns guide. Collocation and same-PR updates don't guarantee the documentation stays current, but they make it dramatically more likely than the "separate wiki that nobody updates" approach.

The other sustainability technique is to document in response to questions. When someone asks you a question about the system, the answer is documentation that should exist but doesn't. Instead of answering in a Slack message that gets lost, write the answer in a place where the next person with the same question can find it. That approach — "answer questions by writing documentation" — turns interruptions into documentation opportunities, and it ensures the documentation you write is the documentation people actually need, because it's grounded in real questions rather than speculative topics.