All our newsletters are copyrighted but we encourage you
to share them with others.
If you use the information, please let us know and cite us as the source.
Thank you.
Copyright 1998 AXIS Performance Advisors, Inc.
People tend to think of all teams as being the same, needing the same things. Certainly, they share certain needs. But if all you have is a hammer, everything starts to look like a nail. In actuality, there are many types of teams and each type needs different practices to be successful. You cannot treat a project team like a self-directed team like a management team....Doing this sets teams up for failure, or at least frustration. This issue of the Axis Advisory highlights the differences between team types and how to make each successful.
Teams differ in many ways. They have different purposes and characteristics. For example, their purpose may be to:
· Do regular, repetitive work
· Solve a problem
· Come up with a new product
· Implement a new corporate initiative
· Share learning
· Coordinate resources
At the same time they may differ in their characteristics:
· Durationtemporary or "permanent"
· Commitmentfull time or part time
· Compositionhomogenous or diverse
· Locationco-located or "virtual"
· Interdependence-tight or loose
· Taskmostly physical or mental
· Authoritydecide or recommend
Take one look at all these variables and you quickly realize that one way of operating can't possibly fit all teams! I don't remember enough from math class to know how to compute the possible combinations and permutations, but we can agree that there could be lots of different teams.
Standing Teams (Permanent) |
Temporary Teams |
| High-performance work team | Project team |
| Management team | Task force |
| Communities of practice (learning teams) | Product development team |
| Functional department | Problem solving team |
Representative committee (can be either temp or permanent) |
We can simplify the picture somewhat. There are some team archetypes that organizations commonly use. In the table below, we've clustered them by duration, but you could do a similar chart for any of the other characteristics. Note that representative committees commonly fall on both sides, sometimes they are temporary (e.g., transition teams) and sometimes standing teams (e.g., office councils).
These archetypes represent common clusters of purposes and characteristics. For example, work teams are usually full time, have high authority, and are often but not always cross-functional (diverse). Product development teams usually stay together only as long as it takes to design a new product, and do highly creative, mental tasks.
A little later, we'll share some best practices for each of these archetypes, but first, let's look at some of the problems you can encounter if you apply the practices of one team type to another.
Operating under the misconception that all teams are alike can lead to practices that defy logic. A college assembled its department and program heads into a "team" to improve cross-discipline synergies. This management team (some 50 people) dutifully met monthly and tried to act like a self-directed team. The meetings dragged on as people talked about what they were doing in their department, information that was largely irrelevant to the majority of the group.
Our diagnosis was that, as a management team, they were only loosely coupled and so their meetings should only focus on issues that cut across departments. Listening to all those department reports didn't seem productive to them, but they assumed it was what they needed to do to be a real team.
The Human Resources department within a west-coast utility decided to break up their functional silos and create self-directed work teams. So they formed cross-functional teams, putting someone from payroll, benefits, labor relations, etc. on each team. So far so good. Then they decided to cross train everyone on everyone else's job and assign each team member a different client department within the agency. So if your HR contact used to be a payroll person but you had a labor relations question, you'd get the best that person could do, which wasn't enough!
What did they do? They designed out the interdependence. So clients got the best and the worst of their HR contact, instead of the wisdom of the whole team. They also confused knowledge work with physical work. Manufacturing teams commonly cross train everyone but that is much less effective in knowledge work.
They would have been more successful if they assigned the whole team a set of customers. It's fine to provide an initial point of contact for the clients. But complex issues should come to the whole team so they could examine the synergies between their functions and provide a whole systems response to the need.
A team of graphic designers had been formed to make a recommendation to management about the purchase of new computer equipment. The rest of the organization used PC's but graphic artists are passionate about the Mac platform. By the time the client called us for help, the team had expended many months in emotional bickering and had gotten nowhere.
We discovered that their facilitator had used a typical total quality problem solving process: write a problem statement, analyze the problem, review possible options, develop a recommendation.... But framing this as a problem only fed the emotional fire. This was not a problem solving team; it was a task force. So we came in with a description of the team's purpose, a picture of the analytical tools we'd need to complete, and a schedule. After five half-day meetings over a couple weeks, the team's recommendations were complete and accepted by management.
Over the years, we have discovered best practices for each team type. Let me highlight some of the key differences here (skipping over functional departments, since we're all too familiar with those!).
· Hand off leadership responsibilities over time; make clear what responsibilities they "own" at a particular time.
· Encourage cross-training to the degree that makes sense. With routine work (e.g., manufacturing) cross-train on horizontal tasks, learning one another's jobs. With knowledge work, it may not be wise to cross-train since people tend to become specialists. Instead, become familiar with one another's work enough to understand the challenges and interdependencies, but focus on sharing vertical/management tasks.
· Make sure the members are technically competent before implementing self-direction.
· Provide a non-threatening process for evaluating team and individual performance on a frequent basis.
· Align organizational systems to encourage teamwork.
· Teach team managers how to coach, facilitate, and support the team without taking over OR abdicating their responsibility.
· Keep the team focused on performance, not on their own personal preferences; they must make decisions in the best interest of the organization.
· Ensure that the natural consequences of their work flow back to them directly (e.g., customer feedback, rework and repairs).
· Get the customer/client intimately involved, viewing themselves as part of the team.
· Ensure that project planning is done with involvement of all core team members so they have an understanding of whole project.
· Conduct review meetings at major milestones. Share relevant learning with other project teams.
· Select a project leader/coordinator who keeps an eye on the big picture, resources, deadlines; but make sure all team members are somewhat familiar with one another's roles/ responsibilities and feel responsible for the whole project. (Example strategies for joint accountability include having to train customers/users, supporting the software once it's implemented, and team bonuses.)
· Insure that auxiliary team members are involved up-front in planning so they know well in advance that their assistance will be needed and so that they can shape the project. They should be kept abreast of progress/schedule changes but only attend team meetings when they have relevant input.
· Connect all team members with their customer (e.g., getting direct feedback, and visiting customer sites), but provide the customer with a primary contact person.
· Clarify the purpose of the team. Is it to coordinate resources, set goals, make decisions that affect all of them or just to learn from one another?
· Make sure the managers feel jointly accountable for their task together. This may include having a portion of their compensation based on the performance of each other's areas.
· Break down turf boundaries or fiefdoms through dialogue, cross-training, joint responsibilities, job rotation, etc.
· Explore the interdependencies and shared needs they have; many managers feel very isolated and independent from one another when often they can benefit immensely from mutual support.
· Team building activities may help to develop trust and openness. But make sure the managers see a direct link to the work they must do.
· Establish a clear charter or purpose, with clear boundaries.
· Provide tight deadlines and concentrated effort (e.g., complete the task in one month, meeting two half-days instead of one hour a week).
· Identify a sponsor with clout who can provide resources, guidance, pre-selling of recommendations.
· Make clear at the outset what they can decide and what they can only recommend; it's better to provide clear enough boundaries so that they can decide.
· Give the task force the responsibility for implementing their ideas where possible.
· Permit informal mingling and sharing.
· Encourage people to share their cheat-sheets (as opposed to the official manual which usually sits on the shelf).
· Avoid formalizing these groups; the need to communicate should drive the desire.
· Organize the physical space to encourage informal communication sharing. For example, place white boards near the coffee machine and flip charts in the cafeteria.
· If the group feels it's appropriate, help them build tools or databases--but only if they are convinced they'll keep them updated and will use them.
· Help everyone notice the things they've learned or things they know that are worth sharing. People often discount their own knowledge.
· Provide clear goals and criteria for the product/service (e.g., cost, features, etc.).
· Include representatives of all major stakeholder groups, including people who use, build, repair, and sell the product.
· De-emphasize professional status so that, for example, maintenance techs feel as free to speak as engineers. But on any particular issue, have the most knowledgeable person make the final call.
· Consider maintaining the same membership for several product development cycles to leverage the synergy that develops. Change membership when you need to encourage fresh thinking.
· Provide a systematic problem solving process that avoids solution-jumping (the tendency of people to come up with a solution before thoroughly understanding the problem).
· Establish self-documenting, structured group problem solving strategies and techniques.
· Provide direct access to anyone with relevant information.
· Offer help in cost-justifying recommendations and preparing a presentation to management.
· Let the team present their ideas so they maintain ownership of them and get direct feedback.
· Make sure you have the right people on the committee so that they can make decisions. What factions need to be represented? Consider people outside your organization like customers, vendors, union officials, etc.
· Where possible, let constituents select their representatives. But provide employees with guidelines for selecting a representative. These usually include: someone they trust and respect, good communicator, not afraid to speak out, creative thinker, someone knowledgeable about the faction they represent, someone who doesn't generate defensive reactions.
· Involve constituents rather than just communicate with them. Don't let the team take on more responsibility than is warranted. Where possible, get the constituents to define priorities and perhaps even vote on options. The committee's job is to do the behind the scenes work to come up with viable options. The constituents should feel as if the committee is working for them, not the other way around.
· Rotate membership so that you don't create "pseudo-managers," coworkers who are resented for their power and access to leaders. Stagger the rotations to provide an organizational memory and continuity.
· Have clear boundaries; this group should be able to make decisions, not just recommend to management. Otherwise, they are redundant with management and will resent being "overruled."
· When a decision is made, take time to explain why it was made (especially if it is not a popular decision). Explain it, explain it, and explain it again. Be absolutely truthful.
· Make most of your meetings public. Encourage others to sit in. Specifically invite people. Post the agenda in advance with room for people to make notes. Communicate the results in several ways.
Self-Directed Teams
Hitchcock and Willard, Why Teams Can Fail and What to Do About It
Kimball and Mareen Fischer. The Distributed Mind (knowledge work teams)
Cross-Functional Teams including Task Forces, Problem Solving Teams, Project Teams, Product Development Teams, Representative Committees:
Parker, Glenn (1994). Cross-Functional Teams: Working with allies, enemies and other strangers. Jossey Bass.
Nadler, Gerald and Hibino, Shozo (1990). Breakthrough Thinking: Why we must change the way we solve problems, and the seven principles to achieve this. Rocklin, CA: Prima Publishing and Communications.
Management Teams
Katzenbach, Jon. Teams at the Top.
Oshry, Barry (1995). Seeing Systems: Unlocking the Mysteries of Organizational Life. San Francisco: Berrett-Koehler.
Hamel, Gary and CK Prahalad (1994). Competing for the Future. Harvard Business School Press: Boston, Mass.
Communities of Practice
Stamps, David (February, 1997) "Communities of Practice: Learning is Social. Training is Irrelevant? " Training Magazine, 34(2), 35-41.
Wenger, Etienne (July/Aug 1996). "Communities of Practice: The social fabric of a learning organization. " Healthcare Forum, 39(4), 20-26.
Virtual Teams
Davidow, William and Michael Malone (1992). The Virtual Corporation. New York: HarperBusiness.
Geber, Beverly (April, 1995). "Virtual Teams." Training Magazine pp. 36-40.
Lipnack, Jessica and Jeff Stamps. (1997). Virtual Teams: Working Across Space, Time and Organization.