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

📌 How to hire a Discord community manager: write the spec before the job post. Decide which systems the role owns, record what already exists in the server, define the first thirty days as output, and fix the shape of the weekly report. Most failed community hires were scope failures wearing the costume of talent failures.

---

The short answer

You hire a Discord community manager by writing the job down before you describe it to anyone. One page. Four decisions. Which systems the role owns. What already exists in the server today. What the first thirty days have to produce. What lands on your desk every week. That one page becomes your job post, your interview script, your onboarding plan and your review criteria. Strong candidates read it and ask sharper questions, because they can finally see the shape of the work. Weak ones remove themselves. And on day one the person is not reverse engineering your expectations from your reactions, which is what most community hires spend their first month doing. The rest of this is how to fill in the four parts, plus what to do if you already made the hire and it is going badly.

Why capable people fail in this role

A post that reads community manager, Discord experience required hands someone a room and calls it a role. Inside the first month that person decides whether a support question belongs in a public channel or a private ticket. Whether a first offense gets a warning or a removal. Who is allowed to hand out roles. What happens to a question asked at 2am. How loud the server should be on an ordinary Tuesday. None of those decisions reach you. All of them become policy. You see the results instead of the decisions. Two moderators enforce two different standards. The same question gets asked in four channels, because no channel is obviously the right one. Someone promises a feature in general chat that nobody scoped. Members who were active in week one go quiet in week five, and nobody can explain what changed.

A person cannot own a system nobody handed them.

Some hires genuinely are wrong for the work. More often the role was never a role, and a capable operator was dropped into an empty outline. A written spec is how you tell those two situations apart, and it takes about an hour to produce.

Part one: the ownership list

List the systems your community actually runs on and give each one an owner. Only three answers are allowed. The role owns it. You own it. Nobody owns it yet. That third answer is the valuable one. Unowned systems are where communities quietly rot, because nothing looks broken until a member notices before you do.

System	Typical owner	What owning it means
Onboarding and the first 48 hours	The role	Entry flow, welcome sequence, the first action a new member takes
Roles and permissions	Shared with you	What each role unlocks and who is allowed to assign it
Support routing	The role	Where a question goes, who answers it, what stays public
Moderation and enforcement	The role	The warning ladder, removal criteria, how appeals work
Engagement rhythm	The role	What gets posted, on which days, and by whom
Paid access and billing	You	Entitlements, refunds, upgrade paths
Reporting	The role	What gets measured and what you read every week

Two notes on that table. Permissions first. Handing a new hire full Administrator access on day one is common, and it removes every guardrail at the moment the person understands your community least. Grant the permissions this week's work needs, then widen them as the work proves itself. Discord's own permissions documentation is worth an hour before you design a role stack, because permission mistakes are far harder to undo once members already hold them. Then keep two things permanently. Server ownership belongs to the company rather than to whoever currently runs the community. Paid access and billing stay with you. A community manager should be able to do the entire job without the ability to end the community or move money.

Part two: write down what already exists

The same job title covers two completely different jobs. Someone stepping into a structured server with documented onboarding, a working ticket flow and a moderation ladder is a caretaker and an improver. Someone stepping into eleven channels, one bot and no documentation is a builder. Both are real hires. They need different skills, different timelines and different money, and the fastest way to sink a good candidate is to hire the first and expect the second. Take twenty minutes and write down what is true today.

• Every channel, and what each one is for
• Every role, what it unlocks, and who can assign it
• Every bot installed, and what each one is genuinely used for
• Any written documentation, including the parts that only exist in someone's head
• Where support requests land right now, including direct messages to you
• What is automated, and what a human does by hand every single day
• What happens between the hour you go to sleep and the hour you wake up

If most of that inventory comes back empty, you are hiring a builder. Expect the first weeks to produce documents rather than visible activity, and read that as progress rather than as a slow start.

Add one more line: the size you will be in six months, not the size you are now. At a hundred members, personal relationships carry the whole community. At a thousand, structured onboarding stops being optional. At ten thousand, documentation decides whether five people answer the same question the same way. Hire against the stage you are heading toward, because the operating model changes at each of those lines and the skills that hold at one of them come apart at the next.

Part three: define the first thirty days as output

Most onboarding plans for this role are written in effort language. Get familiar with the community. Engage with members. Support the team. None of it can be checked, so nobody checks it, and at day thirty you are left holding a feeling instead of an assessment. Write outputs instead. Five is plenty.

1. A written onboarding flow, live in the server, that a new member can follow without asking a human anything.
2. A documented escalation path with names and hours attached, so anyone on the team knows who to wake up and when.
3. One place support requests land, with a written rule for what gets answered in public.
4. A first reply time measured the same way every week, whatever that number turns out to be in week one.
5. One full week of the posting rhythm run without you in it. Every item on that list is something you can look at. That protects the hire as much as it protects you. A person who produced all five inside a month is doing the job, even in a month when the server happened to be quiet.

Part four: fix the reporting shape before day one

Decide what you want to see, and how often, before anyone starts. Reporting invented later tends to arrive shaped like a defense.

CAME IN	Support requests, new members, escalations
ANSWERED	How many, and median time to first reply
STILL OPEN	What is stuck, and what it is waiting on
NEEDS YOU	One to three decisions, each one sentence
CHANGED	What shipped in the server this week

Consistency matters more than the metrics. A report with the same sections every week makes a trend visible by the third read. A report that changes shape each week hides trends even when every individual report looks fine. Keep it to one page, and keep the decisions section short, because that is the only part that genuinely needs you.

Reading the spec against a hire you already made

If you are months into a hire that is not working, do not start with the person. Start with the page you never wrote, and use it as a diagnostic. Ask two questions. Who owns onboarding here. Where does a support request go. If neither answer comes back in one clear sentence, the failure is structural. Write the page, hand it over, and give it thirty days with the five outputs attached. Plenty of people labelled a bad hire turn into a good one within a month of learning what the job actually was. If both answers come back clearly and the server still does not reflect them, that is performance, and you are now holding evidence instead of frustration. Either way the page pays for itself, which is why it is worth writing even when the hiring is already done.

What the spec does not build

Be clear about what this page is. It defines a role. It does not build the system that role operates. That system has layers. Server architecture and channel design. An onboarding sequence. Support routing and escalation. A moderation framework. Automation coverage for repetitive load. Documentation. An engagement rhythm. Reporting a founder can read in two minutes. Most servers have two or three of those layers built and expect a new hire to supply the rest through effort, which is the gap that produces resentment on both sides of the relationship. Naming the layers you have not built is the useful part of the exercise. You will write a different job post once that list is in front of you, and you will read candidates differently too.

Start this week

Three steps, in order. One hour on the ownership table. Twenty minutes on the inventory. Thirty minutes writing the thirty day outputs and the report template. Then write the job post from that page instead of from a template you found. The page outlives any individual hire, which is the quiet benefit here. The second time you fill this role, the job already exists.

*Every community role gets defined eventually. The only open question is whether you define it on a page, or whether the server defines it for you by breaking in public. More at *danieljeong.org