The Bus Problem
Let's talk about public transportation for a second.
Ahmed, a mentor of mine, told a story about the bus system where he grew up in Egypt. The buses were (to put it mildly) inconsistent. Sometimes, they'd be back to back. Other times, you might wait hours at the stop and see nothing.
Because people had to rely on the bus for their livelihood, whenever a bus showed up EVERYONE tried to get on. The bus wasn't just packed, it was overflowing. People were hanging onto the sides and climbing on top. Each person knew that if they didn't make it on, the next bus might not come for hours. It strained the bus and was dangerous for the people.
If you compare this to the London rail system, the differences are stark. You show up on the platform, there's an LED telling you when the next train will be there, and as soon as it arrives, the next one after that. The trains are sometimes just a few minutes apart.
The system is consistent and reliable, and if one shows up and starts filling up, for many people it's not a big deal to wait till the next one. After all, it's only 5 minutes away. Missing this one probably won't endanger your job.
Ahmed calls what he observed in Egypt the "Bus Problem."
Simply put: when an event that matters is inconsistent and/or infrequent, people become much more desparate to not miss it if it is important. When an event that matters is frequent and reliable, each individual event matters less.
You can almost turn it into an equation. Take the importance of the value the event provides, regardless of how many of them there are. Divide that by the number of events. The more total events, the less each individual one matters. If something is very important to an organization, and only one of them happens each year, it becomes a BIG deal. Whereas if 20 happen a year, each one is far less important.
Applying this to Game Dev
In game dev, we have a lot of things like this. There are releases, milestones, review cycles (for people and products), retros, and syncs.
The more frequent the event cadence, the less important each one. This has cascading impacts on devs and leaders and decision making.
For example, if you only release once a year, and you've got a large team, EVERYONE probably wants to be in that release. To handle this, you build a giant process to make sure everything is working. Integration can take weeks or longer. Testing is a nightmare, and when it's done, everyone who made it breathes a sigh of release while everyone that didn't wonders how they'll wait for an entire year for their next chance. The systems built around releasing assume it will be difficult, costly, and dangerous.
Now imagine that same team releases every two weeks, so 26 times a year. Releases might still be very important, but the cost of missing is far less. ALSO, the whole organization is probably very good at it, and each individual release is therefore much simpler, less costly, and safer. If something gets pulled from the current release, it's often not that big a deal because it can go out in a couple of weeks.
If you're in the first scenario, with the once a year release cycle, it's hard to comprehend how much better more frequent releases can be. Because you have a view of releases that they take a month or more all by themselves. It seems absurd to release twice a month. No one would ever get work done! But in extreme cases, organizations get to the point of releasing daily, or even hourly. There are reasons I wouldn't recommend that for a live game, but I do recommend organizations develop the tools so they could do it if they needed to.
Frequently doing the hard but important thing often saves time in the long run, but it costs time in the short term. Transforming your organization to be ready to do the hard thing on demand and frequently takes time and effort. Thinking back to Ahmed's childhood in Egypt in contrast to the London rail network, one requires much larger amounts of infrastructure and setup to work. But once it's in place, it allows the entire city to move more freely. It provides immense benefit if you're willing to pay the cost.
This applies to just about anything that is an "event" or recurring cycle in game dev. All of them become more important individually the less frequently they happen. If you only ever think about how work is getting done in a post-mortem after a game launch, that event becomes very expensive and misses tons of opportunity. Whereas if you do a weekly 15 minutes thinking about what you could do better as a team it can be low impact and much better for actually driving the change that's necessary.
Conclusion
The best game dev teams aren't the ones that make grand reveals or important and rare events perfect. They are the teams that do the important events frequently enough that they are both highly proficient at them and good at learning and improving from them even if things went badly.
It fits with most things in life. Worthwhile things are often hard. Doing hard things makes you better at them. Doing hard things frequently makes them seem less hard.
If you're in game dev, don't make retros or releases or sprints or whatever less frequent to try to save time. It won't work. You'll be worse at them and probably won't save time either. Instead, go the other way: ask what it would look like for those events to be so well practiced that everyone could do them every day if they needed to.
And when we get better at the important things in game dev, we're more likely to build better games.
If you want a deeper dive, check out my recent episode on this topic here: https://youtu.be/ikeDgyXSqYc
If you want to improve your ability to lead game teams, I run a Game Dev Leadership Accelerator. It's helped people advance their career in leadership and better support their teams and games.
Sign up to learn more here: https://www.buildingbettergames.gg/gdla
Don't neglect your own learning. The perfect time will never come.
Responses