{"id":475,"date":"2017-12-12T00:00:15","date_gmt":"2017-12-12T00:00:15","guid":{"rendered":"https:\/\/bryanwagstaff.com\/?p=475"},"modified":"2017-12-11T04:31:10","modified_gmt":"2017-12-11T04:31:10","slug":"working-with-teams","status":"publish","type":"post","link":"https:\/\/bryanwagstaff.com\/index.php\/working-with-teams\/","title":{"rendered":"Working with Teams"},"content":{"rendered":"
\n

by\u00a0Steve Pavlina<\/a>, founder of Dexterity Software. Reproduced with permission. Part of a series<\/a>.<\/em><\/p>\n

A frequent complaint from indie developers is that indie team projects commonly fall apart without ever releasing a finished game. While it\u2019s very difficult to complete a game as a lone wolf developer, some report that it\u2019s even harder to form a multi-person team that can achieve this goal. Because it\u2019s 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\u2019s 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?<\/p>\n

Although team projects can lead to great rewards, they can also be perilous. When a lone wolf\u2019s 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\u2026 you only hurt yourself and hopefully learned from it\u2026 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.<\/p>\n

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\u2019t?<\/p>\n

Here\u2019s the good news: There are ways to increase the chance of success for a team project, and magic isn\u2019t 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\u2019s dive right in and learn how to build and maintain a great team\u2026.<\/p>\n

To build a strong team, you must develop proficiency in the skill of team-building<\/h3>\n

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 \u2014 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\u2019d better learn these skills first before you assemble a team.<\/p>\n

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\u2019ve got to absorb it before you can use it. You wouldn\u2019t want a programmer on your team that couldn\u2019t code a loop to count from 1 to 10 without referring to a book; similarly, it\u2019s very risky to begin building a team until you\u2019ve internalized the basic skills. It\u2019s 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\u2019re going to negatively impact many people\u2019s 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\u2019ll 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.”<\/p>\n

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\u2019t 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.<\/p>\n

How do you know when you\u2019re ready to begin building a team? I would suggest the following rule of thumb: You\u2019re 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\u2019re 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 \u2013 take advantage of it.<\/p>\n

People who\u2019ve never managed a team before will probably consider this advice to be overly cautious. But those who\u2019ve been burned by mismanaged team projects in the past are likely to appreciate it more.<\/p>\n

Team first, project second<\/h3>\n

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\u2019s backwards. The team must come first. You cannot realistically select a project until the team has first been assembled. It\u2019s ok to have a general idea of the type of project you want to create, but until the team is assembled, you shouldn\u2019t decide the details of the project. Why is this so? Let\u2019s consider both alternatives (team first vs. project first) to understand the natural consequences\u2026.<\/p>\n

Let\u2019s 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\u2019ll need to complete the project, and begin looking to build a team. You decide you\u2019ll act as the designer\/producer, and you determine you\u2019ll 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\u2019re confident it will be a terrific game when it\u2019s done, and the specs look achievable. You estimate that the game could probably be completed in 4-6 months.<\/p>\n

Sounds like a reasonable plan, doesn\u2019t it? And that\u2019s 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?<\/p>\n

What happens to the above project in reality? You search for months but can\u2019t find a decent 3D programmer who\u2019s willing to work for your terms. The best you can do is a 2D programmer who\u2019s currently learning 3D programming. The artist you found can\u2019t create decent textures to save his life, but he\u2019s a great 2D animator who\u2019s willing to “give it a shot.” The second programmer you manage to find lives overseas and barely speaks English, but he\u2019s willing to work remotely. So you try your best to work with what you\u2019ve got.<\/p>\n

Things don\u2019t go well. The two programmers experience frequent personality clashes. The artist isn\u2019t 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\u2019t really fun. Team members don\u2019t really buy into your original design and start trying to implement their own ideas, and you get upset that they aren\u2019t 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\u2019re 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.<\/p>\n

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\u2019t true for team projects. For a team project the limiting factor is securing the right team members. With the wrong team, you\u2019ll end up spending most of your time worrying about control. With the right team, excessive control is unnecessary, and individual empowerment becomes the norm.<\/p>\n

Another problem with the “project first, team second” approach is that it fails to leverage the team\u2019s 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.<\/p>\n

Now let\u2019s consider the second option: “team first, project second.” You may have a general idea about the type of project you\u2019re 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\u2019ve 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\u2019s strengths and compensates for their weaknesses.<\/p>\n

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\u2019ve 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\u2019re 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.<\/p>\n

Selecting the right team members is the single most important factor in determining the success or failure of your project<\/h3>\n

You\u2019ll 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\u2019s possible that even the best manager in the world can\u2019t 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.<\/p>\n

Don\u2019t 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\u2019t build a solid team, don\u2019t begin the project.<\/p>\n

Select team players, not individual superstars<\/h3>\n

For a team project to survive and thrive, you must select and recruit people who are team players, not individual superstars.<\/p>\n

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\u2019s 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.<\/p>\n

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 \u2014 for the good of the team. Team players are like the cells in your body, working together to keep the host alive and healthy.<\/p>\n

Because team players accept personal responsibility for the success of the project, you don\u2019t need excessive control and management. Problems won\u2019t be ignored \u2013 team members will root them out and fix them. Why? Because they\u2019re personally responsible. They “own” the project.<\/p>\n

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\u2019t matter.<\/p>\n

Your team must have a single individual in charge<\/h3>\n

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.<\/p>\n

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.<\/p>\n

The team leader\u2019s 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\u2019s the team leader\u2019s 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\u2019s best for the project and the team, even if it means more work or less freedom for them as individuals.<\/p>\n

Software = team<\/h3>\n

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.<\/p>\n

The team leader is directly accountable for maintaining unit integrity. If a team member isn\u2019t pulling his\/her weight, it\u2019s the team leader\u2019s 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.<\/p>\n

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.<\/p>\n

Keep communication channels open<\/h3>\n

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.<\/p>\n

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.<\/p>\n

If your teammates aren\u2019t 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.<\/p>\n

Face-to-face communication is always superior to voice or email because the bulk of human communication is nonverbal. Don\u2019t 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.<\/p>\n

Share the rewards<\/h3>\n

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\u2019s 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\u2019t begin the project.<\/p>\n

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\u2019t just assume that they know they\u2019re 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\u2019t 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.”<\/p>\n

Put it in writing<\/h3>\n

Whatever agreements you make with your team members, you must commit them to writing. It\u2019s 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\u2019ll handle them. What will you do if a team member wants to leave the project prematurely? What\u2019s 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.<\/p>\n

Cut underperforming team members<\/h3>\n

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\u2019s 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\u2019t even a consideration here. It didn\u2019t matter that the SEAL didn\u2019t 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\u2019s focus.<\/p>\n

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\u2019t 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\u2019t matter if this person intends to do better; all that matters is the actual performance. If you\u2019ve 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.<\/p>\n

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\u2019s a necessary and unavoidable part of management. If you can\u2019t stomach letting someone go, then you simply aren\u2019t fit to lead a team, so don\u2019t put yourself in this position.<\/p>\n

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\u2019ve 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.<\/p>\n