A team lead's takeaway on a year long project.

Context

Before I get to the actual interesting stuff I need to give you some context so that you can actually understand why certain things were more difficult than they needed to be.

Together with a team consisting of 22 multi-disciplinary student developers we created a free game called ‘Captain Starshot’ over the course of 32 weeks with 4 working days each. This game was created in function of Breda University of Applied Sciences as a year long project.

I was the producer throughout the entire development process. This included concepting, pre production, production and post production

Because we were working as students in a university we were forced to work in a flat hierarchy. Not because of any hard set rules but simply because of assumptions, desires and goals from every person involved in the endeavor. Here are some of the issues the team was tested with:

At the beginning of the year we were given a project brief and were expected to make something of it. People that know each other and may or may not have worked together in the past were slammed in one team with the hope that it would work out. Concepting, procedures, rules,... nothing was defined and everything started at the same time.

I will try to give you a production/management/lead perspective in case you are in a similar position that it might give you some inspiration and improve your team.

Struggles

In any team there will be difficulties. Company structure, titles and rules are usually what give teams structure. However in our case there was no predetermined structure, no official titles and the rules were extremely limited.

Somehow a team of peers had to figure out what the best course was for a year long creative project that included software development, artistic art stuff and user experience design. No one that officially had more skill or authority for any of the disciplines. 

So what did we do to make it work? 

Goal #1: Structure

The first thing we had to achieve was team structure. Who would be making the decisions, how would we communicate, how and when would we work, what work ethics would be necessary,...

The first thing we did was establish a strong lead team. For each discipline we had one lead. The communicative skill is incredibly important here so be very mindful of who you choose to lead. 

A lead’s job is to be a representative towards anyone that is not directly in that team. If a lead does not properly communicate in any way you should replace him by someone who does.  Some guidelines i noticed:

These are the main ones that I identified as important traits or qualities that a good lead should have. The ability to manage, track and organize the team is also important but is secondary to the above listed points.

The lead’s job is to manage the project’s creative direction. Together with you, the producer, you will form the lead or management team. You guys should be a fixed point, any and all decisions you should all agree on. If there is anything wrong, unclear or otherwise undesirable the team will be looking at the lead team for direction and guidance. 

As a producer you should have little or even nothing to do with the creative direction of anything in the project, that is for your leads to do, your job is to make sure that the team can work as well as possible. Note that i did not say ‘efficiently’. In a lot of information regarding production it is said that the producer should improve the efficiency. While this is true do not treat this as you main objective. Especially not in a flat structure. People will resent you for it as they will not feel like you have the authority, skill or experience to actually make those decisions for them. Instead make efficiency decisions together with the leads based on data you have gathered from the team. 

Anyways, once you have leads setup they will be taking care of the team for now so you can take a step back as a producer to establish project rules. This can literally be anything.

I would advise you to note anything down that you think a team member should know. This is basically a contract, however in the case that you are also dealing with a flat hierarchy call it ‘Team rules agreement’ or something similar and save yourself a world of pain.

Goal #2: Clear & defined responsibilities

Make sure that individual responsibilities are clearly defined. Start with the leads, clearly communicate what the team can expect from them and what they can expect from the team. Make it so that people are able to say that something is not within their responsibility and that it is clear when they are doing something outside of that. This makes it a lot easier when you will be tackling multiple things at once. After the leads define that for roles, disciplines,... whatever you deem appropriate but make sure they can do the same thing.

Goal #3: Set a common goal

Depending on what project stage you start in this may or may not come natural. However having the entire team focused on the same goal is harder than it seems. When you have your team focused on reaching the same goal and vision the ideas and creative effort will be more in line with what the project’s needs.

A couple of tools that helped us establish this:

Help the team see the same thing. There will always be deviations but get them as close to each other as possible. Ideally you would be able to make a cinematic like For Honor.

Before For Honor, Ubisoft’s medieval brawler, actually became a fully playable game they spend millions on creating a cinematic. This was a very simple but high quality video where they followed a knight around the battlefield fighting other dudes with an e-sports sounding narrator talking over it. This establishes:

I would say that this is the only way to get people to see nearly the exact same thing. However i not every team has the funds to do this so you can simply stick with the aforementioned points.

Goal #4: Milestones & Deadlines

As a producer you will no doubt hear the words milestones and deadlines every day. It’s considered to be one of the main responsibilities as a producer. Milestones and deadlines do not mean much to a team until you actually reach them, therefore it is extremely tempting to keep pushing them so that the deliverable will be of higher quality. Even though you are the producer you will not be able to either push or not push one of these without resistance from the team. 

Instead of having the team work hard to make these deadlines i would advise you to set team events. Build reviews, play time, competitions, art competitions, … anything that gets the team involved with the project in a non-development way but still has them look at the project and see where it can be improved. This will give the team a moment where they can sit down, take a moment and actually take a look at what the current state of the game versus what you wanted to achieve. Milestones and deadlines do surprisingly little for that, treat them as official deliverables you have to hit because they will not be much more to the team.

Note #1: Altruism, stress management and scapegoating

As a producer you will be taking a lot of blame. I am talking about almost every single thing. If you can’t take that without becoming emotional and personal you should really consider doing something else. As a producer you will be responsible for everything you are not able to do yourself and if it goes wrong you will take the first blame for it. In many cases even the team will start using you as a scapegoat. 

If the team starts using you as a scapegoat often this might be a sign of a bigger underlying problem you haven’t identified yet so if that’s the case, investigate!

Furthermore, you will be doing a lot of unthankful work. It will happen and you have to be able to deal with that.

Note #2: Hard skills VS Soft skills

Your soft skills will be much more important than your hard skills. Read up and learn about how to open constructive dialogue, how to diffuse an emotional discussion and how to negotiate. These are the tools of your trade, planning scheduling and organizing comes second.

I hope this might help someone out in the future. I tried not to go in depth of the specific issues we had and just stick with the takeaway points.

Cheers,
Nick