Lead TA's : what does your job look like?



It looks like I may be moving into a lead TA position as the studio grows.

I’ve managed small groups of artists on a project basis before,
but not really managed tool coders or riggers as a team.

I’m curious what a TA lead’s job looks like.
how much time do spend managing and delegating vs doing your own work?
what are the important considerations when managing TA’s ?
what surprised you the most about moving into a lead position?
what mistakes should be avoided?


I was a lead at a previous job. The worst part is doing performance reviews.
If you are not already doing code reviews, do them - stop bad habits before they spread! Try to keep everyone on the same page, coding standards, etc.
I did have to delegate more work than I would have liked - too many meetings…


I’ve been leading the TA team of a big Chinese outsourcer for the last 5 years.
Pfew… some day I should write this down, maybe in more detail, but here’s the gist I took away from being a lead.

  • Avoid trying to do everything - especially technical stuff - yourself: You hired specialists - so trust them!
  • A good set of mind is that you’re the guy that make sure everyone else in your team can work - your main job is to remove obstacles for them that keeps them from progressing! Obstacles can be technical, communication related, planning related, etc.
  • However while trust is good, control is better - so check in every once in a while to see that things are on track; even better teach your team how to keep you updated and what info you require. Personally I prefer a mix of software assisted tracking and in-person reports.
  • Spend face time with your team and get to know them - avoid hiding in an office or behind software communication and reporting tools.
  • At the same time, make sure your team understands when you need time to work. You don’t want to be always interrupted or else nothing gets done.
  • Read up on Scrum
  • But also read up on traditional project management knowledge, because not all projects fit the Scrum template.
  • Learn about resource and time planning (i.e. GANTT diagramming, critical path, how to calculate slack times, how to level resources), also learn some risk management - this is classical project manager / producer knowledge.
  • Ensure you have redundancy in skills in your team.
  • Ensure that juniors have a career path and that they are learning - e.g. set up trainee-mentor relationships in your team.
  • Be prepared that people resign - it’s the game industry, people change jobs. Make sure you don’t document the person’s knowledge in the last moment. Have them document things during their entire career. Knowledge sharing is a continuous process (see mentor-trainee relationship; see skill redundancies). Your team should not have a major problem if someone leaves.
  • Allow people to fail and learn from their mistakes.
  • However allow them to “fail gracefully” - if they fail there should be a learning outcome; if they fail they should not bring the project down. You have to set up some safety nets.
  • Communication, communication, communication - with your team, with your team’s client (e.g. artists, project teams)
  • Read up on the software development lifecycle and apply it to every project - regardless if it’s coding, rigging, VFX, etc. 1st gather requirements (i.e. what are you supposed to do? what level of quality?), then formulate a time plan and give it to your client, then do the work and track progress and refine estimates if needed (and update your client!), then test your work (your rig, code, etc). Then gather feedback and refine. This is how your team should approach every task.
  • Teach your team how to plan their own work - it’ll make your life much easier.
  • Identify technical minded artists throughout the company - they will help you to spread knowledge throughout the studio! i.e. teach people to help themselves to avoid your team being a bottleneck that is bogged down by mundane tasks. Make room for your team to focus on stuff nobody else can tackle!
  • Adopt a renaissance man’s mindset: As a lead you have to think about code/technology, but also about art, about motivation and interpersonal skills, about management and planning… i.e. you’re not a pure code/rigger/artist/whatever-you-were-before any more. Neither are you a Senior code/artist/whatever-you-were-before.
  • Come up with some rituals to keep your team together and motivated, but avoid making them mandatory. this can be in and outside the workplace. Have team meetings, knowledge sharing sessions, team dinners or other out of work group activities, whatever works for you.
  • Stand up for your team (but don’t piss other people off) - as lead you’re also your team’s advocate (and also its public face to upper management).
  • Learn, learn and keep up to date! Being a lead puts another barrier between you and “what’s going on on the floor” so its especially important to keep updated on new tech such as Substance, PBR, etc. Sometimes you team knows more than you! Now that is OK - they are the specialists, remember? But you still need to have some clue so you can direct them and place them in positions where they can make a difference.
  • Your job now is the big picture - you do not need to be the best coder/rigger/etc. any more. You are the general. The general isn’t the best fighter/sniper/pilot - but he has the big picture and decides which battles are worth fighting and where to deploy the specialists. If you’ve come from a programming background, you should now focus more on project management, architecture and software engineering rather than low level stuff. i.e. get to the big picture!


thanks for your replies.

Robert, can you recommend any resources to ‘read up’ on these topics:
[li]the software development lifecycle[/li][li]traditional project management [/li][li]resource and time planning[/li][/ul]

We are heavily invested in Agile / Scrum / jira here, so I’m pretty familiar with how it works , at least form the developer perspective.


Your #1 source for producer skills the the PMBOK (Project Management Book of Knowledge) - but it’s a very very dry read. However as it is pretty much a reference work there are many books presenting the same topics in a simplified manner. Also, not all topics of the PMBOK apply to producers work anyway. Mostly risk management, resource/time planning, stakeholder management. There should be tons of books on the subject. Asking a producer can be a good starting point. Here at my company, for example, a couple of producers are PMPs, so those are the guys I would ask.
In general as a lead you don’t need to know as much as a producer anyway. But it helps knowing about the topics and the issues they deal with.

SDLCs are a typical software engineering topic. Agile is a form of SDLC (the other well known one is Waterfall). What’s interesting to learn is not necessarily how other SDLCs work, but how to do things by the book. I often meet people who claim to do Scrum who have no clue about how to do things by the book. It’s like saying “I’m an abstract painter” when in fact you have no clue about anatomy, perspective or color theory. You’re not an abstract painter because of skill, but because of the lack of it. Anyway, you want to read up on requirements engineering, specification, planning, best practices, progress tracking, reviews, configuration management, etc. Some of it is covered in the books mentioned below.

For practical tips McConnell’s Code Complete 2 is the best book imho. The Software Project Survival Guide (also by Mc Connell) adds the project management part that’s missing from Code Complete. “The Pragmatic Programmer” takes a bit more philosophical stance on what is good software. Definitely read “The Mythical Man Month”. I also enjoyed “Software Engineering for Game Developers” (Warning: this book is NOT about making games in practice, and I don’t think anyone makes, or should make, games like describes in this book!; However it is a fairly easily readable introduction to all things Software Engineering which is pretty close to what is being taught at college. It describes how to do things by-the-book.). Only once you understand the rules - i.e. how you should do things - you can break them. At this point you should do Scrum (note: Scrum is pretty much both a SDLC and project management approach).

If you’ve started out as coder, especially one heavily invested in algorithms, you should brush up on your architectural skills. As a lead you give direction and your “grunts” will do all the typing. They will often focus on units and rely on you to provide the big picture. Or you could designate someone as “architect” in your team, but I’ve never seen this in practice in a TA / tools team yet. Read up on some practices how you can write down software architecture. i.e. how modules are arranged, how they interact and what their dependencies are. This will help your team to understand how their work fits into the big picture. Take a look at UML, especially class diagram notation. No need to stick to the book though. Use it as inspiration to share ideas about software architecture with your team, and as basis for discussion. Sharing the big picture (and holding it in a written down form) with your team is important! (or else everyone will forget the grand design halfway during production and your software will be a convoluted mess).
Again, your knowledge doesn’t need to be as deep as someone who designs e.g. an entire game engine. But you should be familiar with the topics and issues.

Resource and time planning: PMBOK covers this. It’s basically a major part in MS Project. But for team leader purposes you can do it with fewer bells and whistles, and this knowledge mostly comes handy for longer projects - e.g. you develop a pipeline or some other complex tool with multiple people working on it. Being able to make a GANTT diagram and identify the critical path allows you to indetify the most resource intensive tasks, the tasks which can or cannot delay, and it allows you to experiment with different schedules and see how they affect your overall project. Basically it lets you explore different scenarios of how you schedule the project, which is nice.
Sure, it’s game dev, and things change all the time, but it helps if you have a plan, as guidance, that shows you the “ideal direction” to follow, rather than being completely lost without any plan. As alternative you can use the Scrum approach. But even there it helps to have some grand design or path in mind and not totally let customers jerk you around all the time (i.e. Scrum is flexible, but it also often happens that clients themselves have no plan)

Edit: Theodox has some books listed on his website, I think there are also a couple which could be useful for a lead to know.


Butters is working on a doc here that you might find useful. It’still immature but has some good info: https://github.com/techartorg/TAD_Resources/blob/master/TechnicalArtKPIs.md


In one sentence I would say:

  • “byebye to your hard-skills and welcome to your soft-skills…” -

The most difficult part in my opinion is learning to delegate (Specially when the things are not going like expected)
There you’re forced to hold your breath, keep calm and make people move fast in order to come back to the main path.
Not an easy thing to do with everybody :wink:



Excellent answer from RobertKist, really well put. I’d suggest you take a look at reading up on Emotional Intelligence:

There’s allot of writing about it and it’ll help you focus on developing your soft skills real fast. One thing I’d suggest doing off the bat is schedule 1 to 1 meetings with every member of your team and just let them vent for a half hour.

[QUOTE=RobertKist;28652]I’ve been leading the TA team of a big Chinese outsourcer for the last 5 years.
Pfew… some day I should write this down, maybe in more detail, but here’s the gist I took away from being a lead.


[QUOTE=RobertKist;28652]I’ve been leading the TA team of a big Chinese outsourcer for the last 5 years.
Pfew… some day I should write this down, maybe in more detail, but here’s the gist I took away from being a lead.
Wow really cool info!

This one was specifically interesting. Many management TA job posts I’ve seen (especially in China) actually seems to imply that the manager will also make tools himself. That to me seems rather shocking since the management duties listed in the same job post already seems way-beyond-9-to-5. But sounds like at least your position is more sane than that.


[QUOTE=Niber;30315]Wow really cool info!

This one was specifically interesting. Many management TA job posts I’ve seen (especially in China) actually seems to imply that the manager will also make tools himself. That to me seems rather shocking since the management duties listed in the same job post already seems way-beyond-9-to-5. But sounds like at least your position is more sane than that.[/QUOTE]

I’s sort of what I do. I like management, but not all the time. I want to keep grounded and keep up to date as good as possible on programming and art tasks, so I try to do some myself whenever I have time.

To make time you have to delegate tasks. Not just production tasks, but also smaller management tasks. Teach your team to manage their own time and there will be less work for you. In return they will feel more ownership about their own work as they can manage it themselves. But this also means they need to be better at reporting what they’re doing. Having motivated people whom you can trust also helps with freeing up your time, as you will have to spend less time on controlling. It requires some experimentation to find the right balance between independence and control. But as a lead you can help improve both by working with your team - by building trust, by giving them the tools and knowledge to manage themselves.

I really try to take the saying “The best boss is the one who can just disappear and the team will keep working as if nothing happened” to heart. I could become sick, I could take vacation. I could decide I want to do some art or programming. In the meantime I don’t want my team to implode :wink: