Finding a team as an indie developer can be challenging. And, once you have found one, keeping it together and working efficiently is even harder. Over the years, I’ve had good and bad experiences with teams and projects, but that’s part of the process. The bright side is that I've learned a few tips and tricks that can help you easily find and manage a team.

For reference, the most complicated team to manage that I’ve been on had people living in Brazil, Japan, Seattle, and Michigan. That’s four time zones!

Finding the right team

This section is the one that can have the most variation, so your experience may differ vastly from mine. However, I will list the ways I use to find people and the qualities I look for when considering people for my teams.

• Meet other developers: I think it’s important to have some sort of a relationship with the people you want to work with, before the project starts. This doesn’t have to be a long or deep relationship, but at the very least, try working with people you’ve talked to in a non-professional setting more than once. You could follow other devs on social media and engage with them. Teaming up with people you know personally can also be a good idea, but these cases can be rare depending on where you live.
• Look through their portfolio: It’s always a good idea to see their previous work and if it fits with what you are trying to do. Another thing you should consider is their ability level and how it compares to yours as I believe it’s good to have teams with similar experience levels. Notice that this goes both ways, so make sure you’ve done some work yourself and have something in your portfolio to show it to people.
• Avoid “ideas people”: Too often I see people trying to assemble a team by saying something like: “I have this never-before-done idea for a game that will make us millionaires! But I need a programmer, designer, artist, sound designer, everything, and I’ll be the idea guy." No. Just… no. Everyone needs to pull their weight in a team. Everyone has a million game ideas in their heads that are potentially a hit. Ideas are worth nothing. Implementing an idea is what’s valuable, so if you find one of these idea people, make sure they at least will code, script, do the art -- something.
• Pay contractors: This one is complicated, but one that also comes up a lot. The issue is that artists and sound designers are often brought into a team, they make some assets, and then the game or team falls apart, wasting their time. In my experience, it’s best to pay for the art and sound for your game outright, or work out a deal where they charge less for their assets in exchange for some revenue share when (or if) the game ever comes out. It’s the best solution to this problem I’ve seen and experienced. Also, you should never ask someone to work “for exposure." Either they have revenue share, a flat fee for their work, or a mix of both, but never work or ask someone to work for free.

First steps once you have a team

While most of these are not 100% necessary at the early stages of development, doing them will prevent future headaches and conflicts. Believe me.

• Write and sign contracts: This will make sure everyone knows what is expected of them to do, what their compensation is, who owns what (can sound designers sell the OST themselves? What about art prints?), and what happens in the event that someone wants to leave the team.
• Create an LLC: To sell the game, you will need to have a company. The easiest one to make and manage is an LLC, but you can look up S-Corps and C-Corps and pick the one that’s right for your project. Having the company early isn’t too vital, but the sooner, the better, especially since you can specify in the contracts that the company owns the assets, instead of individuals.
• Set up a company bank account: When you have the company set up, having a bank account is also important. Sure, you can have the money go to someone’s personal account, but it is MUCH safer for everyone involved if the money from your game is being funneled into a company account.

Best practices for managing the team

In most cases, when you hear about a game that did not launch or got canceled, the issue can be tracked down to bad management. Whether you are working on a team of two, or two hundred, managing teams and getting people to work together to achieve the same goal is very complicated. Luckily, some smart people have created, tested, and improved a bunch of techniques that can be used to more consistently avoid these situations from happening.

I will list a few of the tools I use in my teams, a lot of them I took from from agile, a production methodology that encourages fluidity and adaptability. Agile is a huge topic that is out of the scope of this article, but I encourage you to delve deeper into it if you find the next few practices and tools useful.

1. Pick someone to act as producer

Several of the points I will cover later in this article will mention the producer. This person is NOT the team leader (though it can be), and in an indie team, is usually not only the producer, but has another role, such as a programmer or artist. The person who will take on the producer role needs to be organized and understand that this will add a ton of work and responsibilities on their plate, but will benefit the team in the long run.

2. Communicate as much as possible

The most important aspect of working in any team environment is communication. Having an easy way for everyone to discuss game ideas, ask questions, and show their work is essential. This is especially true when working with people in different time zones, where they may miss a conversation that happened while they were away. Don’t use a program that only has a single conversation thread, as it’s hard to recap what’s going on, especially when there are multiple conversations going on at once.

Instead, use a service that allows you to set up channels for each topic (art, programming, design, etc). This helps members find information that is relevant to them, as it is contained in one or two places. Also, I recommend you have a channel for general banter. It’s always good when teams just hang out and talk for fun, as it strengthens their bonds!

3. Schedule meetings

Part of the job of the producer is to keep the team informed and the project on track. The best way to achieve this is to have consistent team meetings. These are different from your day-to-day chats, and they are most effective when done through a call or video call, not text. I’d say if you are all working full time on the game, having weekly meetings is reasonable, but if it’s more of a hobby project, having meetings every two weeks, or once a month, is fine too. During these meetings, you can check the status of your project, how your milestone is going, do a milestone review, and update your task board (which I’ll talk about in a bit). The producer should always have a plan for the meeting so it stays on topic, covers all the information that is relevant, and makes the meeting short and concise. No one likes long meetings where not much is said.

4. Have a task board

When working on a game with hundreds, if not thousands, of moving parts, it is essential that the team has a way of tracking tasks that need to be done, are finished, or are in the backburner. There’s a few online resources that facilitate these sort of task boards for your team. Choose one that fits your team and use it! It can be a pain in the beginning to get used to the workflow, but after a while, you’ll wonder how you ever worked without one.

The producer is usually responsible for assigning tasks, adding new tasks to the board, and prioritizing them. A big check and update of your board can be done once a week, but small updates will happen throughout the week. This way, everyone in the team can wake up every morning, check the board, pick a task to complete, and do it. After they are done, they can mark it as finished, pick another task, and work away. Good tasks are preferably split into small pieces that can be completed in a single seating. It is still okay to have larger tasks in the board, but it’s a good idea to break them down into smaller pieces once it reaches the point in the queue where people will work on it

5. Daily check-ins

In agile, there’s a useful tool called “stand-up meetings,” which are basically small five to 10-minute chat that happen at the beginning of the day between teams. It consists of people standing around in a circle and saying three things: