Technical director (TD)

What they do

The title means different things at different studios, and this is not a quibble: ScreenSkills publishes separate profiles for animation TD, creature TD, rigging TD, lighting TD, effects TD, pipeline TD and assistant TD, because they are distinct jobs sharing a job title. What they have in common is the shape of the work. A TD sits inside one department, understands what its artists are trying to do, and builds or fixes the machinery that lets them do it. An animation TD writes Maya tools for animators and layout artists and is the person an animator turns to when a rig will not load. A creature TD builds the fur, feather, skin and muscle systems, and at some studios the rigging as well. A lighting TD writes the tools the lighting artists use and solves the rendering problems the show throws up. An assistant TD, the usual entry point, handles data management, archiving, format conversion and small bug reports so the senior TDs can work on larger problems. The day is interruption-driven: a queue of artist problems, a scene that will not open, a cache that will not load, plus whatever tool is being written between interruptions. Python is the common language, with C++ where performance matters, and Linux is the working environment. TDs sit next to but distinct from software developers doing R&D, who build the systems TDs extend.

What they decide

The calls that belong to this role and no other.

• Whether a problem gets a quick fix, a tool, or a pipeline change escalated to engineering
• How much of a department's workflow is automated versus left to artist judgement
• Which artist requests are worth building, given how many people would use them
• The technical approach for a department-specific system: fur, cloth, rig generation, light rigs
• When a scene or an asset has to be rebuilt rather than repaired
• How much documentation and hand-holding a tool ships with, and who maintains it after the show

Principles of the craft

• Ask what the artist is trying to do, not what they asked for: the request arrives as a feature and is almost always a symptom. The fix that lands is often a different, smaller change one step upstream, and finding it requires sitting behind someone while they work.
• Optimise for the artist's iteration count: the value of a TD is measured in how many versions an artist can try before the review. A tool that saves twenty seconds on an action performed two hundred times a day beats an impressive system used once a show.
• Build the boring thing that survives you: tools written to be clever become unmaintainable the moment their author changes show. Plain code, obvious naming and a page of documentation are what let a tool outlive one production.
• Know the difference between a fix, a tool and a pipeline change, and escalate honestly: patching the same broken scene weekly is a signal, not a job. Take the pattern to the pipeline engineers rather than absorbing it forever.
• Be fluent in the craft you support: a TD who cannot animate a bouncing ball will build animation tools that are technically correct and unusable. The credibility, and the good design decisions, come from understanding the artistic problem.

Common mistakes

• Solving the technically interesting problem instead of the one blocking six artists today.
• Building tools without watching anyone use them, producing interfaces that are logical to an engineer and baffling at the desk.
• Hoarding fixes as personal scripts, so the studio depends on one person's home directory.
• Automating a judgement call, which turns an artist's decision into a hidden default nobody can find later.
• The senior TD's mistake: becoming the single point of failure for a system so entangled that nobody else can be trusted to touch it.

How to learn it

Exercises and routes in, not a reading list.

• Write a Python tool for Blender or Maya that automates one repetitive thing you personally do, then hand it to somebody else with no explanation and watch. Every question they ask is a design fault you can fix in an hour.
• Take a scene that is slow and profile it before changing anything. Write down where the time actually goes, then compare that to where you guessed. Repeat until your guesses get good.
• Pick one craft next to your interest and do it properly for a week: animate a shot, rig an arm, light a sequence. You are learning the vocabulary you will need to design tools people accept.
• Read the ScreenSkills profiles for animation TD, creature TD, rigging TD and pipeline TD side by side and write down what differs. Then look at three studio job adverts for 'technical director' and note which of those jobs each advert actually describes.
• Take an open-source pipeline tool, file an issue about something that confused you, and then fix it. Working inside somebody else's code is the skill the job is mostly made of.