Issue 11, Sunday March 26th, 2000
Ten minute Masterclass – Teams
“Few subjects inspire as much bad writing as teams. These days, innumerable companies claim to organize their work in teams – and hordes of consultants are eager to aid the process. Beyond the hype, the truth is that small companies often can't function without good teamwork. But just because teams make intuitive sense doesn't mean they're easy to implement,” said Christopher Caggiano in Inc. (June, 1998, as quoted in our primer on teamwork, at www.baldrigeplus.com/exhibit.htm).
This week, two articles on teams arrived in our letterbox. The first, in the February 2000 issue of Quality Progress (on line at www.asq.org); “It’s all about improving performance,” and the second, in the University of Auckland Business Review (v2 no 1); ‘Creating effective multicultural teams.” We’re going to stretch the normal word limit, and provide summaries of both articles.
The Auckland study notes that while 25% of US firms have tried self-managing teams, introducing them is not easy. Work methods, compensation systems, employee involvement and the role of the first level supervisor all have to change. It’s even more difficult when members are from different cultures – with different values, priorities and language. Managing diversity – something which only 5% of executives think they are doing a very good job of – comes into sharp focus in the teams environment. And managing diversity is going to be an issue everywhere in the Western economies in years to come as third-world migrants fill gaps created by ageing workforces and booming economies.
The authors of this study (a Canadian – David Thomas of Simon Fraser University; an American – Elizabeth Ravlin of the University of South Carolina; and David Barry of the University of Auckland Business School) spent two years studying manufacturing self-managing teams (MTs) in Australasia, home to some of the world’s most culturally diverse workgroups – typically in New Zealand 20% Pakeha (Kiwis of European origin), 15% Maori (the indigenous inhabitants), 15% Samoan, 10% Cook Island, 10% Tongan, 10% Chinese, 10% Malaysian, 5% Korean and 5% Indian. Much of what passes for team wisdom in single culture contexts falls apart when multiculturalism is present, the authors say.
Team effectiveness
How does cultural difference affect team effectiveness? There are three key influences:
(1) Team members bring their cultural norms to work – and different cultures regard teamwork differently. For example, Polynesians are natural ‘team players,’ Asians value low conflict and harmony, and individualistic Anglo-Europeans are least likely to commit to team values.
(2) Perception of cultural difference influences team performance, and different cultural groups regard ‘difference’ differently.
(3) Team diversity (how many different cultures are present) can be both positive and negative. Very diverse teams may have communications problems, but may also be more effective, perhaps because if everyone’s different, difference is not such an issue.
There’s no foolproof recipe, say the authors, but effective management usually involves:
Support for teams – teams work best when management support is visible and positive, and this may be more important than team composition.
Support for diversity – organisations that positively support and respect diversity in their workforce are more likely to have effective multicultural teams
Appropriate rewards – while not as much is known about the effect of reward systems on teams as on individuals, there’s some evidence that effectiveness is related to collective rewards. Performance and team satisfaction were higher when rewards were team-generated.
Status – when teams have high workplace status, they tend to be more effective, with higher levels of trust and team spirit. But the significance of status is also affected by culture, with Anglos valuing status more than Polynesians, for example.
Training – the most effective teams received the most training in team skills.
Self management – the argument that effectiveness is related to self-management may not hold in multicultural teams, where members may have different expectations of what power structure is appropriate.
Lessons
(1) Recognise that the effect of cultural diversity depends on how the team is structured and the nature of the task. Bringing tacit knowledge to the surface, making it explicit, may be difficult, but it may also be the key to team success.
(2) Evaluate teams in terms of team processes and individual outcomes as well as task accomplishment. Multicultural teams may take longer to achieve their potential, but may be considerably more effective than monocultural teams when they do.
(3) Create a climate of support for teams and diversity. Walk the talk – showing support is much more important than just talking about it, especially where there’s more than one language.
(4) Design team level rewards to be consistent with cultural norms. Rewarding team success is important, but one-size-fits-all approaches may be risky. Managers need to get to know what’s important to all team cultures, and act appropriately.
(5) Provide ongoing training in cultural diversity and team skills as well as task-related skills. Untrained teams will struggle. Recognising and respecting cultural difference is the key, but it must be continually reinforced to be effective.
It’s all about improving performance
In an earlier newsletter we introduced “TQM in two hours.” Helene Uhlfelder’s QP article – “It's All About Improving Performance, Teams work better with expanded problem solving and decision making skills,” – concentrates on problem solving and decision making. If you’ve got more than two hours, try this.
Lots of high-performing organizations teach their employees decision-making and problem-solving techniques, says Uhlfelder, usually with four basic components: problem definition, data collection to verify root causes, solution generation and action planning, including a mechanism for tracking how well solutions work. But few seem to teach their teams how to apply this approach. “Furthermore,” she says, “team members rarely understand how the way they think and the biases they carry with them can affect the success or failure rate of the problem solving tools they use.”
The ‘thinking’ factors that people bring to teams include:
- Individuals bring their own preferences, cultural biases, values and experiences
- There’s a tendency to be overconfident about their own judgments and opinions
- People tend to start from what they know, or use the wrong data just because it’s available
- People tend to not take time to revisit and analyze past decisions and their outcomes
With teams taking on more decision-making and problem-solving – whether ad hoc, self-managed or networked – they increasingly need established process to achieve their goals. Uhlfelder suggests:
(1) Define the problem
Pinpoint the problem – with data, observations and measurements. Describe performance or behavior exactly. Describe the gap between current and desired performance. Although teams know the importance of this first step, many are too quick to start. Complex problems are hard to define, and teams like to get on with the job. They often pick the wrong problem to solve.
How to do this step better? Try these approaches:
Mind-maps. Mind-maps are tools a team can use to visually show what factors influence a problem and the relationship among factors. Team members select the topic they suspect is a problem, then brainstorm any other topics or ideas that relate to it. When this is completed, they draw connections and relationship indicators for the various topics and ideas.
Brainstorming problem statements. Create a list of potentia definitions by using brainstorming rules – important because the problem should be framed correctly, and be free from bias.
Problem questioning. Ask:
1. Have we considered all the alternatives? 2. What other ways can we word this problem?
3. What are we leaving out? Why? Does it hurt or help the definition?
4. How can we word it as an opportunity?
5. What would happen if we did not solve this problem?
(2) Decide what process to use
Having defined the problem, agree on how to arrive at a solution. If an individual can solve the problem, delegate it. If it’s a team problem, decide if it is a process problem.
The team may want to ask the following questions:
- Who are the critical stakeholders or experts the team needs to be part of the process?
- What information and data will the team need?
- What tools or equipment will the team need to make a decision? How will they get it?
- What education, expertise or experience does the team need before it tries to solve the problem or during the problem solving process?
(3) Gather information
Having agreed on the process, collect data. Sources of data can be score-cards, financial reports, questionnaire data, interview or focus group data, or work process observation data. Ask:
- Does the team have accurate data that is readily available?
-Does the team need additional information that is not presently available?
-Does the team need help in understanding and interpreting the data?
-Is there information the team needs that is considered private or confidential?
(4) Decide!
But ask three questions first:
- Does everyone need to be involved?
When teams first start to use problem solving tools, there’s a tendency to involve everyone all the time … not always the best use of the team's time.
- How will the decision be made? There are several options:
· By an individual without consulting others
· Consultatively – ask what the stakeholders think. After considering this input, the individual makes the decision
· By consensus - the team comes together, negotiates a decision, takes ownership for the decision and agrees on a course of action
· By delegating it to someone else to decide
- What is the criteria for the solution?
What are the boundaries and requirements placed on the team for its solution? Can the team spend money? How much? Is there a deadline. It is critical the team knows and understands the criteria before it spends a lot of time creating solutions that fall outside its budget, control or influence.
(5) Develop an action plan
“The importance of written action plans cannot be overemphasized,” says Uhlfelder. Teams need to remember what they have agreed to do, specify what action is required and who is responsible, and what the deadline is.
(6) Audit and evaluate decisions and processes
Teams often walk away from problems solved without saving the wisdom. Often there’s no worthwhile analysis of what happened. “The process of auditing and evaluating both the problem solving and decision making processes and the content of what was done can prevent this loss,” says the author.
The team should do a self-analysis at three points in the process: after the action plan is developed, three months later and six months to two years later depending on how long the implementation takes. The team should do this as a team, and the findings from the analysis should be saved for comparative purposes. Teams should ask: How well did we define the problem? How well did we gather information? What would we do the same way next time? What would we not do the next time?
The team should self-analyze, and look for feedback from others. Ask: How would you rate or describe the quality of the decision we made? How effective do you believe our solution was (will be)? Why? Did we appear to use appropriate data and information? How would you describe our timeliness and our meeting of other expectations?
Conclusions should be captured and saved for review before beginning similar problem solving activities in the future.
(7) Record and share learning
If teams are the way your business gets things done, don’t lose vital information between and among teams. Learning doesn’t happen accidentally. Systems for capturing learning need to be put in place.
Organizational databases that are created and maintained by teams provide a vehicle for sharing and learning. When one team wants to know how another solved a particular problem, the information is readily available.
Information sharing can help avoid redundancy, speed up decision making and problem solving cycle times, and create a foundation for developing intellectual capital. The challenges for organizations are to provide the necessary information systems, culture and reinforcement for teams that contribute to the database. Although not all organizations are ready to take this last step, many are making progress.
Six Sigma VI
“The 1.5 sigma 'long-term shift' in process mean is simply process drift, a well-known condition,” Alla Linetsky says in a recent DEN list posting, “Machines get dirty, parts wear out, cutters become dull, etc. The drift is generally not random, and there are two approaches for dealing with it. The older approach was developed by George Box in his book Evolutionary Operation of Processes, published, I believe, in 1967 and long out of print. However, most Engineering libraries in universities have it. The newer approach is called Optimal Process Control which accounts for both non-random and random variation in a process. The current guru on the subject is Douglas C. Montgomery, and if you do a search on his name, you will find a multitude of books and papers on this subject. Otherwise … 6 Sigma is nothing more than a gimmicky package for some ordinary process improvement tools, most of them found in a $100 textbook.”
John Seddon again
In issue 10 we included some international material on John Seddon. This week we’ve published our first Newsletter Supplement, devoted to John’s attack on the ISO standard. If you’ve got anything at all to do with ISO – whether you use it in your organization, deal with organizations which do, are considering implementing the year 2000 revision (and surely that’s all of us, one way or another), or whatever, you’ll find John’s views interesting.