When something falls apart during a transition, we tend to blame the change.
The employee resigned. The funding ended. The program grew too quickly. Leadership changed. A major partner walked away.
And suddenly, things that seemed to be working aren’t working anymore.
It is easy to look at the disruption and say, “This change created a mess.”
But sometimes change did not create the problem.
It exposed it.
The process was already too dependent on one person. The budget was already too dependent on one funder. The program was already operating without enough capacity. The information was already living in someone’s head instead of in an organizational system.
Everything looked fine because someone, somewhere, was quietly holding it together. Then something changed. And suddenly everyone could see the cracks.
The Resignation Wasn’t Really the Problem
I’ve seen versions of this happen more times than I can count.
A key employee leaves an organization.
They aren’t necessarily the CEO or even a senior leader. They’re simply someone who has been there long enough to know how everything works.
Then they give notice.
At first, leadership treats it like a staffing issue. We need to post the position. We need to redistribute responsibilities. We need to hire someone.
Then the questions start.
When is that report due?
“I think she had it on her calendar.”
Who is the contact at the foundation?
“She always handled that.”
Where are the files from last year’s application?
“Maybe in her email?”
How do we pull the numbers for the quarterly report?
“She usually did that.”
What did we promise the funder we would measure?
“She would know.”
Who has the password?
And there it is.
The organization did not just lose an employee. It lost part of its operating system.
Deadlines lived in one person’s calendar. Funder relationships lived in one person’s inbox. Reporting procedures were mostly in one person’s head. Historical knowledge had never been written down because the person who knew it was always there.
Until they weren’t.
The resignation looked like the crisis.
It wasn’t.
The real problem was that the organization had built a critical function around a person instead of a repeatable system.
The resignation simply exposed it.
People Are Not Systems
Good employees compensate for bad systems all the time.
That can make organizational weaknesses surprisingly difficult to see.
A great program director remembers every deadline. An experienced development person knows every funder’s history. The finance director has created a spreadsheet that makes sense only to them. The executive director has relationships with every major donor. The office manager knows which vendor to call, where every document lives, and how to fix the database when something goes wrong.
Things get done.
So leadership assumes the system works, but there may not actually be a system.
There may be a capable person compensating for the absence of one.
That distinction matters.
Your people should bring knowledge, judgment, creativity, relationships, and experience to their jobs.
But your organization should own its essential processes.
Use Change as a Diagnostic
Change is uncomfortable, but it gives leaders information.
When something breaks, don’t only ask: “How do we fix this?”
Ask: “Why was this able to break?”
That second question takes you from crisis management to capacity building.
The immediate problem still matters. You need to get the report submitted. You need someone to run the program. You need to communicate with the donor.
Handle the urgent issue.
Then go back.
Look at what the disruption revealed.
That is where your Change Exposure Audit begins.
Tool #1: Complete a Change Exposure Audit
You can use this after a resignation, leadership transition, funding loss, rapid growth, program expansion, major partnership change, or any other disruption.
Start with six questions.
1. What stopped working when the change occurred?
Be specific.
Don’t write, “Development became difficult.”
Write:
“We missed two grant reporting deadlines.”
“We couldn’t locate the complete history for three foundation relationships.”
“No one knew how the monthly donor report was generated.”
Specific problems are easier to solve than general frustrations.
2. Who or what had been holding it together?
This question can be uncomfortable.
You may discover that the system was working because someone was doing far more than their job description suggested.
Maybe an employee had created personal reminders. Maybe the executive director was reviewing every single decision. Maybe a board member had become responsible for something that should have belonged to staff. Maybe people were regularly working nights to keep up.
Don’t confuse extraordinary effort with organizational capacity.
3. Was there a documented process?
Could someone find instructions for completing the task?
Not, “Sarah knows how.”
Not, “We’ve always done it this way.”
Not, “Just ask John.”
Is there an actual process?
It doesn’t need to be a 40-page manual.
Sometimes a one-page checklist is enough.
But it needs to exist somewhere other than someone’s memory.
4. Could someone else reasonably step in?
Imagine the person responsible for a critical function is unexpectedly unavailable tomorrow.
Could another employee find what they need and keep the basic function moving?
They may not do it as quickly, they may need help, and they won’t have the same experience.
That’s normal.
The question is whether the organization could continue operating.
If the answer is no, you’ve identified a vulnerability.
5. What knowledge exists only in someone’s head?
This is institutional knowledge, and nonprofits lose an incredible amount of it during transitions.
Why did you stop applying to a particular foundation?
Why does one partner require a different reporting process?
Why was a program designed this way?
What happened the last time the organization tried that fundraising strategy?
The answer may never appear in a policy or procedure.
But someone knows the history.
Capture it.
6. Where are we dependent on one person, funder, partner, or system?
Don’t limit this exercise to employees.
Ask what would happen if your largest grant disappeared.
What if your primary referral partner stopped referring participants?
What if the software containing essential records went down?
What if the board member responsible for your annual event resigned?
What if your executive director couldn’t work for three months?
Dependency creates risk.
You cannot eliminate every risk.
You can identify it before it becomes a crisis.
Tool #2: Create a Simple Risk Map
Take a piece of paper or open a spreadsheet.
Create four columns:
| Critical Function | What Are We Dependent On? | What Happens If It Disappears? | Backup |
| Grant reporting | Development director | Deadlines may be missed | None |
| Major donor relationships | Executive director | Relationships may weaken | Board chair knows some donors |
| Program referrals | One partner | Enrollment drops | Two potential partners identified |
| Financial reporting | Finance manager | Reports delayed | CPA has partial access |
You don’t need a complicated risk-management system to start.
Look for the word “none.”
Those are good places to begin. Then look for functions where the backup technically exists but isn’t strong enough to actually work.
Your goal isn’t to make every employee interchangeable.
It is to make the organization less fragile.
Tool #3: Build an Institutional Knowledge Checklist
Start documenting the information your organization cannot afford to lose.
At minimum, capture:
- Recurring responsibilities
- Key deadlines
- Funder and partner contacts
- Reporting requirements
- Password and system access
- File locations
- Current projects
- Standard procedures
- Historical decisions and why they were made
Assign responsibility for keeping each area current.
This matters.
A procedure manual created three years ago and never updated is not much better than having no procedure manual.
Documentation needs an owner. It also needs to be stored somewhere people can actually find it.
Don’t build a beautiful organizational knowledge system that only two people know exists.
Tool #4: Start With Your Most Critical Processes
The idea of documenting everything can become overwhelming quickly.
So don’t.
Start with the things that would create the biggest problem if the person responsible disappeared tomorrow.
Ask each staff member: “What are the five things you do that someone else would struggle to figure out if you weren’t here?”
That’s your starting list.
For each one, document:
- Who owns it?
- How often does it happen?
- What triggers it?
- What are the steps?
- What files or systems are needed?
- Who else is involved?
- What deadlines matter?
- What can go wrong?
- Who is the backup?
You don’t need perfect documentation.
You need usable documentation.
Tool #5: Do a KEEP, CHANGE, STOP Review
Once you’ve identified what the transition exposed, resist the temptation to rebuild everything exactly as it was.
The old system may not deserve to be recreated.
Use three categories.
KEEP
What is working and should be protected?
Maybe a communication process works well.
Maybe staff adapted during the transition and created a better way of doing something.
Maybe a partnership proved especially valuable.
Don’t change things simply because you’re in a period of change.
Protect what works.
CHANGE
What still matters but needs a stronger system?
The function may be essential, but the way you’ve been handling it isn’t sustainable.
Maybe funder relationships need to move into a shared CRM instead of individual inboxes.
Maybe reporting deadlines need to live on an organizational calendar.
Maybe two people need access to critical systems.
Maybe responsibilities need to be redistributed.
Keep the purpose.
Strengthen the process.
STOP
What no longer creates enough value to justify the resources it requires?
This is the category organizations often avoid.
A transition can be an excellent time to stop doing things that have continued mostly because nobody questioned them.
A meeting. A report. A program. A committee. A process with six approval steps. A fundraising activity that takes enormous staff time and raises very little money.
Don’t rebuild something simply because it existed before the disruption.
Ask whether it still deserves to exist.
Tool #6: Watch for Funding Dependency Too
People aren’t the only source of organizational fragility.
Revenue can create the same problem.
An organization may look financially healthy while 60 or 70 percent of a program depends on one grant.
Everything works beautifully.
Until the grant doesn’t renew.
The funding loss gets blamed for the crisis.
But the vulnerability existed long before the rejection email arrived.
Review your revenue by source.
Ask:
- How much of our total budget depends on our largest funder?
- What percentage of each program depends on one source?
- Which grants are restricted?
- Which revenue streams are predictable?
- What happens if our top three funders don’t renew?
- What are we doing now to diversify?
You don’t need to panic because you have a large funder.
You need to understand the risk and plan accordingly.
Hope is not a diversification strategy.
Tool #7: Ask What People Are Quietly Compensating For
This may be one of the most valuable conversations you have with your team.
Ask: “What process is harder than it should be?”
Then listen.
You may hear:
“I keep my own spreadsheet because the database isn’t accurate.”
“I remind everyone personally because the calendar doesn’t work.”
“I usually fix that before anyone notices.”
“I’ve been doing that because nobody else knows how.”
“We created a workaround a few years ago.”
Pay attention to workarounds. They often point directly to weak systems.
A workaround can be useful temporarily, but when they become permanent, organizations start depending on individual effort instead of organizational infrastructure.
Don’t Waste a Good Disruption
Change is rarely convenient.
Losing a good employee hurts. Losing funding creates real consequences. Leadership transitions are difficult. Growth can strain teams. Programs can outgrow the systems that once supported them.
The point isn’t to pretend those things are positive.
The point is to use the information they give you.
Once you’ve stabilized the immediate problem, look backward.
What did this expose?
Then look forward.
What needs to be different so the same vulnerability doesn’t create another crisis?
Maybe you need better documentation. Maybe you need cross-training. Maybe you need revenue diversification. Maybe responsibilities are concentrated too heavily in one role. Maybe your technology isn’t supporting your growth. Maybe your board needs to understand more about organizational operations. Maybe you’ve simply outgrown the way you’ve always done things.
Now you know.
Do something with that information.
The Bigger Leadership Lesson
Strong organizations are not organizations where nothing ever goes wrong.
People leave. Funding changes. Programs evolve. Technology fails. Leadership turns over. Communities change.
You cannot prevent every disruption.
What you can build is an organization capable of adapting when disruption happens.
That requires systems strong enough to support your people without becoming entirely dependent on them.
It requires documentation. It requires redundancy in critical areas. It requires leaders willing to examine uncomfortable weaknesses instead of rushing to restore the appearance of normal.
Change gives leaders information.
Sometimes it shows you exactly where your organization has been relying on hope, memory, heroic employees, or temporary workarounds.
Pay attention.
The things exposed during a transition can become your roadmap for building a stronger organization.
The Rule to Carry Forward
Do not only repair what broke. Find out why it was able to break.
Fix the immediate problem.
Then ask the harder questions.
What was holding this together?
Why were we so dependent on it?
What needs to be documented?
What needs to be diversified?
What needs a backup?
What should we stop doing entirely?
Because the goal isn’t to build an organization where change never happens.
The goal is to build one strong enough to change without falling apart.