A couple weeks ago I went to my first ever Game Developers Conference (GDC) with the hopes of learning a bit more about indie development and bringing that wisdom back home to my team, and boy did I learn a lot! In this blog I thought I’d talk a bit about those little nuggets of knowledge that I found and how they applied to our team.
Overall GDC was incredible. I got to catch up with old friend, meet a bunch of awesome people, and hear some seriously inspiring and educational talks. One of the highlights was “Practical Tips for Growing an Indie Studio” by Alex Kennedy, founder of Failbetter Games. He had a whole slew of techniques that I could apply to my own team, and the two that stuck out were the idea of assigning a “buck” to tasks and flagging — excuse my language — fuck ups.
Alex described the buck as the person who is solely responsible for getting a specific task done. He pointed out that if multiple people are responsible for something, it’s easy for one person to assume that the other will complete it and vice versa, and in the end communication breaks down. Thus, it’s best to assign a single person — or a buck — to each task and have them be responsible for making sure it is completed.
Though I hadn’t consciously thought about this idea before Alex’s talk, I realized that our team has been assigning bucks all along and reaping the benefits of this organizational technique. For example, when we started this blog we knew that we would want to rotate who writes a post every week. Initially we said that whoever wanted to write one would just post it on the blog, but that felt too confusing and two people might end up both writing something for the same week — not the worst thing but not very efficient. So we decided that every week we’d choose one of us to post here and share their thoughts about development; we were effectively assigning a buck without realizing it! This is a pretty basic example and assigning someone a task isn’t a revolutionary strategy, but I do think that being aware of exactly what techniques we’re using and codifying which ones are actually effective is essential for long-term team growth.
Another of my favorites from Alex’s talk was the concept of flagging fuck ups. It’s a simple idea — tell your team if you’re not going to make a deadline or if you’re having problems — but at its heart lies a much more complex problem. Telling people you work with that you’re fucking up requires a great deal of trust in a studio environment. If you feel like you will be punished, ridiculed or fired for telling your co-workers that something is wrong — whether it’s your fault or not — then you most likely won’t say anything until the deadline is actually upon you or the problem bubbles to the surface. This can create all sorts of stress in a team and ultimately builds your studio on the shaky and unstable grounds of dishonesty. Not good. My takeaway from Alex was to create a studio environment built on a foundation of trust in which everyone can feel safe and comfortable sharing their mistakes. There’s few things that make you feel more vulnerable than revealing that you’ve fucked up, but it’s an important step in forming a team that can work together harmoniously and efficiently.
There was so much more about Alex’s talk that I found helpful, so I definitely recommend checking it out in the GDC Vault if you get the chance. Right now we’re working on a new intro section to TWGR that we’re planning on showing at an expo next month — more details to come soon!