3 Lessons we learned about working with a remote game dev team
If you’re a small game developer these days who’s growing — or working more remotely — you’ve probably realized how different it is creating awesome games effectively while managing an increasing number of moving parts.
As a small game development studio who now works with external partners on projects, we totally get it. So here are three lessons we learned about effectively working with a growing, external team (especially if you’re used to working internally).
Who the heck are we? We are BancyCo — an independent game development studio in Toronto, Canada that has created and published original IP like Home, Alone With You, and Worse Than Death on consoles, PC, and iOS since 2012.
We used to be “Benjamin Rivers Inc.”, and in 2019 we published a featured post called Three crucial lessons from a veteran mom-and-pop game studio. Since then, we rebranded to better reflect the growing ambitions we discussed in that post. (You can read about the rebrand process here too.)
More importantly we also began partnering with other teams to realize our greater ambitions, which is why we needed to rethink a lot about how we work. Here is what we learned this year.
Lesson #1: understand what kind of “computer” your team is
When you’re a small company or a team that all works internally, you’re like a computer with a “system on a chip” (like those fancy new M1 Macs). All of your parts are right there, in the same space, and you have near-instant ability to work together, share ideas, and jam on solutions.
Maybe your capabilities aren’t as infinitely scalable or flexible as a big, desktop PC, but you’re always on the same page, working on the same thing, and boy can you work quickly!
But when you’re working with a growing remote team, you’re more like a big desktop PC: space isn’t a problem, so you can have bigger, beefier components. You can add or change parts as the project needs. You can be more ambitious and more flexible.
But now, there’s overhead with everything you do. People aren’t in the same space anymore; they might not even be in the same time zone. People might also be working on multiple teams at once (especially if they’re not full-time), so now you have schedules, priorities, and technology to work around.
And that means you can’t just yell your amazing new ideas across the room at each other now; you’re going to have to learn to communicate in new ways.
Lesson #2: Don’t communicate “more,” communicate “more effectively”
When BancyCo was just Ben + Nancy, we were a “system on a chip” computer. There was little documentation about our projects because we were in the same space, working on the same thing, always thinking about it, together.
But with a growing remote team, we’ve had to accept that we’re a desktop PC now. So we’ve learned to be better with direction and documentation. We know the rest of our team needs to understand our game as deeply as we do, so now we create clear and comprehensive wikis for projects with goals, design pillars, and guidelines. Team members can comment, revise and ask questions, and it can evolve accordingly.
This may seem really obvious, but we noticed that there were a lot of things we took for granted that we had to think through in a more official capacity once we began to grow. And at the beginning, it seemed like a huge amount of “extra” work — but now it’s just part of the process, and it’s making our work so much better.
Lesson #3: Make the smallest bet you can to test new ideas
Developing a game isn’t a strictly linear endeavour; sometimes you need to walk back an idea or try something new to properly solve a problem. But when you have an expanded, remote team, dealing with repeated revisions and iterations of the same content can lead to restlessness, confusion, and burnout.
Now, we’ve learned to take more time internally to test ideas before mobilizing the rest of our team. Specifically, we often create “prototypes of prototypes”: tiny, interactive demos with easy-to-use game-development software to show our programming lead, or “animatic”-style presentations to demonstrate visual concepts to our lead artist.
This way we can try out a gameplay idea or test a new UX flow within a day or two — and if it works, we can proceed to document it and discuss it with the rest of our team for actual development; if it doesn’t, we can make a note of what we learned and apply it to something else.
Working with a growing team made it feel like we had to get everything “right” before assigning work, but this didn’t capitalize on the iterative nature of game development. Now, instead of worry about getting it 100% right the first time, we embrace these fast iterations so we can both play around and provide clear direction to our team.
