They just stopped
Somebody ran the desk for four years. Every week. They knew the system, they handled the problems, they were there before everyone and left after.
Then they stopped. Perhaps they gave a reason... moving, work, a season of life. Perhaps it was gradual: fewer weeks, then none.
The team's version is usually that they got busy. Occasionally that is true. More often something else happened, and because nobody asked properly, nobody knows.
I have watched this happen. It is the reason I started building.
What usually actually happens
From twenty years in and around a church AV booth, it is rarely the work itself. It is rarely a single bad incident.
It is accumulated weight, and it comes from a few specific places.
They could not be absent. If nobody else can run it, every week is theirs. Wanting a Sunday off means either arranging cover that does not exist, or the thing not happening. After a few years, a commitment with no exit stops feeling like volunteering.
They carried the failures alone. When it works, nobody says anything. When it fails, everybody notices. That asymmetry is tolerable occasionally and corrosive over years... a role where the best outcome is silence and the worst is public.
They were asked for more. A team that runs well attracts requests. Could we add a camera, stream this extra event, do something for the mid-week thing. Each request is reasonable. The person saying yes is the same person, and nobody is counting the total.
Nobody asked how they were. They were reliable, so they were not a concern. The people who need attention are the ones causing problems, and the person quietly doing it every week for four years is not causing problems.
They could not hand it over. Even wanting to stop, they could not... because leaving would mean the service losing something, and they cared too much to do that. So they stayed past the point where they wanted to, which turns a good thing into an obligation, and eventually into resentment they feel guilty about.
I know that last one well enough. Some Sundays you run the sound, the cameras, the lyrics and the stream alone, and somewhere in that cycle there is a moment you do not say out loud, when Sunday morning starts to feel like a weight instead of a privilege.
Why this is a design problem too
It would be easy to say this is about how teams treat people, and it is. But part of it is structural, and that part is fixable.
If the system requires one person, that person cannot leave. Not because nobody would replace them, but because replacing them requires transferring knowledge that accumulated over years and was never written down. The barrier to their departure is the same barrier that stops anyone new arriving.
Which means the technical decision, how much must be known to run this, is also a decision about whether the person running it is trapped.
Every step removed, every invisible state made visible, every thing that no longer needs remembering, lowers the barrier in both directions. It lets someone new arrive, and it lets the person who has been there for four years take a week off without the service suffering.
Making a system learnable is how you let people leave gracefully. That is not usually how it is framed, and I think it should be.
What a team can do
Ask them, properly, once a year. Not "you're alright?" in passing. A real question, with time for the answer, from someone who will act on it.
Make absence possible before it is needed. A second person who can cover, trained while there is no pressure. This is the single most effective thing, and it is almost always deferred because the current arrangement is working.
Say something when it works. The asymmetry between silent success and public failure is fixable with about ten seconds a week.
Count the asks. Before adding a request, consider what else that person is already carrying. Individually reasonable requests are collectively how people get buried.
Let them stop without it being a crisis. If someone wanting to step back means the service breaks, you have made stepping back a betrayal. Nobody should have to choose between their own capacity and letting people down.
Ask why, if they leave. Genuinely, without defending anything. The answer is useful and you will not get it unless you ask in a way that makes honesty easy.
What the person can do
If you are the one who has been running it for years:
Say something before you are finished. Teams are frequently unaware of the load, because you have been quietly managing it. Most would respond if they knew... and they will not know unless you say.
Train someone while you still have capacity. Not when you are done. Training from exhaustion does not work.
Take a week off deliberately while you are reachable. It reveals what depends on you, at a moment when you can still explain it.
It is allowed to stop. Four years is a lot. The thing you built does not require you specifically, and if it does, that is worth fixing rather than enduring. Stepping back from something you gave a lot to is not a failure of commitment.
Why I write about this
I build software, and software cannot fix how a team treats people.
What it can do is remove the structural part: the accumulation of undocumented knowledge that makes one person load-bearing. That is a technical problem with a technical response, and it is not separate from the human one... it is most of what makes the human one hard.
A venue where three people can run the desk is a venue where each of them can be absent, be unwell, take a season off, or stop entirely without anyone feeling they have let people down.
That is worth designing for. It is, in the end, the same thing as designing for the person at the back of the room... just measured over years instead of over one live day.