You Hired a Community Manager and You're Still the One Putting Out Fires

Why Hiring Help Doesn't Always Mean Getting Out

There's a pattern that shows up in almost every conversation I have with founders who've tried to get help with their Discord community. They hired someone. They expected to step back. And then, a few weeks later, they realized they were more involved than before. Not because the person they hired was incompetent. In most cases, the person was doing exactly what they were hired to do: showing up, staying active, posting content, engaging with members. The problem was never the person. It was the absence of any structure underneath them. When a community manager joins a server that has no defined systems, they inherit a situation that was already dependent on constant human attention. The channels aren't organized around user journeys. The moderation guidelines exist somewhere in a document nobody looks at. The escalation process is "message the founder." The onboarding flow is someone manually welcoming people when they notice a new member joined. So the CM shows up, learns the unwritten rules, and begins doing what they observe being done. They start managing by presence. And because they can't be present every hour of every day, gaps form. Those gaps get filled by whoever is most available — which is usually the founder. The hiring didn't solve the problem. It just added one more person to a broken system.

What a Community Manager Is Actually Being Asked to Do

When most founders post a job listing for a Discord community manager, they're describing a set of actions: moderate content, engage with members, schedule announcements, manage roles, run events. These are execution tasks. What they're not describing is architecture. They're not asking for someone to audit the server structure, design a scalable onboarding flow, write escalation protocols, or build documentation that lets any future team member understand how the server operates. That's not because founders don't want those things. It's because they often don't know those things are separable from execution. They are. Execution without architecture produces a community that works when the right person is online and breaks when they're not. Architecture without execution produces a well-designed server that nobody actively cares for. The strongest communities have both. But when a founder is hiring their first CM, they almost always get someone focused on execution. The architecture side gets skipped. And because architecture is what removes the founder from the operational loop, the founder never actually gets removed.

The Specific Ways Founders Stay in the Loop

This plays out in predictable ways. A member asks a question that falls outside the CM's judgment. The CM, unsure how the founder would want it handled, tags the founder. The founder answers. The member is satisfied. Nothing is documented. Three weeks later a different member asks the same question and the same cycle repeats. A moderation situation comes up that feels borderline. No written protocol exists, so the CM escalates. The founder weighs in. The decision gets made, but it lives only in a direct message thread between the founder and the CM. The next moderator won't have access to that context. A product announcement is coming. Nobody has defined who drafts the announcement, who approves it, what channels it goes in, or what the response protocol is when questions flood in. So pieces of that coordination happen between the founder and the CM in real time, the night before. None of these situations are disasters. But all of them keep the founder in the building. Over time, being in the building becomes exhausting. The founder starts resenting Discord not because the platform is bad, but because it demands their attention in ways they can't fully hand off.

What Changes When Infrastructure Exists

When a server is built with systems rather than relying on individual judgment calls, several things change immediately. The CM has documented answers to common questions. When something falls outside their scope, there's a written escalation ladder that tells them exactly who to involve and when. The founder only appears at the top of that ladder, for situations that genuinely require them. New member onboarding happens through a structured flow, not through whoever happens to be online. Members are guided from entry to their first meaningful interaction without requiring manual attention for every single person. Announcements follow a defined process. There's a template, a review step, a posting window, and a response protocol. The CM executes that process. The founder reviews the announcement content, not the logistics of how it gets posted. Moderation decisions below a certain severity level are handled by written guidelines rather than personal judgment. The CM applies the framework. Escalations above that threshold follow a documented path. None of this removes the CM from the picture. The CM is still essential for the human layer: recognizing when something feels off before it becomes visible, building genuine relationships with active members, and adapting the systems as the community evolves. But the CM is no longer the only thing standing between the server and chaos. The infrastructure absorbs a significant portion of the operational load.

The Difference Between Presence and Infrastructure

One of the most common things I hear when I start working with a new client is that their previous CM "was always in the server." That phrase is meant as a compliment. It signals dedication, involvement, availability. But a CM who is always in the server is often covering for the absence of systems. When there's an onboarding flow, they don't need to manually welcome every member. When there's a moderation framework, they don't need to be online to catch every violation in real time. When documentation is comprehensive, they don't need to answer the same questions repeatedly. The most effective CM work happens when the person spends less time reacting and more time improving the systems themselves. That looks quieter from the outside. It doesn't produce visible daily activity. But it produces a server that handles its own operations at a level that presence-based management never could. Founders often find this counterintuitive. They equate visibility with value. A CM who is constantly posting and engaging looks productive. A CM who spent the week refining the onboarding flow and writing escalation protocols looks like they weren't doing much. The second CM is the one who actually removes you from operations.

What to Look For If You're Hiring

If you're evaluating a CM and you want to eventually step back from daily involvement, ask them how they approach situations where no written guidance exists. A presence-focused CM will tell you they use their judgment and escalate when they're unsure. That's a reasonable answer, but it describes a system where judgment calls accumulate and escalations eventually find their way back to you. A systems-focused CM will tell you they identify recurring situations, document how they were handled, and build those decisions into the operating framework so the same question doesn't require fresh judgment every time. That second approach is what produces infrastructure. It's slower at the start and faster at scale. The goal isn't to hire someone who works hard inside a broken structure. The goal is to hire someone who recognizes the broken structure, fixes it, and then maintains what they built.

If You're Already In This Situation

If you have a CM and you're still the one getting tagged when things go wrong, the answer isn't to find a better CM. The answer is to audit the infrastructure and fill the gaps that are routing problems back to you. Start with escalations. Map every type of situation that results in you being contacted. For each one, ask whether a written protocol could handle that situation without your involvement. In most cases, it can. Then document those protocols. Not in a way that's exhaustive or formal, but in a way that's findable and usable. A document your CM can actually reference is worth more than a comprehensive policy manual that lives in a folder nobody opens. Once escalation paths are written down, work backward through the other systems: onboarding, announcement workflows, moderation thresholds, role assignment logic. For each one, ask whether it requires a person to be present or whether it can run through a defined process. The goal isn't to automate everything. Human judgment matters in community work, and the nuance of relationship-building can't be systematized. The goal is to push routine operational decisions into documented frameworks so that human judgment is reserved for situations that actually require it. When that work is done, you'll notice something that's easy to miss: Discord becomes quiet. Not because the community is less active, but because the server is handling itself. That's the sign that the infrastructure is working.

Most community problems aren't people problems. They're structure problems. When the structure is right, the right people can do their best work. https://danieljeong.org