The Knowledge that walks out the door

Why continuity depends on systems, not just what gets written down

I think of a program director I've worked with, one of several over the years who fit this same pattern. She'd led her department well for a long stretch, long enough that the work had become second nature to her. When I asked her to walk me through how a particular initiative actually operated day to day, she talked for nearly two hours without notes. She knew which funder wanted a narrative report versus a data table. She knew which community partner needed a phone call instead of an email. She knew the informal workaround for a data system that had never quite worked the way it was supposed to. None of it was written down anywhere. All of it lived in her, built up through years of paying close attention and quietly solving problems as they came up.

The instinct here is to say the fix is documentation, that she simply should have written it all down. I don't think that's quite right, and it's actually a trap worth naming early in this series. An organization that responds to this problem by trying to document everything often ends up with a different version of the same issue: a binder or a shared drive so dense with notes that nobody can find the one thing they actually need in the moment they need it. More written down is not the same as more accessible. What that program director actually had wasn't missing paperwork. It was knowledge that had never been built into the way her department operated, so that anyone stepping into her role would simply do the work the right way by default, rather than needing her, or a manual about her, to get there.

Systems, Not Just Notes

This is worth sitting with for a moment, because it really changes what leaders should be building. The goal isn't a written record of what one person knows. The goal is a set of systems, policies, and workflows sturdy enough that the knowledge is embedded in how the work gets done, not dependent on someone explaining it or someone else reading about it after the fact. A well-designed intake process, for example, carries its own logic. Whoever runs it follows the same steps regardless of who they are, because the process itself directs them. A clear approval workflow means a new hire doesn't need to ask around to find out who signs off on what. The knowledge isn't sitting in a document waiting to be consulted. It's built into the structure of the work itself.

The Real Question Isn't Whether People Leave

It is when, and what happens the day after. Every organization already knows, at some level, that people leave. What fewer organizations have really reckoned with is how much of what they rely on to function lives only in the minds of specific people rather than in the systems those people operate within. I have walked into interim engagements where the outgoing leader could tell me exactly which grant renewal needed to be submitted weeks early to avoid a lapse in funding, exactly how a particular funder liked to be approached, and exactly which monthly report required a manual workaround before the format matched what the board expected to see. All useful. All completely inaccessible to anyone else, because none of it had ever been built into a process that could carry it forward.

What This Actually Looks Like in Practice

Building this kind of infrastructure isn't about producing more written material. It's about making standard work actually standard, so that the right way to do something is simply the default, not a judgment call left to whoever happens to be in the role. In practice, this looks like a few concrete commitments:

•      Workflows designed so the correct sequence of steps is the only easy path, rather than relying on someone remembering the informal workaround that makes a broken system function

•      Policies that are actually followed, not just written, so that decisions get made the same way regardless of who is making them

•      Technology and systems configured to carry institutional logic, such as automated routing or approval chains, rather than leaving that logic sitting in one person's head

•      Cross-training built into ongoing practice, not a one-time handoff, so that more than one person actually does the work regularly and would notice immediately if something changed

•      Project management tools used for recurring annual processes, like budget creation or the annual audit, so that timelines, responsibilities, and lessons learned are captured in the tool itself rather than in one person's memory of how last year went. These tools no longer require certification or specialized training to use well, which makes them one of the more accessible ways to build this kind of continuity into a team's regular practice

Documentation still has a place here, but as a support to these systems, not a substitute for them. A short, current reference for how a workflow operates is useful. A comprehensive archive of everything anyone has ever known is not, because nobody has time to read it when they actually need it.

This Belongs to Everyone, Not Just Leadership

To be honest, this work does not belong only to the executive director or the CEO. It belongs to every department head, every program manager, every person who holds knowledge that would leave a gap if they left tomorrow. In fact, this is often where the most valuable work happens, not at the top of the org chart but in the middle of it, where the actual day-to-day systems get built and maintained. If you are a program director, a finance manager, an operations lead, this is your work to own as much as it is your executive's. The workflows and processes in your own department are very likely the systems most worth strengthening, because they're the ones you understand well enough to build properly.

This is also, not coincidentally, connected to the leadership playbook I've written about in Transitioning Forward. When I build a playbook for an outgoing interim client, the most useful version of that playbook isn't a summary of what one person knew. It's a map of the systems the organization actually runs on, so the next leader inherits a functioning structure, not just a set of notes about how things used to be done. The organizations that make this easiest for me are the ones where the systems were already doing the work, long before I arrived to write anything down.

Knowledge that lives only in a person's head, or only in a document about that person's head, is knowledge your organization doesn't actually possess. It's knowledge you're borrowing, for as long as that person happens to stay, or for as long as someone remembers to go looking for the notes.