What exactly should I document before my lead developer or engineer quits?
Before a lead developer quits, document these five things: deployment procedures, architecture decisions and their rationale, access credentials and infrastructure ownership, active technical debt and known issues, and recurring operational tasks like on-call runbooks. Focus on knowledge that only they hold — the processes others can already do are lower priority.
What are the highest-priority items to document?
Rank by risk: what would cause the most damage if this knowledge disappeared tomorrow?
| Priority | What to Document | Why It's Critical |
|---|---|---|
| 1. Deployment & infrastructure | How to deploy, rollback, scale, and access production | Broken deployments halt the business |
| 2. Architecture decisions | Why systems are built this way, rejected alternatives | Prevents costly redesign of working systems |
| 3. Access & credentials | AWS accounts, API keys, admin panels, third-party services | Losing access means losing control |
| 4. Known issues & tech debt | Bugs, workarounds, fragile components, planned migrations | Prevents stepping on known landmines |
| 5. Recurring operations | Monitoring alerts, on-call procedures, maintenance tasks | Keeps systems running daily |
How do you capture this quickly during a notice period?
Don't ask the developer to write comprehensive documentation — there isn't time. Use a rapid capture approach:
- Record deployment and ops tasks — Have them perform each task while Glyde captures the workflow, generating step-by-step guides automatically
- Architecture Decision Records (ADRs) — For each major system, write a one-page document: what was decided, why, and what alternatives were considered
- Access audit — Walk through every service, credential, and admin panel together and transfer ownership
- "What breaks" interview — Spend 30 minutes asking: "What tends to go wrong? What would you check first?"
The last question is the most valuable. Experienced engineers carry a mental model of failure modes that never gets documented. Capture this explicitly — it saves the replacement months of discovery through painful incidents.
This answer is part of our guide to capturing and preserving team knowledge.