The signal that it is time to hire is not member count. It is that the work has become predictable enough to describe, and that nobody is doing it. Communities get hired for far too early on the first count and far too late on the second.
This post does not quote salary bands. They vary so much by region, seniority and scope that any number here would be a worse guide than the reasoning below.
The signals that actually mean it is time
Four things, and none of them is a headcount.
The fixed work is slipping. The weekly prompt goes out late, the event moves, the newsletter does not ship. That is not a discipline problem; it is the growing half of the work eating the half that creates value, and it is the most reliable early signal there is — the split is explained in how much time running a community takes.
You are the bottleneck for things that do not need you. Members wait on you to answer questions three other people could have answered, because no one else has the standing to.
The work has become describable. You can write down what happens each week and roughly how long it takes. Before that point, hiring means asking someone to invent the job while doing it, which is a senior task disguised as a junior one.
The community is worth more than the salary. Not in vibes — in retention, support deflection, or revenue you can point at. If you cannot make that case to yourself, you will not make it to a finance team either, and the methods are in measuring community ROI.
The signals that do not mean it is time
Three arrive constantly and none of them justifies a hire on its own.
Crossing a member number. Ten thousand passive members need less attention than four hundred active ones. The number that matters is how much conversation happens, not how many accounts exist.
Wanting the community to be busier. A hire will not create demand that is not there. If the community is quiet because the reason to join is weak, a community manager inherits that problem rather than solving it, and both of you will be unhappy within a quarter.
Everyone else has one. Competitor headcount is not a strategy, and a role created to match a competitor tends to be a role nobody can define — which is exactly the condition under which the hire fails.
What actually transfers, and what does not
Hiring redistributes the work; it does not remove your share of it. Being specific about which half is which prevents most of the disappointment.
| Transfers well, immediately | Transfers slowly | Stays yours |
|---|---|---|
| Moderation triage and the queue | Judgment calls on borderline members | What the community is for |
| Welcoming, onboarding, repeat questions | Relationships with the regulars | Decisions that cost money |
| Scheduling, reminders, event logistics | Tone, and knowing when to break a rule | Whether it keeps existing |
| Reporting and the numbers | Being trusted enough to say no | The founder's own presence |
The middle column is where new hires are judged unfairly. Standing with the regulars is earned over months and cannot be delegated on a start date, so a manager who is not yet trusted will look slower than you at exactly the tasks you were hoping to stop doing. That is not underperformance; it is the cost of the transfer, and it is temporary if you let it be.
Part-time first, almost always
The common mistake is jumping to a full-time hire because the work feels heavy.
Ten focused hours a week covers the transferable half of most communities under a few thousand members. It also lets you find out whether the job you wrote down is the job that actually exists, which is worth knowing before you commit a full salary to it.
The exception is when the role includes something that cannot be done in fragments — running a programme, owning a launch calendar, being present daily across time zones. Those break badly when split across ten hours, and forcing them into a part-time role is how you end up rehiring in six months.
From the community, or from outside?
Both work, and they fail in opposite directions.
Hiring a member buys you context you cannot teach: they know the regulars, the history and the unwritten rules. What they usually lack is the experience to push back on you, and a community manager who cannot say "that will not work" is an expensive assistant. The pool is the same one described in recruiting volunteer moderators, and promoting a volunteer is the most common version of this.
Hiring a professional buys judgment and pattern recognition, and costs you three to six months of context. Where they earn it back is in the parts you were never going to be good at — consistency, measurement, and the discipline of doing the boring thing every week.
If you are choosing, weight it by what is missing. A community that lacks culture needs a member. A community that lacks operations needs a professional.
Write the job around the week, not the title
Most bad community job posts are lists of adjectives attached to a title nobody agrees on.
Write what the week contains instead: these rituals, this queue, this event cadence, these reports. Then say which decisions are theirs. A role without decision rights is not a role, it is a queue with a person attached, and the good candidates can tell the difference from the posting — what the job actually contains is in what a community manager does.
Say plainly which standards are already set and which are open. Inheriting a written code of conduct is a gift; inheriting an unwritten one that you enforce by instinct is a trap, and it is the fastest way for a new manager to be wrong in public — see how to moderate an online community.
The handover decides the outcome
The failure mode is not a bad hire. It is a good hire who was never actually given the work.
Hand over publicly, in one post, and say what they now decide. Members route around an introduction that does not transfer authority, and you will still be answering everything in month three while paying someone to watch.
Then stop doing the tasks you handed over, including the ones you enjoy. This is harder than it sounds and it is the single most common reason the hire does not pay off: two people doing the same job produces one salary of cost and no capacity.
Judging it at ninety days
Set the bar before you start, because after three months everyone argues from impressions.
Reasonable ninety-day evidence: the fixed work ships on schedule without you, the moderation queue is current, someone other than you is named when members need help, and you can see where the time went. What is not reasonable at ninety days is a step change in engagement — that takes longer, and judging on it early is how good hires get written off. Pick the measures in advance from the metrics that actually matter.
If the honest answer at ninety days is that nothing moved and you are still doing the work, the problem is usually the handover, not the person. Check that before you conclude anything about the hire.
The bottom line
Hire when the work is describable, when it is slipping, and when the community is demonstrably worth more than the cost — not when you cross a member number.
Start part-time, write the job as a week rather than a title, hand over authority in public, and then genuinely stop doing the parts you gave away. The hire does not buy you a busier community. It buys back the hours you were spending on the half of the work that never needed you.