As always with these stories, this is a composite. The founder is assembled from patterns I have watched play out repeatedly, the numbers are illustrative rather than reported, and nothing here is traceable to a real person. The sequence of events, though, is depressingly common, and I have seen versions of it in communities of every size.
He ran a community for independent bookkeepers. Two years in, a few hundred members, a monthly call, a busy question channel, and a weekly note that people actually looked forward to. It was working, and he was tired.
The tiredness was real. He was answering questions at ten at night, he had not taken a full weekend off since spring, and he had started to notice a small dread before opening the community, which frightened him more than the workload did. Everyone he asked gave him the same advice, and it was good advice, and he followed it: hire someone.
The hire
He found a genuinely capable community manager. Sixteen hours a week to start. Answer the routine questions, keep the calendar, welcome new members, tidy the channels, chase up unanswered threads. Reasonable scope, fair rate, a person who had done it before and came with references.
For about three weeks it was glorious. His evenings came back. The dread lifted. He wrote two long pieces he had been meaning to write for months.
Then, over the following quarter, three things happened that he did not connect to each other until much later.
Engagement in the question channel dropped. Not dramatically. Threads that used to run fifteen replies were running six. Attendance on the monthly call slipped from around forty percent of members to something closer to a quarter.
Cancellations went up slightly, and the exit notes shared a strange, vague theme. Not complaints. Just "not getting as much out of it as I was," from members who had been there a year or more.
And his own workload came back. Not to where it had been, but close, because he was now spending several hours a week on something new: writing instructions, reviewing decisions, answering "how should I handle this," and quietly redoing replies he did not think landed right.
What was actually going wrong
He nearly reached the wrong conclusion. His first theory was that he had hired the wrong person, which is where most founders land, and it is almost never true. She was good. She was doing exactly what he had asked, competently and on time.
The problem was what he had asked.
He had delegated the answering of questions. In a bookkeeping community, answering questions was not an operational chore. It was the product. His specific, opinionated, occasionally funny answers about messy client situations were the reason people paid. When those answers started coming from a capable person who was not him, the room did not become worse exactly. It became generic. And generic is invisible on a dashboard and lethal to retention.
There was a second, subtler loss. By handing over the question channel, he had cut himself off from the flow of information that told him what his members were struggling with. His weekly note had always been good because it came directly from a conversation he had been in on Tuesday. Now it came from a summary someone else wrote. Still accurate. No longer alive.
And the third thing, the one he found hardest to say out loud: the parts of the job he had delegated were the parts that gave him energy. He had kept the admin, the payment problems, the platform decisions, the invoicing, and the strategy, and he had given away the human contact. So he was less busy and considerably less happy, which is not a trade anyone would make on purpose.
The correction, which was not "fire her"
This is the good part. He did not undo the hire. He redrew the line, and the redrawing took a single afternoon.
He took back the question channel entirely. All of it. He blocked ninety minutes a day, in one block, and answered everything himself, in his own voice, including the boring ones.
He gave away, in exchange, the things that were genuinely operational and genuinely draining: the calendar, the event logistics, the reminder emails, chasing failed payments, the resource library upkeep, the onboarding sequence, the first pass on support tickets that were actually technical, and the monthly summary of what members were asking about, which she now compiled from a channel he was fully present in rather than one she was staffing.
And he added one thing he had not thought of. He asked her to run the parts of the community that needed a host rather than an expert: the introductions thread, the casual room, the birthday and anniversary noticing, the nudging of quiet members. She turned out to be dramatically better at that than he was, because she had the patience for it and he did not.
Within two months, engagement recovered and passed where it had been. His own hours settled at a level he could live with, meaningfully better than before the hire, because the operational load really had been eating him. And the cancellation notes went back to normal.
The four questions he now asks before delegating anything
He wrote these down, and I think they are the most useful thing in this whole story.
Is this the product or is this the plumbing? If a member would notice and care that a different person did it, it is the product. Product stays with you far longer than feels comfortable. Plumbing goes first, immediately, gladly.
Would handing this over cut me off from information I use? The question channel was an intelligence feed disguised as a chore. So is reading cancellation reasons, so is the introductions thread, so is the awkward direct message. Anything that tells you what your members actually need should be the last thing you delegate, not the first.
Does this task give me energy or take it? Two founders can hand off opposite halves of the same job and both be right. Some people are drained by live calls and restored by writing. Some are the reverse. Delegate against your own wiring, not against a template you read somewhere.
Am I hiring to fix a workload problem or a design problem? This is the one that saves the most money. He was drowning partly because of volume and partly because his community had accumulated eleven channels, three recurring events, and a support burden he had never redesigned. Hiring someone to run an inefficient system just means paying for an inefficient system. He eventually merged four channels and cut one recurring event, and that saved more hours than the first two months of his hire did.
What he would do differently from the start
Two things.
He would have hired for operations before he ever felt overwhelmed, because operational work is easy to hand over cleanly, has clear success criteria, and does not touch the relationship with members at all. Waiting until you are desperate means you delegate whatever is loudest, and what is loudest is usually the members.
And he would have written the boundary down as a document rather than a job description. Not "community manager, sixteen hours." Instead: here is what I will always answer myself, here is what you own completely, here is what we discuss. Three lists. He says that document, which took forty minutes to write after the fact, would have saved him a full quarter of drift.
The uncomfortable general lesson
Every piece of advice about creator businesses tells you to delegate, and the advice is right. What almost nobody tells you is the order, and the order is everything.
The instinct is to hand over the thing that is hurting most. In a community business the thing that hurts most is very often the thing your members are paying for, because human attention is simultaneously the most valuable and the most exhausting thing you sell. Hand it over and you save time by quietly dismantling the reason your community works.
Delegate the invisible work first. Keep the visible work far longer than you want to. And when the visible work gets too heavy, the answer is usually to reduce its surface area, not to substitute yourself out of it: fewer channels, fewer events, clearer hours, better documentation. Design before staffing.
Do this this week
List every recurring task in your community and mark each one as product or plumbing. Be honest. If a member would notice a different hand doing it, it is product.
Then mark each one with a plus or a minus depending on whether it gives you energy or takes it. You are looking for the tasks that are plumbing and take energy. That list, and only that list, is what you should be handing over first.
If you already have help and something feels slightly off in your community, go and read the last twenty cancellation notes looking for the word "less." "Getting less out of it." "Less useful lately." That word is what a delegated product sounds like on the way out, and catching it early is the difference between an afternoon of redrawing lines and a year of slow decline.