Who Runs Your Community After You've Designed It?
Designing the right community formats and structural layers is only half the job. Someone still has to run them.
A community manager I worked with years ago used to keep her phone on the nightstand, not because anyone required it, but because a new post could show up at eleven at night and she genuinely believed she was the one who had to answer it. She wasn’t wrong that someone needed to respond eventually. She was wrong about who that someone had to be. It took a bad month, not a bad year, before that assumption caught up with her.
That assumption is more common than it should be, and it usually isn’t stated out loud. A team designs a thoughtful set of formats and layers, gets the structure right on paper, and then assumes, without ever really deciding to, that the same one or two people who built it will also be the ones running every part of it forever.
The architecture scales. The staffing plan under it doesn’t, and that gap is where good programs start to buckle.
Deputize, don’t just delegate
The cheapest way to scale the operating side rarely means more headcount. Most of the time, it means handing pieces of real ownership to the members who are already doing the work informally: answering questions before staff gets to them, welcoming newcomers unprompted, keeping a channel useful on their own time without anyone asking them to.
Most of those people don’t especially want a title. What they want is a trade that feels fair: some combination of earlier access, a direct line to the team, recognition that’s visible to their peers, or a genuine say in how their layer of the community runs. Offer that trade explicitly, and you turn a volunteer instinct into a role with real accountability attached, instead of hoping the goodwill holds up indefinitely on its own.
This only works if the ownership is real.
A community advisory badge that comes with no actual authority is a participation trophy, and members notice the difference immediately. Give a deputized member something to actually decide, whether that’s who gets welcomed into their specific layer, what the recurring format for their group looks like, or which questions get escalated, and the trade holds. Skip that part and dress it up as a title instead, and you’ve just created an unpaid role with extra steps.
Not every container needs the same rules
The second piece of the operating model is deciding what each format is actually for before you decide how to moderate it. A blog-style post and a forum thread look similar on a screen and behave completely differently once people start responding.
A broadcast piece, something meant to be read, is a different kind of container than a discussion piece, something meant to be argued with. Treat them the same, and an announcement about a hard product decision turns into an unmoderated debate in the comments, while a genuine discussion thread gets flattened into something that reads like an official statement because nobody feels safe disagreeing there.
Splitting content by purpose rather than by topic fixes more of this than people expect. Read-this content gets a container built for clarity and a lighter moderation touch, because the goal is comprehension, not debate. Discuss-this content gets a container built for disagreement, with moderation calibrated for tone rather than dissent, because the goal is genuinely working through something together. That split is really a decision about which conversations you’re actually inviting. Get it wrong, and the container shapes the conversation more than the topic does.
The restraint nobody teaches
The last piece is the hardest one to sell to a team that prides itself on responsiveness. Sometimes the right call is to wait.
The instinct to answer every new post within minutes feels like good service, and in the first weeks of a community it often is. Past that point, it starts working against you. If staff always gets there first, members stop bothering to answer each other, because why would they, when the “real” answer is coming from the team anyway. Peer-to-peer discussion never gets the chance to become a habit, and the community turns into a support queue with a nicer name, without anyone ever deciding that’s what it should be.
Holding back for a day, sometimes two, on a post that isn’t urgent gives other members room to try answering first. Some of those answers will be wrong or incomplete, and that’s fine. A staff member can still step in afterward to correct or add context. What matters is that the first attempt came from a peer, because that’s the moment a community starts teaching itself to function without staff in the room. It’s uncomfortable to practice. From the outside it can look like inaction. From the inside, it’s one of the more deliberate calls a community operator makes.
Deputizing members, splitting containers by purpose, and building in restraint don’t take a bigger team or a new platform to pull off. They take a decision, though: that the architecture built last month isn’t finished just because the formats and layers exist. Somebody still has to decide who runs each part, and whether that person is going to be you, forever, or someone you’ve actually trusted with a piece of it.
Decoded Takeaways
A well-designed set of community formats and layers still fails if one person is expected to personally staff all of it. Fixing that rarely takes more headcount. It takes a real operating model, built on three decisions: hand actual ownership, not just recognition, to the members already doing the work informally; split content into broadcast and discussion containers, with moderation calibrated to each one’s real purpose; and build in deliberate restraint so members get the chance to answer each other before staff steps in.
Deputizing only works if the ownership is genuine. A badge with no real authority is a participation trophy, and members can tell the difference. The blog-versus-forum split is really a decision about which conversations a container is actually inviting, and mismatching that decision is what turns announcements into arguments and discussions into statements. Restraint is the least intuitive of the three. Holding back can look like inaction from the outside. From the inside, it’s one of the more deliberate calls that teaches a community to function without staff in the room.
Design gets a program most of the way there. Who runs it, and how much room they’re given to run it, is what determines whether the design survives contact with an actual community.