Most founders can describe their business in detail and still fail one simple question: if your most experienced operator gave notice tomorrow morning, what exactly would leave with them?
The Founder's Offboarding Test answers that in an afternoon. You pick one person who has been with you at least six months. You imagine their resignation on your desk. Then you write down everything that walks out the door with them — the context, the client relationships, the undocumented process, and the exceptions everyone on the team "just knows." The output is not a personality assessment. It is a map of where your organization's intelligence is stored in people instead of architecture.
Key takeaways
- The Founder's Offboarding Test asks you to pick one person with at least six months of tenure and inventory every piece of knowledge that would leave with them.
- Run the inventory in four columns: context, relationships, undocumented process, and "just known" exceptions — then apply the osmosis question to each item.
- Sort every item into one of three fixes: a self-serve context source, a written standard, or an encoded decision right.
- Knowledge that exists only because someone sits near you and absorbs it is not organizational property — it is individual leverage, and you will pay to re-hire it twice.
Why this test beats a process audit
A process audit asks, "What do we do?" That question produces a document nobody reads, because the people who already know the answer have no reason to open it.
The Offboarding Test asks a sharper question: "What would we lose?" Loss is specific. It names the client who only takes calls from one account manager. It names the pricing exception that has never been written down. It names the judgment call your operations lead makes in the gap between what the SOP says and what actually works.
That specificity is what makes the test useful. You are not cataloguing your business. You are cataloguing your exposure.
How to run the Founder's Offboarding Test
- Choose one person. Six months of tenure minimum. Do not pick your weakest performer — pick the person whose absence would genuinely cost you. The test only has value if the answer makes you uncomfortable.
- Open four columns. Label them Context, Relationships, Process, and Exceptions. Give yourself thirty uninterrupted minutes and fill them without editing yourself.
- Apply the osmosis question. For every item, ask: does this exist because it is written down somewhere, or because this person sits near me and absorbs it? Anything in the second category is a dependency you have not yet noticed.
- Sort each item into a fix. Every entry becomes a self-serve context source, a written standard, or an encoded decision right. There is no fourth option, and "they'll just handle it" is not a fix.
- Assign one item per week. Convert the inventory into a sequence, not a project. Each week, one at-risk item stops depending on a single person.
The three-way sort
Self-serve context source
Some knowledge does not need to be a rule. It needs to be findable. Client history, past decisions and the reasoning behind them, the story of why a particular workflow exists — this belongs in a place the team can query without interrupting you. When context is self-serve, a new hire stops needing a mentor to narrate the company to them.
Written standard
If a process cannot run for three days without the person who owns it, it is not a process yet. It is a habit. A written standard captures the steps, the inputs, the outputs, and the definition of done — short enough to be used, specific enough to be followed by someone who was not in the room when it was invented.
Encoded decision right
This is the category founders skip, and it is the one that matters most. Decision rights answer who is allowed to act without escalation: what a person can approve, where their authority ends, and what triggers a conversation with you. Without encoded decision rights, written standards become decoration — the team knows the steps but still waits for permission.
| What the test surfaced | Which fix it needs | Why it works |
|---|---|---|
| Context trapped in someone's head — client history, past decisions, reasoning | Self-serve context source | Removes the need to interrupt a person to reconstruct the story |
| A workflow nobody else can run end to end | Written standard | Makes the process repeatable by someone who was not in the room |
| Decisions that stall the moment that person is away | Encoded decision right | Defines authority in advance so work does not wait for approval |
| Exceptions everyone "just knows" | Written standard plus an explicit rule | Turns silent tribal judgment into a visible, reviewable policy |
The common mistake: documenting the visible work only
The visible work is the easy part. It is the deliverables, the handoffs, the calendar.
The expensive knowledge is invisible. It is the exception the account manager grants because they know this client will churn otherwise. It is the informal queue your operations lead keeps in their head so nothing gets dropped. It is the instinct about which supplier to call when the primary one stalls.
Most founders document the visible layer and then wonder why the organization still collapses into their calendar every time someone is out. The Offboarding Test forces the invisible layer into the light, item by item, before a resignation letter does it for you.
An illustrative example
Picture a services business where one account lead holds the relationship with the firm's longest-standing client. The handoff notes exist, but they describe deliverables. They do not describe the client's decision cycle, the two internal champions who need to agree before anything is signed, or the pricing exception granted years ago that nobody has revisited.
Walk that through the test and three fixes fall out. The decision cycle becomes a self-serve context source so anyone can prepare a renewal. The exception becomes a written standard with an explicit rule and a review date. The approval threshold for that account becomes an encoded decision right, so the account lead can act without routing every concession through the founder.
None of those fixes required hiring. They required writing down what was already known and deciding where it should live instead.
Converting the inventory inside the 14-day trial
EXIUSS Intelligence is built for exactly this conversion. The 14-day free trial gives you the guided discovery journey, the founder frameworks, and a working Workspace — funnels, CRM, and pipeline tools — so each at-risk knowledge item moves from someone's head into something your organization owns.
You run the Offboarding Test as discovery. The intelligence surfaces the patterns behind your dependencies and blind spots. Then you build: a self-serve context source in the Workspace, a written standard attached to the workflow it governs, an encoded decision right recorded where the team can see it. Everything you build in the trial carries over when you upgrade — no rebuilding, no restart. The paid tier unlocks real-time conversation with the system, so you can interrogate your own architecture out loud instead of hunting through notes.
Fourteen days is enough to convert one person's knowledge into organizational property. That is the whole test: stop paying to re-hire the same expertise twice.
Quick checklist
- Pick one person with at least six months of tenure and imagine their resignation lands tomorrow.
- Fill four columns: context, relationships, undocumented process, exceptions.
- Run the osmosis question on every item and mark anything absorbed only by proximity.
- Sort each item into a self-serve context source, a written standard, or an encoded decision right.
- Schedule one conversion per week and give each one an owner.
- Start the EXIUSS free trial and build the first three conversions in the Workspace.