How to Hire a Discord Community Manager: The Spec You Write Before the Job Post

The hour that decides the hire

Before you write a job post, spend an hour writing the job.

Four decisions fit on one page. Who owns each system in your server. What already exists in there today. What the first thirty days must produce. What you read every week once the person is in the seat.

Do that and hiring becomes ordinary work. You have something to interview against, something to hand over on day one, and something to review at day thirty. Skip it and you are hiring a personality and hoping it fits a job that has never been described.

What an undefined role does to a good operator

A new community manager makes dozens of policy decisions in the first month, and almost none of them reach you.

Whether a billing question gets answered in public. Whether a rude first message earns a warning or a removal. Which team members can hand out roles. What happens to a question posted at 2am. How often the server should hear from you at all.

Those decisions land as consequences rather than as questions. Two moderators run two different standards. One question appears in four channels because none of them is clearly correct. Somebody promises a roadmap item in general chat. Week one members go silent by week five with no obvious cause.

An undefined role is a series of guesses that arrive at your desk as symptoms.

The hire gets blamed for a structure that was never handed over. Sometimes that judgment is fair. Most of the time it is not, and a page written in an hour would have shown you which case you were in.

Decision one: who owns which system

Name every system your community runs on, then assign each one. Three answers only: the role, you, or nobody yet.

Onboarding and the first 48 hours. Roles and permissions. Support routing. Moderation and enforcement. The posting rhythm. Paid access and billing. Reporting.

The entries that come back as nobody yet are the reason your community feels heavier every month. Nothing announces itself as broken until a member finds it before you do.

Two lines stay with you regardless of how good the hire is. Server ownership belongs to the company. Billing and paid access belong to you. Everything else can move, including permissions, though Administrator on day one is a mistake worth avoiding: it strips every guardrail at the point the person knows your community least. Start with the permissions this week's work requires and widen them as the work earns it.

Here is what a weak answer and a strong answer sound like on each of the questions that decide the role.

Decision two: builder or caretaker

The same title hides two different jobs, and the difference is the current state of your server.

Walking into documented onboarding, a working ticket flow and a moderation ladder is a caretaking and improvement job. Walking into eleven channels, one bot and nothing written down is a construction job. Both are legitimate hires with different skills, timelines and price.

So write the inventory before the job post. Channels and their purpose. Roles, what they unlock, who can assign them. Bots installed and what each is actually used for. Documentation that exists, including the parts living in one person's head. Where support currently lands, direct messages to you included. What runs automatically. What happens overnight.

Write the inventory against the size you expect in six months rather than today's size. Relationships carry a hundred members. A thousand needs structured onboarding. Ten thousand needs documentation, or five people answer one question five ways. The operating model changes at every one of those lines.

Decision three: what month one produces

Effort based onboarding plans cannot be reviewed. Get up to speed, engage members, support the team: all unfalsifiable, all useless at day thirty.

Give the person a short list of things that will exist by the end of the month.

That list is fair to both sides. It tells the hire what winning looks like in a month, and it tells you what to look at instead of relying on how the server feels on a Friday.

Review it as a document review rather than a conversation. Open the server, walk the onboarding flow the way a stranger would, read the escalation path, and look at four weeks of reply times. If four of the five exist and one slipped, ask what blocked it before you draw a conclusion. The answer is often your own approval speed rather than anything about the person you hired.

Decision four: what you read every week

Agree the report before anyone starts, because reporting designed after a problem tends to read like a defense.

Same sections, same order, one page. A stable format makes a trend obvious by the third week. A format that shifts every week hides trends behind perfectly reasonable looking updates.

Two small choices make the report worth reading. Use the median time to first reply rather than the average, because one thread that sat untouched over a weekend will bend an average and disguise an otherwise healthy week. Then read it on the same day every week. Cadence is part of the system, and a report that arrives whenever somebody has time to write it stops working as a control and turns into a chore for both of you.

The two question test for a hire already in the seat

If the hire is months old and going badly, run this before you decide anything about the person.

🔎 Ask who owns onboarding, and ask where a support request goes. Two sentences, one each. No clear answers means there was never a spec, so write it, hand it over, and attach the five month one outputs to the next thirty days. Clear answers that the server does not reflect means performance, and now you have evidence rather than a feeling.

Most founders run this test and discover the structural version. That is inconvenient and also good news, because a structure can be written in an afternoon and a hiring cycle takes months.

The role is one layer of a bigger system

This page defines a role. It does not build the machine the role operates.

That machine has layers: server architecture and channel design, an onboarding sequence, support routing and escalation, a moderation framework, automation covering the repetitive load, documentation, an engagement rhythm, and reporting readable in two minutes. Most communities have a few of those layers and quietly expect a hire to cover the rest with effort. That expectation is where the resentment on both sides comes from.

Seeing the full list changes how you write the job post, what you pay for, and which candidate you choose.

The layers also have an order. Architecture comes before onboarding, because a welcome flow pointing at the wrong channels teaches new members to ignore your directions. Onboarding comes before engagement programming, because activity poured into a room nobody can navigate leaves as quickly as it arrives. Support routing comes before automation, since automating a path nobody agreed on only makes the wrong route faster. Built in that order, each layer carries the weight of the next one. Built out of order, every layer needs rebuilding later.

What to do next

Block ninety minutes this week. One hour assigning owners to every system. Twenty minutes on the inventory. Ten minutes copying the report sections above into a document with next Monday's date on it.

Then write the job post from that page. It will be shorter, more specific, and far less likely to attract someone who is good at community work in general and wrong for this community in particular.

A community role that has never been written down gets defined anyway, one guess at a time, by whoever happens to be online. Writing it yourself is the cheaper version. More at danieljeong.org.