|
The Commerce of Content
|
Project Management | People Management | Business Management | Information Design Models, Processes, and Techniques | Home |
Originally published in the Performance Improvement.
by Saul Carliner
If you're about to begin working with a new work team¾ and want the team relationship to be a successful one¾ what can you do?
A typical starting point is defining the task at hand. You might define the scope of the project, deadlines, resources, and deliverables (or other outcomes).
Certainly these issues seem to be an ideal starting point. They're the one thing everyone has in common¾ and therefore, the most likely subject to talk about. Eventually, these issues do need to be addressed.
But teams might do better to start by tackling an equally important¾ but often neglected¾ issue: people. The following suggestions¾ or secrets of success¾ emerge from actual team experiences (complete with quotes from real project journals) and help both individuals and groups build strong, and successful work relationships.
In interactions with others, your feelings about yourself invariably come into play. What types of roles do you like to play? Do you like to be the leader or the follower? Do you want to work on just one aspect of the project or all of them? Do you like team meetings? How do you handle criticism? How do you respond to ideas from others? Are you open to them or do you suffer from the Not-Invented-Here Syndrome?
In some team situations, people choose their roles. In those instances, you should try to choose a role that's most comfortable for you. Sometimes the choice is conscious. For example, Rick likes leadership roles, so when his teammates were looking for a team leader, he volunteered for the job. In other times, the choice happens unconsciously. For example, Mary generally dominates the conversation at meetings. When her teammates were looking for a leader, they first thought of her, because she had already been leading the meeting.
In other team situations, people need to assume roles that they are not comfortable with. People who hate meetings must attend them. People who like individual recognition must share it with others. People who respond poorly to criticism must receive it. People who dislike leadership roles must assume them.
By understanding your needs and preferences before you start working on a team, you can recognize when your roles and responsibilities on the team is in conflict with your needs as an individual. Learning to recognize those conflicts and to positively address them represents one of the strongest opportunities for growth that people receive from teams.
For example, Leslie was asked to lead the writing of a proposal but had little experience in the process. By identifying her concerns up front, her teammates offered assistance and she was able to build her confidence as a proposal writer.
You could easily be spending eight hours a day for the next several weeks or months working with a group of people who are, at first, strangers. Are you ready to make serious decisions when you haven't even made a simple one such as where to go for lunch? So, do as many Japanese business people do. Spend some time getting to know your teammates before you seriously start working with them.
As Jill notes in her project diary:
Warning! Always...get to know each other before attempting to start a project. It's much easier for a group to tolerate others' mistakes when they understand where the team members are coming from.
Another benefit of getting to know one another before starting work is that you'll have an opportunity to learn one another's skills, strengths, and weaknesses. When you actually do begin work, you can assign tasks that most closely match each team members skills' and interests. That, in turn, makes team members and the group project more likely to succeed.
How can you get to know one another? Hold your first meeting over lunch or dinner and agree not to discuss the project. If none of you are familiar with one another, you might try ice-breaker games to learn a bit about one another. Games Trainers Play and similar publications suggest several ice breakers. You might even invite someone from outside the team to facilitate this first meeting.
In some teams, leadership roles are assigned. These chosen leaders should be aware that team members have expectations of tasks the leader is expected to perform. And the team leader has expectations of what he or she is expected to do. But do the two sets of expectations match? To make sure they do, everyone should state what they expect from the leader, including the designated leader. Address the differences in expectations.
In other teams, leaders emerge from the interaction of team members. In a situation like this, give natural leaders an opportunity to emerge before appointing a leader. Although a meeting without a formal leader is somewhat frustrating, the actual leaders usually emerge by the end of the first meeting. If one does not, work together to determine who should be the leader. After the leader emerges, once again, explicitly state the expectations of the leader. Only in that way leader provide the type of leadership that team members expect.
Although respect and trust are earned over time, each of use can follow certain strategies to provide an environment in which respect and trust are likely to develop.
By openly discussing the decision making process in your first meeting, you can avoid problems later. For example, if you have decided that all major decisions are to be made by consensus, then team members know that they should not be making unilateral decisions that affect the entire project, such as the format of all screens in a computer-based training program.
Often, groups tend to avoid conflict and the unresolved issues rip apart the fabric of the group. The people at the center of the fray often try to recruit other team members to their sides. Instead of a cohesive unit, the team becomes warring factions. Deciding how to handle conflict gives you a strategy for dealing with problems that arise.
By determining how you plan to handle conflict, should Kathryn and Philip take polar stances on wording of the design of a module of computer-based training, you have a method of addressing the conflict rather than feeling like you need to take sides.
One group whose commitment is always questioned is working mothers. They are often limited in their availability to work evenings and weekends. Some people complain that working mothers always leave at a certain time, such as 4:30, and never stay late.
But do these working mothers really lack commitment to the project, or do they have other commitments? Most working mothers, for example, must pick up their children from day care by a certain time or face a stiff fine.
Using conservative language and carefully avoiding discussions and expressions that might offense early in a project increases the likelihood of your acceptance by other teammates. For example, if one team member expresses frustration, try to avoid expressions like, "don't get your panties in a wad."
But the need for good behavior doesn't end once the group works together cohesively. Be careful to avoid taking other group members for granted following the period of good behavior. For example, suppose that Trong is an especially good editor. Remember to thank her each time she reviews your course materials. Don't assume she knows that you appreciate it because you have said so in the past. You haven't told her this time; she has no way of guessing that you still admire her work.
It also breaches trust. Group members rely on each other to make commitments. If a group member fails to make a first commitment, they assume that the person is not trustworthy. Only later in the process are other group members willing to give some slack. For example, until people know what others are like, they can't say "it's not like him to miss a deadline."
The people who can't find their niche constantly worry, wondering how they will contribute. Those who can't should accept that and offer, instead, to help in whatever way possible. Look for ways to contribute. Amanda, who had difficulty finding a niche on project team, commented in her project journal:
It was important to me that I, at the very least, always display that I wanted to help where I could.
For example, suppose you are assigned to a team that needs instructional design skills but a more experienced team member seems to already have the trust of the team to do this work. Offer to help the lead designer so you have an opportunity to contribute as well as build your skills.
If repeated attempts to find a niche fail, leave the team. Your talents and skills are obviously not needed. And rather than develop a negative attitude, go somewhere else and find a way to feel more useful.
As Abbie noted in her project journal:
I think in any group...we bring to the table ourselves. Basically, that's all we have to offer. And none of us is perfect. But in interactions with others, we think they should be and they should never let us down.
So often, team members say that they did not do something because they were waiting to hear from the team leader or another team member. Team leaders say that they did not know about something because the team member never told them. Team members complain that other team members didn't call them.
You could wait until you're blue in the face for the phone to ring. Don't; instead, place the call yourself. Phones work in both directions; if someone doesn't call you, you should call them.
In other words, take full responsibility for all of your own communications. If you want to find out what's going on with your team, don't wait to be told. Call someone and ask. If a team member was supposed to call you and hasn't, call him or her yourself. And if you can't reach that person, call someone else on the team who might be able to help.
As Jill noted in her project journal:
It's dangerous for experienced group members to expect the less experienced group members to do the project without their help. Why not make a phone call to check up on the project or ask if you can help?
Team leaders, too, need to take full responsibility for their own communications. Don't wait for other team members to contact you, contact them first. Team members should also note that people tend to filter the messages they provide to leaders. People tend not to tell the whole story¾ especially if it's not a flattering one. So probe. Ask three or four people what's going on instead of relying on one source. Between all of them, you'll find out what's happening.
Another way to facilitate communication within the team¾ and outside the team¾ is regularly publishing a status report. The report explains how the project as a whole is progressing. A project status report is essential to good communications because, as a project moves forward, team members become engrossed in their own part and forget about the whole.
The project report should be distributed to all team members. Parts of it should be distributed to those who are affected by the progress of the project. Items included in a project status report include:
Projects developed by teams usually involve many changes throughout the course of their development. These changes occur for three reasons:
In theory, all of these changes sound good. But try asking for changes on a team project. On the one hand, those making the comments feel frustrated when other team members don't accept them. As Phyllis noted, "All of my work seemed to be for nothing."
On the other hand, those receiving the comments hate having to make late changes. "We should have settled this months ago," Terrence wrote in his journal. Some people suffer from the Not-Invented-Here syndrome¾ a categorical rejection of any idea that emanated elsewhere.
But, as Jone Rymer Goldstein writes in Technical Communication, the ability to receive and accept feedback represents a high level of professionalism that many team members might not have yet developed. If team members first have an opportunity to develop relationships¾ including a level of professional trust and respect¾ and are prepared for the likelihood of changes, they are more likely to accept them.
As Tess notes in her project journal, people need to look at the feedback as a learning experience. But many are only able to do so when properly prepared for the situation.
As a follow-up to Secret Six, team members need to consciously avoid judging other team members if they are going to openly accept the valuable ideas these other team members offer.
Management experts often warn that we tend to hire people like ourselves and end up with the problem of "group think," when everyone thinks alike. Yet team assignments are usually made for us. The people on teams are not likely to be similar to ourselves at all. Unaware of how to cope with the differences, many of us choose to become judgmental, feeling that we could do things better than our teammates.
To avoid being judgmental, consider adopting one or both of these behaviors :
Also provide feedback in a way that avoids a judgmental response:
Instead, try to discuss the project in general to make sure you understand what is wanted, when it's wanted, who your customer is, and what you are expected to produce as a group.
This is also a great ice breaker, because group members often do not yet know one another well enough to discuss personal issues nor do they know the project well enough to discuss particular aspects of it.
Later, at the end of the first meeting or in the second meeting, you can determine who will play which role.
Tess notes, "I find collaborative processes very frustrating in some ways because there is so much work that needs to be done and so much time is spent up front [work] it seems."
But the up-front effort makes a difference. Consider, again, the value of these eight secrets:
In her journal, Tess notes the value of relationships--not just plans--on teams. She notes that plans don't always work but team members who respect one another, trust in one another, adjust their behavior in response to feedback, and are committed to team success--not just individual success--
I go white-water rafting every summer and last summer, I went at a time when my group at work was falling apart. We were the furthest thing from a team that you could ever imagine. On this white-water rafting trip, I was on a raft with two other experienced rafters, two new rafters, and one person with some physical disabilities. When we started out into the river, I was listening very closely to our guide. When he said, "paddle right," I paddled right. When he said, "Paddle back," I paddled backwards. I was careful to keep my strokes even and at a regular pace. But I kept running into problems.
The person across from me had some physical disabilities and he wasn't coordinated enough to paddle with any kind of regular rhythm. The person behind him just kept getting disgusted when their paddles got tangled up, so she just pulled her paddle into the raft and sat there. The person ahead of me was new to rafting and he hadn't learned to paddle evenly. So no matter how even my strokes were, we kept hitting each other's paddles. Meanwhile, our guide was having a hard time distinguishing his left from his right.
It suddenly occurred to me, as I trudged out of a very cold river, after we'd dumped our whole raft over by not working together through a rapid: Just because I was following the guide and doing everything I was supposed to do, it didn't mean I was a good team member. If the guide told us to "paddle back," but everyone else was paddling forward, I needed to keep paddling forward. If the guy ahead of me couldn't keep his strokes even, I needed to start paddling with irregular strokes, and then try to match him rather than trying to be right. If the person across from me couldn't paddle right then, I needed to stop paddling, too, so we wouldn't go in circles. It came to me very clearly that, at work as well as on the river, sometimes you can only be right by being wrong.
For this project, I think our group steered a pretty good course down the river. Even if our customer was sending us off track, we all went off track together and brought the project back on track together. Some people pulled harder than others, but everyone did what was expected of them in the end, even if those expectations were unequal for different members of the team. We weren't sure where we were headed for awhile, but we never just stopped midstream or drifted without moving forward. And, at the end, we made through the rapids without dumping over or throwing anyone out along the way.
In other words, if people are merely committed to a task and a plan, they are likely to topple over in their efforts. But if they are committed to the team, they'll admirably succeed in their efforts.
Project Management | People Management | Business Management | Information Design Models, Processes, and Techniques | Home
(c) Copyright. 1999, 2000, 2001, 2002. Saul Carliner. All rights reserved.
