Succession planning guide

Succession planning isn't just for when someone leaves. It's for building a project that can grow beyond any individual contributor, including you.

This guide helps you plan for three types of transitions:

Planned departures - Someone stepping back with notice and handoff time
Unexpected absences - Sudden illness, burnout, or life changes with little warning
Gradual transitions - Shifting from active leadership to advisory roles over time

The timelines and checklists here work whatever you run. For the parts specific to your setting, read alongside your overlay: open source, charities and NGOs, companies, small teams.

Why succession planning matters

Most open source projects fail not because the technology is bad, but because key people leave and nobody knows how to continue. Succession planning is how you prevent that.

Good succession planning means:

Your project survives leadership changes
Contributors can take breaks without guilt
New leaders can step up with confidence
The project isn't held hostage by any individual

The three types of succession

Technical succession

Transferring knowledge, access, and capability to maintain and develop the technology.

Governance succession

Transferring decision-making authority and the responsibility for project direction.

Community succession

Transferring relationships, trust, and the ability to nurture contributors.

Most succession planning focuses only on technical handoff. All three are essential.

Planning for expected transitions

When someone plans to step back, you have time to do it properly. Use it.

90 days before departure

Knowledge transfer

Document the context behind major decisions
Create a 'knowledge map' of what this person knows
Identify critical knowledge that lives only in their head
Schedule time for them to brain-dump with successors

Access transfer

Audit what access and credentials they hold
Transfer admin rights and permissions to successors
Ensure password manager access is shared
Update account ownership for services and domains

Relationship mapping

List key external relationships (sponsors, partners, collaborators)
Introduce successors to important contacts
Document the context and history of these relationships
Plan how to announce the transition to external parties

Governance clarity

Document what decisions this person currently makes
Clarify who will make those decisions going forward
Update governance documents with new structure
Communicate changes to the community

60 days before departure

Shadow period

Successors shadow the departing person on their regular tasks
Departing person reviews how successors handle responsibilities
Practice decision-making with the departing person as backup
Test access and processes to ensure everything works

Documentation sprint

Write down processes for recurring tasks
Document the 'why' behind technical and governance decisions
Create runbooks for common scenarios
Record video walkthroughs of complex processes

Community preparation

Draft announcement of the transition
Prepare community for the change
Introduce successors in community spaces
Explain what will stay the same and what might change

30 days before departure

Final handoff

Complete all outstanding tasks or hand them off explicitly
Transfer any remaining access or credentials
Final review of documentation with successors
Ensure successors have everything they need

Communication

Announce the transition to the community
Thank the departing person publicly for their contributions
Introduce successors and their new roles
Clarify how community members should adapt to the change

Ongoing relationship

Discuss what the departing person's future involvement will be
Set boundaries about when/how to contact them with questions
Create an advisory role if appropriate
Plan for knowledge gaps that emerge after they leave

After departure

Check-in points

1 week: How are successors coping? What's broken?
1 month: What knowledge gaps have emerged?
3 months: What processes need adjusting?
6 months: What did we learn for next time?

Continuous improvement

Document what worked and what didn't
Update succession plan based on lessons learnt
Identify new bus factor vulnerabilities that emerged
Start planning for the next transition (there's always a next one)

Planning for unexpected transitions

When someone disappears suddenly - illness, burnout, personal crisis, death - you don't have time for a graceful handoff. You need emergency protocols.

Immediate response (first 24 hours)

Verify the situation

Confirm this is a real emergency, not just someone on holiday
Contact designated emergency contacts if appropriate
Decide who has authority to activate succession plans
Determine if this is temporary or permanent

Stabilise operations

Activate emergency access protocols (password manager, accounts)
Ensure critical systems keep running (deployments, monitoring)
Identify what absolutely must be handled immediately
Assign emergency responsibilities to available people

Internal communication

Inform core team/leadership of the situation
Be clear about what you know and what you do not
Assign someone to coordinate the response
Set up check-ins for the team

External communication

Decide what to tell the community (balance transparency with privacy)
Post a brief, factual announcement
Set expectations about response times and project continuity
Identify a single point of contact for questions

First week

Assessment

What critical knowledge or access did we lose?
What tasks can't be completed without this person?
Who can pick up which responsibilities?
What can wait and what can't?

Temporary assignments

Distribute immediate responsibilities among available people
These don't have to be permanent - just cover the gap
Document what you're doing as you figure it out
Accept that things will be messy for a while

Documentation recovery

Search emails, chat logs, issue trackers for context
Reach out to people who worked closely with the departed person
Reconstruct knowledge that wasn't written down
Document what you're learning as you go

First month

Permanent structure

Decide on longer-term ownership of responsibilities
Update governance documents to reflect new reality
Communicate new structure to the community
Acknowledge what you've lost while showing continuity

Knowledge gaps

Identify what you still don't know how to do
Prioritise learning based on urgency
Decide what to rebuild vs abandon
Accept that some context is permanently lost

Emotional processing

Give the team space to grieve or process the loss
Acknowledge the difficulty of the transition
Celebrate the departed person's contributions
Support people taking on unexpected new responsibilities

Long-term recovery

Rebuild resilience

Distribute the responsibilities that were concentrated in one person
Document what you learned about your vulnerabilities
Update emergency protocols based on this experience
Ensure this doesn't happen again with the new structure

Moving forward

At some point, the project needs to move beyond the crisis
New leadership needs permission to make different decisions
The community needs to adjust to new normal
Document this experience to help the next project that faces it

Gradual transition planning

The healthiest transitions happen gradually - someone shifts from active leadership to advisory over time.

Phase 1: Preparation (6-12 months)

Identify successors

Look for people who show interest and capability
They don't have to be just like you - different strengths are valuable
Discuss with potential successors whether they're interested
Be plain about the responsibility and the time commitment

Start delegating

Hand off small, contained responsibilities first
Let successors make real decisions, even if you'd decide differently
Provide backup without micromanaging
Gradually increase complexity and importance of delegated work

Build public visibility

Have successors represent the project at events
Let them write announcements and blog posts
Introduce them in leadership contexts
Build their reputation and authority in the community

Phase 2: Transition (3-6 months)

Shift decision-making

Stop being the first person consulted on decisions
Redirect questions to successors
Let them make mistakes and learn from them
Support them publicly even when you disagree privately

Change your role

Announce that you're transitioning to advisory/emeritus role
Be explicit about what you will and won't be doing
Set boundaries on your availability
Give successors permission to ignore your advice

Knowledge transfer

Focus on context and 'why' not just 'how'
Share the messy history, not just the official version
Introduce successors to your external relationships
Document things you think everyone knows but probably don't

Phase 3: Advisory (ongoing)

Be available, not involved

Respond when asked, don't volunteer opinions
Provide context and history when requested
Support successors' decisions publicly
Resist the urge to take back control

Let them lead

The project will change without you - that's healthy
New leaders need freedom to make different choices
Your way isn't the only right way
Trust that you chose good successors

Know when to leave entirely

At some point, your presence may hold back the project
New leaders need space to establish their own authority
It's okay to step away completely
Your legacy is a healthy project that survives without you

Succession planning templates

Technical handoff checklist

Technical area: (e.g., deployment pipeline) Current owner: (name) Successor: (name)
Target date: (date)

Access and credentials:

Service: _____ Login: _____ 2FA: _____ Transferred: Y/N
Service: _____ Login: _____ 2FA: _____ Transferred: Y/N
Service: _____ Login: _____ 2FA: _____ Transferred: Y/N

Knowledge to transfer:

Topic: _____ Documented: Y/N Shadowing complete: Y/N
Topic: _____ Documented: Y/N Shadowing complete: Y/N
Topic: _____ Documented: Y/N Shadowing complete: Y/N

Relationships:

Contact: _____ Role: _____ Introduced: Y/N
Contact: _____ Role: _____ Introduced: Y/N
Contact: _____ Role: _____ Introduced: Y/N

Success criteria:
Successor can (specific capability) without assistance

Handoff complete: [ ] Yes [ ] No
Verified by: ___ **Date:** ___

Governance handoff checklist

Governance area: (e.g., project roadmap decisions)
Current leader: (name)
Successor: (name) Target date: (date)

Decision-making authority:

Decision type: _____ Authority transferred: Y/N
Decision type: _____ Authority transferred: Y/N
Decision type: _____ Authority transferred: Y/N

Processes to document:

Process: _____ Documented: Y/N Practised: Y/N
Process: _____ Documented: Y/N Practised: Y/N
Process: _____ Documented: Y/N Practised: Y/N

Relationships:

Stakeholder: _____ Context shared: Y/N Introduced: Y/N
Stakeholder: _____ Context shared: Y/N Introduced: Y/N
Stakeholder: _____ Context shared: Y/N Introduced: Y/N

Governance updates:

Update governance docs to reflect new structure
Announce change to community
Update website/documentation with new leadership

Success criteria:
Successor can make (type of decision) with confidence

Handoff complete: [ ] Yes [ ] No
Verified by: ___ **Date:** ___

Community handoff checklist

Community area: (e.g., contributor onboarding)
Current leader: (name) Successor: (name) Target date: (date)

Key relationships:

Person: _____ Context: _____ Introduced: Y/N
Person: _____ Context: _____ Introduced: Y/N
Person: _____ Context: _____ Introduced: Y/N

Ongoing situations:

Situation: _____ Background: _____ Discussed: Y/N
Situation: _____ Background: _____ Discussed: Y/N
Situation: _____ Background: _____ Discussed: Y/N

Community knowledge:

Topic: _____ Documented: Y/N Discussed: Y/N
Topic: _____ Documented: Y/N Discussed: Y/N
Topic: _____ Documented: Y/N Discussed: Y/N

Communication channels:

Channel: _____ Admin access: Y/N Norms explained: Y/N
Channel: _____ Admin access: Y/N Norms explained: Y/N
Channel: _____ Admin access: Y/N Norms explained: Y/N

Success criteria:
Successor can (community capability) with confidence

Handoff complete: [ ] Yes [ ] No
Verified by: ___ **Date:** ___

Common succession planning mistakes

Mistake 1: Waiting until someone announces they're leaving

Succession planning should happen when things are stable, not during a crisis.

Better approach: Build succession into your normal operations. Rotate responsibilities. Cross-train continuously.

Mistake 2: Only planning for technical handoff

The hardest parts of succession are governance and community, not technical.

Better approach: Plan explicitly for transferring decision-making authority and relationships.

Mistake 3: Assuming documentation is enough

Documentation helps, but it can't replace shadowing, practice, and relationship building.

Better approach: Combine documentation with hands-on transfer of knowledge and relationships.

Mistake 4: Not letting go

The outgoing person hovers, second-guesses, and undermines the new leadership.

Better approach: Set clear boundaries. Step back fully. Let successors make different choices.

Mistake 5: Picking someone exactly like the current leader

Diversity in leadership styles and perspectives makes projects more resilient.

Better approach: Look for people with complementary strengths, not identical ones.

Mistake 6: Making it a surprise

Sudden announcement of new leadership creates uncertainty and resistance.

Better approach: Signal transitions early. Introduce new leaders gradually. Give the community time to adjust.

Mistake 7: Treating it as a one-time event

Succession planning is continuous. There's always a next transition.

Better approach: Build succession into project culture. Make it normal, not exceptional.

Questions for reflection

When was the last time you talked about succession planning with your team?
Who would take over your responsibilities if you stepped back tomorrow?
What knowledge lives only in your head that should be shared?
Are you holding on to control that should be distributed?
What would make it easier for you to step back when the time comes?

Using this guide

Start small:

Pick one area where you're the single point of failure
Identify one person who could take it over
Spend one month deliberately transferring that responsibility
Document what worked and what was hard
Repeat with the next area

Succession planning is about building something that can grow beyond you. Let it.

Good succession planning means the project barely notices when you're gone. That's the goal.