Do you have a mole undermining the work of your team? Someone who constantly complains privately to any teammate who will listen but refuses to bring that same complaint publicly to the team? Someone whose actions are destroying teamwork?

A mole erodes productivity. Stop that mole now.

A team is like a garden. A good gardener manages pests –

Bambi, a deer, can kill a portion of your garden by eating your produce’s leaves. His attacks can be seen so they can be managed by the non-specialist, by using such means as scaring him; erecting a fence; planting produce that he doesn’t like; and using chemicals that make your plants smell or taste yucky.

Buck, a mole, undermines the roots of your garden killing your produce. But unlike Bambi, you can’t see Buck in action so his attacks are almost impossible to mange by the non-specialist. For instance, scaring him won’t work because you can’t see him; erecting a fence won’t stop him because he does his work under the surface; planting different produce won’t stop him because his food source is the worms, insects and grubs beneath your garden; and using chemicals to kill the insects and grubs won’t stop him because his primary food source is the worms.

Bambi’s behavior can be managed so that it is an annoyance. Buck’s behavior is much different — it’s destructive.

Real moles aren’t malicious. Their intention is to eat rather than destroy the garden. I admire them for their single mindedness and work ethic. I, however, disdain a mole on my team.

I believe the Bucks of the world think their actions are helpful. But unlike my ability to manage the Bambis, I don’t have the special skills necessary to consistently manage or turnaround the Bucks. And in my experience, I estimate that there are only 0.1% of all managers who have that special management (therapy) skill.

What’s to be done? Confirm you are dealing with a sibling of Buck’s by — bringing the tunneling behavior to the person’s attention, telling them it’s unacceptable, and determining whether the tunneling continues. If it does, work with HR to immediately rid yourself of them.

Once they’re gone, the team will feel like the weight of the world was lifted from their shoulders. Productivity will skyrocket. Stop that mole. Now.

convert this post to pdf.

“What?” raced through Janet’s head as she read the email. “Now that’s a surprise.”

The message was from Jack Johnson, vice president of development. It said she would receive a meeting request from Rajan Alak, an outside consultant, to interview her about the problems with the new system. The message went on to say the company had made a significant capital investment in the development of Synergy and problems with the system were preventing the company from enjoying the expected ROI. Jack asked Janet to give Rajan her full cooperation.

“He wants me to give an outside consultant–a total stranger–my full cooperation?”

The problems with Synergy didn’t surprise Janet. She had invested almost all of her time during the past year in developing the system. She believed the business planners had been too aggressive with the system integration plans. She thought the company’s chance of achieving the projected ROI was zero. Her suspicion was that the projection was based on politics rather than reality.

A portion of Jack’s message was a surprise: In addition to fixing the problem with Synergy, he wanted to fix problems in the development process that had caused the issues with the system. Solving problems with the development process was an initiative Janet had wanted to see since she started her job seven years ago.

She waited to exhale and asked herself, “How much should I tell this outside consultant? Will my statements be used against me? Or my manager?” And as she exhaled, no answers came.

The next morning Janet received the meeting request from Rajan to interview her the following Wednesday. The request included a copy of Jack’s message and told her she would receive more information about the interview in a forthcoming email.

A part of her kept wondering, “How much can I say?”

Rajan’s email titled “The Interview Process” arrived two days later. Janet read the message carefully. It said she had complete control over the information she shared. She could choose to have information marked as originating from her, originating from an anonymous source, or recorded as off the record. Rajan said that after the interview she would receive a transcript of the “on the record” parts of the interview for her review and approval. Rajan emphasized he would not share any of her comments with anyone else until she approved them.

“Hmm . . . ” she thought. “Maybe it’s OK to share what I know.”

Fundamentals

The quality of an interview depends on how safe the interviewee feels. People guard their knowledge when their answers may endanger themselves or a valued colleague. The safer the interviewee feels about answering questions, the higher the quality of information available to the interviewer.

Creating a safe environment is only the start. In addition to safety, the quality of a set of interviews–whose purpose is to discover problems and solutions–depends on managing the sponsor, interviewing the right people, and interacting skillfully with the interviewees.

Let’s explore effective actions available to the interviewer before, during, and after the face-to-face interview.

Before the Interview

Sponsor Agreement

Gaining clarity about the objectives of the sponsor saves everyone time. Help your sponsor write down what is important to him and, just as importantly, what will gain the cooperation of the interviewees. Have the sponsor sign off on a written set of discovery objectives and a list of people to be interviewed.

For instance, if a vice president says her objective is to fix the problems with a system, her message will be compelling to some of her people. Adding that she also desires to solve the development problems that caused the system’s problems may energize additional people.

Rarely does anyone create objectives that are compelling to everyone. Objectives that are compelling to some people may de-energize others. So, focus on creating compelling objectives for the people whose opinions matter most to your sponsor.

Overcome Restrictions

You will want to talk to the organization’s customers. Some organizations carefully restrict who communicates with their customers. Despite these barriers, assume management wants you to speak with them. Work with your sponsor to identify which customers you will interview. If your sponsor objects to your talking directly to the customer, negotiate. Explain that without customer feedback, the most that can be discovered is less than half the available information.

I prefer to interview the customers first. I want to hear their unfiltered perspectives about outcomes that were expected but never satisfied. Next, I like to interview key middle managers to gain additional perspective. The customer and middle management interviews reveal a panorama of the most visible problems and provide an opportunity to find out more about whose opinion is the most influential.

Sponsor Communication

Regardless of whether you are an inside or outside interviewer, the person you are interviewing needs to hear from his management why he is being interviewed, who will perform the interview, and what actions management expects from him. In the introductory story, a vice president, Jack Johnson, provided that information to Janet.

Prepare an email for the sponsor to send to all the people being interviewed. Take control; if the context isn’t set properly, it will be a barrier to your success. If the sponsor is uncomfortable with your message, ask him to discuss it with you and work with him to revise it so it works for the sponsor and you.

Ask the sponsor to send the message to each interviewee individually. My experience is that messages addressed to a single recipient gain more attention than messages addressed to a group.

Also ask the sponsor to mention the interviews in staff meetings and to emphasize the importance to the interviewees. Scheduling interviews is difficult in busy organizations. When upper management deems the interviews to be of high priority, middle management will more readily support the scheduling of its people’s time. Otherwise, the interviews will be a low-priority event that may never happen.

Interviewer Communication

After the message is sent from the sponsor, it’s up to you to schedule the interview. I suggest you attach the sponsor’s original message to your scheduling request so recipients can review it. The inclusion of the original message prevents confusion by people who may not have read the message from their management.

Follow the meeting request with an email from you to each interviewee explaining how the process will work. This message lets the interviewee know he controls the use of the information he shares. This email will surprise the recipient. People in large organizations frequently receive messages about protecting the company’s rights but rarely receive messages giving them rights.

My preference for the first interview requires no preparation by the interviewee. If you are interviewing the right people, they already know everything they need to know. Inform the interviewee that he doesn’t need to do anything prior to the interview.

I strongly suggest you telephone the interviewee the day before the interview to confirm the time and location. Priorities change regularly in organizations and the interviewee may need to cancel the interview. Knowing about cancellations early will enable you to reschedule your day. If your call is transferred to voice mail, let the interviewee know the time and location of the interview, leave your cell phone number, and let him know that you’ll assume everything is as scheduled, unless you hear from him.

Question Sequencing

The sequence of your questions contributes significantly to a successful interview. A key aspect of most interviews is gathering information about problems. I like to look at questions as either branches or stems. Branch questions move to a new subject area. Stem questions (indented below) gather more detail about a branch. Let’s look at a high-level plan for sequencing questions during a sixty-minute interview:

Q: Who is your customer?

How does your customer relate to Synergy?
Who else is your customer?
Would you recommend that I interview any of the people you mentioned?

Q: What problems did Synergy solve?

Tell me more.
Anything else?
Someone in a previous interview mentioned that Synergy retired a number of older applications. What’s your take on that?

Q: What problems did Synergy create?

Tell me more–what evidence do you have?
Who else should I talk to about that problem?
Who might see this differently?
Anything else?
Francois suggested that I ask you about complaints about poor performance. What can you tell me about that?
Why did this problem occur?
Could something have been done to prevent it?
What suggestions do you have for fixing the problems?

Q: What problems happened during development?

Tell me more.
How did that affect you?
What else?
What recommendations do you have for fixing the problems?

Q: What other questions should I be asking you?

How would you answer your questions?
Anything else?

Q: Do you have any questions for me?

Q: May I contact you if I have additional questions?

These questions can be asked to anyone in the organization. As you gain information from each interview, adapt your questions to fit the person you are interviewing.

Metaquestions

In addition to questions on the topic of interest, effective interviewers equip themselves with metaquestions to gather feedback about the interview process itself. Metaquestions are questions about questions. For instance, if you see a puzzled look on the interviewee’s face, you might respond, “I see a look on your face that suggests to me that you might be puzzled by my question.”

I find answers to metaquestions open new possibilities about what to do next. For instance, you may discover that the person you are interviewing has a different role than you thought and the role isn’t relevant to the discovery. Rather than continue the interview and waste his time and yours,you now have the option of ending the interview. The following is a list of metaquestions I have found valuable in any interview situation:

Do you have any questions for me?
Do my questions seem relevant?
Do my questions puzzle you?
Are you the right person to answer these questions?
Is there anything else I should be asking you?

Don’t Worship the Plan

Plan the interview, but don’t worship your plan. Effective interviewers adapt to the desires of the interviewee. Don’t be the type of interviewer who never deviates from his list of questions. I have experienced that kind of interviewer, and I wondered if he even heard or cared about my responses.

If the interviewee makes it clear that he would enjoy answering more questions, you have connected. And connection is an objective of every interview.

During the Interview

Virginia Satir, a pioneering family therapist, created an interaction model that offers interviewers insight into how to conduct an interview. Satir insightfully broke down each interview interaction into a series of steps. She suggested that careful processing of each step offered new choices for strengthening the connection between the interviewer and the other person.

Satir’s interaction model can be summarized as follows: Perceive -> Interpret -> Evaluate -> Respond.

Let’s use the interaction model to examine a portion of the interview from the perspective of Rajan, the interviewer. For example, Rajan asks Janet, “What problems did Synergy solve?”

Perceive

The first step in the interaction model is to perceive the interviewee’s response. Rajan hears and sees Janet’s response. The words are a single component of Janet’s response; other components–such as tone, pace, breathing, and facial expression–are also part of her response.

For instance, before Janet uttered a single word in response to the question about the value of a solution, Rajan noticed her eyes narrow and her forehead crinkle. Rather than rush to interpret the words, the interaction model suggests there is an opportunity to gather more data before interpreting meaning.

Rajan has the opportunity to say something like this to Janet: “I noticed that your eyes narrowed and your forehead crinkled before you answered my question. I’m not sure how to interpret that reaction. What can you tell me about it?” Regardless of how Janet responds, Rajan has gained additional and perhaps more relevant data about Janet’s response.

Janet blinks, straightens herself, and answers, “It would mean a whole lot to the department. We could process work faster.” Let’s analyze this. Notice that Janet’s words are about the value of the solution to her department rather than to herself. Without further probing, valuable data could be missed.

An effective interviewer explores how something directly affects the interviewee. That’s the subject where the interviewee has total expertise. Rajan, an experienced interviewer, then asks Janet a clarifying question, “What would a highly effective solution to the problem do for you?” Rajan might ask several probing questions to gain more specific data about the value of the solution to Janet.

Interpret

The second step in the interaction model is to interpret the data. Rajan decodes Janet’s meaning from the data he gained through his senses. Successful completion of this step happens when the interviewee agrees that the interviewer’s interpretation is the same as his meaning.

Sometimes interpretation is simple. For instance, Rajan says, “Janet, I understand that solving the problem would save you four to six hours per week. Does that capture the value of the solution for you?” If Janet says yes, Rajan is done with that question. But watch for her wanting to say more. After a long pause from Rajan, she may say, “But the most important thing is that I then could rely on the accuracy of the results.” Now Janet has revealed the real value to her.

Sometimes interpretation is difficult. Transmission errors are normal. Your perception might be wrong. The interviewee might have said something wrong and not realized it. That’s why it’s crucial to gain the interviewee’s agreement about this meaning. After you publish the findings and recommendations, the last thing you want to hear is an interviewee saying, “That’s not right,” “That’s not what I said,” or “That’s not what I meant.”

Let me suggest a method for confirming that you have captured an interviewee’s meaning correctly. Ask the interviewee a series of “Do you mean X? Do you mean Y? Do you mean Z?” questions until you hear three “Yes” answers. For instance, Janet may have provided Rajan with a lot of data about the value of the solution that doesn’t have a single simple interpretation. Rajan asks Janet:

“Do you mean the solution will save you four to six hours per week?”
“Do you mean the solution will enable you to more effectively communicate the status of the client’s requests?”
“Do you mean the solution will enable you to help your colleagues with their work and for them to help you with yours?”

A “Yes” answer confirms your interpretation. “No” answers provide opportunities for finding out what was meant.

Evaluate

The third step in the interaction model is to determine the significance of the meaning. Explore how the meaning connects to value for the interviewee, organization, and customers.

For instance, consider the response “X will save me four to six hours per week.” On the surface that sounds terrific. But how significant is that savings? During the interview with the head of engineering for an airplane manufacturer, I informed him that someone in his organization said that a new system would save each of his engineers four hours per week. He squinted his eyes and said, “So what? That doesn’t guarantee me increased productivity. They may take that time savings and stare at the holes in the ceiling tiles.”

In other words, without connecting the time savings to something else, a benefit that seems obvious at one level may not be obvious at all to a different level or perspective. Dig deeper. Ask follow-up questions such as, how would you use the time savings? Keep probing until you uncover a benefit that is meaningful to the interviewee and, if possible, to his management.

Respond

The final step in the interaction model is for the interviewer to choose the next question. You can choose to continue asking stem questions, ask the first question in a new question branch, ask the first question in an unplanned branch, or ask a metaquestion to help you decide what to do next.

If you are like me, you may have times when you aren’t sure what to ask next. I have found a comment and a metaquestion that has worked well. I tell the interviewee, “I’m not sure what question to ask you next,” and then ask the metaquestion, “What question should I be asking you?”

After the Interview

Observe And Transcribe

I suggest an interviewer use a pocket recorder so you can keep your eyes on the interviewee rather than looking at your notes. Be sure to ask for permission to make a recording, and if you don’t get it, don’t record. Throughout the interview, watch for signs that the interviewee is uncomfortable with the recording. Be willing to switch it off if it’s obstructing the interview process.

Write the transcript of the interview as soon as you can. The transcript only includes the material you may want to use in your discovery report. Share only what is relevant and needs to be confirmed by the interviewee.

I like to tell the interviewee that anything in the transcript is something that I might quote directly. I believe it’s extremely powerful to include in the discovery report quotes from people in the organization as well as customers. If the interviewee grants you permission to quote him, give him the credit for discovering a problem and how to fix it.

Don’t Share Until Approved

Don’t share information from the interview with anyone until the interviewee has given you permission. And let me be clear: I mean no one else. That includes the sponsor and your manager. You have made a commitment to the interviewee with the hope he would feel safe to share things with you. Don’t break your promise.

Adapt Your Plan

From each transcript, follow the suggestions about questions to ask other people. The interviewee gave you a person’s name because he thought that person knew something important or his thoughts had significant influence within the organization. Use this information.

Revise your question plan based on what you have learned during the interview.

Thank the Participants

Thank the participants at the end of the interview. Thank them when you send the transcript. Thank them when all the interviews are done. Thank them all in the preface to your report.

The more appreciation you show the participants, the more they will appreciate you.

Summary

Interviewing is an art. Learning how to do it effectively takes practice.

I’ve made many suggestions. If you can only do three of them, I recommend:

1. Building a foundation of safety so interviewees will tell you what they know.
2. Conducting face-to-face interviews so you hear and see what is being communicated.
3. Planning your questions and using metaquestions to adapt to the needs of the interviewee.

By executing a set of effective interviews, you will gain knowledge about the organization and its problems that no single person in the organization can offer you.

Remember to conduct yourself with integrity every step of the way. It’s fundamental for gaining the trust of people you are interviewing.

<>

Steven M. Smith (www.stevenMsmith.com) is a management consultant who specializes in helping leaders of technical organizations delight customers, manage change, and strengthen teamwork. With more than three decades of experience as a thought leader in technical organizations, he shares his know-how through his writing, consulting, and leadership of experiential workshops. He is a founder and host of the annual Amplifying Your Effectiveness (AYE) Conference (www.ayeconference.com), at which he leads experiential workshops. You can contact Steven at steve@stevenMsmith.com.

convert this post to pdf.

IT professionals must be good team players, but what does that mean?

For one thing, it means they must know how to come into a situation and quickly cooperate and gain cooperation, but cooperation takes many forms. It’s not sufficient to want to cooperate. You must also know how. This column is about the technology of cooperation.

People
Most people, when they think of cooperating, think of everybody doing the same thing?like all pulling on the same rope in a tug-of-war or rowing in the same Roman galley, perhaps chained to the oar. When you consider cooperating by sharing people’s direct labor, first try to categorize the situation into one of these two:

1. The job is well understood and easy to communicate to a newcomer.

2. The job is fuzzy, or not understood at all, or complicated.

In the first situation, as in a tug-of-war, it is relatively easy to move people about from one work group to another. The amount of productivity in this situation is roughly the sum of the individual productivities. Ten people can tug ten times as hard as one. Many managers think that adding IT professionals is just like adding bodies to a tug-of-war team.

But even a tug-of-war is not so simple, for those who are experts at it. Given roughly equal weights on both sides, the team that understands and uses technique will win every time – and can even overcome substantial weight deficits. Adding a new member to a skilled tug-of-war team will not add proportionately to their success. Indeed, unless the new member understands their technology and system of communication, the addition of another body is likely to reduce their total tugging effectiveness.

When the job is fuzzy, and ideas are needed more than simple tugging power, the addition of a new member can be helpful if the team is ready to accept new viewpoints imported by the new member. Experienced IT professionals, however, know how hard it can be to have their better ideas heard when they’ve just started a new assignment. It can be horribly difficult to integrate a new person. Time and “wasted” effort must be allowed for in such additions, especially as the job grows more complex.

Thus, if quick addition is needed, adding people willy-nilly is not the answer. This observation was the essence of Brooks’s Law – adding people late in a project makes the project take even longer. Adding them early, however, which allows time for this “wasted” effort of integrating the new people, can, in the end, make a project go faster.

Any IT professional who is thrown into a project late and expected to make things go faster needs to be aware of Brooks’s Law and needs to communicate to the management what kinds of delays are to be expected. Moreover, each of us IT professionals needs to master the arts of quickly learning what the job is about and how the existing team communicates.

Programs
When we import a program or a piece of hardware to a project, we import technology in a form that may seem more acceptable than a new team member might be. This is the dream of reusable software. But when the team members feel that their own technology is an extension of their own egos, programs may not be portable at all. Instead, they run into the “not-invented-here” brick wall.

Of course, even when a team is willing or even eager to import software or hardware, it may prove poorly designed for portability. In general, portability of complex technology doesn’t come by accident, but by design and by testing of the design. Even for well-designed technology, there is a break-in period which may or may not be shorter than the time taken to add a new member to a team. Of course, the payoff for an imported technology can be huge, but only if it’s adopted and used.

Some IT professionals come on the job with their own tools, not anticipating the amount of difficulty they will experience getting the existing team to adopt their “superior” tools. If you feel that your tools add to your value as a IT professional, you must master the art of introducing tools – especially to people who may be insulted by the very idea that you might know something better than what they already know.

Perceptions
Ideas or ways of thinking can be the most portable of all kinds of technology, as long as the ideas or perceptions are not labeled too clearly as “belonging” to someone. The rule here is perhaps the most important that a technically-oriented IT professional can learn:

There’s nothing you can’t accomplish if you aren’t concerned who gets the credit.
If a project is successful, there’s always enough credit to pass around.

Points or Perceptions
Much of what we do on a job is to win the approval of the management, or of the customer. We call this “scoring points.” Success on a job depends very much on the ability to score points, in whatever game management happens to be playing. If they are playing a good management game, then the more points you score, the better the job you must actually be doing.

But bad managers give points for the wrong things, and if you work under such a point system, you soon become a poor performer. In any case, though, in work as in life:

Points can never be passed directly from one person to another.
To pass points, you must pass people, programs, or perceptions.

In general, sharing perceptions may be the easiest way to cooperate. Moreover, if you don’t share perceptions, it may be almost impossible to cooperate. So, when you enter a new group and want to cooperate, it’s best to start by listening?and learning how other people perceive the world.

convert this post to pdf.

During a recent in-house project management class, I suggested that the project teams move from weekly builds to nightly builds, preferably with an automated smoke test as a technique to increase the pace of the project. “We can’t do that,” one of the project managers said. “Our testers can’t keep up.” Why do your testers need to keep up? Nightly (or hourly) builds aren’t for the testers?though they can take advantage of newer builds?but for the developers.

Developers receive timely and frequent feedback

With staged integration?building weekly or less often?developers receive feedback about their work at least a week after they check it in (sometimes a month or more, in my experience). With nightly builds, developers receive feedback the next day on the previous day’s work, which is a hallmark of agile development.

With nightly builds, if a developer has a bad development day, that developer receives feedback the next day, wasting only one day’s worth of work. With less frequent builds, developers receive feedback days or sometimes weeks after they’ve finished their work. It’s too easy for developers to get stuck with incomplete or wrong thinking and not realize it until weeks have passed, making the project late and adding to the needed rework.

One of my clients can only build their system about once a month. They need a full week to resolve the compile circularities, and then another couple of weeks to find all the people who broke the build to fix their problems, resume or restart the compiles, and finally complete the build process. It’s possible for a developer there to have to change something checked in two or three months ago, because problems with that code didn’t appear until a build or two later when someone else checked in a complete piece of work.

Staged integration, in which developers wait until an entire piece is done to check in the whole darn thing, helps each developer complete a chunk of work, but slows the progress of a project. Here’s why: A developer starts developing in a private sandbox, and every day pulls down the latest changes from the mainline. The developer checks for differences and integrates any found into the code under development. With any luck, no other developer is working in the same area. But if there is someone else working in that area, the developer has a choice to make: does she take the updated code or continue to work in solitude until her piece is complete?

Many developers wait to integrate their code until it is structurally complete and cohesive. But the longer it takes for that developer to complete the code, the more the mainline is changing. And the longer the developer waits to integrate that piece of code with the mainline, the more work the developer has to complete for integration?and the longer the developer has to wait to receive feedback from the build process.

Contrast staged integration with continuous integration: where small pieces are integrated every day and the system is built every night. Every day the developer brings down the new changes into the private sandbox, makes changes to the code, saves the changes, and updates the mainline. Not only does the developer receive feedback on the code via the build process, but also other developers can see what’s changing in that area.If multiple developers are changing code in exactly the same area, they have to talk to each other to make sure they don’t step on each other’s code (a practice that helps any project). But chances are good that even if developers are working in the same set of files, they’re not working in precisely the same areas of the files. Most configuration management systems will automatically merge the changes without problems.

When developers integrate small pieces every day, they are less likely to propagate mistakes for weeks. Instead, because changes are available to everyone using the updated sources and builds, the developers receive feedback within a day. If something is wrong, they only have to look at yesterday’s changes, not a week’s or month’s worth of work.

Testers receive the option of which builds to take

While continuous integration (nightly builds at minimum), solves the problem of ensuring developers receive feedback about their changes, testers might feel left out in the cold. In fact, one tester told me, “I can’t take every night’s build?my regression tests alone take three days to run.”Testers have a choice. They don’t have to fully test every nightly build. Maybe they’ll use the weekly build on which to run regression tests. Maybe they’ll choose to do some exploratory testing on a nightly build in a particular area. Maybe they’ll verify fixes in a different area for a particular build. Testers are responsible for assessing the risky areas of the product and deciding how to test that area in the current build.

It’s not reasonable to expect testers to fully test every build every day. It is reasonable to discuss with testers what their testing strategy will be during the different times of development, so you know the testers are making progress and the developers can receive the testers’ invaluable feedback.

Nightly Builds Might Not Be for Everyone

I have yet to encounter a project where someone can’t use nightly builds, but, then again, I haven’t encountered all projects. It’s possible that your particular circumstance prevents the use of nightly builds. Certainly, if the testers are the only people on the project who use the build, nightly builds may be building too often. But increasing the frequency of your project’s builds is a quick step toward helping the developers see where they’re going, and that helps the project make forward progress.

convert this post to pdf.

This column originally appeared on Stickyminds.com.

Conflict is inevitable at work. Sooner or later, you will disagree about what to test, when to test or how long to test software. How you.and the person you disagree with.approach the conflict affects both the outcome and how you feel about the exchange. Let’s listen in as Jim, a test manager, and Pam, a development manager work through one of those inevitable conflicts.

* * *

Jim, the test manager, started the coordination meeting with
Pam, the development manager, by stating that he needed her team to turn over
all the code on the first Monday in September. In a previous meeting, they’d
discussed having the code complete in October, but Jim’s statement sounded like
a demand to Pam rather than a starting point for discussion.

Pam asked Jim what was behind the change, and when he said
he wanted to begin testing early, Pam was thrilled.

“That’s great,” Pam said. “Early testing will really help
us. We won’t have all the code done until the October date we discussed
earlier, but we’ll have features ready to test starting in August. I can turn
over features every two weeks from August through September.”

“No, I need all the code for early testing the first week
in September,” Jim reiterated.

“Is the issue that you don’t have anyone to assign to
testing earlier?” Pam probed.

Jim shook his head. “No, we need the code all at once.”

Pam asked more questions to understand Jim’s concerns and
offered more options, but Jim stood firm.

Later, Pam mused to herself, “It’s almost as if he needs me to lose in order for him to win. I
offered everything I could think of so the situation would work for both of us.
Now we’ll have to hash this mess out with the VP. Why does Jim always have to
have his way?”

Meanwhile, Jim was thinking, “Why did Pam try to weasel out of this? If I agree to her options, she wins.”

Scenes similar to this one play out in business every day.
The people and the topic may be different, but the ways Pam and Jim are
approaching their differences represent common approaches to conflict:

• Collaborative Problem
  Solving–Pam is approaching her conflict with Jim by trying to find options
  that will work for both of them. She’s looking for the interests behind Jim’s
  position, sharing her interests, and looking for options that satisfy both
  parties.
• Competition–Jim, on the other hand, is approaching the conflict with one aim in mind: achieving his goal. He’s not willing to explore other options; he’s intent on pressing his preferred solution. If he get’s his way, Pam doesn’t get hers.

In addition to Pam’s Collaborative Problem Solving approach
and Jim’s Competition approach, there are three other common approaches to
conflict:

• Yielding–In this style, one person yields, accommodating the other personís wishes without pressing his or her own interests.
• Avoidance–Sometimes people do
  everything they can to avoid a conflict. They pretend the difference doesn’t
  exist to avoid the unpleasantness of confrontation.
• Compromise–In compromise, people try to meet halfway. Each gives up some of what he wants and achieves some of
  what he wants. Compromise is common, though not always satisfying since no one
  is completely happy with the solution.

All of these are valid and useful ways to approach conflict
in some situations. And each can be destructive when misapplied.

In the story about Pam and Jim, Jim could have achieved his
stated interest had he been willing to look for more options to meet the goal
of early testing. His desire to prevail–competition–in this situation will
damage his relationship with Pam, and may hurt his reputation with the VP.

Pam’s approachócollaborative problem-solving, while
appropriate in this situation, might not be helpful when there’s a clear
downside to meeting the other’s interest—for example if the other person
wants to pursue an illegal or unethical action. Pam’s collaborative approach
also takes time in order to uncover interests, generate options, and reach a
mutually satisfying outcome. It’s worth the time when long-term relationships
are at stake, but may not be when time is of the essence or the relationship is
transitory. (If a store clerk in the airport wants to talk on the phone with a
friend instead of serving you, and you have a plane to catch, you probably
won’t use a collaborative problem solving approach. You just want to pay for
your item and be on your way.)

Likewise, yielding is fine when one person doesn’t have much
investment in the outcome and the other person does. Yielding hurts when it’s
habitual–one person always gives in to the other. Others may perceive habitual
yielders as doormats and walk all over them. An
example in the workplace is when someone always says “yes” to all his manager’s
requests without discussing risks and negotiating. The long term cost of
habitual yielding is resentment, depression, anger, and contempt.

Avoidance may be the best policy when there’s nothing to be
gained by working through an issue. For example, one manager walked away from a
conflict with a peer when they couldn’t agree on a testing standard. He saw
that the situation would correct itself as soon as the standard (which he
believed was misguided) was published to the organization, and that arguing
with his peer would only damage their relationship.

We often hear that compromise is the ideal, and sometimes it
is. But looking for compromise often ends in a half-horse, half-camel solution
that isn’t fully satisfying to anyone. Compromise leads people to miss novel
solutions that can satisfy both parties and may be better than either of the
original solutions. Pam could have compromised and agreed to turn over
partially completed features, but that wouldn’t have worked out well for either
Pam or Jim. Compromise is the best option when it’s clear that a collaborative
solution isn’t possible.

Like Pam and Jim, most of us have a preferred style for
approaching conflict. Sometimes it works for us–and sometimes it doesn’t. When
we approach every conflict with the same style, regardless of what’s at stake
and without consideration for maintaining important relationships, we may win
in the short term but lose in the long term. Or we may avoid a difficult
conversation but build up resentment. We’re all more effective when we develop
our ability to approach conflict with the style that suits the situation.
Consciously choosing which approach fits best, given the stakes and the
relationships, is a winning strategy every time.

convert this post to pdf.

“Our retrospectives have become so repetitive,” Fran told me over lunch one day. “We seem to cover the same ground no matter what problem-solving approach I try.”

“Have you tried AI yet?” I inquired.

He retorted, “What does artificial intelligence have to do with anything?”

“Sorry for the confusing acronym. Not artificial intelligence. AI stands for Appreciative Inquiry, a different approach. I find that folks can get a lot more out of their retrospectives when they use an approach that focuses on where they’ve added value or felt high energy. Teams often lose energy when they hunker down to confront setbacks, obstacles and mistakes. It’s discouraging.”

“I haven’t heard about your AI. Tell me more.”

Developed by David Cooperrider and colleagues at Case Western Reserve University in the 1980’s, the AI method brings a fresh approach to improving systems and catalyzing change. AI begins with a series of interviews and questions ? the inquiry. Cooperrider based his method on the observation that humans learn and change in the direction of their questions. Appreciative inquirers search for the best in people, their organizations and their environments. They ask questions to uncover stories of when their group felt most alive, contributed most effectively, and found itself most capable of adding value?or appreciating. (For fuller definitions, see the links at the end of this article.)

I prefer an appreciative approach in retrospectives and try to build an appreciative focus to all or part of every session I lead. Teams who build on strengths, successes, and positive energy carry that energy and momentum forward. They also accelerate and deepen trust in their team and work relationships.

Retrospective leaders and teams who focus on what went wrong, where the team failed, and who to blame generate a downward spiral of depleting energy. The team often stops holding retrospectives as a result. Putting attention on failure and blame depletes trust among team members?who start to avoid failure more than seek success. Continuous improvement discontinues.

How can a retrospective leader shift to an appreciative inquiry approach?

What would a retrospective that followed an exclusively appreciative model look like?

Follow the retrospective framework from Agile Retrospectives: Making Good Teams Great! by Esther Derby and Diana Larsen, then give it an appreciative twist.

Set the Stage:
To begin, welcome team members to the retrospective. State an affirmative goal for
the session. Choose among goals like:

• During this retrospective, we’ll find ways to amplify our strengths in process and teamwork.
• In this session, we’ll discover where we added the most value during our last iteration and plan for increasing the value we add during the next iteration.
• The goal for today’s retrospective is building on our best uses of engineering practices and methods.
• We’re going to seek out our highest quality working relationships and find ways to expand on them.

Or any goal that sets up an expectation for positive outcomes.

After stating the goal and giving an overview of the agenda for the retrospective, offer a quick round-robin question to each team member, “Which of our working agreements did you see in action during this iteration
(or release)?” This question brings team members’ attention into the retrospective session and reminds the group of their working agreements?by focusing on the times when they followed them.

Gather Data:
Team members ask and answer a series of three or four questions that focus awareness on individual and team strengths and successes.”Tell us a story about a time this week when you felt particularly energized by our work.”"What did you value most about your contributions this week?” (No false modesty allowed. This isn’t bragging or boasting, it’s important data for the team.)

“What did you value most about the work we’ve done together?”

“In what ways did this iteration (release or project) make a unique contribution?” or “What metaphor describes this iteration (release or project) best?”

Keep track of these answers for later. The team will use the responses along with ideas from the next phase to help determine which actions they want to take.

Generate Insights:
Follow the data gathering questions with a question that creates a vision, such as, “Imagine we could time travel to the end of the next release. When we arrive there and converse with our future selves, we hear that it was the most productive, most satisfying effort we’ve ever worked on. What do you see and hear in that future time?”

Wait 2 or 3 minutes for team members to connect with this vision. Then ask: “What changes did we implement now that resulted in such productive and satisfying work in the future?”

Write down all the answers.

Look back over all of the answers the team gave in the last two phases. Pull out common ideas. Look for patterns, common threads, and compelling ideas, then consider why these hold significance for the team.

Decide What to Do:
Based on the data and insights, discuss the implications of different possible actions. Ask: “Which ideas and actions build on our successes, meet the situational (or customer) needs, and tap our greatest energy?” “What are we best positioned to try next?” “What do we really want to try (or sustain)?” Create a list of potential action steps.

Choose no more than three small actions the team can take during the next increment of work. Identify which team members want to lead the follow through effort for each action. Only volunteers with zeal for the action item need apply. No one gets “volunteered.” Ask team members to include the tasks in iteration or release planning and report on the outcomes at the next retrospective, or sooner.

Retrospective leaders can create various activities around affirmative questions by having team members record some key words from answers on sticky notes or index cards for easy sorting. Or record answers on flip charts or white boards. Use dot voting or consensus techniques for selecting final actions.

Close the retrospective:
Reiterate the actions the team chose to undertake. Lead the “Offer Appreciations” activity or hold a full “Temperature Reading,” if you have time. Ask that team members write the thing or things they liked most about this retrospective, so the retrospective leader can incorporate that feedback and design even more satisfying, enjoyable retrospectives.

Voila! A retrospective held entirely with an appreciative inquiry approach.

Keep the lists you’ve created of patterns, common threads and compelling ideas. They will provide a rich source of future retrospective goal topics. Look for other sources of appreciative questions to hone in more specifically to those topics. Sources include:Appreciative Team Building by Whitney, et al, and Encyclopedia of Positive Questions by Whitney, et al.

Teams hold retrospectives to inspect and adapt their processes, methods and teamwork. Taking an appreciative approach to leading retrospectives gives the team a new perspective and renewed energy for implementing actions. Conduct your own experiment. Track the enthusiasm for follow-through you get from a positive core-focused, affirmative retrospective. Compare it to “balanced” and/or obstacle- or vexation-focused ones. Let me know what you find.

“What is Appreciative Inquiry” at http://appreciativeinquiry.case.edu/intro/whatisai.cfm or visit the Appreciative Inquiry Commons hosted by Case Western Reserve University http://appreciativeinquiry.case.edu/.

“Appreciative Inquiry” entry at wikipedia http://en.wikipedia.org/wiki/Appreciative_Inquiry

convert this post to pdf.

You’re not going to meet schedule. Maybe requirements have taken longer. Perhaps in the middle of implementation, you uncover something requiring redesign. Maybe developers haven’t met one milestone yet and you’re worried about the test time. What do you do?

The first slip is the initial indication that something is wrong. Don’t think you can make up time. You can’t. Use the first slip to evaluate what’s going on vs. what you’d like to have going on. When you hit the third or fourth slip, you’ve lost the schedule battle.

Early Schedule Slips

When software projects begin slipping, they’re talking to you. The first slip is a whisper: “Your expectation is not matching my reality. Listen. I can tell you my reality.” If you ignore the first slip, the second slip is a murmur: “Things aren’t quite right. Don’t you want to know what’s going on?”

By the third slip, the project says: “Knock-knock. Are you there? Don’t you want to know what’s going on?” At the fourth slip, the project yells: “Hey, you! You didn’t listen when you could act. Now you’ll have to pay.”

As an observant project manager, when you detect an early schedule slip, you have several options, all related to the project quality requirements and project constraints common to every project:

With an early slip, you can change all, or a combination of these: change the ship date or feature set, allow different defect levels, increase project cost, add more people, or change the work environment.

Mid-Project Schedule Slips

After a couple of schedule slips, when you’re in detailed design or early implementation, it may be possible to inject more people into the project, or change the way you work. I’ve had success with design inspections from people outside the project when we realized the design was not going as well as it should. If you’re in early implementation, maybe you can change the feature set or allow more defects, and still ship on time. If you consider the project requirements and project constraints, changing the feature set or allowing different defect levels are no longer options at this stage.

It’s easiest to slip the ship date, increase the project cost, or change how people work. If you can’t slip the ship date, then you must change how people work. Reviews and inspections can help the design and implementation effort dramatically. The implementation may not meet its milestone date, but with reviews and inspections, you may be able reduce the rework and therefore, some of the test time.

It’s much harder to decrease the feature set (some features may be coupled), or achieve low defect levels in the same amount of time. Generally, it’s also difficult to get more people on the project, but you may be able to hire some people with specific skills: automated test developers or exploratory testers, an external architect to help look at the design, more project managers on a large project. When you add more people to the project, ensure everyone understands their roles so that you don’t slow the project.

Late in the project slips

I recently worked with a company just before they planned to ship a beta release. They were having trouble getting the software ready and they wanted help completing the work done by their beta date. I had questions about the schedule, defect data, testing, and how the developers integrated the code. My first question addressed schedule. “Oh, we planned the schedule six months ago. We haven’t changed it.” I asked if they’d met their milestones. “Well, not really. We missed the first deadline. The requirements weren’t done, but we had to get started, so we started designing without knowing all the requirements.” This is risky, but not a Terrible Thing, especially if they planned to manage the risks. I asked about the other milestones. “Well, since the requirements weren’t done, we couldn’t finish the design on time. Since the design wasn’t done, the coding was late.” The first slip cascaded into every other milestone. Then came the key question: “When did the testers know what to test, if the requirements, design, and implementation were late?” The answer? “Last week.” Uh oh.

I asked one more question: “How much testing did you plan for this project?” They looked at each other. “Well we planned about six weeks worth, but I guess we won’t get to that now.” These people were not stupid. They had a simple problem with a huge cascading effect. Then they had trouble hearing the reality of their project. They started with a small slip, but because they kept going, it magnified the effect of later slips. If they had stopped at the first slip and re-planned their work or schedule, they might have met their beta date. Now, their only option was to extend the schedule.

It’s extremely difficult to recover from late-in-the-project slips. Our only options are to extend the schedule, increase project costs, or change the work environment. In this situation, see if you can change what people are doing. I find that peer review or inspections of every fix helps reduce the number of bad fixes. If you can reduce the amount of rework, especially from bad fixes, you can stop having to extend the schedule. It’s extremely difficult to add more people unless the testers have not yet had a chance to design the tests -you might then be able to use more exploratory testers to save some time.

Summary

If you’re still early in the project you have some options and the most appropriate ones for you depend on what’s driving your project. Clarify your project’s requirements and constraints and you’ll know better what to do. You can reduce the feature set by using peer review on all fixes (to decrease the number of bad fixes), and re-plan the rest of the schedule in detail with the technical staff, using inch-pebbles. If you’ve lost the schedule battle, give up and cut your losses.

Schedule slips are a useful indication that something is not-quite-right on your project. Use that information to make the best decision for your project.

convert this post to pdf.

Josh was dumbfounded when his boss, Brad, fired him. As far as he knew, his work was just fine. But Brad believed he?d given Josh ample warning that his work and work habits weren?t up to par.

When Brad told me he?d fired Josh, he seemed puzzled, too.

?I just don?t get it,? Brad said. ?Josh acted all surprised that he was being fired. But he should have known. I told him not to watch stocks at work. And it wasn?t just that,? Brad continued. ?His other work wasn?t so great. I expect tech writers to turn over clean copy. When Josh handed in work, I always had to proof it.?

?Hmmm. That is puzzling,? I said. ?How did you give him feedback??

?Well, I was walking by his desk one day and saw him checking the stock market sites, so I asked him what he was doing. Josh closed the browser and said something lame like ?Oh nothing.? So I said to him, ?Doesn?t look like nothing to me. Looks to me like you?re checking out the markets.??

?Is that the only time you gave Josh feedback?? I asked.

?No, I gave him other feedback. I brought up appropriate Internet use at a team meeting. And I gave him feedback on his writing, but it was always the same thing. I told him, but he just never listened.?

?How?d you tell him about his writing?? I asked. I was beginning to detect a pattern.

?Well, I proofed it and handed him back the markup. Next time it was the same thing. All five chapters he worked on were the same. It was like he expected me to proof his work,? Brad huffed.

I?ll bet poor Josh didn?t have a clue he was in hot water at work.

Communicating Expectations

Brad may have been more effective, and Josh might still have his job, if Brad had followed these steps for delivering clear and intentional feedback.

Give serious feedback in a serious setting. Brad gave Josh important information in a casual manner while walking by his cube. Neither the timing nor the setting marked the communication as important. Regular one-on-one meetings are a great place to provide feedback for minor course corrections. Always schedule a separate, private meeting to address situations that are more serious.

Address specific issues individually. Brad made a general announcement outlining appropriate Internet use in a staff meeting. General announcements of policy don?t carry the same weight as an individual conversation. If it?s important enough to bring up, it?s important enough to speak directly to the person involved.

Give clear examples. Brad would have been more effective if he had said something like, ?Josh, I saw that you were checking the stock markets on the Internet this afternoon, and on Monday and Tuesday,? or ?In Chapter 1, I had to correct numerous spelling and grammar errors.? General statements such as ?your work is of poor quality? don?t provide enough specific information for people to know what to improve. Labeling statements, such as ?you?re a sloppy writer,? will set up an oppositional dynamic that is likely to go nowhere.

Check for agreement. Getting agreement on the data is the first step in problem solving. Provide concrete facts. People are more likely to accept what you say when it is specific and observable. Josh will probably acknowledge that there were spelling errors in Chapter 1; Josh is less likely to admit to being sloppy. (Of course, if the employee consistently denies the facts, that?s another problem for another article.)

Request a change in performance. While he did drop little hints, Brad never clearly communicated to Josh that he?d like to see changes. Brad could have said, ?I?ve marked spelling and grammar errors on the copy you gave me. In the future, I expect copy to be clean when I receive it.?

Engage in problem solving. Brad could have made a straightforward request for a change in performance, or he could have engaged Josh in helping to solve the problem. Brad might have said, ?Josh, I was surprised at the number of spelling and grammar errors in the chapter you turned over to me. I expect copy to be clean when I receive it. What are three ways you can make sure the copy?s in good shape?? Josh might come up with several ways to reduce errors. He?s more likely to accept the solution if he?s involved in creating it.

Agree on how you?ll follow up. Sometimes you?ll need to follow up on the changes you?ve requested. Brad and Josh could have made an agreement that Brad would skim for obvious spelling and grammar errors and return the work to Josh if he found any.

Check for understanding. Brad assumed that his indirect hints were sufficient. He didn?t check to ensure that Josh had received the message. One manager I know wraps up feedback conversations by saying, ?I?m going to check for understanding now. I?d like you to summarize our conversation for me so I can be sure I?ve been clear.?

Giving clear and intentional feedback is an important part of every manager?s responsibilities. Our employers pay us to provide timely information to our direct reports to guide and influence their work and work habits. Providing feedback effectively gives employees information that may help them improve their performance. And that means we?re more likely to meet management goals, too.

convert this post to pdf.

This column originally appeared on Stickyminds.com

Are you tired of attending endless meetings where the conversation goes in circles and nothing gets done? Even if you can’t stand up and take control, you can nudge the meeting in the right direction from where you sit. Here are some strategies for improving the quality of meetings when you’re not in charge.

Ask for an agenda ahead of time. When you receive a meeting notice, ask for an agenda. Make your request in the spirit of the best use of everyone’s time: “Knowing the agenda will help me come prepared to participate.” You can also say, “Knowing the purpose of the meeting will help me determine whether I can contribute.”

Sometimes a request for an agenda is unsettling to the meeting convener? probably because he hasn’t though through the purpose of the meeting. Your request may prompt him clarify in his own mind why he called the meeting. If you’re really lucky, he’ll realize he didn’t really need a meeting at all (it happens!).

Sometimes though, a meeting convener will insist that you must be there, even though he can’t provide an agenda. I’m a little skeptical when the meeting convener assures me that I need to be there but can’t articulate the purpose of the meeting. If you feel like its not political suicide, tell the meeting convener that you can’t assess the priority of his request against all your other work without an agenda.

Send only one person. Sometimes the person calling the meeting goes overboard to be inclusive. If two or more people from your group are asked to attend a meeting, check to make sure that all perspectives are really required. In many cases, one person can speak to the interests of the group and you can send a representative. One person can go spend an hour at the meeting and then report to the rest of the group. Fewer people will make the meeting easier to manage and the people from your group who don’t go will have a bit more desk time.

Politely decline the invitation. When you don’t have relevant knowledge and expertise to contribute or won’t be affected by the outcome of the meeting, bow out. Ask to be on the distribution list for meeting notes or other communication.

Offer to take notes. Some times when I talk to people after a meeting, its hard to believe we were in the same room. Taking notes can help. As a participant you can offer to help by taking notes. Bring your flip chart paper and a marker and take notes so that all can see. Taking notes in public ensures that every one agrees that what is written is what was said.

Facilitate from where you sit. A well-timed question or comment has saved many a meeting. Here’s a sampling of tactics that I use to facilitate from the back of the room. One word of caution about facilitating from the back of the room: Do this only if you genuinely want to be helpful. If you’re feeling snide, it will come across in your voice.

Request a review of the agenda. When you arrive at a meeting with an overstuffed agenda, make a request to review and prioritize the agenda: “I’m wondering if we have time to cover everything we need to in the time we have. Can we please review and prioritize the agenda before we start?”

Ask for a progress check. When you see that time is getting short, ask for a process check: “I’d like to check on our progress. Its 1:50 and we still have three topics on the agenda. Can we prioritize them since we can probably only do one in 10 minutes?”

Help others participate. You can help the meeting when you help others participate. If you see a quiet person trying unsuccessfully to break into the conversation, say “I think Jennifer has something to say.” Don’t force her to speak, but make an opening if she wants to take it. You can also help when a speaker is interrupted: “I think we may have cut Josh off before he had a chance to finish. Josh?” Then Josh can finish his though if he wants to, and the interrupters will be a bit more aware of their behavior.

Rephrase. Sometimes rephrasing can help when someone is stuck on one point: “What I hear you saying is XYZ. Is that right?” Rephrasing helps people feel heard and can break the logjam.

Comment on what you observe. Sometimes it helps to comment on what you observe: “I think we’ve covered that already,” can help get people moving again.

Summarize. Summarizing important points and decisions can help the group move forward. “Here’s what I heard us agree to. Is that right?” Don’t be upset if people disagree with what you’ve said ? you’ve just turned up the fact that people really don’t have a common understanding. Once you’ve surfaced the misunderstanding, it’s more likely to be resolved before everyone leaves the room.

You may not be able to solve every meeting problem when you’re not in charge. But you can help many meetings to run more smoothly. After a while, people may start following your cues: they’ll write an agenda, pay attention to whom they invite and start attending to the interaction. And you’ll look good, too.

convert this post to pdf.

This article originally appeared in Stickyminds.com

When people
communicate face-to-face, they not only hear words and inflections, but also
see facial expressions. This helps each communicator understand what the other
is saying and gives clues to assess when people are mad, sad, or glad.
Teammates know what each other looks like; they learn about each others
families.

But it’s not always possible to have a
team working in the same room. When people aren’t co-located, you can’t just
hope that communication will work and the team will gel–that somehow,
miraculously a group in the U.S.
will hand off to a team in Hungary
without missing a beat. Some teams can achieve round-the-clock attention
through seamless hand offs, but it’s rare and takes a lot of work.

When teams aren’t collocated, they face
challenges about contact, time, context, and culture. To compensate for the
distance, extra effort is required to make contact with distant members,
leverage phone time, adjust for time zones, and learn the differences in
context and culture. Below, I’ve detailed five tactics that can help you
compensate for distance on your distributed team.

1. Make Contact
When people are in the same room, or at
least close by, they get to know each other. They develop relationships that go
beyond work-related transactions. They may not be best friends, but there’s
some social element that ties them together.

You may never get to meet your
distributed teammates in person, but you can make contact. Post a map that
shows where your far-flung team members are located. Post pictures of them. (We
tend to trust what we can see, and this little gesture can help build trust.)

When you can, share a meal together–even
if you are on different continents. Schedule a call, post the pictures, and set
the table. Breaking bread together is an ancient sign of hospitality and good
will. This simple gesture can help knit the team together.

2. Make the Most of Phone Time

There’s an old adage, “Children
should be seen but not heard.” It seems that conference calls go even
further: people who aren’t seen are often not heard. One team I work with has
pictures of every offsite team member in stand-up frames. When they have a
conference call, the frames are placed around the table to remind the people in
the room of who else is on the phone. This way they are less likely to forget
the people they can’t see.

Until everyone on the team recognizes
each other’s voice, it’s good practice to say your name each time you speak.
Yes, it feels awkward, but it really helps the people on the other end of the
phone who aren’t in the room and can’t see who is speaking. Be careful to have
one conversation at a time; a babble of voices emitted from a small, black box
is impossible for most mortals to decipher.

Appoint a facilitator for each call.
Having someone monitoring the flow of conversation and participation helps the
quality of conference calls immensely. Poll the people on the other end of the
line when it’s time to generate ideas or give input. Don’t rely on them to
break into the conversation.

Utilize wikis–Web pages that users can
edit on the fly–to build a meeting agenda and post decisions, action items,
and other meeting outcomes. My team–there are six of us in six different
states–uses a wiki to keep track of meeting outcomes and any other important
information that each of us needs to know.

Don’t use conference calls for serial status
reports. In my experience, the people who aren’t talking during these regularly
scheduled calls also aren’t listening. They’ve hit the mute button and are
probably checking their email. Save phone time for when you need to have
conversations.

3. Adjust for Time Zones
Most of the time, I can keep track of
time zones within my own country. I have a harder time minding time zones
across the world. Along with your map, try posting inexpensive clocks that show
what time it is where each group is located. The clocks remind us that the end
of our day may be the beginning of someone else’s.

Make every effort to schedule meetings in
the slice of time that overlaps “normal office hours” for as many
people on the team as feasible. When there is no overlap, don’t always expect
the “other” team to get up early or stay up late. Be willing to trade
off for the extra hours of work.

4. Understand Context
Even if you work for the same company in
different locations, you work in different organizations. Learn as much as you
can about your teammates’ work world. What is the organizational structure?
Don’t assume it’s just like yours, even in the same division. What are the
physical arrangements? Having a picture of your teammates’ physical
surroundings–their cubes, floor, and building–is another way to make distant
people more real.

Look for commonalities between your
organization and each teammate’s organization. They may share similar values,
or they may not. Knowing where there is overlap and where there isn’t helps you
manage expectations.

5. Be Sensitive to Culture
Some cultural differences are readily
apparent, while others are subtle. Watch out for words or expressions that mean
one thing in your language and something different (and possibly negative) in
another’s culture.

A Canadian friend of mine tells a story
about how he inadvertently offended half his team by offering a virtual
toast–”Cin cin!”–after a successful code release. His toast had a
completely different meaning in Japanese–one that I can’t write in this
column.

Making a distributed team work takes
extra effort, but putting all these tactics to use can help any team traverse
distance. Differences in context, culture, and organizations are magnified when
there isn’t day-to-day contact to build familiarity. Compensate for the
challenges by applying these and other practices to help your distributed team
gel.

convert this post to pdf.