Obviously we have a lot of talented engineers and programmers across all of our studios, but some are juniors and some are seniors who have their own specialties and aptitudes. How do we decide who works on what?

It's an interesting problem, right? Because fundamentally, all these talented programmers and engineers are human beings behind it. I think that one of the challenges that the teams face regarding this, not necessarily prioritization, let's talk assignment first, is there's a certain level of ownership. I write a system, then I own it, right, in a way. And then further iterations or bug fixes on this thing, I will be the best qualified to do it because I know the code. Anybody else that needs to go in this code is going to have a little ramp up, right? And sometimes we can't pay that ramp up, especially at the pace at which, I keep saying that, in our project it's different, typically. We don't release a game before it's in a better state.

Most games don't run a live game environment in the middle of their development.

Exactly. And that, I call it the cost of shipping, is what hurts us the most, because now any priority issue for the live patch needs to become absolute. Back to assignment. One programmer writes a system, he owns it. So we're going to try to go back to this person when there's bug fixes or items to go to. They're going to have the least on-ramp time. But now sometimes it can happen that that's a junior developer. It can happen that it's a senior developer. It really depends, right? Some systems also end up with no owner when there's churn and people leave and there's replacements or people move on. There's a lot of internal movement at CIG where people want to change their specialty. And so you want to keep the distribution fair for the people in there. You don't want to assign someone to pure bug fixes for five years, because they're not going to stay with the company. You need to balance this out in terms of how you assign the work. Again, I'm not talking prioritization, but assignment. Typically, we're going to try to pair juniors with seniors to encourage growth so that these juniors can become seniors and then we can depend even more on them. That's another constraint, that sometimes you need to spend time from a senior on a specific issue to help a junior on another issue.

Sometimes you'll have two people on an issue, not because they can make the baby twice as fast, but because that's how you train that junior to become a senior. And that's one less person that could be working on something else, because this is part of their training, this is their growth.

Correct. There's also, so we talk juniors, seniors, right? We make it simple, but there's also leadership, right? So lead developers, most people know this, but the lead developer is not necessarily the best developer of the team. But the lead's responsibility is management. It's making sure that the issues move and that our plan of action is sound, that it's vetted, that there's code reviews, make sure the quality is there, but also just orchestrating the team. Typically, a lead should spend roughly 40% of his time doing management. So leadership is also a key element in that. Even if you pair people and you have a million things going together, what is the drumbeat is the leadership. And so you need to have all those combinations to be able to have a healthy engineering team. You want to avoid overburdening as well. So sometimes you have some developers that come into the company and they're really good, right? But they're juniors, right? So they're learning fast. They have a lot of energy. They're going for it. And so, path of least resistance, we're going to go like, oh, well, can you look at this? Can you look at this? Can you look at this? And at some point, that person's overburdened. And we have to release our patches, so time constraints come in. And so code quality goes down, right? And that's an issue we have to battle every single day.