Stephen Brenish
Your game ships. Reviews are good. Steam numbers are climbing. The Discord is alive. And then, over the next 90 days, three of your best people hand in their notice.
This isn’t a horror story. It’s Tuesday in the games industry. Post-launch attrition is one of the most predictable, most preventable, and most consistently ignored talent crises in game development. Studios pour enormous energy into getting to launch and almost none into what happens to their people after it. The result is a pattern so common it has become normalized. It shouldn’t be.
The Psychological Crash Nobody Plans For
Development is a long, sustained pressure campaign. For most studio projects, that’s two to five years of deferred gratification. Every decision, every crunch stretch, every “we’ll fix it after ship” conversation is held together by one shared belief: launch will make this worth it.
Launch arrives. And it’s fine. Maybe great. But the emotional payoff doesn’t match the emotional debt. The adrenaline drops. The shared purpose evaporates. What’s left is exhaustion without a goal attached to it.
Psychologists call this arrival fallacy. Game developers live it hard. The team has been chasing a finish line for years, and crossing it doesn’t feel like victory. It feels like a void. For a meaningful percentage of your team, that void is the moment they finally have the bandwidth to ask themselves: “Do I want to keep doing this here?”
The answer, for many, is no. And it isn’t primarily about money.
What Actually Drives the Departures
Attrition after launch usually gets diagnosed as a compensation problem. Sometimes that’s true. More often, it’s a symptom of three deeper issues:
Creative exhaustion combined with uncertainty. The team doesn’t know what’s next. If leadership hasn’t communicated a clear next project, people who have options start entertaining them. Ambiguity is expensive. Talent reads silence as a signal.
Feeling undervalued during the home stretch. Crunch leaves marks. If someone spent six months in mandatory overtime and received no meaningful acknowledgment, a LinkedIn recruiter message lands differently than it would have in year one. The launch bonus, if there was one, doesn’t erase the memory of cancelled vacations.
Resume timing. This is coldly practical. A shipped, well-reviewed title is the best possible career leverage a developer will have. Recruiters know this. Developers know this. The 90 days after a successful launch is prime hunting season. Some departures have nothing to do with your studio and everything to do with the market timing.
Where Studio Leadership Gets It Wrong
The most common mistake I’ve seen: studios treat launch as the finish line for people management too.
Retention conversations that should happen in months 8-10 of a two-year project get postponed until after ship. By then, you’re having the conversation six months too late. The developer who needed to feel seen in October is already interviewing in January.
Another failure mode exists in how messy the post-launch period actually is. Live ops, DLC planning, patch firefighting, and whatever the next project is all compete for attention simultaneously. If your senior engineer is spending their post-launch weeks doing unplanned hotfix triage with no clear end date, they’re not feeling relieved, they’re feeling trapped.
There’s also a structural issue in how studios celebrate. Most launch celebrations are external: press coverage, player numbers, review scores. The team needs something internal. Recognition that is specific, personal, and not just a Slack message from the CEO.
What Retention Actually Looks Like in Practice
Here’s a practical sequence for the post-launch window, broken into phases:
30 days before launch:
- Hold 1:1 conversations with every senior contributor about what they want to work on next. Don’t wait for HR to schedule performance reviews.
- Identify your five highest-flight-risk people. These are usually your most competent and most exhausted. Plan specific retention conversations.
- Pre-plan the launch celebration. Budget for it. Make it feel earned, not obligatory.
Launch week:
- Resist the urge to immediately pivot everyone to live ops. Give the team 48 to 72 hours to actually experience the launch.
- Public, specific credit matters. Mention names. Developers remember when leadership says their name in a public context for the right reasons.
30 to 60 days post-launch:
- Announce next project direction, even if it’s incomplete. Uncertainty is worse than imperfect information.
- Offer meaningful time off. Real time off, not “take a few days and we’ll ping you if something breaks.”
- Begin structured retrospectives. Teams that process what just happened together are more likely to want to do it again together.
60 to 90 days post-launch:
- Lock compensation reviews. If you’re giving raises or bonuses, do it in this window, not six months later.
- Identify who you’d actively build around for the next project and make sure they know it.
The Comparison: Studios That Keep Their Teams vs. Studios That Don’t
| Factor | Studios with low post-launch attrition | Studios with high post-launch attrition |
|---|---|---|
| Next project communication | Shared early, even if rough | Delayed until leadership is “certain” |
| Post-crunch recovery | Mandatory recovery time, enforced | “Take time if you need it” (nobody does) |
| Recognition | Specific, named, public and private | Generic team-wide posts |
| Compensation reviews | Proactive, tied to launch milestone | Reactive, after someone threatens to leave |
| Senior staff conversations | Ongoing throughout development | Triggered by resignation letter |
The pattern is consistent. Studios that retain talent treat the post-launch window as a retention campaign, not a cooldown period.
Post-launch attrition isn’t an industry inevitability. It’s a producer problem, which means it’s solvable. The studios that consistently ship and retain their core teams aren’t doing anything magical: they’re treating the post-launch period as seriously as they treat pre-production. That’s the whole difference. Start the retention work before you need it, and you might actually get to build something together twice.
Photo: hitesh choudhary via Pexels
