Process
Documentation that survives the next hire
Runbooks and ADRs only help if they live next to the code and get updated when behavior changes. We prefer short, current docs over stale encyclopedias.
Onboarding should answer: how do I run this, where do logs go, who owns which service? We keep those answers in the repo or internal wiki with owners, not in a slide deck from last year.
Architecture Decision Records capture the “why” when the context is fresh—future you will not remember the tradeoffs.
When docs drift, we treat that as a bug: either update the doc or delete misleading sections so newcomers are not misled.