How to Onboard a New Discord Community Manager in 30 Days With Weekly Deliverables

Start from the standard you are hiring toward

The standard is three days. Three working days where you are unreachable, nobody covers for you, and the server keeps its promises to members anyway. Everything in a new community manager's first month should be built to reach that standard, and you can check it on day thirty rather than guessing about it in month six.

The reason to work backwards from a standard is that community work is easy to mistake for progress. Someone answering questions in channels all day looks busy and feels helpful. That activity leaves nothing behind. When the same person takes a week off, or leaves in month nine, the server drops to the floor and the person who picks it up is you.

Four weeks, four artifacts

Set the deliverable and the reading date before the hire starts. The dates are the mechanism. A deliverable without a date on your calendar becomes a conversation, and a conversation leaves nothing you can inspect.

Week one has a quality nothing later can recover. A manager who is four days old still experiences the server the way a member does, and that view disappears once they know where everything is. Spend it.

The escalation ladder does most of the work

Of the four documents, the ladder is the one that decides whether your calendar goes back to normal. It answers a question every growing community faces daily and almost none write down: who is allowed to decide this, and how long do they have.

Without time limits, a ladder becomes a suggestion. The automatic movement upward is what keeps a member from waiting two days for a decision that only needed thirty seconds from somebody else.

Reading the results honestly

By day thirty you have four artifacts and one absence to review. The signals are unambiguous, which is unusual for a first month.

A manager who cannot be absent has not built anything yet, and neither have you.

The queue is the signal worth acting on fastest. Founders usually read it as a staffing problem and add another person, which buys a few weeks and then produces two people holding a server in their heads instead of one.

The report that keeps this alive after month one

The four week structure works because reading is scheduled. Keep that property once onboarding ends by holding a small weekly report in place. Short enough that it gets written, specific enough that a bad week cannot hide inside it.

WEEKLY REPORT

New members:
Median first reply time:
Items that reached my rung, and why:
One thing that broke this week:
One document I changed because of it:

The last two lines carry the value. A report of only good news is a report that stopped being useful, and a document that never changes is a document nobody is using.

The layer this belongs to

The first thirty days test one layer of a community operating system. The rest of the stack covers entry and onboarding flow, role and channel architecture, support routing, moderation coverage and escalation, engagement rhythm, documentation, automation coverage, and reporting leadership can read without a translator. Each layer changes shape as the community grows, since a server of a hundred runs on personal relationships and a server past a million runs on automation frameworks and specialised teams. Across communities at both ends of that range, including one that reached roughly 1.7 million members while holding around fifteen percent engagement, the pattern holds: written rules survive staff changes and remembered rules do not.

Getting the first month right does not build the other layers. It tells you early whether the person you hired can build them, and it stops you discovering the answer during a crisis.

Start here

If someone starts next week, write the week one deliverable today and put the reading date in the calendar invite. If someone is already three months in and none of these documents exist, run week two and week four anyway. The absence test works on any hire, at any point, and it takes three days to tell you something a performance review will circle for a year.

Every community eventually gets handed to someone new. The ones that survive the handover were written down by the person who left. danieljeong.org