Succession Planning¶
Succession planning is not about preparing for people to leave. It's about building organizational resilience, developing the next generation of leaders, and ensuring that critical knowledge and ownership don't disappear when someone changes roles, takes leave, or moves on.
Most engineering teams don't do succession planning until they need it—and by then it's too late. The senior engineer leaves with all the context. The manager goes on parental leave and no one knows how to run the team. The tech lead accepts an offer elsewhere and suddenly a critical system has no owner.
This page provides a practical approach to succession planning: identifying key-person risks, developing successors deliberately, and creating the organizational muscle to handle transitions gracefully.
The problem succession planning solves¶
Without succession planning:
- Key-person dependencies are invisible. You don't know where the risk is until someone leaves.
- Transitions become crises. Knowledge transfer happens in a frantic two-week notice period.
- Development is reactive. People get stretch opportunities only when there's a vacancy, not when they're ready.
- Leadership pipeline is empty. When you need a new tech lead or manager, there's no one ready.
- High performers plateau. Without visibility into next-level responsibilities, growth stalls.
Succession planning makes risk visible and manageable. It turns leadership development from an afterthought into a deliberate practice.
When to use this approach¶
Use succession planning when:
- You have roles or individuals that represent significant key-person risk.
- You want to develop future leaders before you need them.
- You're responsible for organizational continuity (any manager or director role).
- Someone in a critical role announces they're leaving or transitioning.
- You're preparing for a reorg or significant team change.
Succession planning should be an ongoing practice, not a one-time exercise. Review it quarterly or semi-annually.
When succession planning isn't enough¶
Succession planning addresses continuity and development. It doesn't solve:
- Immediate departures. If someone is leaving tomorrow, you're in crisis mode, not planning mode.
- Team-wide dysfunction. If the team has fundamental problems, finding a successor won't fix them.
- Lack of talent. If no one is ready or developable, you need to hire—succession planning won't create candidates from nothing.
- Systemic knowledge gaps. If critical knowledge isn't documented, succession planning will expose the gap but not fill it.
Roles and responsibilities¶
| Role | Responsibilities |
|---|---|
| Manager | Own succession planning for their direct reports and critical roles on their team. Identify risk, develop successors, maintain documentation. |
| Director/Skip-level | Ensure managers are doing succession planning. Review key-person risks across the organization. Sponsor high-potential individuals. |
| Individual contributors | Document their work. Cross-train peers. Develop skills that prepare them for larger roles. |
| HR/People team | Support the process with tools and frameworks. Track leadership pipeline. Facilitate transitions. |
Succession planning is a leadership responsibility at every level. If you manage people, you should know who could step into key roles if needed.
Core concepts¶
Key-person risk¶
Key-person risk exists when:
- Critical knowledge lives in one person's head.
- A system, process, or relationship depends on a single individual.
- Someone's departure would cause significant disruption.
This isn't about judging people—it's about understanding organizational vulnerability.
Successor readiness¶
Not everyone who could eventually fill a role is ready now. Distinguish between:
- Ready now. Could step in immediately with minimal ramp.
- Ready in 6–12 months. Has the foundation; needs specific development.
- Ready in 1–2 years. High potential; needs significant experience.
- Not a fit. May be excellent in current role but not suited for this particular succession path.
Development vs. replacement¶
Succession planning is not just about who replaces whom. It's about ensuring that:
- Knowledge is distributed, not concentrated.
- Future leaders are being developed.
- Career paths are visible.
- The organization can absorb transitions without crisis.
Process: building a succession plan¶
Step 1: Identify critical roles¶
Not every role needs a formal succession plan. Focus on:
- Single points of failure. If this person left, would something important break?
- Leadership roles. Manager, tech lead, staff engineer positions.
- Critical domain expertise. The person who understands the legacy system, the key integration, the complex regulatory area.
- Relationship owners. The person stakeholders trust, whose departure would damage a partnership.
For each critical role, document:
- What makes this role critical?
- What would happen if it were suddenly vacant?
- How much notice would you need to transition gracefully?
Step 2: Assess current state¶
For each critical role:
- Knowledge documentation. Is the knowledge written down or only in someone's head?
- Cross-training. Does anyone else understand the work?
- Potential successors. Who could step into this role, and what's their readiness?
Rate the risk:
| Risk level | Description |
|---|---|
| High | Single person holds critical knowledge; no one else could step in; minimal documentation |
| Medium | Some cross-training exists; one or two people could partially cover |
| Low | Multiple people could handle the role; knowledge is documented; transitions would be smooth |
Step 3: Identify potential successors¶
For high and medium risk roles, identify candidates:
- Who has the aptitude and interest?
- What's their current readiness?
- What development would close the gap?
It's okay if no one is ready now—that's useful information. It tells you to prioritize development or consider hiring.
Step 4: Create development plans¶
For each successor candidate, define:
- Gap analysis. What skills, experience, or exposure do they need?
- Development actions. Stretch assignments, shadowing, training, mentorship.
- Timeline. When could they realistically be ready?
- Success criteria. How will you know they're prepared?
Connect this to their Growth Plan.
Step 5: Review and update regularly¶
Succession planning isn't a document you write once. Review quarterly:
- Have risks changed?
- Has readiness improved?
- Do development plans need adjustment?
- Are there new critical roles or new candidates?
Reducing key-person risk¶
Beyond identifying successors, reduce risk through practices:
Documentation¶
Critical knowledge should be written down:
- System architecture and decisions (ADRs).
- Runbooks for operational tasks.
- Relationship context (who to contact, history with stakeholders).
- How-to guides for specialized processes.
If something exists only in someone's head, it's a liability.
Cross-training¶
Deliberately spread knowledge:
- Pair programming on critical systems.
- Rotations through ownership areas.
- Backup owners for key responsibilities.
- "No single points of failure" as a cultural value.
Distributed ownership¶
Avoid concentrating too much in one role:
- Split responsibilities when roles get too broad.
- Ensure teams have overlapping coverage.
- Make ownership explicit and visible.
Templates and artifacts¶
Succession planning template¶
# Succession Plan: [Team/Org]
**Last updated:** [Date]
**Owner:** [Manager name]
## Critical roles
| Role | Current holder | Risk level | Key-person concerns |
| ------------------- | -------------- | ---------- | ------------------------------------------- |
| [Tech Lead, Team X] | [Name] | High | Only person who knows [system] |
| [Staff Engineer] | [Name] | Medium | Deep domain expertise; partially documented |
| [EM, Team Y] | [Name] | Low | Peer managers could cover; strong bench |
## Successor map
| Critical role | Successor 1 | Readiness | Successor 2 | Readiness |
| ----------------- | ----------- | ------------ | ----------- | ------------ |
| Tech Lead, Team X | [Name A] | Ready 6-12mo | [Name B] | Ready 1-2yr |
| Staff Engineer | [Name C] | Ready now | — | — |
| EM, Team Y | [Name D] | Ready now | [Name E] | Ready 6-12mo |
## Development actions
### [Name A] → Tech Lead, Team X
**Gap:** Limited experience with [system]; hasn't led cross-team initiative.
**Actions:**
- Shadow current tech lead on [system] decisions (Q1)
- Lead upcoming cross-team initiative as primary owner (Q2)
- Complete leadership training (Q2)
**Success criteria:** Leads a significant technical decision independently; positive feedback from stakeholders.
### [Name C] → Staff Engineer
**Gap:** Minimal; already operating at level.
**Actions:**
- Ensure documentation is complete
- Introduce to key stakeholders
- Gradual transition of responsibilities
## Knowledge documentation status
| Area | Documentation | Owner | Action needed |
| --------------------------- | ------------- | ------ | ----------------------------- |
| [System X] | Partial | [Name] | Complete runbook by Q1 |
| [Stakeholder relationships] | None | [Name] | Document contacts and context |
| [Deployment process] | Complete | [Name] | Validate with peer review |
## Review schedule
- Quarterly review: [Next date]
- Annual deep review: [Date]
Key-person risk assessment¶
# Key-Person Risk: [Role/Person]
**Current holder:** [Name]
**Role:** [Title]
**Team:** [Team]
## Why this role is critical
[Explain what depends on this person]
## Current state
- **Knowledge documentation:** [Complete / Partial / Minimal / None]
- **Cross-training:** [Who else knows this? Level of depth?]
- **Backup coverage:** [Who could cover short-term? Gaps?]
## Risk assessment
**If this person left with 2 weeks notice:**
- [What would break?]
- [What would be disrupted?]
- [What would we lose permanently?]
**Risk level:** [High / Medium / Low]
## Mitigation actions
| Action | Owner | Timeline | Status |
| ------------------------------- | --------- | -------- | -------- |
| Document [area] | [Name] | [Date] | [Status] |
| Cross-train [person] on [skill] | [Name] | [Date] | [Status] |
| Identify successor | [Manager] | [Date] | [Status] |
Transition plan template (when someone is leaving)¶
# Transition Plan: [Name departing]
**Role:** [Title]
**Last day:** [Date]
**Successor:** [Name, if known]
## Knowledge transfer
| Area | Method | Recipient | Date | Status |
| --------------------- | ----------------------- | --------- | ------ | ------ |
| [System X] | Pairing session | [Name] | [Date] | ☐ |
| [Stakeholder context] | Document + handoff call | [Name] | [Date] | ☐ |
| [Ongoing projects] | Project handoff | [Name] | [Date] | ☐ |
## Documentation to complete
- [ ] [Document 1]
- [ ] [Document 2]
- [ ] Update runbooks
## Relationships to hand off
| Stakeholder | Context | Intro meeting | Notes |
| ----------- | ---------------------- | ------------- | ----- |
| [Name] | [Relationship context] | [Date] | |
## Open items
| Item | Status | Handoff to | Notes |
| -------------- | -------- | ---------- | ----- |
| [Project/task] | [Status] | [Name] | |
## Post-departure
- Questions contact: [Who can answer questions after departure?]
- Gap coverage: [Who covers until permanent solution?]
- Hiring plan: [If backfilling, timeline?]
```
---
## Signals that succession planning is working
| Signal | What it indicates |
| ------------------------------------- | ----------------------------------------------- |
| Departures don't cause crises | Knowledge is distributed; successors are ready |
| Leadership pipeline exists | Future leaders are being developed deliberately |
| Key-person risks are known | Assessment is happening; visibility exists |
| Development is tied to succession | Growth plans connect to organizational needs |
| Transitions are planned, not reactive | Succession is a continuous practice |
| Critical knowledge is documented | Risk mitigation is active |
---
## Failure modes and mitigations
| Failure mode | What it looks like | Mitigation |
| ----------------------- | ------------------------------------------------------------ | -------------------------------------------------------------- |
| **Invisible risk** | Key-person dependencies unknown until crisis | Regular succession reviews; document critical roles |
| **Development neglect** | Successors identified but not developed | Tie succession to growth plans; track development actions |
| **Documentation debt** | Knowledge lives in heads; no written record | Make documentation part of the role; review in one-on-ones |
| **Single successor** | Only one person could fill the role | Identify multiple candidates at different readiness levels |
| **Succession theater** | Plan exists but isn't reviewed or updated | Quarterly reviews; accountability in leadership meetings |
| **Comfort hoarding** | Current holder doesn't share knowledge to feel irreplaceable | Name the behavior; make knowledge sharing part of expectations |
---
## Equity in succession planning
Succession planning can either reinforce or disrupt existing patterns of opportunity. Watch for:
- **Who gets identified as high-potential?** Ensure you're not just recognizing people who look like current leaders.
- **Who gets development opportunities?** Track stretch assignments and ensure they're distributed equitably.
- **Who gets sponsored?** Advocacy for advancement should include underrepresented individuals.
- **Whose knowledge is valued?** Critical knowledge isn't just technical—relationship and cultural knowledge matter too.
See [Diversity in Leadership](diversity-in-leadership.md) for more on equitable development.
---
## Related pages
- [Growth Plans](growth-plans.md) — Development framework for potential successors
- [Coaching New Tech Leads](coaching-new-tech-leads.md) — Supporting transitions into leadership
- [Performance Management](performance-management.md) — Assessing readiness for advancement
- [Diversity in Leadership](diversity-in-leadership.md) — Ensuring equity in succession
- [Team Ops: Onboarding 30/60/90](../team-ops/onboarding-30-60-90.md) — Structure for transitions