How Small Teams Run a Discord Community One Program at a Time

TL;DR

One program improves while the rest hold their line

The rule comes first: improve one program at a time, and hold every other program to a written standard of one line. A community team of two or three people runs several programs at once: onboarding, support, events, announcements, moderation. It has enough time to keep all of them running and to improve one. So put a single program in focus and send every spare hour of improvement work its way. Each of the others runs on its one-line standard, which says what must still happen every week while nobody is changing it. Before the focus work starts, write down the condition that ends it. When the program meets that condition, it goes back to its standard and the next program takes its place.

Two versions of the same month

The quickest way to see why this works is to watch one team run the same month twice.

Everything at once

The team is a Community Lead, one moderator and a support person who covers the help channel part time. In week one, the lead starts rewriting the onboarding questions because new members keep asking where to begin. In week two, the support person starts moving the help channel into a forum with tags. In week three, the founder wants more events, so a new series gets planned. Somewhere in there, the announcement template gets a fresh layout and a spam wave eats two full days.

At the end of the month:

1. The onboarding rewrite is half live, and one of its answers points at a channel that no longer exists.
2. The help forum exists, but half the old questions still sit in the old channel.
3. The new event series has a name and no date.
4. The regular weekly event was skipped once, because its host was busy planning the new one.
5. Nobody on the team can name one thing that is finished.

Everyone worked hard. Members saw nothing get better, and some of them saw things get worse.

One program in focus

Same three people, same hours. This time a pinned message in the staff channel says onboarding is in focus, and the other four programs each have one line to hold.

The lead spends the month on onboarding and nothing else that counts as improvement. The support person answers every help post within the time the standard sets, in the channel as it already is. The weekly event runs in its usual format. Announcements go out on the old template. When the founder asks for a new event series, it goes on a parked list with a note saying events will be in focus in a couple of months.

At the end of the month, onboarding meets the end condition written on day one. The other four programs held their lines. The team can point to exactly what improved. Next month, support moves into focus.

TITLE: The same month, spread thin or run on a focus rotation
ASPECT RATIO: 16:9
ALT TEXT: Two one-month timelines for the same team: in the top row five improvement projects start at different times and none reaches the end of the month, and in the bottom row one program is improved all month and finishes while the other four run steadily and support starts next.
CAPTION: The same team and the same month, run two ways: spread across every program, nothing finishes, while one program in focus finishes and hands over to the next.

Landscape inline graphic, 16:9: two one-month timeline rows stacked one above the other on a single shared time axis, drawn as clean vector bars, lines, small markers and set type on a plain field. It sits inside the article at reading width and is read on a phone, so it uses few elements drawn large, generous margins on all four sides and nothing that depends on fine detail. Primary shapes carry one heavy, even outline, and hairlines are kept for the week dividers.

The time axis runs left to right across nearly the full width. Three evenly spaced vertical hairlines divide it into four weeks, a heavier vertical line marks the end of the month near the right margin, and one label, "One month", sits centred beneath the axis. Each row has a short label at its left end. The top row is labelled "Everything at once" and holds five thin bars on five lanes, one per program; each bar starts in a different week and stops short of the end line in a small open circle, so none of them reaches the end of the month, and the label "Nothing finished" sits just past the end line. The bottom row is labelled "One program in focus". Its top lane holds one thick bar that runs from the start of the month all the way to the end line and finishes in a check mark, with the label "Onboarding finished, support next" just past the end line. Beneath it, four thin flat lines run the whole month on four closely spaced lanes, even and unbroken, each ending in a small filled dot, with the label "The rest held to their standard" at their right. Just past the end line, on the first of those four lanes, a short thick bar begins in a dashed outline to show the next program moving into focus.

Hierarchy has two steps: the two row labels are the largest text, and the other four labels share one smaller size. At phone size the contrast reads before any small label: scattered short bars that all stop early on top, one long finished bar over steady lines below. A reader who follows the axis sees in a few seconds that the team and the weeks are the same in both rows and only the placement of the improvement work changes. The style reference is a hand-ruled production schedule pinned to a workshop wall: one axis, plain bars and a clear end-of-month line.

Not in this design: no photographs, no generated or raster illustration, no 3D, no gradients, no raster textures, shadows or glow, no words beyond the quoted strings, no dates, week numbers, other numbers or percentages, no names of people, no Discord interface, channel list or logos, no emoji, no decorative shapes outside the two rows and the axis.

Trying everything at once fails for a structural reason. Keeping a community running is loud. A member is waiting, an event starts in an hour, a raid arrives. Improvement work is quiet, so it gets whatever minutes are left over. Split those minutes across five programs and none of them gets enough to finish.

A big team can absorb that waste for a while. A small one feels it almost at once.

Building the rotation in six parts

Write down what you run

List every program your community runs for members on a repeating basis and that someone on the team has to keep going. A small team might land between four and six. The usual set:

Leave one-off work off the list. A launch or a server reorganisation is a project, which either fits inside a program's focus period or gets its own short slot. If you end up with more than six programs, merge some. A long rotation means the first program drifts before it comes round again.

Give every program a line to hold

This line is the maintenance standard: what the program still does while nobody is improving it. Write it as what happens, how fast or how often, and who checks.

Treat the times as placeholders and set them to what your team already does on an ordinary week. A standard pitched above that level fails every week, and a board that always shows failure stops being read. Each standard also needs to be something you can check by looking at the server, and it needs to fit on one line. A line that grows into a paragraph has become a plan, and plans belong to the program in focus.

Discord does some of this for you on events. Its Scheduled Events feature lets members press Interested on an upcoming event and get notified when it starts, so the reminders keep working while events sit in maintenance.

What maintenance includes: answering, posting, running what already exists, fixing a broken link or a wrong date, tightening an AutoMod rule after a new kind of spam gets through, swapping an outdated image.

What maintenance parks: new channels, new formats, rewritten onboarding questions, new bots, redesigned templates or layouts. These wait on the parked list until their program is in focus.

Choose the first focus with three questions

Give each program a point for every yes:

• Is the program failing its own maintenance standard today?
• Does the program's weakness create work for another program?
• Can the team improve it with the access and tools it has right now?

The second question carries the most weight. Problems flow downhill. When onboarding is unclear, the same questions land in support. When support is slow, frustrated members vent in general chat and moderators have to step in. Fix the program at the top and the ones below it get quieter, which hands the team time back for the next round. The third question keeps you honest: a program whose fix waits on a developer or a budget decision makes a poor first focus, however much it matters.

Highest score goes first. On a tie, pick whichever comes earlier in a new member's path: onboarding, support, events, announcements, moderation. Onboarding often wins the first round, because the first days are where a newcomer decides whether to stay, and because its problems leak into the other programs.

Decide what "done" means before you begin

Write the end condition, which I call the baseline, before anyone touches the program. Without it, the person doing the improving keeps going, because there is always one more thing to polish, and the rotation never moves.

A baseline has three parts, and a focus period ends when all three are true:

Add a review date four to six weeks away. For a support focus, the written baseline might read:

Focus: Support
Picked because: help posts often wait more than a day for a first reply, and members repeat them in general chat.
Done when:
  1. Two weekly checks in a row find every help post answered inside the standard.
  2. Help posts carry forum tags, so repeat questions can be found and linked.
  3. The ten most repeated answers are saved where every staff member can copy them.
New maintenance standard: every new help post gets a first reply within one working day, checked each morning.
Review date: [date]

On the review date, check the three parts. All met: rotate. Close: extend once, by a short fixed period, and write the new date on the board. Far off: cut the baseline down to what was achieved, put the remainder on the parked list, and rotate regardless. A rotation that stops moving is the old way of working with extra paperwork.

Fix the order, and the single exception

Start with the order a member travels through the server: onboarding, support, events, announcements and content, moderation. Re-score with the three questions at every rotation, because a program can slip below its standard while it waits and need to move up.

The exception is safety. If moderation stops holding its standard because of scam links, a raid or harassment, it goes into focus straight away. Whatever was in focus drops to its standard, with its progress noted on the board, and resumes when the server is safe again. That is the only interrupt. A request for a new event series, however senior the person asking, goes on the parked list with the month events come into focus.

Pin one board and look at it weekly

Keep the whole system on a single board in a staff-only channel: a pinned message edited every Monday, or one post in a staff forum. It should hold:

1. The program in focus, its written baseline and its review date.
2. Each maintenance program, its one-line standard, and whether it held that standard last week.
3. The next program in line.
4. The parked list, with each idea tagged by the program it belongs to.

Spend fifteen minutes on it each week. Ask whether every standard held, whether the focus program moved closer to its baseline, and whether anything triggers the safety interrupt. Then close the meeting. When leadership asks what the community team achieved this month, the board already holds the answer: one program reached a written baseline, and every other program held a standard anyone can check.

What the rotation adds to the bigger system

The rotation is a way of ordering work, and the work itself is larger. It sits inside a community's operating rhythm: onboarding, support routing, engagement rhythm, moderation and reporting. Each of those parts needs its own design, and none of them is small. What the rotation adds is sequence. A small team gets onboarding, then support routing, then each of the others to a finished, steady state one after another, rather than holding all of them half built at the same time.

Setting it up means writing the program list, giving each program one line to hold, scoring them with the three questions, writing the winner's baseline and review date, and pinning the board where the whole team sees it.

After the first rotation, each program that comes into focus needs its own design work, and I keep my articles at https://danieljeong.org/articles for that stage. If you would rather have someone look at your server before you pick a focus, start with my free community analysis at https://danieljeong.org/free-analysis, where I'll tell you exactly what's working, what isn't, and what to fix first. Some teams would sooner have someone outside the team run the server day to day, and I take that on through https://communitymanagementpro.com.

Progress only counts for members once it is finished, because they never see the plans behind it. One finished program, shown on the board, is progress they can actually see. danieljeong.org