Startup Knowledge Transfer When Someone Leaves
In a small startup, one person often carries a whole function in their head: the billing quirks, the investor who prefers calls to email, the reason a setting is switched off. When that person leaves, all of it can walk out the door with them. This guide shows you how to run a calm, structured knowledge transfer in the weeks you have, so the team keeps moving and the person leaving goes with goodwill on both sides.
Key takeaways
- Start the handover the day you learn someone is leaving, not in their final week.
- Map what they know in four buckets: responsibilities, relationships, systems and access, and unwritten context.
- Pair the leaver with a named successor and record short working sessions, not just documents.
- Finish with an access review and a follow-up check a few weeks later to catch gaps.
People leave startups for all kinds of reasons: a new opportunity, a move, a career change or a role that no longer fits. However it happens, the risk is the same. Early teams rarely have deep documentation, so a lot of how things really work lives in one person's memory and inbox.
Midsummer adds its own twist. With holidays in July and August, the person taking over may be away for part of the notice period, and so might the people who need to sign things off. Plan around the calendar early so the handover does not depend on someone who is on a beach.
A quick note: notice periods, garden leave, final pay and what you can ask of a departing employee depend on their contract and on employment law where they work. This guide is general information, not legal or HR advice, so check the contract and speak to a qualified professional where needed.
Start the handover on day one
The moment you know someone is leaving, the clock starts. Even a notice period of several weeks disappears quickly once you subtract holidays, final projects and goodbyes. Make knowledge transfer a named project with an owner, usually the leaver's manager or a founder.
- Agree the last working day and availability. Confirm dates in writing and check for planned time off.
- Name a successor for each area. If you are not replacing the role yet, split it between two or three people and say so clearly.
- Ask the leaver to draft a knowledge map. Give them the template below and a few days to fill it in.
- Schedule handover sessions. Book short, focused sessions in the calendar now, before the diary fills up.
- Plan the access review. List every tool and account they use so nothing is forgotten on the last day.
- Book a follow-up. Put a check-in two to four weeks after they leave on the successor's calendar to review what is still unclear.
Pro tip
Frame the handover as a chance for the leaver to protect the work they built. Most people care about what happens to their projects, and being asked to pass them on well feels like respect, not a chore.
Map what they know
Knowledge is more than a list of tasks. Ask the leaver to work through four buckets, so you capture both the obvious and the invisible.
1. Responsibilities
Every recurring task, with how often it happens and where it is done. Think daily checks, weekly reports, monthly invoicing runs, quarterly filings and annual renewals. Ask them to scroll back through their calendar for the past year to spot the rare ones.
2. Relationships
Customers, suppliers, partners, investors, advisers and contractors they deal with. For each one, note what the relationship is, how they like to communicate and any open promises or sensitive history.
3. Systems and access
Every tool, account, password vault entry, domain, admin role and API key they control. Include personal accounts that were used for work, such as a social profile that manages your business page.
4. Unwritten context
This is the bucket people forget. Why was a decision made? Which workaround is holding something together? Which customer always pays late but always pays? Ask open questions like "What would surprise your replacement in their first month?"
Common mistake
Relying on a single long document written in the last week. It will be rushed, incomplete and hard to read. Spread the work over the notice period and mix written notes with live sessions and recordings.
A knowledge transfer template
Copy this table into a shared doc or your knowledge base. One row per responsibility, relationship or system. The entries below are made-up examples for an imaginary operations lead.
| Item | Type | How often | Where it lives | Hidden context | Successor | Handover status |
|---|---|---|---|---|---|---|
| Monthly customer invoicing run | Responsibility | Monthly, first working day | Accounting tool, invoicing checklist | Two clients need purchase order numbers on every invoice | Finance lead | Shadowed once, doing next run solo |
| Main packaging supplier | Relationship | Orders every 6 weeks | Shared inbox, supplier folder | Prefers phone calls; agreed a price review in the autumn (example) | Founder | Intro call booked |
| Domain and DNS settings | System and access | Annual renewal | Domain registrar, password vault | Email deliverability records were changed last spring | CTO | Admin role transferred |
Use the status column as a simple tracker. "Not started," "Documented," "Shadowed," "Done solo" and "Signed off" work well, and they make it obvious where the gaps are with a week to go.
Run handover sessions that stick
Documents tell people what to do. Sessions show them how. The best handovers combine both.
- Keep sessions short. Thirty to sixty minutes on one topic is easier to absorb than a full afternoon.
- Let the successor drive. In the second session on any task, the successor does the work while the leaver watches and comments.
- Record where appropriate. A screen recording of someone walking through a process is often clearer than a written guide. Tell everyone it is being recorded and store it with access controls.
- Make warm introductions. For key relationships, send a joint email or book a joint call so the contact meets the successor while the leaver is still there.
- Write questions down. The successor should keep a running list of questions and get them answered before the last day.
Where to store it all
Put the knowledge map, recordings and notes somewhere the whole team can find them later. A knowledge base tool such as Notion, Confluence, Slite or Guru works well, but a well-organized shared drive folder is fine for a very small team. Check current features, pricing and privacy policies before you choose a tool, and keep sensitive items such as passwords in a proper password manager rather than in a page anyone can read.
Hypothetical example
Imagine Amara, cofounder of a small online homeware brand, whose operations manager gives notice in early July. Amara asks him to fill in the knowledge map in his first week of notice, then books eight one-hour sessions spread across the next three weeks. Each session ends with the successor repeating the task alone. In the last week, they run a full access review and introduce the successor to the three most important suppliers on video calls. A month later, a quick check-in surfaces just two small gaps, both fixed in an afternoon. (Amara and her business are made up for illustration.)
Secure access and accounts
Knowledge transfer and offboarding overlap here. The goal is to make sure nothing important is locked inside one person's login, and that access ends cleanly.
- Transfer ownership first. Move ownership of shared files, folders, social pages, ad accounts and admin roles to a company account or the successor before removing access.
- Rotate shared credentials. Change any shared passwords and API keys the leaver knew.
- Forward or monitor email. Decide how their inbox will be handled after they leave, in line with your policies and local privacy rules, and set an auto-reply that points people to the right contact.
- Collect equipment. Agree how laptops, phones and security keys will be returned.
- Remove access on the last day. Work through the systems list from the knowledge map and tick each one off.
Pro tip
Use this departure to fix single points of failure for good. For every critical system, make sure at least two people have admin access and that ownership sits with a company account, not an individual.
Make the next handover easier
The best time to prepare for someone leaving is long before anyone does. A few habits make future handovers much lighter.
- Keep a living "how we do things" page for each role, updated whenever a process changes. (If you already have formal SOPs, link them from the knowledge map rather than rewriting them.)
- Rotate small responsibilities so at least two people can do each important task.
- Record decisions with a line or two of reasoning in the place the team looks for them.
- Review admin access every quarter.
- Hold a short exit conversation and ask what was hardest to hand over. That tells you where to document next.
Common mistake
Treating a departure as a failure to hide. When the team does not know who now owns what, customers and colleagues get mixed messages. Announce the change, share the new owners and keep communication warm and professional.
Your knowledge transfer checklist
- Confirm the last working day and any planned time off
- Name a successor for every area of responsibility
- Ask the leaver to fill in the knowledge map template
- Book short handover sessions across the notice period
- Make warm introductions to key contacts
- Store notes and recordings in a shared, access-controlled place
- Transfer ownership of accounts, then remove access on the last day
- Announce the new owners to the team and key contacts
- Schedule a follow-up check two to four weeks later
Frequently asked questions
What if someone leaves with very little notice?
Prioritize ruthlessly. Focus on access and ownership transfers first, then the few tasks that would cause real harm if missed, such as payroll steps, customer deadlines or renewals. Record quick walkthroughs of those, and capture the rest from emails, calendars and files afterward.
Can I contact a former employee with questions after they leave?
Many people are happy to answer a few questions, especially if they left on good terms. Keep it brief and respectful of their time. If you expect to need ongoing help, consider agreeing a short paid consulting arrangement, and check any contractual points with a professional.
Who should own the knowledge transfer?
Usually the leaver's manager or a founder. The leaver does much of the work, but someone who is staying must own the plan, check progress and make sure every item has a successor.
Should a departing cofounder follow the same process?
Yes, and often more carefully, because cofounders hold investor, legal and banking relationships as well as daily work. Equity, board seats and legal documents add extra steps, so involve your lawyer and accountant early.
Related reading
The bottom line
When someone leaves a startup, their knowledge does not have to leave with them. Start on day one, map responsibilities, relationships, systems and hidden context, pair them with a successor and secure every account before the last day.
Copy the template into your knowledge base today, even if nobody is leaving. The next time someone hands in their notice, you will already have half the handover done.
