How to Give Feedback on a Teammate's Work

Good team feedback is anchored to shared goals ('this fights our readability pillar'), names problems rather than prescribing solutions, and matches the work's stage — direction-level notes on drafts, detail notes on near-finals. Deliver it promptly and privately, ration it to what matters most, and remember the relationship outlasts any single asset. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

Anchor critique to the shared target

'I don't like it' starts an argument about taste; 'this enemy reads as friendly, and our pillar is instant threat-legibility' starts a fix. Anchoring feedback to agreed goals — pillars, the style guide, the reference board — makes it depersonalized and actionable at once. This is half the practical value of writing those documents at all.

When no shared standard covers the issue, say so honestly: 'this might just be my taste — flagging it, weigh it accordingly'. Labeled opinions are cheap to give and easy to receive; opinions disguised as standards are neither.

Name the problem; let the owner solve it

Prescriptions ('make it blue, move it left') quietly insult the person whose craft it is, and they're usually worse than what the owner would invent given the actual problem ('it vanishes against the background in motion'). Problem-first feedback respects expertise and produces better fixes — the artist knows ten ways to fix visibility you've never heard of.

Ration it too: a wall of forty notes flattens priority and morale together. Lead with the two things that matter most; batch the nits or drop them. Feedback volume should track importance, not your thoroughness.

Stage-match it, and build the receiving culture

Critiquing polish on a rough blockout wastes everyone's time; questioning direction on a finished piece wastes the piece. Ask or announce the stage before reviewing: 'early — direction feedback only' versus 'final pass — tear it apart'. Teams that adopt this one convention eliminate most feedback friction outright.

And model the receiving side: thank people for hard notes, act visibly on good ones, disagree with reasons rather than wounded silence. On a three-person team, feedback culture is set by whoever takes critique best — be that person and the rest follows.

Momentum is a resource — budget it

Progress you can see is fuel. Long stretches of invisible work — refactors, systems with no on-screen result — drain motivation even when they're necessary. Good project plans alternate: one stretch of plumbing, then something you can watch move on screen.

When motivation dips, shrink the loop. Pick the smallest change that makes the game visibly better today. Shipping anything, even a menu fix, restarts the engine.

Decide how you'll know it's working

Every project needs a definition of done that isn't a feeling. Pick the few signals you'll trust — playtesters finishing the demo, crash-free sessions, wishlists per week — and check them on a schedule. Otherwise you'll steer by whichever anxiety is loudest that day.

This is also the honest defence against endless polishing. When the signals say players get through it, enjoy it, and nothing breaks, the feature is done. Move on.

The quiet work that protects all of this

Everything in this post gets undone by an unstable build. A great store page, a clever marketing beat, a perfect jam entry — none of it survives 'crashed twice, refunded'. Stability isn't a feature players praise, but it's the floor everything else stands on.

Give yourself visibility before you need it: crash reports with stack traces, a simple way for players to flag issues from inside the game, and a habit of fixing the top recurring error before adding anything new.

Putting it to work

Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.

Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.

Scope to the hours you really have, then ship the small game that fits them.