Work generates work.
Hello everyone! Happy to be back.
You might have noticed I was gone for a couple of weeks and probably thought to yourself “he said he was going to do weekly posts but that only lasted for a month…” but hey, I was gone for a good reason: I was starting a new role as a contract Junior Producer at 2K! I’m extremely excited to be here, and so far the team has been extremely welcoming.
Now that I’ve (partially) found my footing, I’ll be back to writing weekly blog posts. And with that said, let’s get to the meat of the post…
The other day I was listening to a GDC talk on “sustainable collaborative production” by Carrie Patel, the game director on Avowed at Obsidian at the time of the talk.
It’s a great talk and you should definitely listen to the entire recording yourself, but the gist of it is that Carrie describes the dangers of two types of developers:
- “Mavericks” is the term used to describe developers who have an idea they’re determined to see through, and manage to piece it together in engine by themselves through crafty solutions that usually require a lot of metaphorical duct tape.
- On the other hand, “martyrs” are those who go above and beyond to implement content in time for a deadline, even if it means long hours, working weekends or sacrificing personal commitments.
Both of these kinds of developers do what they do out of passion for the game, and it can be tempting to even reward this kind of behavior, but their good intentions can be ultimately a net negative for the team:
- While a maverick can get a e.g. quest functional and playable, it usually requires more work from specialized team members to reach a shippable level of quality.
- A martyr's sacrifice usually isn’t sustainable in the long term, and can either cause issues in estimation data down the line or simply burn out other team members who are unable to keep up with the martyr’s pace of work.
While I haven’t had the chance myself to run into these kinds of individuals in a larger organization, Carrie’s talk in general reminded me of a lesson I learned early on in my career: work generates work.
Imagine you’re making a fully voiced narrative game. If you have talented, hard-working writers, it might be tempting to let them go wild and write an intricate story with detailed main characters, companions and NPCs. But each line of dialogue they write means an additional line of voice acting to record. Each additional line of voice acting will require editing and implementation in engine. And each implemented line will have to go through QA to ensure that it plays at the right moment and the text on screen matches what the actor actually said. And don’t get me started on localization!
While being cautious in this kind of situation is probably intuitive to anyone who has had to handle a budget for hiring voice actors, “work generates work” applies to any kind of situation where the work of one developer upstream (concept artist, designer, etc.) will affect another developer downstream (modeler, gameplay programmer, etc.). I’ve worked with designers who worked very hard making fantastic, detailed designs with clear mockups of how a system should work, yet ultimately we’ve had to scrap or simplify their designs because we simply did not have the downstream capacity to properly implement their ideas. A pipeline will only be able to produce work as fast as its slowest step is able to produce. In other words, an individual being highly productive does not necessarily translate into the entire team being more productive.
Another version of this idea I really like is this Benjamin Carcich video on the difference between being efficient versus being effective. It can be tempting for teams to focus on being more efficient (e.g. getting better at making more models, designing more levels, writing more code) since it’s easier to measure, but this won’t necessarily result in teams being more effective at reaching its goals, whether it be making a great game, or something else. While mavericks and martyrs are team members that could be described as very efficient individually, the additional work they’re generating for other team members can make the team less effective as a whole.
What are we supposed to do, then?
As a producer, it is expected that we have a bird's-eye view of a development process, but I have found it extremely useful to make sure individual team members also understand how their work fits into the rest of the team. A designer doesn’t have to become an programming expert, but the better they understand the work required to implement one of their design specs, the better they’ll be able to account for the programming team’s capacity when designing.
There will definitely be situations where some steps in the pipeline will be slower than others, and sometimes the best you can do is have people upstream slow down when you realize the developers downstream have more work in their backlog than what they can handle. In an ideal situation, the upstream developer could possibly spend time preparing materials that then makes it easier for a downstream developer to do their job (e.g. a character designer creating thumbnails of possible ways the animator could animate the character), and I’ve seen some success “multiclassing” on smaller indie teams where team members already wear multiple hats. But sometimes, I’ve found it most effective to give time to the developer to experiment on another project, enroll in a course to upskill or simply take it easy. It does sound suboptimal and inefficient — but the more you make them work, the more work they will generate for the rest of the team.
I’ve met a lot of passionate, hard working developers, and it’s part of the reason why I love the game industry. Part of your job as a producer is ensuring your team does its best work possible, and many times that means helping them move faster with more clarity. But, every once in a while, that also means knowing when it’s the right moment to slow them down.