What Makes a Great Team

Years ago, when the PC first came out and for some while thereafter, it was actually possible for a single programmer to create a meaningful software product. But those days are long gone now. I don’t know of any non-trivial piece of software today that was produced by a single programmer. Modern software products require thousands of man-hours or more to produce, and one person doesn’t have enough time to do this. Thus good software today is always produced by more than one person, and the only effective way to do this is through those people working together as a team.

But you can’t just put a bunch of people together on a project, call them a team, and automatically expect teamwork. So what is needed to really make a team work?  This is probably one of those questions that you either have never really thought about, or you just assume that you know the answer.

So if you think you know the answer, write it here: _____________________________

If not, or even if you think you did, read on.

If you were to research this topic, I’m sure you could find a lot of different answers. I haven’t done this, but I did come across one definition that I really liked.  It lists 3 key elements that are needed for a great team:

  • Clear definition of roles.  In an effective team, each member needs to know exactly what his role is so that he knows how to interact with the rest of the team. If everyone on the teams does their own thing, the team is not necessary.  Furthermore, it is essential that each team have an undisputed leader.  An interesting socialogical study with children showed that if kids were put into “teams” and told to solve a problem, the usual result was that one kid would dominate and the others would act disengaged – not an effective team.  But the study also found that if roles were defined when the team was established, the kids then understood what they needed to do and worked to reinforce the given structure.  Interesting.
  • Small team size.  There have been various studies on this, but many sources suggest that 4 – 5 is the optimal size for a team. If your team is much larger, it starts to lack cohesion.  It’s probably no accident that basketball and hockey teams are about this size. While baseball and football use a larger number of players, it is debateable whether or not 9 or 11 players are really working together with complete awareness and support for all their fellow players.  If you must have a large team, it probably needs to be sub-divided into more manageable groups of … 4 – 5 people.
  • Presence of an outside threat.  While it isn’t always the case that teams can only exist under competitive situations (for example, people might form a team to do charitable work, or they might work for the government), there is a lot of evidence that it is competition that really makes a team come alive. (There are other types of outside threats that could motivate a team, such as fighting for survival, but let’s hope that that is not one of the conditions that face us in software development!)  In our case, the outside threat clearly must be our external competitors, and thus a key motivation for our teams should be beating our competitors. Without being aware of our competitors, do we really know how well we are doing?  Consider this: If you went out for a run, do you think you would run faster if you were in a group of competitors or all by yourself?

The above thoughts pertain not only to our technical teams, but I think they apply even more so to our management teams.  Think about the team(s) that you are a part of and whether or not they have these characteristics.

I’m sure that great teams might have a few other characteristics; anyone have any thoughts on what some of them might be?

Inspiration and some data for the preceding came from an article entitled “How to Build a Great Team” by Jerry Useem.  The original article is no longer available, but you can read a copy at: [link TBD]

About John

John Peterson has been creating and managing the creation of software for his entire professional life. During that time, he's been through many projects large and small, worked with a wide variety of people on a wide variety of technologies, made a lot of mistakes, and learned a lot in the process. The intention of this blog is to pass along the wisdom he has accumulated in the creation of software to those who may be earlier in their path of experience.
This entry was posted in Organization. Bookmark the permalink.

Leave a Reply