The first thing somebody other than you runs is the biggest milestone a community has, and no dashboard anywhere records it.
Posts, members, active users — every number you watch measures the same thing: how well the place works while you are operating it. The moment somebody else runs something is the moment it stops being a service you provide, and it shows up in none of them.
Most handovers keep the authority
Owners hand over the task and quietly keep everything that made it a task.
"You can run the monthly call — just send me the agenda first, and I will post the announcement." That is not delegation. It is homework with supervision, the member can feel the difference immediately, and what they learn is that the thing is still yours and they are helping with it.
The giveaway is that nothing about your week changed. A real handover costs you something — a decision you no longer make, a post you no longer write — and if you cannot name the thing you stopped doing, nothing moved, which is the same reason the hours never go down.
The test is whether they can do it badly
One question settles whether you have actually handed anything over.
If they run it worse than you would, does it still happen? Not "would you be annoyed" — would you step in, take the pen back, fix it before anyone noticed? If the answer is yes, you have lent it out rather than given it away, and everybody involved already knows.
Accepting a worse version is the entire transaction. It will be worse at first, sometimes for months, and the community gets something in exchange that you cannot produce at any quality: evidence that this place does not depend on one person.
Four things worth handing over
Start with exactly one of these. The failure column is what actually happens, not what might.
| What you hand over | What it needs from you | How it fails |
|---|---|---|
| A recurring thread | A name, a fixed slot, and public backing | You keep answering first in it |
| A live session | Access, and you doing the promotion | You attend and become the centre of it |
| Welcoming new members | A short note on what to say | You welcome everyone too, so theirs is redundant |
| A whole space | Real authority and an agreed way out | Nobody decided what happens when they stop |
The first row is where almost everyone should start, because it is small enough that failing at it costs nobody anything — and if they pick the second, send them the hosting craft rather than assuming they know it.
"Someone should do X" is an application
The person to hand something to is almost always the person who just suggested it.
When a member says the community should have a reading group, they have told you three things: they want one, they have thought about it, and nobody else has. The correct reply is not "good idea, I will look into it" — it is "would you run it?", asked immediately, while the enthusiasm that produced the suggestion is still in the room.
Most people say yes, and the ones who say no usually say something useful instead — they are too busy, or they wanted it to exist rather than wanting to make it. Either answer is better than the suggestion quietly becoming another item on your list.
What stops people is permission, not ability
Members rarely decline because they could not do it. They decline because two things are unclear.
The first is whether they are allowed. In most communities nobody has ever said who may start something, so the safe assumption is that it belongs to the owner. The second is what happens if it flops — nobody wants to run a session that four people attend and have that be a public fact about them.
Both are fixed with sentences, not systems. Say in public that anyone can start something and that you will help. Then say, before it happens, that a quiet first one is normal and that you will be the one who says so afterwards — which costs you nothing and removes the only real risk they were carrying.
Give them a slot, not a favour
A one-off request builds nothing. A named, recurring slot builds a role.
"Could you run something next month" makes a member a helper for one month. "The reading group is the first Tuesday, and it is yours" makes them the person who runs the reading group, which is a thing they can be, introduce themselves as, and grow into. The name matters more than it sounds: a thing with a name survives a bad month, and an unnamed favour does not.
It also changes what happens when they eventually stop, because a named slot can be handed on and an informal arrangement can only lapse — the mechanics of that are the same ones behind recruiting volunteer moderators, which is this question's older sibling on the moderation side.
Do not take it back when it goes quiet
Something they run will have a bad run, and your instinct will be to help by posting in it.
From the inside that is generosity. From theirs, and from everyone else's, it reads as the owner stepping in because the member was not managing — which is exactly the message that stops the next person volunteering. The help is real and the signal is worse than the problem.
Ask first, every time, even when it is obviously fine. "Want me to post something in there this week, or would you rather leave it?" costs one message and keeps the thing theirs, which is the whole asset you were building — and it is the same discipline as not answering every question yourself.
What you can actually hand over
Some of this is a permissions question, and the answer is more granular than most owners assume.
On Mateflow a member can be made a co-host of an event, and the permissions are not one switch: a co-host can manage and edit the event without being able to delete it, and acting on a whole recurring series stays with the author, the space owner or a space manager. A space, separately, has its own roles — admin, moderator and member — so handing over a whole room is a different and larger decision than handing over one event.
One thing to know before you rely on it: a co-host who leaves the space loses those permissions entirely. The access is attached to their membership rather than to the event, so if somebody steps back from the community they also, silently, stop being able to run the thing you gave them — worth checking whenever a handover goes quiet, because the cause is occasionally this rather than anything human.
Agree the ending before it starts
Every handover ends, and the ones that end badly are the ones where nobody said they could.
A member who took on a monthly session and has quietly dreaded it since April will keep going rather than admit it, because stopping now means admitting they failed at something you trusted them with. So they limp on, the thing gets worse, and eventually it dies in a way that embarrasses everybody.
Give it a term out loud at the start — a season, six months, whatever fits — and say that handing it on at the end is the normal outcome rather than the sad one. It costs nothing, it makes the ask smaller, and it means the slot can pass to somebody else while it still has momentum, which is what turns one handover into a structure that survives people instead of a favour that lapsed.
Three things not to do
Do not build a programme. Applications, tiers, a handbook and a title convert a favour between two people into an institution that needs administering, and you will be the administrator.
Do not hand over something you do not care about. Members can tell the difference between being trusted with something that matters and being given the washing up, and the second one is worse than asking nobody.
Do not skip the public part. If you hand something over privately and never say so, members assume you are still running it, and the person doing the work gets none of the standing that was most of their payment.
The bottom line
A community where only the owner starts things has a ceiling, and the ceiling is one person's week.
Hand over one small thing to the person who suggested it. Give it a name and a slot rather than making it a favour, say out loud that it is theirs, and then let it be worse than you would have made it. Ask before you help, and never take it back quietly — because the goal was never a better reading group, it was a community in which somebody other than you is willing to be responsible for something, and that is the difference between programming and attendance.