Delegation

1. Delegation Is Unavoidable

Unless you plan to make the entire game yourself, delegation is a fact of life. Someone has to decide who does what. Tim notes a common tendency he dislikes: people who want the authority to make decisions but don't want the responsibility for the consequences. His view is clear — if you delegate, you're responsible for the outcome, and you must monitor and follow up.

2. Where Delegation Sits in the Hierarchy

Delegation scales with your position:

• Juniors don't delegate — they are delegated to
• Seniors manage and delegate a little, often having a few people under them (this is how they learn management)
• Leads delegate extensively — some do a lot of hands-on work in their area, some don't, but all find time to delegate tasks to their people
• Principals are a rare breed — senior-level people who don't manage anyone but are entirely responsible for a specific subset of the game (e.g., a principal graphics programmer who owns rendering, shading, and lighting)

3. The Two-Pronged Approach

Tim breaks delegation into two categories based on his own competence:

3.1. Tasks He Can't Do or Has Never Done

For areas outside his expertise, Tim hires a lead and hands off entirely. Art is his prime example — he completely delegates to a lead artist who decides the style, the look, everything. "Did you like how Fallout looked? Great. I had nothing to do with that. Did you like how The Outer Worlds looked? Great. I had nothing to do with that." The lead artists have discussions about color variation, skin shading, and tones that Tim literally cannot perceive the difference between.

Narrative design is a middle ground: Tim wants to be involved in storyline, characters, and quests, but he knows he cannot write the actual dialogue. So he attends meetings and makes suggestions, but the lead handles the final product.

Networking is another example — he hired a programmer experienced with networking code who completely owned that section, defined the API, and told other programmers how to call into his code.

3.2. Tasks He Has Done Before

When Tim is the lead or director in an area he has experience in, delegation looks different depending on the person's level:

For seniors: Tim writes the spec — "this is what we need out of this thing" — but they decide on data structures, algorithms, and APIs. They estimate the time themselves. Tim can then ask probing questions ("why this algorithm instead of that one?"), and because they're seniors, they should know the answers. That's why they're in charge.

For juniors: Tim provides more scaffolding — he writes the API, the class structure, or the high-level description, and they implement the individual methods. He provides his own time estimate and suggests algorithms, data structures, and reference materials. If a junior wants to do something differently, Tim wants to know why, and their estimate must be in line with his. "That's great that you want to do it that way — that'll take a week. Why aren't you doing it this way? That'll take four hours. Explain it to me."

4. When Things Go Wrong

Once work is delegated, management kicks in. Producers monitor progress and schedules, but when intervention is needed, the leads step in — producers can't evaluate whether network code is correct or whether a model is properly rigged.

Tim's approach: "Show me your work." Show the code, the script, the design. Talk through it as if presenting it. He finds this usually gets people past their roadblock — they're stuck on something unimportant, or something that can be deferred.

4.1. Handling Consistent Underperformance

When someone is consistently taking too long, Tim has several escalation strategies:

Task swapping: Swap tasks between two people at the same level. If one person is halfway done and another should be but isn't, swap them. This serves as a diagnostic — sometimes the new person discovers hidden complexity ("oh, I never would have thought of doing it this way"), but sometimes they finish quickly, revealing that the original person was making it overly hard on themselves. Tim has even done this with himself when he's at the same programming level as others on the team.

Moving to less critical work: Assign tasks where no one else is bottlenecked — work that needs to be done before QA but isn't on the critical path.

Transferring to another project: Sometimes a change of programming language, game engine, or even just a different lead is all someone needs. Different management styles, different complexity levels — suddenly they're happy and productive again.

Demotion: As a last resort, Tim has demoted people — moving a senior programmer back to staff level, with the associated pay cut, done at review time. Some people leave at that point. Others take the demotion, do well at the lower level, and eventually get promoted back. "They just weren't ready yet for that step."

5. The Peter Principle

Tim explicitly rejects the Peter Principle's inevitability — the idea that people get promoted until they reach a level where they're incompetent, then stay there forever. His attitude: "Okay, then take a step back." He's done it to himself and to others. People deserve second chances, and sometimes stepping down is exactly what someone needs before they're ready to step back up.

6. References

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