Abstract
Problem: What does it actually feel like to lead a game project for the first time, and what do you get right and wrong without experience?
Approach: Tim Cain reflects on becoming project leader of Fallout in 1994 at age 28 — his first real management role — with no training, no processes, and no idea what he was getting into.
Findings: Ignorance was genuinely bliss. Some things went right by accident (passionate self-selected team, clear creative direction, individualized management). Some things went wrong (trusting without verifying, no dedicated UX or producer, no established processes). The game succeeded in spite of mistakes, not because everything was done correctly.
Key insight: You will get things wrong your first time leading — and that's fine. Don't overthink it. Learn from mistakes, take the opportunity when it comes, and know that every leader started exactly where you are.
1. How Tim Became Project Leader
Tim didn't get promoted because someone saw leadership potential in him. His producer had 22 SKUs across multiple platforms and was overwhelmed. Tim had been writing daily status updates — what he did today, what he planned tomorrow — and sending them to his producer. The executive producer essentially said: "You're the project leader now. Send those updates to me instead."
At the time, the team may have been just Tim himself. He was 28, had been at Interplay for three years and in the industry for 12, but had zero management experience. Interplay offered no training — no game company did. When Tim asked an executive producer what would happen if he started sinking, the answer was: "We'll probably just throw you more stuff to carry."
2. Ignorance Was Bliss
Tim emphasizes that he should have been terrified but wasn't — because he didn't know what he didn't know. He had no processes, no plans for rough patches, no understanding of how big problems could get. Some crises swept past without him realizing until years later how close they came to destroying the project.
Fallout was considered B-tier at Interplay. Nobody was putting Tim in charge of the next big thing — it was a small side project because they had nothing else for him. This lack of pressure was actually liberating: "I was just happy to forge ahead."
3. What Went Right (Mostly by Accident)
3.1. The Team Self-Selected for Passion
Because Tim couldn't recruit through normal channels and had to invite people to after-hours pizza brainstorming sessions, the team naturally filtered for passionate, dedicated, creative people. These weren't people optimizing for work-life balance, money, or career advancement — they wanted to make something cool and saw Fallout as a chance to get their own ideas into a game.
3.2. Clear Creative Direction
Brainstorming sessions weren't random idea-swirling. Great ideas were generated, then Tim picked a direction. Even unconsciously, he avoided making a "committee-based game" — the team contributed ideas and owned features, but final decisions had a single point of authority.
3.3. Individualized Management
Tim managed everyone differently based on their preferences. Some people wanted daily check-ins. Others said "don't talk to me until the due date." Tim respected that — with one condition: if someone didn't deliver on time and hadn't warned him in advance, they lost the privilege and got check-ins from then on. The system was transparent and transactional: "no manager jumping out of the bushes."
3.4. Ownership of Features
Team members could own ideas from conception through implementation. They'd follow their feature through art, design, and code to make sure it matched their vision. This happened naturally because the team was passionate and self-motivated, and Tim provided direction and deadlines.
3.5. Shielding the Team
Tim absorbed background noise from the larger company — unsolicited input, suggestions, requests. He'd either refine outside ideas into useful tasks or reject them outright, so the team could focus. He didn't realize how effective this was until after he left and team members were suddenly getting bombarded directly.
4. What Went Wrong
4.1. Trusting Without Verifying
Tim's biggest admitted mistake: he trusted people who said their work was on track without checking. This caused problems at the end of the project. The lesson: trust but verify. "You said that feature's almost done? Show me."
4.2. No Established Processes
There was no structured approach to setting, story, then mechanics. Tim acknowledges this matters even though Fallout succeeded without it — that's survivorship bias, not validation.
4.3. No Dedicated UX Person
The UI pipeline was a "management nightmare" — art from different people, different programmers on different UIs with wildly inconsistent code, some UIs pausing time and others not.
4.4. No Dedicated Producer
Tim was trying to be full-time producer, full-time lead, and do design work simultaneously. He shouldn't have. Fallout 2 got a dedicated producer, and it needed one — that game shipped in less than a third the development time of Fallout 1.
5. Survivorship Bias Warning
Tim warns against assuming everything went right on a project just because the game turned out well. For every successful indie, there are tens of thousands that didn't make it. He'd love to see postmortems written on the day a game locks — before the team knows how it'll be received — to capture honest assessments rather than narratives shaped by hindsight.
6. The Encouragement
Despite everything that went wrong, Tim says he'd do it all again. When your turn comes, you'll get some things right and some things wrong — just like everyone before you. Don't overthink it. Take the opportunity. You'll never forget your first time leading a project.
7. References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=0l6AhAhJu-0