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

Small teams that keep one program in focus finish improving it while the rest keep running. Four moves cover how to manage a Discord community with a small team: list your programs, write a one-line maintenance standard for each, put all improvement work into one of them until it reaches a baseline you wrote down first, and then rotate to the next program.

---

Two modes of work for a small team

A common belief says a small team should improve every program a little each month. Test it on a real month: onboarding, support, events, announcements and moderation all get touched, and none gets finished. A small team can keep all five running and improve one of them. So split the team's work into two modes. One program is in focus. Every hour the team has for improvement goes to it. Every other program runs in maintenance, on a one-line written standard that says what still has to happen each week. When the focus program reaches a baseline you defined before you started, it drops back into maintenance and the next program moves into focus. The system needs five decisions: a list of your programs, a maintenance standard for each one, a rule for picking the first focus, a written baseline that ends each focus period, and a rotation order. All five live on one status board in a staff channel, and the team reviews it once a week.

Before: the team that improves everything at once

Picture a community team of two or three people. There is a Community Lead, a moderator or two, and maybe someone from support who covers the help channel part of the week. Between them they run five programs: onboarding, support, events, announcements and moderation. On Monday someone notices new members asking where to start, so the lead begins rewriting the onboarding questions. On Tuesday a member complains that help posts sit unanswered, so support gets a new forum channel with tags, half set up. On Wednesday the founder asks for more events, so a new weekly series gets drafted. On Thursday the announcement template gets a redesign because it looks dated. On Friday a wave of spam arrives and everyone drops everything for moderation. By the end of the month, five improvements have been started and none has been finished. You can usually spot this team from the outside:

• Half-built changes are live. A new member picks an onboarding answer that sends them to a channel that was renamed last week.
• The basic work slips. The weekly event gets skipped because the person who runs it is busy redesigning it.
• Every new idea starts the day it comes up, so the list of open projects only grows.
• Nobody can say what improved this month, even though everyone was busy all month.
• Members notice no difference, and the team is tired anyway. The cause is simple. Improvement work and keep it running work sit on the same to-do list and compete for the same hours. Keeping things running tends to win the day, because it is louder: a member is waiting, a raid is happening, an event starts in an hour. Improvement gets the leftover minutes, split five ways, and leftover minutes split five ways rarely finish anything. Larger teams can hide this pattern for a while. A small team feels it within weeks.

After: the same team on a focus rotation

Same people. Same hours. Same five programs. The difference is one written page. Onboarding is in focus. The lead spends all of the team's improvement time on it: rewriting the onboarding questions, fixing the welcome message, making the first action obvious. Support, events, announcements and moderation run in maintenance. Each has one line that says what must still happen. Help posts still get answered on time. The weekly event still runs, in its current format. Announcements still go out on the existing template. Nobody redesigns any of them this month. When someone has a good idea for events, it goes on a parked list, where it waits for the month events are in focus and there is time to do it properly. By the review date, onboarding has reached the baseline the team wrote down at the start. The other four programs held their standard. The team can say exactly what changed and show it. Then support moves into focus, and onboarding becomes a maintenance program with a better standard than it had before. What I like most about this setup is that it is honest. A small team was never going to improve five programs at once, and the rotation turns that fact into a plan.

List the programs your community actually runs

A program is anything your community does for members on a repeating basis that someone on the team has to keep running. A small team might run four to six. A typical list looks like this:

• Onboarding: what a new member sees and does in their first days. On a Community server this includes Discord's Community Onboarding settings, which set the default channels every new member sees and the customization questions that hand out roles and channels, plus your welcome message and the first action you ask new members to take.
• Support: where member questions get answered, such as a #help channel, a help forum, or a ticket panel.
• Events: anything on a schedule, such as office hours, AMAs, workshops or game nights.
• Announcements and content: product updates, weekly recaps, resource posts and guides.
• Moderation: AutoMod rules, member reports, and keeping the server safe. One-off work does not go on this list. A launch, a single giveaway or a server reorganisation is a project. It either fits inside a program's focus period or gets its own short slot on the board. If your list runs past six, merge programs until it does not. A rotation through eight programs takes so long that the first one drifts before its turn comes round again.

Write a one-line maintenance standard for each program

The maintenance standard is the most important line in this whole system. It says what a program still has to do while nobody is improving it. Write it in this shape: what happens, how fast or how often, and who checks it.

Onboarding: every introduction post gets a reply from a person within one working day. The community lead checks on Mondays.
Support: every new help post gets a first reply within one working day. The support lead checks each morning.
Events: one weekly session runs in its current format and is posted as a Scheduled Event a week ahead. The events lead checks on Fridays.
Announcements: one update goes out each week using the existing template. The community lead checks on Fridays.
Moderation: every member report is reviewed the same day. The mod lead checks each evening.

These are examples. Set the times to what your team already manages on a normal week. Three rules make a standard work:

1. Describe the level you already hit, not the level you wish you hit. A standard the team cannot meet in maintenance turns every week into a failure, and people stop reading the board.
2. Make it checkable by looking at the server. "Members feel welcome" cannot be checked. "Every introduction post gets a reply from a person" can.
3. Keep it to one line. If it needs a paragraph, you have written a plan, and plans belong to the focus program. For events, Discord's Scheduled Events feature does part of the maintenance work for you. Members can press Interested on an upcoming event and get a notification when it starts, so a standard of "posted as a Scheduled Event" keeps attendance prompts running without anyone writing reminder posts. The line between maintenance and improvement needs to be clear, or improvement work sneaks back into every program. One way to draw it:

Maintenance allows	Maintenance parks until the program is in focus
Answering, posting, and running the event as it already exists	New channels, new event formats, new recurring posts
Fixing a broken link, an expired invite or a wrong date	Rewriting onboarding questions or the welcome flow
Adjusting an AutoMod rule after a new spam pattern gets through	Adding a new bot or replacing an existing one
Replacing an image that has gone out of date	Redesigning templates, banners or channel layouts

Maintenance means fix what breaks and run what exists. It never means redesign.

Which program goes into focus first?

Score each program by asking three questions. Every yes is one point.

1. Is it below its maintenance standard right now? If a program cannot even hold its one line, it is the most visible problem in the server.
2. Do its problems create work in another program? This one matters most. Unclear onboarding shows up as the same questions in support. Slow support shows up as frustrated messages in general chat that moderators end up handling. When you fix the program at the top of that chain, the programs below it get quieter, and the team gets time back for the next focus period.
3. Can the team improve it with the access and tools it already has? If the fix depends on a developer, a budget decision or permissions you do not hold, it is a poor first focus, however important it is. The program with the most points goes into focus first. If two programs tie, pick the one that comes earlier in a new member's path through the server: onboarding, then support, then events, then announcements, then moderation. Onboarding often wins the first round. New members decide quickly whether a server is worth their time, and the first days are where an unclear entry costs you the most. It is also the program whose problems spill into the most other programs.

Writing the baseline that ends the focus period

The baseline is the written condition that says a program is good enough to go back into maintenance. Write it before any work starts. Without it, focus never ends: the person improving the program keeps polishing, the rotation stalls, and you are back to one program getting all the attention forever. A good baseline has three parts:

1. The problem you picked the program for is gone, checked by reading the server rather than by feel.
2. The program can run on a maintenance standard without extra effort from the person who improved it.
3. The changes are written down wherever your team keeps its docs, so anyone on the team can maintain them. Then set a review date, four to six weeks out as a starting point. Here is what a baseline for onboarding might look like:

Focus: Onboarding
Picked because: new members keep asking in #help where to start.
Done when:
  1. Two weekly checks in a row find no "where do I start" posts in #help.
  2. Every customization question leads to a channel that exists and is active.
  3. The onboarding setup and welcome message are written up in the staff docs.
New maintenance standard: every introduction post gets a reply from a person within one working day, and a staff test account clicks through onboarding on the first Monday of each month.
Review date: [date]

At the review date, one of three things is true. If the baseline is met, rotate. If it is nearly met, extend once, for a short fixed period, and write the new date on the board. If it is far off, shrink the baseline to what has been reached, move the rest to the parked list, and rotate anyway. The rotation only works if it keeps moving.

Setting the rotation order

The default order follows a new member's path: onboarding, then support, then events, then announcements and content, then moderation. At each rotation, run the three scoring questions again rather than following the order blindly. A program that slipped below its standard during someone else's focus period may need to jump ahead. There is one interrupt, and only one. If moderation cannot hold its standard because of scam links, a raid or harassment, moderation goes into focus immediately. The current focus program drops into maintenance, its progress gets written on the board, and it picks up again when the server is safe. Nothing else interrupts. A founder asking for a new event series is a parked idea, not an emergency. Write it on the parked list with the date it came in, and tell them which month events are in focus. A date is usually enough to settle a request.

Everything goes on one board the team can read in ten seconds

Put everything on one board in a staff-only channel. A pinned message that the Community Lead edits every Monday works. So does a single post in a staff forum channel. Keep it short enough to read in ten seconds:

STAFF BOARD, updated every Monday

IN FOCUS: Onboarding
Done when: no "where do I start" posts in #help for two weekly checks, every onboarding answer leads to an active channel, setup written in staff docs
Review date: [date]

MAINTENANCE                     STANDARD                                   LAST WEEK
Support                         first reply on every help post, 1 working day   met
Events                          weekly session, posted as Scheduled Event       met
Announcements                   one update a week from the template              missed, back on track
Moderation                      every report reviewed the same day               met

NEXT IN FOCUS: Support
PARKED IDEAS: monthly AMA format (events), new FAQ layout (support)

Review it once a week for fifteen minutes with three questions. Did every maintenance program meet its standard? Is the focus program closer to its baseline? Is there a safety problem that triggers the interrupt? The board does a second job too. When leadership asks what the community team did this month, the answer is already written: one program reached a baseline you can show them, and four programs held a standard you can point to.

The same team, before and after

	Before	After
Where improvement work goes	Spread across every program	Into one program at a time
What the other programs get	Whatever time is left over	A written one-line standard
How you know an improvement is finished	You do not	A baseline written before work starts
What happens to new ideas	Started the day they come up	Parked until that program's turn
What the team reports each month	"We worked on a lot"	"Onboarding reached its baseline, the other four held their standard"

Rotation decides the order of the bigger work

Focus rotation is a way to sequence the work inside a community's operating rhythm: onboarding, support routing, engagement rhythm, moderation and reporting. Each of those parts has its own design work, and each one is a bigger job than a single article. The rotation leaves that work in place and decides the order it happens in, so a small team finishes onboarding, support routing and the rest one at a time instead of starting all of them at once.

Do this this week: list your programs, write a one-line maintenance standard for each, score them with the three questions, write the first focus program's baseline and review date, and pin the board in a staff channel.

Rotation gives your team an order to work in, and each program still needs its own design once its turn comes. My other articles live at https://danieljeong.org/articles if you want to read further before the next focus period. For a second opinion on which program should go first, ask for my free community analysis at https://danieljeong.org/free-analysis, and I'll tell you exactly what's working, what isn't, and what to fix first. Running onboarding, moderation, engagement and monthly reporting for a team is what my service does at https://communitymanagementpro.com.

Teams with only a few people improve a whole community fastest by leaving most of it alone for a few weeks, on purpose and in writing. Pin the board today and pick the first program. danieljeong.org