Sponsored By

Lessons from Interstellar Racing League

Here are four important lessons I learned about being a producer on a 55 person team.

Cole Thatcher, Blogger

December 13, 2018

3 Min Read
Game Developer logo in a gray background | Game Developer

Working on Interstellar Racing League (IRL) brought me many new experiences including my first time being a producer, first time being a lead producer, and first time working on a team larger than a dozen people. These new opportunities allowed IRL to be an incredible opportunity for me to grow. I want to share with you the most important lessons I learned throughout the development process.

Being a producer is more than schedules and risks

I knew going into the project that as a producer I was responsible for helping with schedule, managing risks and removing blockers. I found that these tasks do not express what a producer does. I learned that every day I must listen to others, problem solve, facilitate communication and be emotional support for team members. These soft skills are essential to serve and lead your team well.

Team culture and dynamic is important

At times, the development of IRL was hindered because of team dynamic issues. Members of our team had strong subteam identities (i.e. track team, physics team etc.) but lost the idea that we are one team. The lack of team identity led to trust issues which hindered open communication between teams. The lack of team culture and identity taught me that it is essential to take the time early in the project to set your team up for success. Even when we feel too busy, we need to take the time to have a meeting about culture, how we are going to hold each other accountable and how we will function as a team. Additionally, having team events where people get to know each other outside of work is incredibly helpful for the development of your team and game.

Making time for yourself: Urgent vs. Important

As lead producer, problems that arose during development were quickly brought to my attention. These urgent issues often pulled me away from an important task I was working on. I learned that the urgent tasks could usually be delegated and that I couldn’t let urgent tasks be prioritized over important tasks. To do this, I made sure I incorporated my time into sprint planning and broadcasted it in the room, so others knew what I was working on.

It’s all about the player

This is probably the most important lesson of the four. It is always all about the player. Whether members are in a debate about design, art style, UI or I am trying to decide between which tasks are urgent and important, the player is what matters. Design debates can’t be settled until they are in the game to evaluate. The player is the boss in the room. This mentality will allow you to create to best experience for the person that will play it. We are not making a game for ourselves, our stakeholders, our leads or our game designers. We make games for the player.

Read more about:

Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like