Documentation that survives handoff
Good documentation is not a memory dump. It is a maintained interface between the person who knows the system and the person who needs to act on it later.
Documentation is most valuable at the moment someone else has to continue the work. That might be a teammate, a user, a future maintainer, or just future-me trying to remember why a decision made sense.
The useful pattern is simple: document the context, the decision, the steps, and the failure modes. Context explains why the process exists. The decision records what was chosen and what was rejected. The steps make the work repeatable. Failure modes tell the next person what to check when the happy path breaks.
I prefer lightweight docs because heavy systems decay. A short note that gets updated is better than a perfect template nobody wants to touch. The structure should reduce decision fatigue, not create another task to manage.
The best docs are written close to the work. If a ticket reveals a missing troubleshooting step, the doc should change while the context is still fresh. If onboarding exposes a confusing assumption, the instruction should be rewritten before the next person hits the same wall.
The goal is not to document everything. The goal is to make the next correct action easier to take.