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.
thanks for your replies.
Robert, can you recommend any resources to ‘read up’ on these topics:
[ul]
[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: TAD_Resources/TechnicalArtKPIs.md at master · techartorg/TAD_Resources · GitHub
In one sentence I would say:
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 
cheers!
Excellent answer from RobertKist, really well put. I’d suggest you take a look at reading up on Emotional Intelligence:
http://www.amazon.com/Primal-Leadership-With-Preface-Authors/dp/1422168034
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]
[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]
Wow really cool info!
[QUOTE=RobertKist;28652]
*Avoid trying to do everything - especially technical stuff - yourself: You hired specialists - so trust them!
[/QUOTE]
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