Abstract
Problem: How should you handle problematic team members in game development — both as a peer and as a lead?
Approach: Tim Cain draws on decades of experience to categorize problematic behaviors, then walks through escalation strategies from peer-level conversation to formal performance improvement plans (PIPs).
Findings: The most effective first response is always a thorough, respectful conversation that surfaces the hidden costs of a proposed change or behavior. As a lead, escalation through HR and PIPs is sometimes necessary — and PIPs genuinely work for some people. Ignoring problematic employees is the worst option, because it demoralizes and drives away your best people.
Key insight: One unaddressed problematic employee can ruin an entire team — not by what they do, but by what management fails to do about them.
Two Categories of Problematic Behavior
Tim identifies two broad types of problematic behavior he has encountered across his career.
The Universal Problem: Not Getting Work Done
This spans every industry, not just games. It manifests in several ways:
- Taking too long — Someone estimates a week, it takes two. This causes crunch, which then gets blamed on management. The root cause may be poor estimation, poor communication, or lack of effort.
- Turning in unfinished work — Claiming something is "done" when it's buggy or broken. Tim admits he's done this himself. But the worst cases involve people checking in work without even running the game once — code or art that crashes the build immediately.
Tim emphasizes this isn't just a programmer problem. He's seen artists submit assets that crash the game because they ignored basic requirements (texture power-of-two constraints, file size limits) and simply went home.
The Industry-Specific Problem: Not Making the Same Game
This one is particular to creative, open-ended projects with large teams. Despite attending team meetings, reading design documents, and seeing the vertical slice, some team members are mentally building a different game.
Sometimes this is an honest misunderstanding. Sometimes it's willful — they know what the game is, but they think it should be something else.
The behavior surfaces as:
- Constantly critiquing others' work as "wrong"
- Perpetually suggesting new ideas that contradict the established direction
- Actively lobbying other team members for changes
The Ammo Story: A Case Study in Hidden Costs
Tim shares a vivid example. Two years into a three-year project, someone walked into his office and proposed eliminating ammunition from all ranged weapons. "You could have that fixed in a day," they claimed.
Tim walked through the cascade of consequences:
- Balance — Ranged weapons had already been balanced against melee weapons, with ammo consumption as a key balancing factor
- UI — The interface displayed ammo counts; removing them would leave visual gaps requiring redesign
- Animations — Reload animations (some deliberately slow for balance, like shotguns) would need to be scrapped
- Loot tables — Ammo existed as loot drops; removing it breaks drop tables and devalues containers
- Economy — Ammo was a money sink, and as Tim notes (referencing his economy video), money sinks are hard to design and easy for players to circumvent
What was pitched as a one-day fix would actually ripple through every system in the game, with no clear plan for where to fit the rework into the schedule or what existing work to cut.
Handling It as a Peer vs. as a Lead
As a Peer
The approach is the same conversation Tim had about ammo: don't dismiss the idea ("no, stupid idea, get out"), but methodically walk through the consequences. Make the hidden costs visible. Tim spent two hours on that conversation — colleagues thought it was a waste, but he saw it as necessary to prevent the issue from recurring.
As a Lead
A lead can go further. After the thorough discussion:
- Set a clear boundary — "This has to stop. You're trying to make a different game. I'd love to see a game you make, but it's not this game."
- Escalate if it continues — If the person keeps lobbying the team for changes, it becomes a formal issue
- Involve HR and PIPs — Performance Improvement Plans lay out specific expectations and timelines
PIPs: Not Always a Death Sentence
Tim acknowledges the cynical view of PIPs — that they're just documentation for a predetermined firing. He's seen that happen. But he's also seen two other outcomes:
- People quit immediately rather than engage with the process, which creates its own reference-check problems
- People genuinely turn around — Some employees just need to be told what to do, not just what not to do. They need a concrete game plan. Once they understood that their "proactive" suggestions were actually slowing down production, they became much better team players
The Real Danger: Ignoring the Problem
Tim's strongest point is about what happens when problematic behavior goes unaddressed. The damage isn't just from the problematic employee — it's from losing your good ones.
High-performing, committed team members become incredibly demoralized when they see a disruptive colleague face zero consequences. From their perspective, someone is actively sabotaging the project and management is doing nothing.
Tim has seen good people quit companies over this. A junior employee tying up a feature that's been in the game for two years, six months from ship, with no management response — that's the kind of thing that drives talent out the door.
As Tim puts it: one problematic employee can ruin a team, depending on how problematic they are and how thoroughly the situation is not dealt with.
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=f6hnzJ_H19E