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:
What they worked on the day before
What they’ll be working on today
If there’s anything blocking them from completing their tasks
These simple questions are great because it informs the entire team of everyone else is doing and helps them solve any issues before they happen (such as two people working on the same task or on a feature that is already implemented). I adapted this idea and called it “check-ins." The idea is that your communication server has a channel dedicated to check-ins, where everyone will answer these three questions as soon as they sit down to work every day. The answers should be short, but concrete.
Try to avoid being too broad (working on gameplay today) and be specific about what you are doing, referencing specific tasks you will tackle from your task board. Going into this channel to write your answers also encourages each member to read everyone else’s answers and know what’s going on in the project. It’s also a great way to make sure everyone is working and pulling their weight within the team. Last, make sure to be honest. If possible, the days you are not going to be working, hop into the channel and post: “Not working on anything today, I’m taking a break for the day." The team will understand and it relieves the pressure off your shoulders knowing the team is aware of what’s going on.
6. Set milestones
Planning too far ahead into the future is almost impossible, especially in games where the design is constantly changing. Having a goal to “finish the game” can feel like a goalpost that is ever-moving and unobtainable, which negatively affects the motivation of the entire team.
Instead, have short-term achievable goals and try your best to meet them on time. This will help with team morale and will take you from a small prototype to a released game more consistently. Remember those meetings we talked about earlier? Those are a great place to plan and talk about milestones. I’d suggest having a milestone every month, or maybe every two months. These should be stuff like: all movement mechanics implemented, art for world one is complete, 50% of character sound effects done.
Time estimation is an area we all have trouble with, but it can be trained and your estimates will get better and better the more you work on it. However, try to meet milestones, so if you need to get creative or cut content to meet it, then do it. Games small and large cut content constantly in order to meet milestones, and they are all the better for it. Just make sure you are in constant communication with your team and keeping them informed on your progress so you can all make the decision on cutting content.
7. Use source control
The use of source control in any project is extremely important, and it is essential when your team has more than one programmer. It’s a great way to backup your game, use it to pinpoint when a certain bug was created, and keep resources up to date. This is why I encourage teams to teach their artists and sound designers to use source control. This way, they can always have the latest build working on their computers for testing (test your game constantly please!) and they can add or tweak their assets without the help of a programmer or designer, which improves the team’s workflow. If you don’t know much about source control, I wrote a couple of articles about it. It is focused on GameMaker, but some of the basic concepts are the same, and there are lots of resources out there to learn how to use it in your project. Here are the articles:
I hope these tips help you find a team and improve your communication, teamwork, and workflow. Remember that this list isn’t exhaustive and that you should only use what works for your team, but I definitely encourage you to try some of these tools for a few weeks. You may be surprised at how effective some are even if they sound silly at first. If you have any questions, feel free to contact me through Twitter at @AleHitti.
Alejandro Hitti is a videogame Programmer and Designer from Venezuela. Although his background is in C++ and working using custom-made game engines, his two commercial games, INK and HackyZack, were made using GameMaker Studio 1.4. With the release of GameMaker Studio 2, that became his engine of choice. The novelty of GMS2, paired with his knowledge of the previous version, ignited his interest to create tutorials that focus on this new engine.