Making AAA games has always been a challenge. Nowadays even more than ever despite the existence of engines such as Unreal Engine or Unity 3D. The impact of the free-to-play market not only in mobiles but also on traditional platforms such as PC and console and the huge amount of pre-existing projects has caused a shift in the way we craft games.
In this article, which will be the first in a series, I would like to share my experience in the field on how to start and manage such big projects. Beginning with the first steps one has to perform and how I tuned my mindset for the task.
First things first, my name is Manuel Rello. I became a software engineer in 2009 and I’ve been working in the videogame industry for the past 13 years. I was Lead software engineer in Disney Speedstorm, a free-to-play triple-A combat racing game, from the first day until it was released for PC and consoles in 2023. After that I became the founder of Plastic Games Studios and in parallel I’ve been teaching software engineering at university.
So put yourselves in the situation: Your boss has approached you, already the lead of a small technical team, with a request: make me this triple-A game. If you are lucky, you’ll probably already have a considerable amount of design documentation, UI fakes and even some concept art and videos. If you are not, you’ll just have a sentence with a beautiful declaration of intentions and nothing else. Most likely, though, you’ll land between those scenarios.
First: Breathe.
This may seem like an stupid recommendation, but it really works. When such a big request has landed in your lap, do not rush. There is no gain in hurrying to grab your keyboard to send emails, write some code or create UML diagrams. Take a break, go for a walk, drink some tea… anything that helps you relax and clear your mind. When your mind is relaxed and you are ready, then follow.
Second: Where are we?
Planning for a project that will involve dozens of people for several months/years is no easy task. But it is definitely impossible if you don’t know where you stand.
Gather all existing documentation, locate the stakeholders and review your team status. Check for the rest of the teams’. Ask your bosses on the studio plans. Is the studio growing? Will it shrink?. Get all information you can about release dates, platforms and anything that management may have already agreed/signed.
In my case, the project involved an important partner that would provide the license for the characters that would appear there, so it was crucial to know what was already set in stone and what was still to be signed.
Finally, look for similar projects you can have access to. Maybe your studio/company has already worked on something similar in the past you can start with.
And now, before you break the news to the team, you need to set your mind on two different fronts, the psychological front (you as the leader) and the technical front (you as the engineer).
In this first article I’ll focus on “the leader”, which is probably the least known aspect of these kind of managing roles.
Being “the leader” is an important aspect of your management. I know for a fact there are companies where there was a huge technical rotation during and after a project was being developed. Burnout, frustration and tiredness made it not uncommon to see a project where only a fraction of the engineers who kickstarted it would see it finish, and this was a situation I was not willing to accept. So, with that in mind I crafted the following principles I was going to abide with.
Principle 1: Get rid of your ego, and your team’s.
As a technical person, one of the things that feels the worst is changing plans. If let loose, this feeling will root in you and your team and will generate a sensation of “being surrounded by incompetent people”. But there will be a lot of people who want to put their hands on such a big project and since the stakes are high, requirements will change for sure and many many iterations will happen on the same elements of the game. In my last triple-A project UI was one of the most challenging fronts: The game’s economy was very complex and ultimately it was a matter of experience, not just information presentation, that lead it. We actually had to iterate intensely on menus, some of them being re-thought many many many times. Imagine the impact this can have in you and your team. From their point of view, their work is being “thrown away” for reasons that have so little technical explanation that it is hard to justify. On top of that, be sure those things will happen at the worst time, close to important dates and at stress peaks. If you don’t work on ego-management from the get go, when projects are at their initial state you are most certainly doomed as those moments will root in their minds and prevent them from doing their best.
My vision here is to encourage people to deal with their non-technical counterparts directly. Have them meet “the person”, not just the “task creator”. Make sure they understand them, their motivations, their concerns and their criteria. Also inside your team, make them work in pairs in a rotative fashion so they know each other and can rely on them. Point being: Do not become a barrier in their day-to-day work, let them communicate freely. They should keep something in their mind though: They must inform you on any changes that may be requested to them directly. They are free to communicate, but they are not allowed to change the course of action, task assignment or take any project decision without you being involved.
If you manage to have a fluid intra and inter-department communication, ego will disappear.
Principle 2: Work on a team, not a bunch of people working together.
One of the worst possible scenarios you can have here is a team where everybody works alone, just delivering the tasks you assign to them and nothing else. If the project is to succeed, you need your team to act as a unit, so whenever anybody makes a mistake, which is something that will inevitably happen…many times, somebody else will jump in and assist them, ideally, without your intervention.
My decision here was to plan tasks in pairs, rotate ownership and encourage direct communication between team members. Make sure they work together, organize together and solve problems together. Also to praise tasks as a whole, not individually and also complain about tasks as a whole, not as a person’s work. If you do this from the very beginning, the team will get resilience and flexibility as well as improving teamwork.
Principle 3: Channel feelings.
This is very related to the previous point, as it aims in the same direction. Make sure you stablish a plan to be aware and channel the team’s feelings.
There are several techniques that can help here. The one I applied was to make sure it was me who delivered shaking news to the team. As a lead I was to be present in all important meetings and I tried to shield the team from hearing news from other sources. I mentioned before how challenging UI was in my last triple-A game, so my stand was always to be the one notified first (and only) so I could break the news to the team in the proper way. Some companies’ structure will actually encourage that, but some other’s, with more fluid ways of communicating. won’t.
Another thing I wanted to enforce was to be extremely transparent. Rumors can hurt, so you need to make sure your team knows at heart that you are not hiding important information from them. And the best way to do it is to be transparent. Even if there was to be some secret meetings, I informed them that these were taking place, even if I did not disclose their contents or conclusions to them.
Finally, as a lead, I also wanted to channel feelings in the right direction, so I actually applied a philosophy that is so controversial many people do not share: I would make sure I do not hide my personal opinion about certain aspects of the project. I tried to have two modes: one fo them was “Manuel the boss”, who would be cold and informative (but very transparent) and then there would be “Manuel the workmate” who would say things as he feels. Point being: if you are one member of the team, not their boss, you’ll be able to avoid ego, distrust and conflicts. And again, this will help them perform better since they will be a team, rather than individual people working in the same direction.
Principle 4: Trust
“Trust is the byproduct of past successes. One cannot trust a team who has had no success”. I heard this once in the past (won’t cite the font for obvious reasons) and it is something I completely disagree with. If you want to make a triple-A game, or any big project, you need to trust people around you from the get go. You need to trust they’ll do their best, that they will challenge their comfort zone and that they will be honest with you. You cannot wait for people to prove themselves to you, nor can you stablish a process to “gain your trust” as there is too much work to do. My philosophy was very clear in this aspect: I will trust everybody in my team, regardless of their experience or knowledge. I did, of course, intensive reviews in the process, and I expected people to have no problem in giving (or receiving) negative feedback when it was due. Take into account that negative feedback based on trust is the same as a chance of improvement, and when people feel trusted, safe, they do take those opportunities. At the same time, I would give people plenty of chances should they fail to deliver, but I was also relentless to kick them out of the team If I felt that was necessary.
Trust will make improving easier, will make development and collaboration faster and will encourage people to give their best instead of just putting in the hours. So make sure you trust them.
There was this time during the project where an engineer joined. I had already heard all kind of horrible stories about him, on how he antagonized everybody, his deliver quality was not top-notch and how big were the conflicts he had in the past. Yet I decided to give him a chance. And by doing so it meant I was trusting this person, who supposedly was so bad. Turned out that the true problem was that nobody had trusted him in the past so he was acting extremely defensively. He got into the team mindset immediately and was extremely eager to learn, to grow and to deliver at his best. Never he complained or antagonized any kind of negative feedback, never he had conflict with anybody and once I managed to know where he could shine (see part 2 of this article, The engineer) he was an amazing person to work alongside.
Principle 5: 1-on-1s
There is one thing you need to be aware of: People have lives outside the triple-A game. And people’s lives do matter to them. The company I worked for started a process of encouraging 1-on-1 meetings with everybody’s lead. A 1-on-1 is pretty much like an informal chat between two people with the aim to know and understand each other without a direct job-related conversation. Please take the chance to do this. Many events can unfold in one’s life in the amount of time a triple-A game project needs. And people willl still need to deal with delivery dates, stress and pressure. Some events will be nice events, which you don’t need to worry about, but some others will be nasty and sad, at which time you need to make sure your team knows, at heart, it will be better for them to tell you “Hey, Manuel, I’m struggling for this reason, can you please lower my workload?” rather than pushing harder in a rough time. Empathy is key here. Be empathic to them, if they feel you are there to help them, you will, most certainly, be able to help them, the project and ultimately yourself.
Principle 6: No remorse. No hesitation. And don’t forget: we are making a product here
If you were to take an approach such as mine, where you trust, help and even care for your team, then there is one final consequence for this: Do not hesitate to kick somebody out if he/she is taking advantage of you or the team. Also be relentless if they do not want to be working as a part of a team, their growth has stopped or people feel uncomfortable working around them. Your job is to make the most of people who do want it.
In the same fashion, be firm when denying somebody entry to your team.
Conflictive people, lone wolves and divas have no place in a true team. Ex boyfriends or girlfriends or even people who you “just” feel will ruin the team spirit neither. Do not feel bad to deny somebody the chance to work in your team, even if you have available slots in it.
Finally, keep in mind that the objective of the team is to build a triple-A game. You can be caring, helpful and understanding, but the moment somebody deviates from this objective, that somebody should be out.
There is a thin line between being a nice person and being a dump one, make sure you don’t cross it over to the dump side or you’ll ruin the potential of your team.
