A couple of months ago, I walked across the stage to commemorate graduating from college. I studied the Management of Creative Media, and have since started working at Filament Games (Filament) as an Associate Producer. Over that time, I’ve realized there are a couple things I wish I knew more about before starting. However, I feel that the lack of focus on these topics in my education is something to be expected, as schools and businesses have different objectives.
I’ve found that there are three pillars of being a producer at Filament: sales & budgeting, allocation, and managing the team as a whole. Before I go into more detail I need to properly set the scene: Filament typically has multiple projects going on at once, and each might have it’s own client. By contrast, typical big budget game studios focus on one title and devote the entire studio working on it. This difference in studio structure makes a difference in how I approach the three pillars listed above.
Sales and budgeting at Filament covers and combines a host of logistical project factors. In sales, a producer is responsible for the effective communication of the specifics found within a project, rather than focusing on the initial procurement of a client’s interest. They would work with the Game Design team to lay out initial features, but also outline support services, quality requirements, payment schedule, and services that are deemed out of scope for the project. Budgeting is both the management of cost on a project and managing the original cost estimates for the entire project. This is done in collaboration with individuals from each discipline, in order to be as accurate as possible, with the producer bearing the responsibility for taking all that information and presenting it in a digestible way to a client.
Speaking of cost (time), allocation at Filament is a crucial part of a producer’s role on every project. Here, allocation refers to how much of a developer’s time in a given week they should devote to a specific project. This typically is displayed in the form of a percentage, and the producer’s job is to monitor where every team member is at in order to effectively plan sprints. Beneath all of this, though, is the traditional bedrock of managerial duties. The producer is the primary contact of client communication, setting up a meeting schedule, managing the roadmap with the designer, running most meetings, and keeping tabs on the status of the project.
The areas listed above are the main points where I feel that schooling could have better prepared me: sale & budgeting and time allocation. For sales, it was an expectation that we should define the criteria of a project, but this was done on a much smaller scale compared to studio life. At Filament, we need to at least broadly define the core problem the game is aiming to solve, touch upon how to create a solution, and provide a full schedule of the project. Things will always come up in a given project, which is just a fundamental aspect of software development. Filament has a straightforward Change Order process to respond to those situations. However, the focus in my education seemed to be purely on game design and iterating on that. The same goes for budgeting; the priority was getting the work done flat out rather than making sure it was within cost expectations.
The only real attempt I saw was a requirement for individual members to put in at least so many hours per week. Looking back, I could have used this number more like a resource and budgeted accordingly with the team. The intention of the number, though, seemed to be put in place moreso to make sure team members worked on the project flat out. This all resulted in a chaotic environment where it was difficult to determine the given cost of features in the game, or the impact of changes. Despite all this, I do feel like I gained a good, general understanding of the process of game management. I learned about various methodologies such as Agile, Scrum, and Waterfall. On day one of my time at Filament I felt confident discussing with people about Daily Scrum, Sprint Planning, Retrospectives, and Build Reviews. These are aspects of management that I had worked into teams over the past four years, and so I have become innately familiar with their definitions and application.
I don’t think the lack of focus on the above areas is a bad thing, and is understandable when remembering the objectives of both environments. In school, the goal is for students to learn the theoretical best practices in their given field. Students are hammered on their studies, and pushed to understand it as deeply as possible. Businesses, in contrast, are trying to make sure they keep enough money flowing so that the doors stay open. At times, the theoretical best practice is too constrained to be applicable, and thus breaks down. However, the goal of school is to depart the ideal to the students, and help them get familiar with the supporting aspects.
In all, I do feel like going to school for this discipline was a good decision, but not necessarily for the curriculum I was taught. Instead, I feel like the aspect of constantly putting together students onto team in the program I chose was where the value was. I worked on six different projects, of varying length and scope, forcing collaboration between the various disciplines. I just wish I could have been exposed more to the supporting aspects, and gotten some practice implementing and working with them. Nonetheless, due to that program I was able to get a foot in at various studios for internships, and jobs!