Definition of a technical director for a game development studio

A lot of game companies search for the ephemeral list of priorities that a TD must have in order to build and run a software development team dedicated to games. While I have been part of the process of defining these, no one can ever seem to agree to the exact set of necessary responsibilities and the list can be massive and daunting. This blog page is meant to capture the basics. No TD can do all of these, but delegation can be a way for a company to achieve all of these. I find that picking a few of these to focus on, and then requesting other people to take on the remaining responsiilities is the way to go. The first few major categories, every TD must do in any case.

Priorities and keys to success are listed here by major category and in cases where the subcategories could be made into acronyms, I did it. If you have any additions or subtractions to this list, please feel free to comment.

Product quality (PATS)

1. provability (stable, reliable, code-review)
2. agility / adaptability (most code should be usable across projects)
   
3. testability (includes building tools to test)
4. suitability (does it meet the requirements strictly? loosely? spirit?)

Building and keeping business relationships (LIFF)

1. listen first (everyone wants to talk, don't interrupt, just listen, then talk)
   
2. intellectual discussion (never personal or emotional)
3. frankness / honesty
4. follow up (don't let any ask go two weeks without asking "where are we on this task?", make lists for following up)
   

Manage subordinates (LINGER)

1. listen (subordinates have a lot to say, and they can tell if you are listening or not)
2. integrate ideas (demonstrate that you trust that person by using his ideas)
3. needs (home, pets, schedule, etc, openly discuss social style)
4. goals for the employee - possibly cross training
5. engage employee (one on ones, intellectual debate on work, etc)
6. radiate positivity

Software development for tools or as a set of tools (PIECeS)

1. production (pipeline)
2. integration tools (tools for AI, tools for audio, etc)
3. effort reduction (automated builds, automated build disks, file copying, etc)
4. core systems (engine, memory, file systems, etc)
5. status monitoring (build bot, PerForce, frame rate monitoring)

Steady at the helm - this is the hardest responsibility to do because everyone wants to make rapid changes but this one is the key to the success of any engineering process. These are suggestions and require you to be a hard ass.

1. Quarterly changes. Do not change deliverables/goals but once per quarter. Stable delivery is impossible when the goals change often.
2. Queue up change-requests in a detailed list and one week before the next quarter, review. Only keep things that designers think are still important. Use a rating system.
3. Rate the importance of all game features based on fun, necessity for modern titles to have it, and difficulty to deliver. There should be very few features not listed.

Integration pieces and main development areas

1. front end and interface (GUI, menuing, icons, etc)
2. controllers (esp for wii)
3. audio
4. presentation and camera control
5. gameplay
6. AI
7. animation
8. systems

Design

1. People don’t know what they want until they see it. Encourage mockups, design docs, and whiteboard sessions.
2. give the designers ‘tweekability’ and allow them to do as much testing as they can stand.
3. UML baby
4. always discuss patterns by name when it applies. (education)
5. build systems, not classes. Integrate, not isolate.

Delivery and finaling

1. early preparation (make periodic builds that run on target hardware, put processes in place to facilitate quick builds)
2. under-promise and over-deliver (a good engineering pracice I learned from Scotty)
   
3. warn early - repeat warning (always let others know when you face a mountain and that it is interfering with other work).
   
4. be prepared to repeat everything you say at least 5 times related to delivery
5. define key dates by names (alpha, beta, FPP, etc, this really matters)
6. define short-term deliverables and mid-term deliverables for everyone (less than 8 weeks and 8-20 weeks respectively)
7. keep designers busy or they make your life hell (tools, design ideas, helping with testing tools, etc). Do not let designers or art staff work directly with programmers.

Project scheduling - this is mostly the roles of the producer or project manager, but TDs must be involved.

1. set and keep schedules (project management 101)
2. we know the tasks, let engineers pick which ones get to be done. This gives people a little control over their lives and some choice is better than none.
   
3. Allow cross pollination by letting people work on different teams at least one day per months. This keeps your bus number moderate (if you were hit by a bus...) and keeps people inerested and educating one another.
4. allow engineers to speak, at least a little and use their ideas
5. look for cross-discipline gains like creating an event system that can be used to drive AI, Gameplay, Audio, etc.
6. leave progress tracking to the producers. This isn't your job and distracts you from your job.

Other tasks you must do:

1. Build and maintain a book library that all staffers can use. Checkouts must be written in blood and all people who leave the company must return these items.
2. Make decisions about which software the company should be using for building, maintaining, and creating software. Do not decide this on your own, but ask the opinions of all of your leads. Then make a hard choice and not everyone will like your choice. That's part of being in charge. Just let everyone know what you decided and if you want to be nice, you might explain to them why you chose that piece of software over their recommendations.
3. Always show up on time
4. Never undercut your leads in public... ever. Always support them in public, even when they conflict (where possible).
5. Encourage XP style of development. Most game companies could use more of this and it does dramatically improve code quality.
6. When you hear others bitching about someone, remind them that they would want respect from others. Don't give them a hard time or make a big deal of it. This is natural and all people do it. When you catch others bitching about you, just ignore it. This is natural and you are the boss: very few people love their bosses.
7. You must love the success that comes from guiding people, helping people, and reforming people. Your job is mainly a people job and not a programming job. If you are a TD, you won't have any time to code, debug, test, or review: get over it.

That's about it for now. Please offer your suggestions.