# Structuring a Discord staff team past ten people > At ten people a Discord staff team becomes an organisation. What breaks is not conduct but ambiguity over who owns a decision and who may change what. - Canonical: https://discordservers.blog/blog/discord-staff-team-structure - Published: 2026-08-30 - Author: The Journal desk - Facts checked: 2026-08-30 - Sources: - Discord Safety — Managing Moderation Teams (https://discord.com/safety/managing-moderation-teams) — checked 2026-08-30 - discord/discord-api-docs discussion 4864 — bots requesting Administrator (https://github.com/discord/discord-api-docs/discussions/4864) — checked 2026-08-30 - docs.vetox.io — Applications (https://docs.vetox.io/en/utility/applications) — checked 2026-08-30 - docs.vetox.io — Access Control (https://docs.vetox.io/en/server-management/dashboard-permissions) — checked 2026-08-30 - docs.vetox.io — Dashboard Watcher (https://docs.vetox.io/en/server-management/dashboard-watcher) — checked 2026-08-30 - Publication: The Journal, an independent site not affiliated with Discord Inc. --- Past roughly ten staff, a Discord team stops being a group and becomes an organisation: it needs named functions, a written escalation path, tool access narrower than Administrator, and a record of who changed what. The failure at this size is rarely misconduct. It is ambiguity about who owns a decision. The symptom is that two people fix the same thing differently, on the same day, and neither knows the other did it. ## What actually breaks at ten staff? Three things break at once, and they are easy to mistake for a people problem. **Coordination cost overtakes capacity.** Below about six moderators, everyone reads everything. Above ten, nobody does. A report handled in one channel is invisible to the person who handles the same member's next report, and the second decision contradicts the first — which is [the variance problem that a written policy exists to solve](/blog/writing-a-moderation-policy), reappearing at team scale rather than at server scale. **Access outgrows trust.** To let someone tune the automod, you handed them Administrator. Now eleven people hold the permission that can also delete every channel, and you gave it to them one reasonable decision at a time. **Nobody owns the configuration.** Settings drift. A log channel gets pointed somewhere else, a levelling multiplier changes, a ticket panel loses an option, and there is no answer to "who did this and when" because Discord's own audit log does not see anything that happens in a bot's dashboard. ## How should the team be divided? By **function**, not by seniority. Seniority tiers produce a queue where every hard decision travels upward; function tiers produce owners. | Function | Owns | Decides alone | Escalates | | ------------- | ---------------------------------------------- | ------------------------------------ | ---------------------------------- | | Response | Reports, chat moderation, first-line tickets | Warnings, timeouts, mutes | Anything permanent | | Community | Events, engagement, welcome flow, self-roles | Anything reversible in the same day | Anything that changes a rule | | Configuration | Bot settings, logging, automation, permissions | Config changes inside their own area | Anything touching moderation gates | | Adjudication | Bans, appeals, staff conduct, precedent | Everything above | Nothing — this tier is the end | Four functions covers most communities up to a few tens of thousands of members. The point of the table is not the labels; it is that each row has a column that says _decides alone_. A team without that column escalates everything to the owner, and the owner becomes the bottleneck they were trying to delegate away. The adjudication row is the one small teams skip, and it is the one that makes [a review process for your own mistakes](/blog/discord-appeal-process) possible — an appeal has to be read by someone who did not make the original call, which requires a tier that exists for exactly that. Discord's own guidance for moderation teams is worth reading alongside this — it is explicit that team members "should always be given the option to take a break from moderation to avoid burnout", which is a structural instruction, not a wellbeing platitude. A rota that cannot lose a person for two weeks is not a rota. It is a set of single points of failure with names. ## Why does Administrator become the problem? Because Discord's permission model is coarse, and the coarseness bites at exactly this size. There is no native way to say "this person may configure the spam filter and nothing else". The nearest available grant is Administrator or Manage Server, both of which carry the ability to restructure the entire server. Discord's own developer community has argued about the equivalent problem for bots for years — one maintainer's position in the API discussion is that "bots shouldn't be able to request admin in the invite", countered by the argument that server managers should keep the authority to grant it. Both sides agree on the underlying fact: Administrator is a blast radius, not a permission. The staff version of that argument is the same one. You are not worried that your community manager will delete the server. You are worried that eleven accounts can, that one of them will reuse a password, and that the recovery cost is measured in months. ## What does delegated access actually look like? The fix is to move the fine-grained permission out of Discord and into the tool, then keep Discord's Administrator list as short as it can be. Vetox's **Access Control** does this on the dashboard side. Without it, every Discord administrator sees and can change every page. With it, an entry pairs one or more roles and/or specific Discord users with the exact set of sections they may open — **40 grantable sections in 11 groups**, covering each moderation surface, each community feature, the eight notification platforms, tickets, applications, monitoring and administration. Up to 25 entries per server. Everything else collapses to the overview page. Two details are what make it real rather than cosmetic: **It is enforced server-side on every request**, not by hiding sidebar entries. A delegated administrator who guesses a URL gets a 403, not the page. **The page can lock itself.** A switch labelled Restrict Protection makes Access Control itself owner-only, which closes the escalation loop where a delegated administrator quietly grants themselves more. That loop is the entire reason most teams never delegate at all. Access Control requires Max ($7.99/month). Below that tier everything is visible to every administrator, which is workable for a team of three and stops being workable somewhere around the size this article is about. Two things pair with it and cost nothing: **Command Management** scopes the Discord side. Every command can be enabled or disabled individually, restricted to specific roles, restricted to specific channels, given prefix-free text aliases and given preset moderation reasons — free on every tier. This is how a trial moderator gets `/warn-add` without `/ban`, without anyone needing to hand out or withhold a Discord permission. **Dashboard Watcher** records what delegated staff actually changed: user, module, timestamp, and an expandable list of the individual settings that moved. It is free on every tier, keeps the most recent 500 entries for 90 days, and filters by module, time window and free text. Entries are written only when a save succeeds — so an absent entry means the change never took effect, which is a diagnostic in its own right. The three compose into one loop: **scope with Command Management, delegate with Access Control, verify with Dashboard Watcher.** Delegation without the third step is just hope with extra steps. ## How do you know the delegation is working? Read the watcher a week after you grant something. You are looking for two failures. **Unused grants.** A section nobody has touched in a month should be removed from the entry. Access that is not exercised is pure risk with no offsetting benefit, and it accumulates because nobody ever proposes taking something away. **Grants that are being routed around.** If the person you gave the automod section keeps asking you to change the automod, the grant is not the problem — the interface or the confidence is, and more access will not fix either. ## Recruiting, and the part most teams get wrong The common mistake is recruiting for availability. Availability is real, and it is the thing that decays fastest — the enthusiastic volunteer who is online sixteen hours a day in month one is the person most likely to be gone by month four. Recruit for **judgement under ambiguity**, and test it with the thing you actually have: past cases. Give a candidate three real reports from your own logs with the outcomes removed and ask what they would do and why. The reasoning matters more than the answer, and it surfaces the one trait that cannot be trained quickly, which is the willingness to say "I do not know, I would ask". Run applications as a structured form rather than DMs, so the answers are stored, comparable and visible to the rest of the team. Vetox's Applications system does this inside Discord — a panel with Apply buttons, per-form questions, eligibility gates checked before someone can start, a review queue, and workflow actions that assign the role on acceptance rather than leaving someone to do it by hand. Starter allows 1 panel with 5 questions; Basic raises that to 3 panels and 15 questions and adds voting, review threads and eligibility roles; Max allows 10 panels with 50 questions. The reason to use it over a Google Form is not the form — it is that the decision is recorded against the Discord identity, with who made it, which is the same evidentiary standard the rest of this article is arguing for. ## Rotating people out Every staff team needs a way to leave that is not a resignation. Name it before anyone needs it: an inactive or emeritus tier that keeps the person in the community, removes the obligation, and removes the permissions. Without that path, the only exit is a dramatic one, and people who are quietly done stay on the roster with full access for months because leaving would look like a statement. Remove the access on the same day, always, and without it being a judgement. A team that treats permission removal as an accusation will never remove permissions, which is how a server ends up with Administrator held by four people who have not opened it since last year. That habit is also the cheapest [burnout prevention](/blog/discord-moderation-burnout) available: the exit being routine is what makes taking a break thinkable. ## The shortest version Split by function so every decision has an owner. Delegate tool access instead of Discord permissions. Record what changes. Recruit for judgement, and build the door out before you need it. The teams that survive their own growth are the ones that wrote this down while it still felt like overkill.