Career Advice From Adam Savage

Q-TIP: Quit Taking It Personally

Adam Savage's first and most memorable piece of advice is Q-TIP — Quit Taking It Personally. Tim illustrates this with a story from his own career: his boss went directly to one of Tim's team members, told them to make a change Tim explicitly didn't want, and instructed them not to tell Tim — even though Tim played the game build every morning and would immediately notice.

Tim's takeaway wasn't anger but analysis. He couldn't control his boss — this was a pattern the boss repeated across multiple projects and directors. He couldn't truly control his employee either. What he could do was set clear expectations, document the issue, and create consequences for repeat offenses.

The key framing: this is a business problem, not a personal attack. Even when workplace situations are genuinely unfair (and Tim acknowledges this one was), treating them as professional problems to solve rather than personal affronts leads to better outcomes. Learn from it, address it through proper channels, and move on.

Late-Career Luxuries

Adam Savage talks about things he could only do later in his career — like dropping difficult clients — because he had financial stability and reputation to fall back on. Tim maps this directly to his own experience of walking away from projects, stepping down from director roles into lower-paying positions, and outright quitting companies.

These are luxuries earned through years of proving yourself. Tim warns against junior developers who demand lead roles after two or three years, or who make dramatic career moves before they can afford the consequences. Walking away from a project requires being able to survive six months without pay. Demanding a title requires having the track record to back it up.

The principle: prove yourself first, then you earn the right to take drastic steps. Early in your career, build skills and stability. The bold moves come later.

Mistakes Happen — Stay Flexible

Adam Savage's third piece of advice concerns handling mistakes in high-pressure production environments where time is money and people are waiting. His recommendation: stay flexible, pick an option, keep moving, and address blame later in private.

Tim translates this into concrete game development practice through design fallbacks. Every feature in a design document should have a documented fallback — a simpler version the team has done before, with a known time estimate. This creates a clear decision point: if the ambitious version isn't working and the fallback takes two weeks, you know exactly when to pull the ripcord.

On The Outer Worlds, Tim maintained an entire Confluence page called "Design Fallbacks" for exactly this purpose.

Forgive But Don't Forget

Tim adds an important nuance to handling mistakes: forgive but don't forget. Most mistakes come from people attempting something ambitious, challenging themselves, or making honest errors (like the famous Fallout bug where <= should have been <, causing a crash that took two weeks to find). These are completely forgivable.

But you document everything. During performance reviews, patterns become visible. If someone consistently has more bugs or slower delivery than peers, you can have a data-driven conversation. If they have a good explanation — bad task estimates, personal hardship — that's valid. If they deny the pattern entirely, that's a different problem.

The principle: in the moment, fix the problem and move forward. Later, review the pattern and address it privately. Never assign blame in the heat of the moment.

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=mkftkgKEaBI