How to Onboard a New Discord Community Manager in 30 Days With Weekly Deliverables
Four weeks, four written deliverables, and one test that shows whether the server can run without you.
| To onboard a new Discord community manager, run four weeks against four written deliverables: an audit, the operating documents, a live week where you answer nothing, and three days of your absence. What survives your absence is a system. What breaks is still in one person's memory. |
|---|
The plan, stated first
Give the new hire four weeks, one written deliverable per week, and a date set in advance when you will read each one. Week one produces an audit of the server as it exists today. Week two produces the operating documents the server runs on. Week three is a live week where they handle every message and you answer nothing. Week four is three working days where you are unreachable. Most onboarding is context transfer. You walk the new person through the history, introduce the team, share the roadmap, and hope enough of it sticks. A community manager onboarded that way spends the first month answering questions in channels. It looks like work because it is work. Thirty days later the server still runs on their memory, you are still the person members escalate to when an answer never arrives, and the only thing that changed is that someone else is now tired. The four deliverables below ask nothing of the hire that a competent manager would not do anyway. What they buy you is evidence, on a schedule, in a form you can read without that person in the room.
Week one: an audit you can read
Ask for a written inventory of the server as it actually is. Not as the strategy deck describes it, and not as it was designed to be eighteen months ago.
- Every channel, what it exists for, and when it was last used by a member rather than by staff.
- Every role, what it can do, and how a member gets it.
- The path a new member walks. What they see first, second and third after they accept the invite.
- Response times, measured by hand across the week, separated by channel and by weekday against weekend.
- The questions that repeat, written in the words members actually use.
- Every bot, what it does, and who controls its configuration. The pass condition is simple. You read the audit and can answer what happens when a member joins on a Saturday without calling anyone. Week one is the only week where being new is an advantage. A new manager still sees the server the way a member does, and that view is gone by week three. A thin audit this early usually means the person is filling gaps with assumption, and that habit does not improve once they are busy.
Week two: the documents the server runs on
Four documents, written for a stranger rather than for themselves. The channel map states what each channel is for, who is expected to post in it, and which channels are being archived. Most servers carry channels that exist because someone made them once. Naming the ones to close is part of the deliverable. The role map states what each role can do, whether it is granted automatically or by a person, and who approves the ones that are not automatic. Discord gives you a lot of control here through roles, permissions and its built in onboarding tools, documented in Discord's own support material, and the control is worth nothing while the rules live in a conversation instead of a document. The escalation ladder is the one that matters most, because it is the document that decides whether you get pulled in. It states what a moderator handles alone, what reaches the manager, what reaches you, and how long each rung has before it moves up. The response index collects the questions that repeat, with an approved answer for each and a note on where that answer lives in the server, so the answer stops being retyped from memory every week. A weekly report template closes the set. Two figures and two sentences beat a dashboard nobody opens. ESCALATION LADDER
| Rung | Role | Responsibilities | SLA |
|---|---|---|---|
| 1 | Moderator | Spam, slurs, off-topic, low-stakes disputes | Handled within 15 minutes |
| 2 | Manager | Refunds, access problems, repeat offenders | Handled within 2 hours |
| 3 | Founder | Legal threats, press, partner conflicts | Handled same day |
Anything unresolved at its time limit moves up a rung automatically. Every decision above Rung 1 is logged in #mod-log with a one line reason.
WEEKLY REPORT TEMPLATE
New members this week:
Median first reply time:
Rung 2 items and how they closed:
One thing that broke:
One document I changed because of it:
The pass condition for week two: a competent stranger could act from these documents on their first day without asking a single question.
Week three: they run it and you answer nothing
The documents mean little until they meet real members. Week three puts them under load.
Rules for the live week
- You do not reply in public channels, even when you see the answer and it takes eight seconds.
- Members who message you directly get forwarded to the manager, not answered by you.
- Every decision above the first rung of the ladder gets logged with a one line reason.
- Anything the manager had to invent on the spot gets written into the week two documents that same day. That last rule is the deliverable. At the end of week three, the week two documents should look different from how they looked on Monday. Edits are proof the documents are being used. A live week that produced no edits means the manager ran the server from memory and left the documents sitting where you last read them. This is also the week where you find out how the person handles being watched without being rescued. Some managers ask for the answer. Better ones ask for the rule, then write it down.
Week four: the absence test
Pick three consecutive working days. Tell the manager the dates in advance. Then go unreachable, with no quiet cover from you and nobody standing in on your behalf. When you come back, look at four things.
| What to inspect | What a pass looks like |
|---|---|
| Open messages older than the ladder allows | None, or one with a logged reason |
| Tickets closed during your absence | Closed with a resolution, not with an apology |
| Decisions parked waiting for you | Only genuine top rung items |
| Members who joined while you were gone | Same first contact as any other day |
If the server stalls when you go quiet for three days, you are still the operator and the title on the offer letter has not changed anything.
Three days is the right length. One day hides everything, because almost any server survives a single day on goodwill and a pinned message. A full week is unfair to a hire who is four weeks in. Three days is long enough for a weekend queue to form and short enough that a real system absorbs it.
What the four results tell you
Each weak deliverable points at a specific problem, and each one is cheaper to fix in month one than in month six. A thin audit means the person guesses instead of looking. A set of documents that only makes sense to their author means the knowledge is being stored in a person, whether or not that was anyone's intention. A live week with no document edits means memory is doing the work. A queue after three quiet days means the manager is the process, and the process cannot take a holiday. None of that makes them a bad hire in week five. It tells you what to correct while correcting it is still easy, and it gives you something specific to correct, which is more than most performance conversations manage.
Where this sits in the larger system
The first thirty days test one layer of a community operating system. The other layers are entry and onboarding flow, role and channel architecture, support routing, moderation coverage and escalation, engagement rhythm, documentation, automation coverage, and reporting that a leadership team can actually read. Communities that hold together at scale have all of them built and written down, and the operational model changes at every size step, from a hundred members carried by personal relationships to a million where specialised teams and automation frameworks are the only thing keeping the room habitable. Running the moderation side of a community through growth to well past a million members teaches the same lesson repeatedly: the servers that stay calm are the ones where the rules are written, not remembered. Fixing the first four weeks does not build those layers. It tells you within a month whether the person you hired is capable of building any of them, which is the most useful thing you can learn that early.
Do this before their first day
Write the week one deliverable and the date you will read it, then put both in the first calendar invite. Grant access on day one at the level the role genuinely needs, because a manager waiting on permissions spends week one on the wrong things. Decide the top rung of the escalation ladder yourself, since that rung is about what you are willing to be interrupted for and nobody else can answer it for you.
*The best community people leave a trail somebody else can follow. That is the difference between a room that depends on them and a room they made stronger. *danieljeong.org