The Game Producer's Quest Log

The right choice of tools

Cat in a box

The tools you want your team to use v.s. the tools they actually use. Via Daily Mail.

There’s this joke I saw on Twitter once that I always think about that went along the lines of “Hey, I sent you a message on Slack. I tagged you in a thread with a link to the Jira issue. Don’t forget to check the comments on the Google document. We updated the priorities on the Airtable. The latest design is on Canva. The brainstorming is on Miro. I uploaded a Loom with the instructions. We added some details on the GitHub issue.”, etc… You get the point.

We have access nowadays to a near infinite amount of SaaS platforms for whatever use case you think of, and most of them do a pretty decent job at solving a specific problem or two (or maybe they do not, but you’re locked into using them because of organizational policies…).

Yet, using all of these tools is clearly a pain point for teams as there is a whole breed of all-in-one workspace platforms such as Notion or Coda that promise to “reduce the clutter” and provide a “definitive source of truth”. While these applications do serve an important purpose and can even theoretically replace some of the tools you already use, overgeneralizing your process in these applications instead of specialized tools isn’t ideal either. Yes, I could theoretically create a table in Coda instead of using spreadsheet, but it will be much more limited and slow than just using a real spreadsheet. Yes, I could just use Notion’s tools for task tracking but it will quickly buckle under the weight of any medium sized team with more than basic needs.

As a producer, many times it’ll fall upon you to make choices about what and how many tools your team will use. These choices should not be made lightly, as each new tool means another source of information you’ll have to ensure is properly maintained and that people know how to access and use.

When is it the right time to pick a new tool? How do you know which is the right tool for your team? When is it best to just use a tool the team is already familiar with, even if it’s not the best option?

There are many ways to think about it, but there’s one guiding principle I always use as a starting point.

Minimizing Friction

When talking about tools, the one story I keep telling is back from the early days of Smarto Club when we were going through the transition from “group of friends making games together” to “actual company backed by a publisher”, and part of that was figuring out how to formalize our processes beyond just doing whatever felt right at the moment.

One of my responsibilities was figuring out the right task tracking system for the team. Admittedly, I personally had already worked on software projects that mainly used Trello for task tracking, but now that we were making “real” games, I wanted to look for an alternative tool that was game-oriented. I ended up falling in love with Codecks, a really great tool for game developers with a playful analogy of decks, cards and hands.

While we made a valiant attempt at trying to implement it within the team, the fact that I loved it did not mean much if the rest of the team did not click with it. It worked well at first, but after a couple of months it was clear to see that nobody else on the team was updating their tasks without me prodding them, and I could see that this would not be sustainable with more than half of development still ahead of us.

At the same time, we were in the process of looking for a platform to communicate about work (our group chat had definitely hit its limits…). We found out about Guilded as our publisher was experimenting with it at the team, and it felt like a nice fit: it combined the familiar structure of Discord’s voice and chat based channels with integrated organization tools such as calendars, documents and… to-do lists.

You might be groaning/rolling your eyes if you already guessed where this is going, but we ended up using Guilded’s to-do lists as our main task database. It was extremely barebones and not a great system by any means, but it did something important: it minimized friction for team members who had to interact with it daily. It was simple, yes, but the fact that it was simple and integrated into the same platform we used for everyday communication meant that the rest of the team was proactive in updating their tasks and adding new ones, which was an overall net positive for the development process.

This was enough for our first game Teacup as it was a relatively simple game, but we started running into issues when we moved on to our second project, Bubblegum Galaxy. As a bigger, more interconnected game and a slightly bigger team, there was much more nuance in the tasks than what we could describe in short to-do list items, and we had no good way to keep track of the more complex web of dependencies that were resulting. Using the same tool was now resulting in more friction, so it was time to change to a new tool.

We ended up moving to Notion for our task tracking and documentation, which made a lot of sense for the size of the team and complexity of our work. What was key about Notion is that we could build a task tracker that was as simple or complex as we needed — thanks to it’s customizable databases, we began with a very simple tracker that wasn’t overwhelming for the team to switch over to, and I only began to add more custom fields when the team asked for them to better understand the work and its relation to other tasks.

Questions to Ask Yourself

While this is a specific story about a specific tool, what I’ve learned here has helped me whenever considering whether we really need to add a new tool or replace an old one. Some questions I ask myself are:

A tool is just a means to an end. It’s tempting to get swept up in the promise of shiny new technology and fall in love with the solution it promises, but ultimately, a rough tool that works and people use will always be better than trying to find the perfect tool that solves the problem but nobody uses after a few months.