The Myth of the Power of Teamwork

“The work of the individual still remains the spark that moves mankind ahead even more than teamwork.” – Igor Sikorsky

Imagine if Keith Lockhart and the Boston Pops Orchestra rolled into Tanglewood this summer with flutists playing the violin parts. Or if the Green Bay Packers appointed Brett Favre to be the water boy and just tried to go at it without a quarterback? What if you hired six burly men to help you move your grand piano and the labor pool sent you half a dozen ballerinas in tutus?

Sound ridiculous? Not if you’re chanting one of the most popular buzzwords in American business: Teamwork.

The problem with buzzwords is that when they start to be indiscriminately applied without regard for what makes sense, you start to see meaninglessness in action.

For teamwork to be a productive aspect of a work group:

1. Each team member should be the best person available for solving a specific problem.

Problem: While sports coaches and musical directors can be highly selective when recruiting talent for their teams, businesses generally look for people with a wider variety of skills. Some of these people may be adaptable to what the team needs for a particular effort while others may not. Don’t try to teach a pig how to sing; it’ll frustrate the hell out of you and annoy the pig.

2. All the skills necessary to carry out the project must be present in the combined members of the team.

Problem: When gaps appear between the needs of the project and those combined abilities of the team members, they are often filled with second-best efforts. If you want top-quality output, there will then come a point when you’ll have to go outside the team to get the project back on track.

3. The time spent on team meetings and “work” sessions should not compromise time that could be better spent on other things.

Problem: If “The Apprentice” showed us nothing else, it provided evidence of how a team approach can be misused. Every assignment was done as a team — but every time, at least one person got frozen out of the process or was clearly not the best person chosen to do a specific task. The team approach ended up doing more for the self-serving desires of a few of the contestants than for the accomplishment of the objective.

Next time you’re seduced by the team concept, take a look at what your real needs are:

  • Define your functional needs for the project and fit the skills of your people to specific roles. If there are too many gaps or mismatches, a team approach may be a mistake.


  • Understand what kind of information is needed for the project, who needs it, and how it will be gathered, produced, and disseminated. Not everyone on the team needs to know everything about everything.
  • Let the most skilled people do their thing. You don’t want your water boy quarterbacking the team, and you don’t want your quarterback carrying the water.

When mishandled, a team approach can inhibit creativity and innovation and encourage conformity. It can stifle special contributions from those who may not be effective in a team atmosphere.

To make a team work, follow ETR’s previously mentioned recommendations:

  • Teams need leadership.
  • If you are the leader, don’t be afraid to be in charge.
  • Formulate the team’s objectives. Make sure they support the goals of the business.
  • Create a division of labor based on talent and experience. Don’t try to “even out” assignments, making them all equally important. Give each person a job that he can do well.
  • Focus on achieving the stated goals. Make sure all team members do too. Teams operate best when they have a specific, achievable objective that can be completed in a reasonable amount of time.

Remember, it’s all about the work . . . not about the teammates.

  • 7
  • Sen Tinel

    Very interesting article. A few months ago I started working in a small company as programmer. For years, this company had had only one programmer who had built a whole ERP tool. The tool had many defects, but worked reasonably well with tons of features. As he was the only one, he decided how to do improvements and issues were solved quickly and on time.

    When I started working there, the original programmer had left and there were three programmers (four included me). Not surprisingly, the flow of work was much slower… There were not clear objectives, it wasn’t uncommon for me to have to throw days’ work to garbage and restart again because there hadn’t been good communication. There wasn’t a daily meeting (but there were irregular long meetings where much time was lost), the leader did not transmit a positive attitude, the other team members usually used headphones (so asking questions was just uncomfortable…). Many issues were delayed and stuck because I had to consult very trivial details with several people.

    There were also things that had been done correctly (setting up a chat, a task manager and a wiki for documentation, git control, a training plan for new programmers, etc.). But in general everyone was quite unhappy, and my conclusion was clear: in some cases, one competent person might be just better… I also feel that in incompetent teams introvert talented people are wasted.

    • Thank you, Sen, it was helpful to hear your experience.