Giving and receiving feedback without making it weird
Based on true stories ;)
You know that silence. Someone just got feedback, they go very still, say “okay, thanks” in a tone that means the exact opposite, and you both spend the next five minutes pretending that was a normal conversation. You’ve been on both sides of it. So have I.
The games industry is genuinely bad at this. We pitch games and get non-answers dressed up as feedback. We send builds and get “looks great!” from people who clearly launched it for thirty seconds and closed it. We sit in review meetings where nobody says what they actually think - and then the project ships broken and everyone acts surprised.
And then there’s the other kind. Someone decides that honesty means skipping the part where they consider you’re a human being. That one leaves a mark too. I do appreciate honesty, but being an ass is not something I consider a professional skill, no matter how senior you are.
Neither works. I’ve been on enough sides of this table to have opinions about what does.
Why feedback goes wrong
Before we get into technique, it helps to understand why feedback conversations fail in the first place. There are usually three reasons.
The first is that the person giving feedback hasn’t decided what they actually want to achieve. Are you trying to improve the work? Manage expectations? Document that you flagged an issue? These are different goals and they require different approaches. Feedback given without a clear purpose tends to be vague, contradictory, or more about the giver than the receiver.
The second is that the person receiving feedback hasn’t separated their identity from the work. This is especially common in games, where teams spend years on a project and the line between “my game” and “me” gets blurry. When that line disappears, feedback on the game feels like feedback on the person. Every note becomes a judgment. Every suggestion becomes a criticism. The defensiveness that follows isn’t weakness - it’s a predictable response to feeling personally attacked.
The third is that both parties are performing. The giver performs confidence and authority. The receiver performs openness and gratitude. Neither of them is being honest.
The feedback that gets said in that room is not the feedback that gets discussed afterward in the car park or at the after party.
Giving feedback that actually lands
There’s a framework I keep coming back to when I think about feedback done well. Five steps, simple in theory, consistently ignored in practice. Let me walk through each one with the gamedev context in mind.
Setting - choose the right moment
This one sounds obvious until you see how often it gets ignored.
A developer just came off stage after showing their game publicly for the first time. They’re running on adrenaline, relief, and anxiety in roughly equal measure. This is not the moment to tell them the combat feels off. This is the moment to be a human being - say something genuine and supportive, and save the detailed feedback for a few days later when they can actually hear it.
In practice: I once received bad news on a Friday afternoon - a message that we needed to talk on Monday because there were concerns about my performance. What followed was the worst weekend of my professional life up to that point. By the time Monday came around, I’d already processed every possible outcome, none of them good. The feedback itself ended up being manageable - we made a plan, I proved my value, and I stayed at that company for a long time afterward. But the timing was unnecessary cruelty. The person delivering it has since acknowledged the same. Don’t do that to people.
If someone sends you a build right before a milestone deadline and you have serious concerns, ask yourself whether those concerns can wait 48 hours. A developer in crunch who gets a wall of critical notes at 11pm on a Friday processes none of it. The same notes on Monday morning, framed properly, might actually change something.
Framing - say what you’re trying to do before you do it
Before you get into the content of your feedback, establish your intent.
“Everything I’m about to say comes from wanting to help make this better - can I share it?” is not a diplomatic nicety. It’s information. It tells the person you’re not attacking them, you’re not performing authority, you’re not ticking a box. You’re trying to be useful.
I’ve also learned - the hard way - to clarify the nature of my feedback explicitly. Because I tend to spot problems early, I’ve been told more than once that I’m “killing good ideas” or “being negative.” What was actually happening was that I was seeing risks two or three steps ahead. The content was valid. The framing wasn’t landing. Now I say upfront: “I’m not trying to sink this - I want to flag something I’m seeing before it becomes a bigger problem.” That one sentence changes the entire dynamic.
In the publisher-developer context: if you start with “these are my observations, not requirements - I want to hear your thinking on them,” you’ll get a different conversation than if you just send a list of changes.
Praise specifically - not as a warm-up, but because it’s useful
Not the sandwich. Actual, specific acknowledgment of what’s working.
People close to their work lose perspective on what’s genuinely good about it. A developer who has been staring at the same level for six months cannot see it the way a fresh player sees it.
I had a junior once who was inexperienced but genuinely sharp - he just didn’t have the skills yet to execute on his own thinking. My mistake early on was giving him simple tasks and leaving him to it. What actually worked was spending at least an hour a day teaching him - a kind of informal Top 100 tricks to perform better as a community manager. Building his skills while he built his confidence. It blew his mind. He started scheduling, expanding and promoting like crazy. I checked his LinkedIn recently - he’s now a Senior Community Manager at a Danish company. That didn’t happen because I gave him tasks. It happened because I told him specifically what he was already doing well, and then gave him the tools to do more of it.
Specific praise also makes the critical feedback that follows more credible. If your observations about what works are precise and accurate, your observations about what doesn’t work carry more weight.
Be specific and use “I” statements
This is where most feedback in the games industry falls apart.
“The onboarding is too long” is a judgment. “I lost track of what I was supposed to be doing around the fifteen-minute mark” is an observation. The first invites an argument. The second invites problem-solving.
I reviewed a game once - Vilde - that was rushed, released too early, with systems that didn’t work and balance that felt deeply unfair. I wrote a long email. Respectful, specific, with references to comparable games in the genre and concrete suggestions. Twelve months later, the developer came back to tell me he’d rebuilt most of the game - the UI, the mechanics, the character and weapon balance. He wanted to know if I’d give it another shot. I will. That conversation only happened because the feedback was grounded in specific observations, not general disappointment. Remember Hello Games? Same energy. A developer who takes a rough start and rebuilds rather than disappears is rare - and they can only do that if the feedback they received gave them something to work with.
“I noticed...” and “I found myself...” and “I had the impression that...” - these phrases do a specific job. They make clear you’re reporting your experience, not declaring objective truth.
Don’t end on the problem
Ending a feedback session on “here are the things that need to change” leaves the person with problems in their head and no counterweight.
I also know from experience that I’m not always right. I’ve given feedback based on my own genre preferences and discovered afterward that I was simply the wrong audience for that game - that the thing I was criticizing was a deliberate design choice that made complete sense for a different player. Being old enough to recognize when you’re incompatible with a genre, rather than assuming the game is wrong, is something that comes with time. Now I say it explicitly: “I might not be the right person to evaluate this particular thing - here’s my experience with it, make of it what you will.”
That acknowledgment is itself a form of empowerment for the person receiving the feedback. It tells them they’re allowed to weigh what you’ve said.
The gamedev-specific piece nobody talks about: credibility
Feedback lands differently depending on who gives it.
A publisher who has shipped twenty games in the same genre has credibility giving notes on level pacing. A publisher who primarily publishes narrative games giving structural feedback on a competitive multiplayer game has much less.
I’ve also learned something about how I’m perceived that took me a while to understand. Because I’m a perfectionist, because I care deeply about what I work on, and because my voice apparently sounds like a sixty-year-old who smoked for decades, I can come across as harsh before people know me well. The feedback I’ve received about being a “difficult” or “critical” person has sometimes been accurate - but often it’s been from people who hadn’t spent enough time with me to understand that the criticism comes from the same place as the investment. Once they see that, we end up getting on well. Many of them I run into at events and we’re genuinely friendly.
So now I explain myself in real time - like the Elcor from Mass Effect, spelling out the emotional intent alongside the content. “I’m flagging this because I want this to succeed, not because I want to be right.” It shouldn’t be necessary. It helps anyway.
Receiving feedback without losing your mind
How you receive feedback determines whether you keep getting useful feedback in the future. From anyone.
Buy yourself time before you respond
The worst responses to feedback happen in the first thirty seconds. The defensiveness, the justification, the counter-argument that starts with “yes, but” - these come from reacting before you’ve processed what was said.
Most feedback, even badly delivered feedback, has something true in it. Finding that true thing is your job as the receiver.
Separate the message from the delivery
This is something I’ve had to practice. The worst performance feedback I’ve ever received came in situations where I genuinely didn’t have enough to work with - where the conditions I was operating under made success nearly impossible, and then the failure was attributed entirely to my performance. That hurt. It made me doubt myself. It took about a week to process and then I came out the other side and found something new quickly. And six months later, at a different company with better conditions, I was hitting targets in two to three months that had been impossible at the previous job.
The feedback wasn’t entirely wrong. I wasn’t performing. But it was missing crucial context - and the delivery left me with nothing to work with except self-doubt.
Filter the delivery. Extract the content. Decide later whether to have a separate conversation about how they communicated.
Don’t perform gratitude you don’t feel
“Thanks for the feedback, really helpful” said through gritted teeth helps nobody. It trains the person giving feedback to think they’re doing it well when they’re not.
There’s also a version of this that’s specifically about standing your ground. I’ve received feedback that I was wrong about something, pushed back with data and market analysis, and had that dismissed because of hierarchy. My usual approach in those situations: nod, take note, thank them. And if the gap between their position and the evidence is too large to bridge, that’s usually when our paths diverge. I don’t like fighting that battle. It rarely ends well for either party.
When the feedback is about you, not your work
This is the hardest category - feedback about your attitude, your communication style, how you show up on a bad day.
The worst thing you can do when someone tells you that you’ve been difficult, closed off, or unpleasant to work with is to get defensive or shut down. It doesn’t matter how good you are at your job. A senior developer who poisons the atmosphere around them doesn’t keep their seat for long. The games industry is full of talented people - talent alone doesn’t protect you from the consequences of being genuinely hard to be around.
That said - fighting your corner is fine. Not all personal feedback is accurate, and you’re allowed to disagree. I’ve been confused with someone else and had someone go to considerable lengths to convince me that I was the person they were describing - when I wasn’t. I tried calmly to explain the mistake. Eventually I stopped trying and offered to reset entirely and start from scratch. Some people are going to have made up their minds regardless of the evidence.
But when the feedback is accurate - when you’ve been difficult because life is difficult right now - own it directly and without making it a bigger deal than it needs to be. Something like: “Look, I’ve had a lot going on lately and I know I haven’t been easy to be around. I’m aware of it. If I’ve been short with anyone, I’m sorry - that’s on me.”
Then do something small and concrete to reset the atmosphere. Order lunch for the team. I once brought Karpatka for the entire team - a great cream cake I love, and wanted to give them something which I also cherish, as a “I’m sorry” gesture. Small gestures after a difficult patch signal that you’re present and that you care, which is often all people need to move on.
The specific contexts
Publisher feedback on a game in development
The most functional publisher-developer feedback loops have one thing in common: clarity about what kind of feedback is being given. There’s a difference between “here’s an issue we see” and “here’s a change we require.”
I’ve watched a publisher gradually take over the creative direction of a project through accumulated notes - each one seeming reasonable in isolation, until collectively they’d replaced everything the developer had originally made. The game didn’t sell. The publisher blamed the studio. The studio blamed the publisher. What was missing from the beginning was a clear agreement about where the boundary was between input and mandate.
If something is a requirement, say so. If something is a suggestion, say that too. Ambiguity here costs everyone time.
The worst feedback I’ve ever seen from a publisher was simple: “It’s shit,” followed by standing up and leaving. Zero context, zero direction, zero humanity. That’s not feedback. That’s a display of power. It helps nobody.
Feedback on a pitch
Getting feedback after a pitch that didn’t land is one of the most valuable things you can do, and most people don’t ask for it. Ask specifically. The feedback you get in that five-minute conversation is worth more than a dozen pitch prep sessions.
And when you get it, don’t argue. Listen, say thank you, and leave.
Feedback in small teams
Small studios are where feedback gets the most personal, because everyone knows everyone and the stakes feel higher. I once had to write what amounted to a formal assessment of an entire publishing division - pointing out that our reputation was suffering, that our terms were getting worse, that developers would soon stop signing with us because word travels fast in this industry. The feedback was correct. The response was not good. But I wasn’t able to sit on it - that’s not how I’m built. I said what needed to be said.
Sometimes that’s the cost of being honest. Sometimes it’s also the right call regardless. I was kindly asked to look for another job, but I knew I wasn’t the problem and found the next one fairly quickly. And I can still sleep like a baby.
One last thing
I’ve come to think that the best feedback culture isn’t about technique. It’s about trust. When you trust that the person giving you feedback wants the work to succeed - not to demonstrate their own authority or cover their own position - you can hear things you couldn’t hear otherwise.
And on the receiving end: I’ve learned that I need positive reinforcement more than I usually admit, that I sometimes hold on to criticism longer than is useful, and that the moments I’m most defensive are usually the moments I most need to listen. That’s not a comfortable thing to know about yourself. It’s useful.
It takes practice. Give one piece of specific feedback this week that you’d normally soften into uselessness. Receive one piece of feedback this week without immediately justifying yourself.
See what happens.
Everyone has one feedback they’d take back, and one they wish they’d heard sooner. What are yours? Drop it in the comments - I’ll read every one.
Photo courtesy of Nordic Game