What in the heck is this all about?
I’m going to start a series of production articles, centered on detailing what I’ve learned during my time as a producer in the game industry. For those who may be confused by the term, a producer is akin to a software project manager. The terms may be slightly different, but the management techniques and approaches are very similar.
I’m doing this for a few reasons. First, sharing my professional experiences and personal critiques and ideas is key to my job search. That is, perhaps, my most selfish reason for doing this.
Second, I understand that my experience is only one point of view. Even if I provided an unbiased, objective account of my experience, it would only be my experience. That said, we tend to learn best by listening to stories built upon experience. Gary Klein’s book, Sources of Power: How People Make Decisions (MIT Press, 1998), discusses the power of storytelling and how listening to the experiences of others makes us better able to recognize patterns, improves our mental simulations, and helps us to more effectively respond to critical situations as they happen. So really, I’m doing this for your own good.
Third, I’m motivated to correct some prevalent misinformation I’ve encountered. I’ve worked and talked shop with people who — to this day — don’t understand what “Agile” really means. Agile, as an umbrella term, describes several iterative and incremental software development methodologies. It doesn’t mean that the team can simply react to any whim or impulse. It also doesn’t mean that the process is irrelevant, so long as the goals are achieved. Words have meaning. By extension, so do terms. Agile, as a term, means something, and most game dev studios are not truly Agile in their approach.
Finally, I believe in sharing knowledge, when it comes to basic techniques, tools, and management styles. I’ve worked with teams that tried to keep all of their learnings on these topics under wraps, as though these ideas embodied some sort of “secret process” that was guaranteed to bring them success. That sort of magical thinking prevents real progress. It also ignores the fact that most non-game development environments have already solved many of the problems that continue to befuddle game makers.
I plan to touch on a variety of topics over the course of this series:
- Cadence Scheduling for live ops and its relationship to the Dynamic Systems Development Method (DSDM)
- Agile versus DevOps methodologies for game development
- Agile approaches during the development phase
- Managing departments that use a different agile framework (creating team processes)
- Process and the bureaucratic impulse
- QA: The Critical Path for Cadence
- Community & Customer Service: Building a Relationship with the Audience
- Product Management and Production for Free-to-Play Games
- Avoiding “Crazy Town”
- The value of knowing how to make things as a producer
- Project costing, including basic PERT/CPM methods and building a Monte Carlo Simulation in Excel
- Prioritization, including the MoSCoW method
- Risk Management in a Creative Environment
- Core Production Tools
- Basic decision making, including scenario trees and weighted ranking
- Basic hypothesis testing
- Useful Excel/Sheets formulas
- Useful SQL
- Generating user stories
- Running a structured playthrough
- Building trust and appropriately exercising influence
- Creating useful, measurable OKRs and KPIs
- Writing team member reviews
- When you can and when you can’t rehabilitate an “at-risk” team member
- Recognizing Project Success
- Dealing with Failure
I’ll very likely intersperse these articles with a few more bits of old design docs, design theory, pitch docs, teardowns of existing products, tips for voiceover directors, and so on.
More to come!