Every nonprofit has a version of this story. Ours goes like this.
A small nonprofit — employees on staff, a volunteer board running the show — needed someone to handle their network and IT. Nobody on staff had the skills, and nobody had the budget to hire it out. But one of the board members had a son in high school who was good with computers. Really good, actually. So he took it on.
And for a while, it worked. He was around, he was capable, he cared about the organization. He set things up, kept them running, fixed what broke. Free IT support from someone who genuinely wanted to help — what’s not to like?
Then he graduated. Went to college. Got a job. Grew up, the way kids do.
He was still willing to help when he could. But “when he could” is not the same as “when the organization needed him.” And by then, he was the only person who knew how any of it worked. The only one with the passwords. The only one who understood the network. Every login, every configuration, every workaround lived in one person’s head — a person who now had a full course load, then a full-time job, then a life that had nothing to do with this nonprofit anymore.
Nobody Wanted to Be the One to Say Something
Here’s the part of the story that isn’t really about IT at all.
The staff knew there were problems. Systems had holes. Things broke and stayed broken because the fix required someone with more time or more expertise than a former high schooler tinkering in his spare time. But nobody wanted to be the person who walked into a board meeting and said, “We need to replace the board member’s kid with an actual IT professional.”
That’s not a technology conversation. That’s a relationship conversation, wrapped in board politics, wrapped in gratitude for years of free labor, wrapped in nobody wanting to make it awkward. So the organization kept limping along on outdated fixes and crossed fingers, because the alternative felt worse than the risk.
I get it. I really do. Most people in this situation are good people trying not to rock the boat. But “nobody wants to rock the boat” is exactly how organizations end up with a single point of failure holding their entire network hostage — not out of malice, just out of circumstance.
The Story That Didn’t Happen — But Could Have
In this case, the kid was trustworthy. When it was time to move on, he handed everything over. No drama, no standoff, no bill for “consulting hours” he decided to invoice on his way out the door.
But picture the other version.
Picture a volunteer — or an employee, this works exactly the same way — who leaves on bad terms. Maybe they’re let go. Maybe they feel undervalued and walk away angry. Maybe they just don’t feel like returning calls anymore. Now the organization needs into its own systems, and the only person who can get them there doesn’t want to.
What recourse does a small nonprofit actually have in that moment? An awkward phone call? A strongly worded email? There’s no backup admin account. No documented network map. No second person who even knows what questions to ask. The organization isn’t just inconvenienced — it’s locked out of its own infrastructure, with a donor database, financial systems, and email all sitting behind a door only one person holds the key to.
That’s not a hypothetical horror story. That’s just what happens when “the person who knows IT” and “the only person who knows IT” become the same sentence.
This Isn’t About Whether You Trust the Person
This is the part I really want to land, because it’s the part people get wrong.
This isn’t about whether the volunteer or employee is trustworthy. Most are. This is about what happens to your organization if you’re wrong even once — or if someone trustworthy simply gets hit by a bus, gets a demanding new job, or just stops being available. Good intentions don’t keep the lights on. Access without redundancy is a liability no matter how much you like the person holding it.
A resilient organization doesn’t ask “can we trust this person.” It asks “what happens if this person is gone tomorrow, for any reason at all.” Those are different questions, and only one of them protects you.
What This Actually Looks Like to Fix
None of this requires firing the volunteer, insulting the board member’s kid, or blowing up years of goodwill. It requires a few unglamorous, unemotional practices that most small organizations simply never got around to:
- A password manager with organizational ownership, not individual memory. Credentials belong to the organization, not to whoever happened to set them up.
- Documentation of the network and systems, so knowledge doesn’t live in one head. If it’s not written down, it doesn’t exist when that person is unavailable.
- A second set of eyes with admin access — even a light-touch, part-time professional relationship — so there’s always a backup path in.
- An offboarding process for volunteers, not just employees. If someone with access steps back, there’s a checklist, not a hope.
None of this is about distrust. It’s about building an organization that doesn’t have to bet its survival on one person’s goodwill, availability, or continued interest in a volunteer gig they took on in high school.
Call Me Before You’re Hacked, Not After
If your organization’s entire IT setup lives in one person’s head — staff, volunteer, board member’s kid, doesn’t matter — that’s not a compliment to how capable they are. It’s a risk sitting quietly in your systems, waiting for an ordinary life event to turn it into a crisis.
The good news: this is one of the easiest problems to fix before it becomes a story like the one that almost happened to us. It just takes someone willing to have the slightly awkward conversation.
That’s what I’m here for.
