Unfortunately, it looks like you are using an outdated browser.

To improve your experience on our site and ensure your security, please upgrade to a modern browser such as Chrome, Firefox, Safari, or Edge.

Skip to main content

The Community Lounge » Internal communication for community managers: How to talk to your team

Internal communication for community managers: How to talk to your team

This guide dives into the often-overlooked internal side of community management. Here’s what you’ll learn:

Most guides about community management focus on the outward-facing side. How to post, how to moderate, how to respond to angry players. But it’s also only half the job.

The other half happens inside the studio: convincing a developer that a frustration pattern is real, summarizing 400 Discord messages into something a producer can act on, figuring out who to tell what and when.

“A lot of Community Managers that get into the profession, they only focus on the players and they don’t really think about, well, I’m presenting the stuff that the game designer, artists, or producers are working on, but do they actually trust me? And if they don’t, that can cause problems later. So I would also like, please take the internal communication seriously as well.” – Dennis Abe (S02E06)

From the conversations I gathered on The Community Lounge podcast, internal communication came up again and again. Not as a skill people were taught, but as something they had to figure out on their own. This guide collects what they learned.

1. You are the bridge (and the cushion)

The community manager sits between two groups that rarely speak the same language.

Players speak in emotions, anecdotes, and demands. Developers speak in priorities, constraints, and timelines. The CM translates in both directions.

“Because I view it as primarily my job to communicate to the devs what the players think and the players what the devs are thinking. Like to be that bridge of communication, to make it so everyone understands each other.” – Jeremy Fielding (S01E02)

This sounds simple, but it creates a specific tension: players can start to see you as “the studio’s mouthpiece,” and devs can see you as “the community’s advocate.” Neither is accurate. Your job is to represent reality in both directions, not to take sides.

Thomas Schramm puts it more bluntly:

“At the end of the day, you’re not doing the product. You are not iterating on it. The product will be released without you. You are the cushion between the product and the bridge of communication between the product and the consumer.” – Thomas Schramm (S02E03)

The “cushion” framing matters. You absorb impact from both sides. Players vent at you because you’re the closest person to the studio. Developers push back through you because you’re the closest person to the community. Being comfortable in that position is the foundation for everything else in this guide.

2. Learn the game, the team, and how decisions get made

Before you can communicate effectively inside the studio, you need to understand what you’re communicating about. That means going deep on three things: the game itself, the people who build it, and the processes they use to make decisions.

Start with the community.

“If it is an already existing community, you’ve got to go deep into the lore of that community. I’m not just talking like, what’s this game about? I’m talking like, which of the moderators hate each other because of X, Y, Z reason?” – Charis Reid (S03E04)

This isn’t optional. If you don’t know what the community cares about, your reports to the dev team will be shallow. You’ll escalate the wrong things. You’ll miss the signals that matter.

Then learn the team. Not just their names and roles, but how each discipline thinks and what their priorities are.

“You need to know how a Programmer works. You don’t need to know how to do their job, obviously. But you need to know what an Artist is doing. You need to know what a Game Designer is looking for. You need to know exactly what the priorities of each field are. And your job is to kind of bridge that knowledge gap.” – Victoria Tran (S02E11)

A lot of this learning happens informally. Sit in on stand-ups, even if you have nothing to contribute. Eat lunch with developers. Ask QA what they’re testing. These small moments build the understanding that makes your internal communication actually useful.

“A lot of days actually I eat with the game designers and we’re talking about concepts of game design and how we think about making games. And I think if I wasn’t doing this, I would have such a much poorer understanding of how we go about things. I’d be so much worse at communicating with our players.” – Jeremy Fielding (S01E02)

At Stunlock Studios, they have a Swedish tradition called Fika: a daily coffee break at 9:30am and 3pm where the whole team sits together for 15-20 minutes. Jeremy credits these informal sessions with shaping his understanding of the studio’s thinking. If you work remotely, you lose this by default. Find ways to replace it.

If you’re starting a new role, also push for structural clarity early. What’s your scope? Who do you report to? Who reviews external communication before it goes out?

“You can really tell from a community manager listing whether the company that’s behind that actually knows what they want. Sometimes they just need like three people, but they want you to do everything.” – Thomas Schramm (S02E03)

Some practical onboarding steps:

3. Talking to developers

This is where most of your internal communication energy goes. And it’s where the biggest mistakes happen.

Build trust first

The CMs who get the most freedom are the ones whose internal teams trust them. Trust isn’t given. It’s built through consistently accurate, well-framed communication over time.

“If the developers and the company trust you, you have so much more freedom on what you want to do with the players.” – Dennis Abe (S02E06)

One concrete way to build that trust: make predictions. When you sit in sprint reviews or brainstorming sessions, speak up about how you think the community will react. Then follow through.

“Your time as a CM is spent in two phases. One is, I’m telling you now, and the other is, I told you so. You might be in a brainstorming session or going over the next content update or a sprint, and you’ll pitch in saying, hey, I’m telling you now, I think players will react this way or that way. And then we go forward with it and then the reactions come in. And because you kind of see the future a little bit, understanding your community so much, you point and say, aha, I told you so.” – Lyn Dang (S01E04)

When your predictions are right, and you can point to the evidence, you build credibility. The team starts consulting you earlier in the process rather than after the fact.

“This is how you solidify. Like, I’m the CM and this is what I’m here for. I truly understand the player base and I’m advocating for them. Giving them a seat at the table, so to speak.” – Lyn Dang (S01E04)

Understand their constraints

The single most effective thing you can do for your credibility with developers is to understand what they deal with.

“I’m not as delusional, I hope, when I ask of stuff from the developers now, but I think it has given me some strengths in understanding of just how, what kind of effort and resources goes into the development.” – Dennis Abe (S02E06)

You don’t need to code. But you need to understand that “just add this feature” is rarely simple. When you bring feedback that accounts for development effort, timelines, and trade-offs, developers take you seriously. When you bring raw community complaints without context, they tune you out.

Dennis takes this a step further. He suggests CMs should apply the same empathy they show players to their internal colleagues:

“When you get requests from players, how urgent does that feel versus when you get a request internally? A lot of the times people prioritize the player. But the programmers need to know how players feel about this specific feature. How can you get that to them? How can you understand what they’re looking for? It’s almost looking at a different type of player. You have to kind of decipher what they want as well.” – Dennis Abe (S02E06)

Developers are another audience you need to understand. That reframe changes how you approach internal communication.

Speak their language

Different stakeholders need different communication styles. This is one of those things nobody tells you, but it changes how effective you are.

“The way you talk to your product manager is a little bit different than to management or a little bit different to your game designer. And each time, I think finding the right ways to talk to people is also one of your jobs as well.” – Christian Jürgensen (S01E05)

A producer wants volume and trends: “40 complaints about matchmaking since the patch, up from 5 the week before.” A game designer wants specifics: “Players are saying the new weapon feels slow because the reload animation locks them out of movement.” A manager wants risk assessment: “This has the potential to become a review-bombing event if unaddressed.”

Same feedback, different packaging.

Filter the noise, protect the team

Community feedback often comes wrapped in anger, personal attacks, and demands that someone be fired. Your colleagues don’t need to see that. The CM acts as a filter: extracting the signal and delivering it in a form that’s useful, not hurtful.

“As a community manager, you read that and you try to figure out, okay, how many people do actually hate this feature, then you work with sentiment trackers or tools. Because suddenly you can quantify things and then you can go to the team and tell the team, hey, we introduced a new feature in the last patch. This new feature is perceived relatively negative because of the following reasons. And then the person who designed or worked on the feature can be like, okay, this and this is stuff that I maybe expected… But they are shielded from ‘you should be fired.’ You can, in a completely neutral manner, deliver feedback to them, which helps them to do their work in a better way.” – Florian Rohde (S01E07)

The word “neutral” is key. Your job isn’t to make feedback sound nicer. It’s to strip away the personal attacks and present what’s actually being said, with numbers when possible, so the team can act on it.

What players care about is not what developers care about

This is one of the most useful insights for structuring your internal reports. The development team has spent months on a specific feature. They’re proud of it. They want the community to react to it. The community, instead, is obsessed with something the team considers trivial.

“It’s a really interesting concept that what you find interesting about a game will not be the same thing that people find interesting about the game.” – Joshua Mathews (S03E05)

Your job is to bridge this gap honestly. Don’t filter out feedback that contradicts what the team expects to hear. And don’t soft-pedal disappointing reactions to avoid awkwardness. The team needs to know what the community actually cares about, even when it’s not what they hoped.

This also works in reverse. When the audio engineer says “I worked really hard on this and no one’s talked about it,” the CM can surface that topic in community spaces, steer a conversation, and bring back the response. The CM is an information channel in both directions.

Reporting this gap well requires more than just data. Numbers tell part of the story, but not all of it.

“We can write reports that are pages and pages long about how people feel, why people feel that way, and what we should do about it. But I really feel like solid numbers do not always tell the story and one of the skills that is important to a Community Manager is their gut. Being able to communicate what that feeling is that you’re getting is also quite important.” – Joshua Mathews (S03E05)

Your work shows up in the game

Community management sometimes feels invisible. You’re gathering data, summarizing, escalating, and it all happens behind the scenes. But when it works well, community input directly shapes the product.

“There is so much of my work that has ended up in games because so much of my work is keeping the conversation going between developers and players and developers listen to me, and players listen to me.” – Charis Reid (S03E04)

This only happens when the feedback loop is consistent and trusted. One-off reports get ignored. Recurring, well-structured updates that connect community sentiment to specific features and decisions build the kind of trust where developers start asking you what the community thinks.

When developers should be in community spaces

Some studios keep developers out of community channels entirely. Others throw them in without guidance. Neither approach is ideal.

“There was just always a member of the team in there. It wasn’t necessarily the community manager. You’d have like the lead dev, you’ve had game designers, you have QA and they’d just be in there talking to people.” – James Croucher (S01E01)

Developer presence in community spaces is valuable, but it needs to be structured. Not every developer should be responding to frustrated players. Some developers take negative feedback personally and react emotionally.

“There’s a reason community managers are community managers and developers are developers a lot of the time. And the fact is, if you’re working on a game that does invite some toxicity or has some negative kind of feedback towards it, it’s easy to be a developer, go on there and just want to scream at someone” – James Croucher (S01E01)

The CM’s role here is to structure and de-risk developer participation. Set guidelines for what developers should and shouldn’t respond to. Make it clear that the CM handles heated conversations. Create safe opportunities for developers to interact with the community on positive topics like design insights, behind-the-scenes content, or answering technical questions.

4. Working across departments

Community management doesn’t only connect to the development team. Marketing, support, production, and leadership all need community intelligence, but in different formats and at different frequencies.

At the lead level, cross-departmental communication becomes a major part of the job.

“Half of my day minimum I spend in meetings to sync with my team, but also sync with the global team. Be in touch with our brand team, marketing team, PR teams. Because we have a lot of power in that we have our publishing structure within the studio. So that means that we can impact a lot of things, but that also comes with a lot of meetings about how we impact these things.” – Carolin Wendt (S01E08)

Even if you’re not at the lead level, collaborating with other departments makes your work better. You don’t have to do it alone.

“I’ve loved working with producers and designers and the analytics department as well. These are people that can really help you get a better perspective on things. QA as well. Even if it’s for like, hey, you know, I drafted this announcement, what do you feel about it? If you were a new player and you read it. You can ask anyone, but ask for help.” – Nicolas Nottin (S02E05)

Having a producer sense-check your announcement before it goes out costs nothing and catches blind spots. Having analytics confirm whether the sentiment pattern you’re seeing matches the data makes your reports harder to dismiss.

How organizational structure shapes access

Where you sit in the company changes how your internal communication works. A CM embedded with a developer has direct access. A CM at a publisher has layers between them and the people who build the game.

“Working for a dev is very different to working for a publisher. Working with a developer, if a community member comes to you with a question about the game, you can literally just get on a call to the dev and say, I’ve got a question, can you answer it? Easy. With a publisher, the dev is a few steps away. They’re not quite so easy to get a hold of.” – Vicki Fieldhouse (S03E06)

If you’re at a publisher managing multiple titles, you probably can’t know every game inside out. That makes your communication style different: you ask more questions, you document more carefully, and you rely on structured check-ins rather than hallway conversations.

Don’t just report problems

Internal communication isn’t only about escalating issues. One of the most overlooked parts of the CM role is bringing good news back to the team.

“I really like that I get to take everything that we get from social media, all the comments and all the likes and everything, and just kind of push it onto my colleagues and like, there you go. I said that you were awesome from the first thought. Look at it. Everyone is agreeing with me.” – Sofia Pettersson (S02E09)

Developers often don’t see the positive feedback. They see bug reports, they see patch complaints, they hear about the fires. When you relay community praise back to the team, you’re doing something small that has an outsized effect on morale. Sofia noted that her colleagues sometimes struggle to accept praise from her alone, but when she shows them the community saying the same thing, it lands differently.

Some practical patterns for cross-departmental communication:

The key principle across all departments: figure out what each team actually needs from you, and deliver it in their preferred format. A monthly summary deck works for leadership. A Slack message with three bullet points works for marketing. A Jira ticket with reproduction steps works for QA.

5. Translating decisions to players

The outward-facing side of the bridge gets its own section because it requires a different mindset. Internally, you advocate for the community. Externally, you explain the studio’s decisions.

Both directions require honesty, but external communication has an additional layer: empathy. Players don’t have the context you have. They don’t know why the patch was delayed, why a feature was cut, or why their favorite bug was “fixed.” Your job is to provide that context in a way that respects their experience.

“Make sure with your players, you’re building trust. You are approachable, you show empathy. Make sure you show that you listen, showing that you care.” – Greg Cummings (S03E08)

Being honest doesn’t mean sharing everything. It means being truthful about what you can share, including the process constraints that players don’t normally see.

“Players don’t know what goes on behind the scenes. Players don’t know that we need to be able to replicate a bug before we can fix it. So I think it’s just a case of being honest with them and just saying, until we can replicate it, we can’t fix it. I’m really sorry that’s happening to you.” – Vicki Fieldhouse (S03E06)

This kind of transparency, explaining the why behind delays or limitations, turns frustration into understanding. Most players aren’t unreasonable. They just lack context.

When players report bugs or request features, you can also frame the interaction as a collaboration rather than a complaint box.

“I cannot promise you that we are going to fix this issue, but together we can do something better. We can maybe make the team aware of that, and maybe the team, if they have the bandwidth, can fix it. It’s not going to be good just for you, it’s going to be good for a lot of players. For me, it’s like the player was temporarily a member of the Dev Team.” – Hichem Taleb (S02E04)

Some principles for translating internal decisions into player-facing messages:

6. Build your internal communication toolkit

The difference between a CM who gets listened to and one who gets ignored is often not insight, it’s format. Developers drown in information. If your reports look like everything else in their inbox, they’ll get skipped.

“I will create a strategy and plan that I want them to be on board of. They will get to be part of it all. I’ll give them the feedback that one feels to have ownership of the strategy. And then we have a sync meeting once or twice.” – Erik Jakobsson (S02E02)

Regular rituals beat ad hoc reports. A weekly community sync, even if it’s 15 minutes, builds a habit. The team starts expecting your input and planning around it.

Conclusion: The Invisible Half of the Job

Internal communication is often the invisible half of community management. However, this behind-the-scenes work is exactly where your biggest impact lies. By acting as a neutral translator, building trust with your developers, and protecting your team from the noise, you turn community feedback into actual product improvements.

In studios where community management is still finding its footing, it can be challenging to show leadership how much player sentiment matters. Mastering your internal communication bridges that gap. By building trust and sharing data clearly, you stop being seen as just a “social media moderator” and start being seen as a strategic partner.

And once that happens, the entire dynamic shifts: you will find game producers and designers actively coming to you for input before creating new features or deciding how to move forward with the game.

Getting to that level takes time, patience, and a lot of trial and error.

If you are just stepping into a new role and still trying to figure out how your studio operates, building this bridge might feel a bit overwhelming. Don’t panic. If you are still navigating that initial chaos, we recommend taking a step back and reading our guide:👉 Your first week as a community manager: What actually matters. It covers the essential survival skills you need to nail down before you start reshaping your studio’s internal communication.