I talk about delegating tasks to others, including when and how I do that.
Delegation is unavoidable unless you plan to make the whole game yourself. Some parts are going to have to be done by some other people and you or someone else will have to decide this. Cain has noticed a tendency (which has always been around) for some people to want the authority to make decisions but not the responsibility of what that decision causes. If you delegate, that is part of your authority and you are responsible for it.
Delegation comes from your position on the ladder. Juniors don't really have to delegate, they are delegated to. Seniors need to manage and delegate a little, they have a few people under them and that is how they learn how to manage. Lead do a lot of delegating, Cain does some leads that don't do much work in their field, he knows some who do, but they all make time to delegate the other tasks. There is the rare exception of the Principal of a role, a lead-senior level who manages nobody but in exchange has total responsibility of some subset of the game. Cain has worked with Principal Programmers, one example is someone who entirely does the game rendering. Manage nobody, but it's on them to make sure that segment works flawlessly.
Cain considers a two pronged approach to delegation. If there is a task Cain has never done before or knows he is not good at (As you go along in the game industry you have to acknowledge what you are not good at), he gets a Lead for it. That person is responsible for that area of the game, including delegating out. This can happen in different ways, Cain hired a networking lead because he was very experienced with networking code and the game needed multiplayer. He saw the spec, was told what they needed, and owned that section of the code from then on. Art is an example of something Cain cannot do at all, he hires a lead artist and that person handles all of it. Liked how Fallout looked? Great, Cain had nothing to do with that. Liked how Outer Worlds looked? Great, Cain had nothing do do with it.
Lead artist decides look, style. Half the time, the artists are discussing differences between things Cain can't tell the difference. They discuss color variation, skin tones, and it is all pink to Cain.
Narrative design, Cain wants to be involved with the storyline of the game, wants to be involved in the characters and quests they have, but he knows they cannot write those things, especially dialogue. Wants a lead for that, but also wants to go to their meetings and make suggestions.
For tasks Cain has done before, it's different. For seniors where Cain is the lead in, Cain will write their specs and tell them what is needed, they implement it however they see fit, they decide the appropriate data structure and algorithms. His seniors estimate the time it takes to do that task, Cain asks them questions such as why something is taking a certain amount of time or why they decided on a particular algorithm. They are seniors, they should be able to answer those type of questions.
For juniors, Cain writes the API/Class/High level description but then they have to write the individual methods themselves. Cain will give them his time estimate. If they want, he will tell them how he has done it before and where they can look up useful information. The data structures and algorithms he recommends will be based on his own work. If they want to do their own thing, he wants to know why, and will want to know their time estimate. It has to be in line with his estimate, or he's going to start asking questions on why you're doing design X that takes a week to do instead of Cain's recommendation of design Y that takes four hours. Even juniors should be able to explain their thought process.
Once delegating, now you are managing. This isn't all on producers, producers monitor and make sure things are going to schedule. Producers go to leads if something is going wrong. But you can't expect a producer to glance at someone's networking code and realize it's wrong, or look at a model and notice it isn't rigged. Leads have to intervene and take a look at tasks to see why they are taking longer than estimated. What Cain does is go to the developer in question and ask them to show their work to him. Show the code, the script, if it's a system mechanic what have they designed and what is getting them stuck. Talk through it, discuss their approach to it. Usually, this solves it, they get over their roadblock. They were stuck on something that didn't really matter and solve it or move onto to the more important stuff.
The problem is when someone consistently is taking too long. Different ways Cain has handled this, sometimes on the same project and different projects. Cain swaps tasks between two people on the same level, i.e move junior tasks over to another junior or senior to another senior. One guy is making good progress, one guy is struggling, swap around and see if the problem continues. Cain has done this to himself on some projects if he at the same programming level as others. If someone is struggling, Cain can swap their projects and take a look. Walking a mile in another person's shoes, you can start to understand the problems, or notice where they are making it too complex for themselves. Sometimes you swap tasks and notice the hidden complexities. But if that keeps happening, you need to have a serious discussion with them. Sometimes Cain moves them to less time sensitive tasks, something that won't bottleneck other people's work. Sometimes he talks about moving them to another project, changing another lead/engine/programming language can be all some people need. Cain has moved people to another project and suddenly that person is happy and working at full speed.
Once or twice, it lead to demotion. Cain is not a fan of the Peter Principle that says everyone eventually gets promoted to a level they aren't good at. Cain would prefer taking a step down, Cain has done it before himself. Cain has done it to other people once or twice after they keep delivering slow/substandard work. Senior staff has been moved to staff, with all the resulting consequences such as salary decrease. Cain does this at their review, giving them a few weeks to think about what comes next. Some people leave (Cain will give them a reference), some people stay and end up doing quite well in that demoted position, even going back up a level when they really are ready for that previous role.
