by Steve Pavlina, founder of
Dexterity Software and author of
Personal Development for Smart People
A frequent complaint from indie developers is that indie team projects commonly fall apart without ever releasing a finished game. While it’s very difficult to complete a game as a lone wolf developer, some report that it’s even harder to form a multi-person team that can achieve this goal. Because it’s so rare for an individual to achieve sufficient talent in the areas of design, programming, art, music, and sound effects (not to mention marketing, selling, and business acumen), there’s an obvious incentive to assemble a team that covers most or all of these areas. Not only can a team tackle more ambitious projects than an individual, but there are projects you can complete with a team that are effectively impossible for an individual. But do the potential rewards of a team project outweigh the risks?
Although team projects can lead to great rewards, they can also be perilous. When a lone wolf’s project fails, the damage is minimal. Often only one person is affected, and that person generally assumes full responsibility for the results anyway. Few outsiders will even take notice. You made a mistake… you only hurt yourself and hopefully learned from it… no harm, no foul. Sometimes a failed individual project is even considered a badge of honor, a sign that you endeavored to stretch beyond your previous limits. However, when a team project fails, many lives are affected. Fingers point in all directions. Angry posts from disgruntled team members start flooding message boards: "The designer is an idiot," "The whole art team is lazy," "The programmer is incompetent," "The project was just too ambitious." The project dies a painful public death. Bitter ex-participants conclude that team projects are perhaps doomed from the start and opt never to make that mistake again.
Yet some team projects actually manage to succeed. The team synergizes well, completes a game in a reasonable amount of time, the game sells well, and the team continues to work together on future projects and lives happily ever after. Why? Did they just get lucky? Or do they know the magic formula that others don’t?
Here’s the good news: There are ways to increase the chance of success for a team project, and magic isn’t required. Most of what follows will probably resonate as common sense, but despite that label, the application of "common sense" principles in team-building remains all too uncommon. So let’s dive right in and learn how to build and maintain a great team….
To build a strong team, you must develop proficiency in the skill of team-building
No one seems to question that if you want to write solid code or create quality music, you need to develop proficiency in those areas. Yet how many developers dive into team-building with no real skill or experience in this area? Team-building is a skill like any other, and for a team project, this skill is more important than technical, artistic, and musical talent combined. Team-building is very challenging — it demands respectful consideration. If you do not know how to select team members, how to manage for results, how to resolve conflicts, and how to handle poor performance, you’d better learn these skills first before you assemble a team.
So how do you become proficient in team-building? The same way you become proficient in any other skill. Read books and articles, listen to audio programs, watch videos, interview successful teams with proven results, and attend classes and seminars. Successful team-building skills can be learned, and this takes time. Be patient. The information you need is out there, but you’ve got to absorb it before you can use it. You wouldn’t want a programmer on your team that couldn’t code a loop to count from 1 to 10 without referring to a book; similarly, it’s very risky to begin building a team until you’ve internalized the basic skills. It’s ok to build individual skills through trial and error, but if you use trial and error as your primary method of acquiring team skills, you’re going to negatively impact many people’s lives, damage your reputation, and probably make some enemies. Jumping into a team project to build your team skills is akin to fighting in a war to build combat skills. In both cases you’ll be lucky if you survive, and you may even bring your whole team down with you. So train yourself in basic team skills in private first. As the U.S. Navy SEALs like to say, "The more you sweat in training, the less you bleed in war."
As a minimum I recommend reading at least five books in this area before you begin to assemble a team. The specific books you read are not as important as your commitment to ongoing education. Keep absorbing new knowledge in this area even after the team is formed. If you already have a team, and it isn’t working out, then head for the bookstore and start learning right now. Take good notes and write out your own processes, such as for interviewing, resolving conflicts, rewarding excellence, and dismissing underperforming team members. Each time you apply these processes, you can further refine them.
How do you know when you’re ready to begin building a team? I would suggest the following rule of thumb: You’re ready when you can acknowledge that you would willingly join a team formed and managed by someone else who had your level of skill in that area. If you would think twice about joining such a team, you’re not ready to form your own. Identify what specific weaknesses would give you pause, and begin educating yourselves in those areas immediately. You live in the information age – take advantage of it.
People who’ve never managed a team before will probably consider this advice to be overly cautious. But those who’ve been burned by mismanaged team projects in the past are likely to appreciate it more.
Team first, project second
Many developers decide on a project they want to develop, work out a design doc, and then begin assembling a team to create it. This may seem like a good idea, but it’s backwards. The team must come first. You cannot realistically select a project until the team has first been assembled. It’s ok to have a general idea of the type of project you want to create, but until the team is assembled, you shouldn’t decide the details of the project. Why is this so? Let’s consider both alternatives (team first vs. project first) to understand the natural consequences….
Let’s first assume you opt for the common "project first, team second" approach. You get inspired by an idea, design a game in some depth, figure out what talent you’ll need to complete the project, and begin looking to build a team. You decide you’ll act as the designer/producer, and you determine you’ll need two programmers and one artist. You can license the music and sound effects for the game. The project is a simple 3D action game. You’re confident it will be a terrific game when it’s done, and the specs look achievable. You estimate that the game could probably be completed in 4-6 months.
Sounds like a reasonable plan, doesn’t it? And that’s the trap. Because it looks so reasonable on the surface, indies keep falling for this approach year after year. On a few occasions it actually works, but most of the time it fails utterly. Why?
What happens to the above project in reality? You search for months but can’t find a decent 3D programmer who’s willing to work for your terms. The best you can do is a 2D programmer who’s currently learning 3D programming. The artist you found can’t create decent textures to save his life, but he’s a great 2D animator who’s willing to "give it a shot." The second programmer you manage to find lives overseas and barely speaks English, but he’s willing to work remotely. So you try your best to work with what you’ve got.
Things don’t go well. The two programmers experience frequent personality clashes. The artist isn’t able to create quality textures even after much practice. You get something running on the screen, but the technology is very buggy, and the game isn’t really fun. Team members don’t really buy into your original design and start trying to implement their own ideas, and you get upset that they aren’t reading the design doc carefully enough, so you try to assume more and more control, telling the artist exactly what to draw and giving the programmers ever more detailed to-do lists and schedules. But still everyone has a different conception of how the final game should look, and the lack of synergy causes the project to stall. Team members start doing the minimal work necessary just to make it look like they’re still contributing, but no one really expects the project to succeed. You discover that one of the team members is already contributing to another project, putting yours on the back burner. This downward spiral eventually leads to the cancellation of the project.
The erroneous assumption was that designing a good game is the key limiting factor in the success of the project. That may be true for individual projects, but it isn’t true for team projects. For a team project the limiting factor is securing the right team members. With the wrong team, you’ll end up spending most of your time worrying about control. With the right team, excessive control is unnecessary, and individual empowerment becomes the norm.
Another problem with the "project first, team second" approach is that it fails to leverage the team’s strengths. A game designed to exploit the specific talents you have available is a far better choice. Developers thrive when they work from their strengths. If you have an outstanding 2D artist, use him/her to create an outstanding 2D game instead of a lousy 3D game. Because the team is the limiting factor, the team must dictate the project.
Now let’s consider the second option: "team first, project second." You may have a general idea about the type of project you’re looking to develop, but you keep your options open. You take the time to find the best team members you can. Since you have greater flexibility in choosing team members with this model (because you’ve kept your game design options open), you can pay more attention to interpersonal factors, selecting team members you expect will work well together. Once the team is assembled, together you work out a design that takes best advantage of the team’s strengths and compensates for their weaknesses.
For a project to succeed, you need every team member to be as committed to the project as possible. And developers are more likely to commit when they’ve contributed to the design and when the project gives them a chance to show off their strengths. Each team member knows their contribution will make a real difference, and they assume co-ownership of the project. So in this scenario you’re more likely to witness an upward spiral where enthusiasm and commitment remain strong throughout the project. Also, the team is more likely to want to work together again on future projects.
Selecting the right team members is the single most important factor in determining the success or failure of your project
You’ll see the statement above stressed in the strongest words possible in many top management books. Selecting the right team members is absolutely critical. If the wrong team members are selected, it’s possible that even the best manager in the world can’t salvage the situation and keep the original team intact. When a team is broken, an effective manager will frequently give some team members the axe and recruit new members to replace them.
Don’t blindly recruit the first interested person that comes along. Take your time to find and select the best team members you can, even if it takes months. The main limiting factor for your project will be your ability to attract and select the best team members you can find. If you can’t build a solid team, don’t begin the project.
Select team players, not individual superstars
For a team project to survive and thrive, you must select and recruit people who are team players, not individual superstars.
Consider the case of the 1980 Winter Olympics. Team USA created a huge upset in ice hockey by defeating the USSR team 4-3 and winning the gold, even though the USSR had previously blown away the USA 10-3 in the final exhibition match shortly before the Olympics. Team USA’s coach, Herb Brooks, said in an interview that he used a psychological test to reject self-centered superstars, and he selected only team players who would support each other.
Team players respect individual differences while at the same time committing to the achievement of a mutual goal. Team players are still highly ambitious, but their ambition is directed into the project or the company, not their own egos. Their ambition is for the team. They will rewrite any piece of code, redo any piece of artwork, recompose any piece of music, willingly and without complaint, for the good of the project — for the good of the team. Team players are like the cells in your body, working together to keep the host alive and healthy.
Because team players accept personal responsibility for the success of the project, you don’t need excessive control and management. Problems won’t be ignored – team members will root them out and fix them. Why? Because they’re personally responsible. They "own" the project.
Character trumps personality. Where personal honor is sacred, every individual assumes responsibility for the project. When honesty is paramount, suspicion and distrust cannot gain a foothold. And where mutual respect is high, petty personality differences simply don’t matter.
Your team must have a single individual in charge
Every team must ultimately have exactly one leader, and everyone on the team must know who that leader is with no ambiguity whatsoever. The leader sets the example that the other team members follow, and s/he must earn the respect of the team. When the team members no longer respect the team leader, the downward spiral begins. Respect cannot be coerced. It can only be earned.
How does a team leader earn respect? By embodying the virtue of integrity and by putting the needs of the team first. The team leader is the quintessential team player. The team leader must strive to be honest, fair, and objective. If the team leader makes a promise, it must be kept. Whatever standards the team members are expected to live up to, the team leader must become the embodiment of those standards.
The team leader’s job is to give the team a victory on the first project, no matter what. Because this is an awesome responsibility, it must be coupled with a high degree of control. The team leader listens to all team members, but whenever a key project decision must be made, it’s the team leader’s job to make the final call. In a properly functioning team, team members rarely second-guess the leader. Once all the facts are on the table for a decision to be made, team players will generally come to the same conclusion regarding what’s best for the project and the team, even if it means more work or less freedom for them as individuals.
Software = team
The quality of the software you create will be a direct reflection of the quality of the team you build. The state you want your team to achieve is called unit integrity. In this state all team members are working together to achieve a singular goal. Morale and productivity are high. When you have unit integrity, your project will converge towards a successful launch. Without unit integrity your product will diverge towards cancellation.
The team leader is directly accountable for maintaining unit integrity. If a team member isn’t pulling his/her weight, it’s the team leader’s job to straighten things out or to replace the underperforming team member. If morale is low, the team leader takes action to improve it. The success of the project will depend heavily on the team dynamics, and this cannot be left to chance.
A great way to build unit integrity is to do something together as a team outside the software project itself. If your team is local, try getting together for a pen-and-paper role-playing night once a week. If your team is scattered across the globe, find other activities you can do together, such as playing an online game together, especially a squad-based game where you can play together as a team. If the team members genuinely like and respect each other, it should be easy to find common activities. When teammates become friends, people look forward to the time they spend working together, and team morale soars.
Keep communication channels open
Maintaining a successful team requires an abundance of communication. Keep team members informed about the status of the project. Check in with team members frequently to see how work is progressing. Secrecy breeds resentment.
Build the project at least weekly, and make that build available to all team members. Let every team member know the status of the project. This not only prevents self-delusion about phantom progress, but it also boosts team morale as team members see the project improving week by week.
If your teammates aren’t local to each other, consider maintaining a private section of your web site where every team member can access project documents, including the design doc, schedule, task assignments, and project status updates.
Face-to-face communication is always superior to voice or email because the bulk of human communication is nonverbal. Don’t buffer yourself behind email when another method of communication would be more productive. Pick up the phone or meet with teammates face-to-face if possible.
Share the rewards
There are many ways to establish a compensation structure for your project. Ideally your team will function best if active team members share in the potential rewards, which means a percentage of royalties from sales. It’s critical that team members feel they are being fairly compensated and that their extra efforts will be rewarded. If you feel that a fair compensation structure is impossible, then simply don’t begin the project.
Aside from financial compensation, ensure that every team member receives credit within the game. Praise team members liberally, and be sincere and genuine in your praise. Don’t just assume that they know they’re doing a good job. Praising people is an easy way to boost morale. If possible, always praise individuals publicly (in front of the other team members). Be specific in your praise. Don’t just say, "Great job." Instead say, "You did an outstanding job on those textures last week. The level of detail and lighting were superb. Excellent work! Your art is really helping this game shine."
Put it in writing
Whatever agreements you make with your team members, you must commit them to writing. It’s often easy for people to agree verbally, but when everything is committed to writing, omissions and inconsistencies are more easily discovered. Try to predict all the various contingencies and decide how you’ll handle them. What will you do if a team member wants to leave the project prematurely? What’s the compensation structure? What duties will be performed by each team member? When will the royalty checks be sent out? Who owns the intellectual property? Can the musician sell the songs created for the project on his/her own CDs? There are no right or wrong answers to these questions. Every team will answer them differently. The only wrong choice is not to decide these things in advance and commit them to a signed contract.
Cut underperforming team members
During an anti-terrorist training exercise for a U.S. Navy SEAL team, a SEAL team member accidentally slipped, and his gun went off, shooting and killing one of his teammates. (SEALs train with live ammunition.) The team leader’s response? He immediately kicked that SEAL off the team for life, and in fact, out of the SEALs altogether. Why? Because from that point on, the others SEALs would never be able to fully trust that team member again, and trust is essential for unit integrity. Notice that intention wasn’t even a consideration here. It didn’t matter that the SEAL didn’t intend to kill his teammate. All that mattered was that he did, and this mistake killed team morale. From then on that particular team member would have always been a reminder of failure, which would have destroyed the rest of the team’s focus.
Despite this drastic example, in many ways software projects are similar. If a team member is underperforming, you must take immediate action to correct the situation. Explain what you expect of the team member in terms of performance, and put it all in writing. But if such correction doesn’t satisfactorily occur within a relatively short period of time (30 days is a good figure), this team member will quickly lose the trust of the other team members. And lack of trust kills unit integrity, acting like a cancer that may eventually spread to the whole team. In this situation you must cut the underperforming team member and replace him/her as quickly as possible. It doesn’t matter if this person intends to do better; all that matters is the actual performance. If you’ve selected only team players, there will be no grudges held in such a parting. The team player will recognize that the health of the team and the success of the project may require his/her departure.
A common mistake made by inexperienced team leaders is that they are too patient and forgiving of underperforming team members. While it may seem like a good idea on the surface to give people as many opportunities to change as possible, this generosity comes at great cost. Holding onto the underperformer for too long ends up punishing and sabotaging the entire team. Yes, it can be very tough to let someone go who very much wants to succeed, but it’s a necessary and unavoidable part of management. If you can’t stomach letting someone go, then you simply aren’t fit to lead a team, so don’t put yourself in this position.
This article only provides a small glimpse of the rules for building and managing a successful team. Team-building is a rich subject that can require a lifetime to master, and it is one of the most sought-after skills for CEOs. But despite all the risks and hard work, being a part of a team is an extremely rewarding experience, and most who’ve enjoyed it will tell you that it is indeed worth the effort. Hopefully the tips in this article can help you avoid some of the pitfalls and enjoy more of the rewards of team projects.