UnTeams and Real Teams

Not long ago, I worked with an organization where the managers talked about teams, even though there wasn’t a real team in sight.

To these managers, any group of people who reported to one manager was a team.

All the DBAs reported to the DBA manager, all the GUI developers reported to the GUI manager, and so forth.

But these groups didn’t work as teams.

They didn’t have complementary skills, they all had (roughly) the same skills.

While the people within one group had a common goal (e.g., maintain the integrity and performance of the databases), the goal wasn’t about creating a product.

Each person was also assigned to one or more (usually more) projects, which were also called teams.

The so-called project teams were made up of people with complementary skills, and they had a common goal of creating a software project.

That meets part of the definition of a team; but when people are assigned on a temporary or part-term basis, it’s not likely that they will gel as a team.

There’s no crime in having a work group. Some work is much better suited for a group than a team. And I’m not just being picky about precise use of language.

Managers who believe work groups are teams usually expect some level of cohesion and …err…team work from that group. And they are disappointed when they don’t see it. Their disappointment can come out in blame, castigations, or lower performance reviews (the dreaded “not a team player” evaluation).

Here’s how I define team:

They have a common goal or purpose.

They share an approach to their work. That doesn’t mean they have a rigid process that they follow in lock-step, but they do have agreement on key elements of their work.

They are jointly accountable for results. If one person finishes his tasks and the rest of the team members don’t the team isn’t successful, and neither is the one who finished his tasks.

They are small in size, usually between 7-9 people. Some research indicates a productivity sweet spot in the 4-6 range.

They have shared history. Teams aren’t teams on the first day. They have to agree to be a team, and then develop enough trust and cohesion to function as a team. Overtime, they learn each others strengths and weaknesses. They learn how to make the best use of everyone’s talents.

Finally, teams build their capacity through their work.

Leave a Reply

What is 1 + 6 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA