©2009 Steven M. Smith, www.stevenMsmith.com

You have what you believe is an important thought to share with management. You’re concerned though that management may dislike what they hear. How do you assess how safe it is to share your thought with management?

It’s certainly perilous if management regularly scowls, aims their finger at you and fires words such as: “You have no right to correct me.” “You never do anything right.” “It’s all your fault.”

The more management copes with problems by blaming others, the less safe it is for you to share potentially sensitive information with them.

I don’t need anything to measure this danger — my body automatically feels it. But if you are someone who senses rather than feels things, note the number of times you encounter blaming by management. The larger that number, the more dangerous communication is with them.

Gauging Safety

Let’s use the following three categories to gauge environmental safety:

Secure (zero blame) when you share your thoughts with management.

Risky (blame is possible) when you carelessly share your thoughts with management.

Perilous (blame is highly likely) when you share anything that doesn’t support the party line.

Framing Your Thought

Let’s explore how the safety categorizes can be used to frame your message so that you minimize the risk of being harmed by sharing your thoughts with management.

Secure — Complaint with Recommendation

I relish working in secure environments. I can speak my truth without fear of recrimination. But if my thinking is scattered, management may label me as someone who doesn’t think things through. That label will limit both my access to management and my opportunities for advancement.

Rather than merely making a complaint as many people do in secure environments, show management your thoughtfulness by framing your communication as a complaint with recommendation.

Let’s investigate an example: As a developer, you notice that clients are bypassing the sustaining organization and going directly to people in product development for fixes to problems. Management tells you that fixing these problems is important. You experience a decline in your productivity as you divert time to conversing with these clients and fixing their problems. You notice your colleagues are experiencing the same effects. Furthermore, the development organization failed to deliver three critical features it had promised in the last product release.

You could merely complain to management by saying, “Those damn clients are circumventing our sustaining organization and chewing up my time.” What is management supposed to do with that? They can’t read your mind. Unless they have already have thought through the dynamics, they aren’t going to know what to do. You have burdened them with yet another problem.

Let’s frame the same information differently — “I believe a key element of our failure to deliver scheduled features in our least release was caused by clients circumventing our sustaining organization and bringing their problems directly to us (the developers). I recommend that we disable this direct access and return clients to escalating their problems only through the sustaining organization.”

You’ve registered a problem with management but, just as importantly, you have provided them an action they can take to solve the problem.

Management in secure environments appreciate people who make complaints with recommendations. They label them as people who think things through. That’s how I want to be labeled. I suspect that’s how you want to be labeled.

Risky — Puzzle

Let’s look at how that same information might be framed in a risky environment where your uncertain about whether it’s safe to speak your mind. A complaint with recommendation may expose you to danger in a risky environment, instead frame your thought as a puzzle.

For instance, “I am puzzled about whether there is a relationship between our clients going directly to product development for fixes rather than working with our sustaining organization and our inability to ship all the scheduled features in our last release.”

That statement is neither a complaint, conclusion, nor recommendation. You’ve suggested that there may be a relationship, but you aren’t sure. The puzzle is open for discussion, data exploration, and interpretation. If management probes, you can choose to provide more information and you can can help them reach a conclusion and solution. Otherwise, you can let the puzzle go knowing that the timing was wrong for that conversation.

Timing is critical for management to recognize things in risky environments. Puzzles offer the possibility for you to safely offer the opportunity for management to become aware of a situation. Puzzles also help you probe for whether the timing is right for communication with management on that topic.

Perilous — Silence

How do you frame that same information in a perilous environment? You don’t.

Maintain your silence. Perilous means sharing any thought that deviates from the party line will expose you to harm. It would be masochistic to share potentially sensitive information with management. If you need a catharsis, talk with a colleague or someone outside the organization.

Keep your mouth shut, hope for an organizational change, and look for a new job.

Final Thoughts

I like sharing my thoughts with management. They are my partners in producing the desired organizational results.

I am depressed by my recommendation that you keep your mouth shut in a perilous environment. I suppose that’s why I don’t always follow my own recommendation. But I recognize that 95% of my attempts were ineffectual and harmed me. What’s your experience communicating in perilous environments? What tips will you share with me?

I am uplifted by recognizing that solidly framed communication in secure and risky environments will increase the chances of management respecting people’s thoughts. In my experience, puzzles and complaint with recommendation are powerful frames for communicating with management.

I believe in accepting the environment as it is now rather than how I would like it to be. If I’m hiking in the desert, I carefully monitor and consume my water so that I survive. Organizational environments can be like deserts. You are wise to carefully construct and share your thoughts. Your organizational survival and growth depend on it.

Wishing for you encounters with management where you see the palms of their hands rather than the tip of their index finger.

convert this post to pdf.

Virginia Satir developed this method for discovering a group’s temperature — what we in technology often call the system’s state.

A facilitator leads the discovery. He or she keeps the group focused on each agenda item; works with the group members to help them communicate information congruently; and publicly displays each contribution so the group can review the temperature data throughout the meeting.

The temperature reading consists of five items in the following sequence: 1) Appreciations, 2) New Information, 3) Puzzles, 4) Complaint with Recommendation, 5) Hopes and Wishes.

Appreciations (past)

The first item focuses the group on the positive aspects of past experiences between the members of the group.

A model for an appreciation is -

“________ (person’s name), I appreciate you for ________ (doing some specific thing).”

For example, “Don, I appreciate you for creating the annotated bibliography in the handout about personality types. It’s cool and I feel it increases the value of our handout.”

Amplify the power of an appreciation by standing face-to-face with the recipient and looking into their eyes while appreciating them.

New Information (now)

Group members may learn, within minutes of a temperature reading, news that will affect how the group sees itself . This agenda item provides an opportunity to share news so everyone has the most up to date information, which may eliminate someone’s puzzle or complaint, which prevents needless processing of them in the next two agenda items.

For instance, “Food will be served at the banquet tonight (Sunday) from 7:30?9:30pm. That time is later than previous years.”

This item is also an opportunity to alert the group to foreseeable interruptions. For instance, “My father is in the hospital and I’m expecting a call from the doctor to update me on his status. When the doctor calls, I’ll step out of the meeting for a few minutes to take his call. My (meeting) buddy will update me on what transpired while I was gone.”

Puzzles (now)

This agenda item is an opportunity to share something that is puzzling a member; for instance, “I’m puzzled about whether I’ll be charged for using the Internet connection in my room.” Note, you won’t be charged; Internet usage is complimentary for the people who registered in the AYE block.”

The facilitator is responsible for preventing people from using a puzzle as a vehicle to make a complaint. Complaints are the subject of the next agenda item so the facilitator will ask an individual whose puzzle sounds like a complain to restate it during the next agenda item.

Complaint with Recommendation (now)

After puzzles are noted, the next agenda item is an opportunity to share a complaint and make a recommendation for eliminating the complaint. A recommendations is vital for preventing other members from feeling burdened to solve the complaint so — carefully note — complaints without recommendations are NOT allowed.

For instance, during last year’s tutorial, a tutorial participant said, “I won’t be able to remember the specifics about each agenda item in the temperature reading. I recommend that you provide more information about each item in the handout.”

Hopes and Wishes (future)

An opportunity for members to share with each other what they would like to have happen in the future. For instance, “I hope the members of my triad stay in touch throughout the conference.”

Final Thoughts

A temperature reading is about uncovering the state of a group: It isn’t about solving a puzzle or deciding whether to accept a recommendation. Use those discoveries to schedule separate meetings to solve problems and make decisions.

The success of this method depends on how safe members feel about sharing information. The safer people feel, the richer and deeper the information they will provide. Part of the facilitator’s role is to foster a safe environment where members feel safe to share what they know and how they feel.

I advise against altering the sequence of the agenda items. The sequence is carefully designed to move the group from past to present to future.

I prefer a rapid fire method for gathering people’s contribution so the reading is completed in 25?35 minutes.

I typically ask people to raise their hand if they have a contribution; create a stack of contributors; and process each person’s contribution. Processing name stacks enables me to keep the meeting within the expected duration. How? I monitor the time carefully and if we are consuming it too rapidly, I stop at the end of a name stack and move to the next agenda item.

Regardless of the methods used to collect the information, I believe you will find that a temperature reading is an effective method for revealing the state of a group to its members.

convert this post to pdf.

(c)2007 Steven M. Smith

“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 [email protected].

convert this post to pdf.

(c)2008 Steven M. Smith

A smile formed on Eleanor’s face as she saw me approach her doorway.

She and I were meeting to discuss her views on recognizing and rewarding employees. She had been my manager for three years when I worked as a developer. A skillful manager, her recognition and rewards had brought out the best in me and my teammates.

I am now a manager in the testing organization. Although I recognize and reward the members of my team as best I can, I know that Eleanor’s recognition and rewards are more effective than mine. I knew what she did, but I knew little about the thought process behind her actions.

I wanted to learn about the thoughts that shaped her actions, because I suspected they could help me.

As I entered, Eleanor moved around her desk, extended her hand, and said, “Trevor, it’s great to see you. How is Ginny’s first semester at the U going?”

Typical Eleanor. Although we hadn’t talked in months, she remembered that my daughter Ginny had started at the university two months ago. How did she remember details like that?

“She’s doing well,” I answered, reaching out to shake her hand. “Although I think she may be a little homesick. Thank you for asking.”

“Sit down,” Eleanor said, motioning to a chair that I had sat in many times. She moved to the other side of the small, circular conference table and sat down.

“How can I help?” she asked.

“I want to learn the secrets you use to recognize and reward employees,” I replied.

“Secrets?” Eleanor’s forehead crinkled as she started to laugh. “I don’t have any secrets.”

“Your methods may not seem like a secret to you,” I said, returning her laughter, “but I don’t see any other managers rewarding the members of their teams as effectively as you. For instance, I recall your giving Fredericko soccer tickets as a reward for the work he did on the Tahoma project. He told me how thrilled he was to receive them. Other managers give their people trinkets, such as pens and USB flash drives.”

“Oh, I hope taking the time to know people well enough to reward them with something that will please them isn’t a secret,” she said. But you’re right. Some managers do reward people with trinkets. I don’t believe in that.”

I probed, “Why?”

She looked up for a few seconds, then slowly leveled her eyes with mine and said, “I suppose my behavior follows directly from a story my mentor told me years ago about a reward he received. At the banquet for the program he led, his manager gave him a gold watch.”

“A gold watch sounds like a great reward to me.”

“It did to me, too,” Eleanor said slowly. But it turns out my mentor is allergic to metal. It causes him to break out in hives. Although he never said anything to his manager, he told me he felt insulted by being given something that he could never use. He thought his manager should have known him well enough to give him something he would enjoy.

“The look of hurt on my mentor’s face still drives me to this day to learn enough about each member of my team to know the rewards that would please them.”

Eleanor continued, “You may be surprised, though, to find out that some people tell me that they don’t like receiving awards. They feel like they’re being bribed.”

“What do you do for them?” I asked.

Eleanor leaned back in her chair and said, “I explain to them that receiving a reward is part of a bigger process.”

“What do you mean by that?” I sputtered, caught off guard.

“When I give an award to someone at a big event, it exposes that person and his work to other members of the organization. And that exposure leads directly to more opportunities in the organization for him.”

“Those rewards you gave me did bring me opportunities. No question about it.” I said.

“I haven’t had anyone insist he didn’t want an award after my explanation. But if anyone ever does, I won’t force him to accept an award. I’ll find another way to communicate his value and the value of his work to the other members of the organization.”

“Are there other questions I should be asking about rewards?” I asked.

Eleanor looked up and didn’t say anything for a few seconds.

“I can’t think of anything.”

“Then tell me your thoughts on recognition,” I said.

“I invest significant energy recognizing things that team members do to help the team be more effective. The essence of what I do is what my mentor called ‘Catch Them Doing It Right.’”

“What did he mean by that?”

“He believed that the behavior of people in organizations is shaped by every organizational action and, just as importantly, every organizational inaction. He thought of recognition both as feedback and as action. He coached me to provide immediate feedback to employees when I caught them doing something right. And he also taught me how to leverage other team members to provide similar feedback.”

“Whoa!” I said. “I remember we had a segment in status meetings where we appreciated people for something specific they had done that helped us. You said it was something you learned from a famous family therapist. That’s recognition?”

“You got it,” Eleanor said. “The part of recognition that’s the most overlooked is providing the feedback as close as possible to when the behavior happens.”

“What else should I be asking you about recognition?” I asked.

“You should be asking me why it’s important to recognize a behavior as soon as possible.”

“You’re right. That’s exactly what I should be asking. Please tell me why.”

Eleanor’s eyes sparkled as she said, “It’s to increase the chances that the behavior is repeated by that member. Then the other members who hear the recognition consider exhibiting similar behavior. I like to think of it as planting the seeds of effective behaviors.”

“Is there anything else should I be asking you about recognition?”

She smiled. “I can’t think of anything. And now is a good stopping point because I have another meeting in five minutes. Did the discussion help you?”

“Yes, I got more help than I expected. Thanks for your help, Eleanor. Would it be alright if I sent you an email outlining my understanding?”

“Of course, I would like that. And please let Deanna know that I appreciate her for the coaching she gave Sanjay today on putting automated unit tests in his code. That’s going to pay dividends in speed and quality as we go through the development of the new product. Normally I would send her an email, but I think it would be more powerful coming from you,” she said with a wink.

convert this post to pdf.

© 1996 Jean McLendon and Gerald M. Weinberg, www.satir.org and www.geraldmweinberg.com

“England, though at present enjoying a very high state of prosperity, still shows some symptoms of a decaying nation. Propose to an Englishman any principle, or any instrument, however admirable, and you will observe that the whole effort of the English mind is directed to finding a difficulty, a defect, or an impossibility in it. If you speak to him of a machine for peeling a potato, he will pronounce it impossible; if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple. Import the same principle or show the same machine to an American, or to one of our colonists, and you will observe that the whole effort of his mind is to find some new application of the principle, some new use for the instrument.” — Charles Babbage, 1852

As early as 1852, Charles Babbage could see symptoms of decay and infer from them a vision of future performance. In so doing he provides a perfect description of the blaming style of communication, which emerges in ‘decaying’ organizations-be they nations or software engineering organizations. What is a “blaming style of communication,” and why is it important in systems development?

What Is Congruence?

Congruence is a concept that describes the human experience of alignment between the internal and external-what is thought and felt (the internal), and what is said and how it is said (the external).

In order to operate congruently in the world, you need to take into account three general factors: self (the internal world), other (the immediate external world of people), and context (the larger external world of things, structures, processes, laws, and cultures).

• Self: You must consider your own needs and capabilities. Suppose you are a manager who doesn’t trust anyone else’s judgment, so you try to attend every technical meeting. Doing this, you’re likely to overload all your available time, and then be unable to do the managerial job, nor to make real technical contributions in any case.
• Other: You must consider the needs and capabilities of other people. For instance, if you are a programmer who refuses to be bothered to write readable code, then testing and maintenance of your code will be a great burden, if not an impossibility.
• Context: You must consider the reality of the context in which you are operating. For instance, if you are a manager who insists on sticking with an old design that no longer has the capacity to handle the task, your project may be doomed no matter how hard everyone works. Or, if you are a manager in a start-up company and spend money as if the company had a billion-dollar cash balance, your organization may be out of business before its software product is ready for market.

Congruence is integrity at the most basic level and thus has immense value to a project and each individual in it. Without integrity, we cannot build trust; without trust, we don’t feel safe; without safety we have a hard time being congruent. Thus, congruence reinforces congruence in a powerful loop which improves the chances of producing a quality product, on time, and within budget.

On the other hand, the same loop causes incongruence to reinforce incongruence. If a project is allowed to ride such a downward spiral, the integrity of information is destroyed. Soon it becomes impossible for anyone to know what is really happening. Such projects invariably fail, and when they fail, they are invariably found to have been keeping two sets of “books.” Their external picture is not congruent with their internal picture, and they die. Or worse yet, live forever-the living dead.

If congruence is so important for project success, why aren’t all projects congruent? One reason is that congruence is not without a price. Another is that congruence usually involves risk. The level of risk is somewhat contingent on the kind of congruence being demonstrated-mental or emotional.

Mental congruence

In the United States, it’s relatively easy to express our thoughts with out too much incrimination-freedom of speech was a foundation upon which the country was built. Even so, there may be a price to pay for “speaking up.” For example, differing with a colleague or someone in authority at the wrong time can put us on a fast track to isolation, reprimands, reduced opportunities, and subtle door closings. Thus, we’ve all learned the importance of being careful about what we say where and to whom. Saying the wrong thing can lead to heated debates, followed by proclamations of who is right or wrong and who is good or bad. At that point, we’ve lost most possibilities for enhanced understanding and effective communication.

Emotional congruence

In our culture, feelings are reserved for athletic events, celebrations, funerals, near death experiences, deeply felt spiritual experiences, fights, and exchanges between intimate others, the very young and the very old. We even have many feelings about our feelings and some of the strongest have to do with shame and embarrassment over having them. Feelings are personal and lie close to our heart, where we are tender and vulnerable. No wonder we have all become so skilled at denying our feelings-which necessarily makes us incongruent.

Suppose you are a developer who is scared that you won’t be able to deliver a product when you promised. You try to tell your manager about your fear, but he tells you in no uncertain terms what will happen to you if you don’t express more confidence. “Why are you so negative? Aren’t you a team player?” One way to protect yourself from such negative responses is to live in your head. Perhaps you say, -”It’s just an estimate; I’m not attached to it,” meaning you won’t be hurt because you’ve distanced yourself sufficiently to ward off anything that might hint at rejection. But, though you deny your scared feeling to your manager, you still feel it, squashed down inside. You can stand back away from your ideas, but you always remain standing in your feelings. And, of course, you have been incongruent, and deprived your manager of your best information.

When you share your feelings, your heart-self is being presented to the outer world-exposed to the elements. When you’re scared and express your fear while maintaining consideration for the other person (your manager) and the context (the project), you are being congruent. Your critical issue here is, “Can I share my feelings and still be in control?” If the environment of your project is blaming, it threatens to remove your control if you tell the truth-so the temptation to lie about your feelings and your ideas increases. That’s why blaming cultures lead to “double books,” and that’s how they lead to failure.

What is Blaming?

In a congruent organization, your manager asks, “Where does your project stand?” and you answer, “I’m rather scared that I’m not going to make my schedule.” This starts a problem-solving discussion, out of which the two of you make new plans to get the project back on track. In a blaming organization, however, your manager may well tell you that only inferior people lack confidence. In that case, problem-solving will be replaced by blame-avoidance.

From a writer’s point of view, congruent interactions aren’t very dramatic; people just act sensibly, are considerate of one another, get their work done, and enjoy what they’re doing. That kind of behavior might not make as good a soap opera scene as your manager throwing a tantrum and you cringing in the corner, but it definitely makes a better project.

Not that a blaming culture conducts every interaction in a dramatic, blaming way. Under ordinary circumstances, congruent coping is the rule, but if circumstances were always ordinary, we wouldn’t need managers. When feelings of self-esteem are low, they are manifest much more dramatically in characteristic incongruent coping styles: blaming, placating, being superreasonable, loving or hating, and acting irrelevant. We can’t deal with all of these in a short article¹ , so let’s discuss blaming, perhaps the most common and most directly destructive of the coping styles.

Under stress, people tend to lose their balance, and one or more of these three essential components may be ignored, leading to a characteristic incongruent coping style. For example, when people fail to take other people into account, they fall into a blaming posture. Here is a typical blaming action you may see in software organizations (italicized words are stressed in this style of speaking-because multiple stressed words in a sentence are a linguistic sign of blaming²):

Manager, as programmer arrives late for a meeting: “You’re always late. You never show any consideration for other people.”

Why is this incongruent? If the manager really is feeling and thinking that the programmer is always late and inconsiderate, isn’t she being congruent by saying so? Yes, but that isn’t what this manager said. She didn’t say, “It’s my impression that you’re always late to my meetings.” Instead, she pronounced her impression of lateness as if it were a scientific fact, never offering the possibility that the programmer might have a different impression. She generalized experience in her meetings as if they necessarily applied to all meetings, never allowing for the possibility that her experience might not be the only one that counts.

If the manager really is feeling and thinking that the programmer is always late and inconsiderate, she might say, “I think that you’re always late, and I feel that you’re not being considerate of me and the others. Is this your perception, too?” (And leave out the stressed words.) Even better management style would be to give the programmer a chance to provide a different perception before launching into interpretation. At the very least, that prevents embarrassment in situations such as the following:

Manager, as programmer arrives late for a meeting: “It seems to me that you’re always late. Is this your perception, too?”

Programmer: “Yes, and I feel bad about it. The reason I’m always late is that I have to donate blood for my 9-year-old son, who’s dying of leukemia, and the only time they take donations is just before this meeting.”

Manager: “I’m sorry about your son. I didn’t know about it. Let’s figure out a new meeting schedule so you don’t have to be late.”

More generally, it allows for the possibility that there may be other considerations that count besides those of this one manager. For example, perhaps the programmer is coming from a meeting with customers-a regularly scheduled meeting which overlaps the manager’s meeting.

But what if the programmer really is always late, with no reasonable explanation? Isn’t the manager then entitled to blame the programmer? Not really, because this situation is not about entitlement, but about getting the project done. For that purpose, the problem is most effectively resolved using a non-blaming confrontation with the facts about the unacceptable behavior. By foregoing blaming, the manager keeps the communication clear and open, maximizing the chance that the programmer will receive the intended message. And, of course, receiving the intended message maximizes the chance (though it doesn’t guarantee) that the problem will be solved.

When blaming, problem-solving is less likely because the facts of the case become a minor issue-the major issue in blaming is “who is important and who is insignificant.” When blaming, a person is saying, in effect, “I am everything, you are nothing.” Of course, this stance comes not from really thinking “I am everything,” but just the opposite. Directing the attention at another person-and blaming is often accompanied by a pointed finger-is a self-protective device to distract others from the inadequacy the blamer feels.

Like all incongruent coping, blaming is reinforced by feelings of low self-esteem. When you blame, you attempt to build yourself up by tearing down others because you don’t have the confidence that you can amount to much-or even survive-any other way.

Blaming usually fools people who are unsophisticated, or whose own self-esteem is at a low ebb. The knowledgeable observer, however, sees the amount of blaming as a sure measure of how inadequate the blamer feels. Moreover, if blaming is the preferred project communication style, then it becomes a measure of how far an environment has degenerated-how little communication is being directed at the project’s issues, compared to the amount that is being directed to puffing up the communicator’s weak self-esteem.

In a blaming organization, it’s not merely the managers who blame, as illustrated by these examples:

Programmer, when asked by a manager to volunteer to talk to a job applicant: ‘Why don’t you do it yourself? I’m not going to do your job for you. If you were better organized, you wouldn’t need to ask me such things.”

Customer, when project manager asks about the possibility of revising the requirements: “You never get the requirements right the first time. If I told you once, I told you a thousand times: Do the job right the first time, then you won’t bother me with revisions.”

(To test your understanding of the blaming style of communication, you might try to improve the congruence of these examples.)

How Blaming Hurts A Project

Of course, people are not perfect, so it’s impossible to conduct a large project without occasions on which people cope incongruently. Normal project management can deal with these situations-when they are exceptional. But when the whole environment encourages blame, each new situation further elaborates the incongruence. Fred Brooks³ once asked, “How does a one-year project get to be two years late?” His answer was “one day at a time.” Our answer is “one incongruent communication at a time,” as the following example illustrates:

One of the developers was developing a module that produced a printed report when it was tested. The manager put a lot of pressure on the developer to be ready on time, with no excuses allowed. The programmer produced the report, and the manager was pleased (though he didn’t show it, of course-it was “just an expected part of the job” in this blaming culture).

A month later, other people tried to use this module and discovered that it was not finished after all. The developer had used a word-processor to produce a fake report that looked just like a correct test report should look. He thought this would buy him time (it was a month, after all,until anybody found out) to finish the module. Unfortunately, since he was in over his head, a month wasn’t enough time.

The manager blamed the programmer. The programmer said nothing, because in this culture of blame, saying something only brought further streams of blame down on your head. The person who reported this incident said that in this organization, failure is not allowed under any circumstances. People who have problems in a project and can foresee slippage are unable to cry HELP! and receive appropriate assistance. According to the managers, each programmer is responsible for meeting the deadlines that the programmer agreed to. Inaccurate estimation is “not allowed” and perfection is to be achieved from day one-otherwise you are put in the pillory of blame. In this situation, fake test reports are the rule, not the exception.

Blaming is the dark secret underlying the failure of many projects. A blaming culture hurts a project in at least six major ways:

1. People commit to plans they know they cannot achieve, at least to delay blame.
2. People hide facts that managers need to control the project, as in the above example.
3. When problems are finally revealed, people avoid coming forth with creative solution ideas, for fear they will be blamed if the ideas don’t work, or simply appear dumb at first glance.
4. In day-to-day operations, a major portion of everyone’s effort is devoted to positioning themselves so they will not be accused when the time of reckoning arrives.
5. Those people who somehow feel safe enough to focus on the job at hand find themselves spending large amounts of time checking up on the reliability of others’ communications.
6. People feel bad most of the time, and spend a lot of time fiddling with unproductive tasks or simply staring at the walls.

What Incongruence Looks and Feels Like

Organizations can be changed from a culture of blame to a culture of congruence. To make this change, the first step is measurement, or at least detection-but how to measure blaming? Actually, an experienced consultant can detect a blaming organization within a few minutes of contact, because symptoms are everywhere. Indeed, people within the organization already know it’s a blaming culture-but of course within a blaming culture, blame is undiscussable, and moreover, the undiscussability is also undiscussable.⁴ Paradoxically, the existence of undiscussability makes blaming easy to detect. The manager of one project issued a memo saying that there would be no more discussion of project morale, and that he would entertain no questions on the subject because everyone should be grateful to be working on such a terrific project. This could happen only in a blaming organization.

Executives

A culture of blame usually starts at the top. Members of the top level of management are inclined to see the other people in the organizatation as the source of all problems. The employees are seen as “ungrateful” for the jobs, pay, benefits, and opportunities management has bestowed on them. They are seen to “lack an appropriate work ethic,” “not know the value of a dollar,” “have authority problems,” and “resist change.” These perceptions leave upper management in a predicament: “Do I fire them, or do I fire the people who hired them?”

Such managers feel that they are trying to realize a vision without getting the necessary support, which leaves them out on a limb. The internal kinesthetic experience of these executives is normally a dull and chronic headache-unless the profit margin is really down. In that case, they have more acute feelings, like pain in the chest and burning in the gut. Their low self esteem reflects outwardly in the form of frequent downsizing, re-engineering, avoiding serious problems, futile memos, and, of course, humiliating of subordinates. Towards themselves, they often practice addictive and self-destructive behaviors (which cannot be discussed, but are alway the subject of gossip).

Middle Management

When the top leadership is incongruent, middle managers constantly receive mixed messages. Project managers are told of their importance, then find that their seniors have bypassed them to intervene directly in projects or change the rules without consulting them. They feel as if they are living on a roller coaster-unable to predict whether a particular day or week will be an upper or downer. After being publicly humiliated a few times, they decide their best strategy is to try to stay out of trouble by not ever rocking the boat. Even though they cannot perform at their best, they try to appear important and extremely useful.

In the blaming organization, top managers try (perhaps unconsciously) to teach their middle managers their own blaming attitudes. When one project manager complained of her inability to get the developers to work faster, the Vice-President of Development said, “If your dog won’t jump high enough, get a bigger stick to beat it with.” Living in hail of such incongruence from above, middle managers’ survival issues stay close to the surface. As they did when they were children, they figure out how to either appease, please, or avoid the power owners. By so doing they insure their survival-and pass the blame on to lower levels.

Employees

At the bottom rung of a blaming organization, employees are usually looking for someplace else to work unless the company is in a stable condition with little competition-or if their retirement is within view. The way to survive is to hide out and appear only to pick up a regular pay check.

Employees are discouraged from thinking creatively-new ideas are interpreted as blaming the management or attempting to usurp their power and prerogatives. Employees are not rewarded for industriousness-but they are frequently punished for perceived “laziness.” Employees cannot seem to find their managers-except when there are problems. Then, the major efforts are directed as attaching blame rather than solving the problem at hand.

The style of blaming varies from organization to organization. It can be harsh, vindictive, direct or indirect-but it is always contagious. Some organizations have polished their blaming style to a high degree of subtlety-without raised voices, merely by a look, or a memo, or an e-mail message, or a phone call, or a visit if things are really bad. In other organizations, the blame is loud, angry, and frequently done in front of an audience of peers-ensuring that all get the message of who is right, who is good, who is in charge, and who should become invisible.

In such an environment, defensiveness becomes pervasive. To those without formal power and authority, it seems that those with power really don’t care about them-and would banish them with no feeling at all. Thus they feel justified in retaliating (in advance, and in secret), and in avoiding their managers and their problems.

Regardless of the style, blaming from the top always generates fear, malaise, errors, accidents, and passive-aggressive responses from the bottom. Those on the bottom feel small and act from a place of powerlessness. The lack of emotional safety effectively erodes the trust level and makes any attempt at congruence extremely risky. This envirorunent sounds awful and it is-both for the person who has regressed into emotional immaturity and, sadly, for the person at the top who is doing the blaming.

Those on the bottom of any large organization can easily come to feel a sense of dependency on those above them in the hierarchy. When blaming is the primary mode of dealing with people, this dependency is exacerbated. Then, out of a feeling of dependency, people easily generate a feeling of hostility. As this hostility grows so does the debilitating experience of shame-that overly critical judge that lies latent in all humans.

What Congruence Would Look/Feel Like

Most people who have experienced a congruent organization won’t tolerate the misery of working in a blaming organization. But many people haven’t ever had that experience, and have a hard time believing what a congruent organization is really like. Let’s look at what would happen if a healthy dose of congruence could be magically applied on a large scale to an incongruent project organization.

Executives

If we could magically install congruence in the internal programs of those blaming executives, their style would shift dramatically. For example, if they would truly consider the others involved in their communication, they would be more likely to believe in the intent of people to contribute, to be productive, to belong, and to learn-and would take deviations from this ideal as evidence of ineffective management. Their belief in the inherent value of all people along with a healthy respect for the constraints of the work context would engender energy, hope, appreciation, understanding, and gratitude among their employees.

An executive who truly does not believe in the good intentions of the employees will be likely to say, ‘No excuses! You will get this done on October First.” But, with employees whose intentions are bad, this style (or any other style) isn’t really going to work.

A congruent executive who truly does believe in the good intentions of the employees will be likely to say, “We need this badly by October First. What do you need from us to help get it?” This kind of mutuality and support enlivens a genuine “can do” feeling that increases the chance that a project meets its goals-and that nobody has to make false promises to escape abusive blaming.

When the top level managers sustain their commitment to congruence, they see that most workers appreciate the opportunity the business provides them in developing skills, meaning, relationships, and monetary rewards. They also know how to cope when the occasional worker doesn’t seem appreciative or even productive. Managers who know how to use their power congruently generally get the results they seek-not perfection, which they know not to expect.

These leaders know they have a special kind of power-power they use with awareness and sensitivity. They do not resist accountability to those they lead, but demonstrate the same level of integrity they seek from others. And if they cannot match the levels of commitment they request from others, they are open about that. They know they are sometimes going to be weak and vulnerable and need support-perhaps even to see the value of their own visions. They use their awareness of this human reality to nurture their capacity to empathize and to have compassion for themselves and others.

Congruent executives know that their principal job is developing their organization’s capability, not just pushing the same old shoddy products and services out the door. They involve themselves seriously in organizational improvement efforts while simultaneously involving others in the organization to ground these efforts in real-life, practical operational input and decision making. They know that synergy is needed for organizational development, and they know that synergy comes from high quality connections among people-regardless of level.

Middle Management

When the top folks begin to operate from congruence, the middle managers receive direct, clear messages-not mixed messages with double meanings. Communications are more open, making it is easier to know more about what’s really going on. Given higher quality information, they know more about how to be useful, so they can more easily join their leaders in their visions. Knowing more clearly the strategic directions desired and feeling that they count in this process frees them to contribute more generously and thoughtfully-rather than merely playing safe. Success becomes a goal that all can share.

Given their unique vantage points, middle people have useful input to assist in predicting problems, projecting realistic time lines, and forecasting trends. What they see, hear, think and feel is valued, and they are in a position to initiate behaviors that prevent project weaknesses from growing into project failure. They know the necessity of interdependence, so if major problems do develop, they can be counted on to provide-and seek-truthful information. They are not ashamed or afraid to work for those who employ them. Indeed, they have pride about their commitment to the organization-and know it is a commitment not so much as to schedules and budgets, but to the truth about schedules and budgets.

Because congruence at the top trickles down, middle managers take notice of the difference in their leaders. They respond to the modeling by passing it on to their constituencies. Everyone in the organization knows what is at stake in doing each job well, so everyone feels safe to tell what is wrong, what is getting in the way, and what is needed to fix it. Honest reporting of facts and feelings is genuinely appreciated, and do not put people at risk of being humiliated or losing their jobs. That’s why congruent organizations deliver their projects as promised.

Congruent middle managers encourage high quality communication. Their belief in people’s ability to learn and change towards more congruence make those around them responsive. With congruence radiating from the center of the organization, everyone can have a place, position, and function of importance and value-so things get done, and done right.

Employees

Working at the front line of a business where the top leadership is congruent, is entirely a different experience from working in a blaming organization. Commitment and energy are the norm, not the exception practiced by new employees until they “learn the way things are around here.”

Congruent organizations hold to an ideology that doing well in the marketplace is connected to doing well with employees as well as with customers. The perspective of the leadership includes a global consciousness about the existence of multiple non-linear factors, the importance of connections among all the various parts of the whole, and the necessity of all parts knowing their value. Workers feel that this is a company going somewhere, where growth is a natural state and everyones’ efforts count.

Workers in a congruent organization tend to have a long range view and can usually maneuver as needed to meet the changing needs of clients and customers. Employees trust that what they see and hear is real. They share in the enthusiasm of creating a future. They may not like everything that happens-for instance, they don’t always feel that they are rewarded adequately for what they give-but they don’t feel that there is a chronic pattern of undercutting, diminishing, discrediting, and devaluing them and what they do. They can risk congruence knowing that it will act as a catalyst for optimizing successful outcomes that benefit everyone.

Congruence is the bright secret underlying the success of many projects. A congruent culture helps a project in at least six major ways:

1. People commit to plans they know only after open negotiation, so plans are more likely to be realistic in the first place.
2. People come forth readily with facts that managers need to control the project, as soon as they are known, so managers can act early and act small to correct the problems.
3. When problems are revealed, people readily come forth with creative solution ideas, increasing the chances for quick and effective solutions.
4. A major portion of everyone’s effort is devoted to getting their jobs done, and helping other get their jobs done.
5. Because human fallibility is considered normal, an appropriate-but small-amount of time is spent assuring the reliability of communications.
6. People feel good most of the time, and thus are productive most of the time.

Congruence in Large Systems Development Efforts

In the course of developing systems, people engage in numerous acts of communication-about requirements, schedules, interpersonal problems, designs, progress, and just about anything else. That’s why effective individual communication is important in all projects, large and small. That being said, effective communication becomes even more important as the size of the development effort grows. The number of necessary communications goes up non-linearly with the size of the project, so the effect of imperfect communication style is magnified. Thus, if the quality of individual communications remains fixed while the project grows, the overall quality of communication will go down.

For instance, a certain level of congruent communication might be adequate for a producing a product with 25,000 lines of code, yet be totally unacceptable for a product with 2,500,000 lines of code. In order to develop larger and/or more complex systems, then, it’s not sufficient to pay attention to technical issues-accepting that the existing communication style will be adequate. Managers must also improve the project’s communication culture, and thus they must pay more attention to congruence.

To make matters worse, unless we manage well, tougher projects tend to dimish congruence-because stress tends to rise when the expectation of quality rises. We are not always utterly logical creatures, but have feelings as well as thoughts in response to tougher assignments. When these inner feelings are strong enough, they translate into characteristic styles of coping with the stress. If our characteristic style is incongruent, communications become less effective and the job becomes even more difficult, creating a viscious cycle.⁵

Congruence, of course, is but one of the factors in effective communication-other factors include such things as timeliness, memory, proper audience, and accuracy of data. But without congruence, your efforts to improve these more “logical” factors will always be seriously undermined, along with your ability to build bigger, more complex, or more reliable systems.

Achieving Congruence

When Deming said, “Drive fear out of the workplace,” we think he was talking about changing the blaming organization to the congruent organization. This kind of change is made by one person at a time-hopefully starting at the top-and one step at a time. The steps can be broken down into six ‘A’s’, as follows: Awareness, Acceptance, Authorship, Articulation, Application, Activism. Let’s look at how each of these steps takes place in the context of an individual trying to change a blaming organization.

Awareness

Awareness says, “This is happening. This is real.” Awareness comes from experience, when I allow myself to experience the world around me as it is-not as it is supposed to be, or I wish it to be, or someone else tells me they want it to be.

Awareness is always the first step, and probably the hardest, because generally we’re not aware that we’re not aware. Here’s a personal example of how lack of awareness stops the change process before it can even start:

Jerry was attending a project meeting in a software company-a meeting called by the company President to find out what was going on in a late project, After some coaxing, one of the developers said that she was afraid to go to Nat, the Development Manager, with problems, because of the reception she got. Nat got red in the face, stood up, and shouted angrily, “How can you say that? My door is always open to hear your problems! The only thing I won’t tolerate is if you’re all emotional when you come, or if you don’t have a proposed solution!”

In the calmest voice he could manage (it’s hard to stay calm when someone is being so angry, even if it’s not directed at you), Jerry turned to the President and asked if Nat ever came to him with problems. When the President said yes, Jerry asked if the Nat was always calm and carrying a proposed solution. Before the President could answer, Nat interrupted: ‘Why would I come with a problem if it wasn’t important enough to get excited about? And, if I had a solution, why would I come to him?”

Although it was now clear to everyone else in the room that Nat was demanding that others “do as I say, not as I do,’ he was unable to see the incongruence. Lacking awareness, there was no way Nat was going to change-and indeed he never did change, up to the time the President released him to seek greener pastures.

Nat’s case is quite typical. Since incongruence is a defense, incongruent people erect all kinds of shields that close off information about congruence. Their own incongruence, and that of others, is invisible-it is accepted, especially if it is the norm in the organization. This invisibility makes it very hard to reach them with any kind of information on the subject.

In other words, when you’re being incongruent, you’re losing your ability to take in what’s going on in the world (inner or outer). So, you don’t know that you need changing. And, even if you did, you haven’t a clue what to change to. No wonder it is so difficult to transform an incongruent culture, when the very first step-awareness-is so hard to come by.

Awareness comes from experience, when you allow yourself to experience the world around you as it is-not as it is supposed to be, or you wish it to be, or someone else tells you they want it to be. But in the blaming organization, where people shield themselves from experience, becoming aware usually requires help. Helping others become aware takes the skill to develop safe environments and to build relationships. It takes the patience and caring to watch for signs of awareness and help build on them. It also takes a belief and a commitment that “part of my job is to help the people on my team to develop- the most important part.” If you don’t believe this, then certainly don’t try to help people become aware. Otherwise, you’ll find yourself saying, “You aren’t aware of what a lousy employee you are, but I’m going to make you be aware!”

But awareness of the overall situation is not sufficient-you also need self-awareness. Self-awareness says, “This is me. This is mine.” You may be fully aware of the blaming, but as long as you merely say, “This is a blaming organization,” you’re not doing anything to change it. When you say, “I am a part of this blaming organization,’ you move forward. You own the blaming as a part of yourself and your behavior-not just something that “they” do (to you).

Self-awareness is often followed by depression or shame or guilt. Some people react with anger, at themselves or at any convenient target. Yet Self-awareness is empowering-the thought that since I own it, it’s mine to do something with.

Acceptance

Acceptance moves the change process beyond self-blaming and says, “I’m not a bad person because I do this. My intentions are good, though my actions may not be effective.” Acceptance means that you understand that taking responsibility is not the same as blaming yourself. Thus, you have mercy on yourself and your all-too-human imperfection. You stop being angry. You forgive yourself for not doing better in the past, based on your present understanding and standards. And, as you forgive and accept yourself, you gain compassion for the others involved-thereby increasing the chance that you can communicate with them and effect change.

At the point when you’re trying to reach acceptance, it’s critical that you not be punished or humiliated by someone else. You need a little help in getting off your own back, or else you think so little of yourself that you couldn’t possibly do anything about the situation. Of course, in a blaming organization, you may have a hard time avoiding this kind of punishment, which is why authorship and acceptance are usually done internally, and kept internal for some time.

Authorship

Authorship is the first decision point, when you say, “I have choices. I can do something about this.” With some encouragement, you accept that you are responsible for choice in your life. You understand that you don’t have to react, but that you can chose your response-that you create, in large part, your own interpersonal context. You know there are some parts of the context that you can control and some that you can’t; and you know accurately which is which.

Articulation

Articulation is the public commitment to change, and says, “I’m going public with this (for accountability and support).” Articulation is ineffective if attempted before the prerequisites are in place. If you can’t accept yourself or how you have reflected yourself out to the world, or if you don’t know that you have choices or feel you can gain support for those choices, then speaking out is merely ineffective bravado.

But, when the prerequisites are in place, you cannot be effective by keeping silent-you must decide to speak out. In the process of speaking you transform your inner awareness to another kind of experience. You hear yourself and you notice the response you get from others. You make public, if you will, your self-your mental and emotional position.

Initially, of course, you must seek out safe places to disclose your truer and more honest expressions of your thoughts and feelings. When you become more grounded in the power of your true self then you can seek the kind of support that challenges and confronts you, as opposed to the kind of support that coddles and consoles.

Initial steps of articulating congruence are often awkward. That’s why a responsive and receptive listener satisfies one of the requirements for promoting the development of congruence.

Application

Application says, ‘These are my choices (my new ways of coping).” You learn to be congruent yourself, first in your most immediate, safe, and encouraging context. Then you expand the contexts in which you can respond congruently. Don’t try to “not be incongruent.” This paradoxical command only invokes the incongruence of perfectionism. (”If I can’t be perfectly congruent all the time, I’m worthless.”) Focus on congruence, practice congruence, and the incongruence “muscles” will simply atrophy.

With support and practice you can begin to use and test out congruence in your immediate relationships. We suggest that you continue to design for success, so that initially these tests of your new skill are done within environments where you will more likely be given the benefit of the doubt. As you experience success, then you can be centered even in more turbulent and conflicted arenas. In other words, once you “get the call,” don’t march into the president’s office and announce that henceforth, all the guilty parties must stop blaming, or else.

Activism

Activism says, “Now that I can make a difference in myself and my most familiar world, I’m going to help spread this throughout the organization.” Activism is applied leadership, starting at the point at which you have enough competence at being congruent to reach out and be proactive-anticipating, initiating, instigating-but not inflicting. You cannot operate from an incongruent position and force other people to be congruent. (”I have to blame them, because they’re so blaming. Once they change, then I’ll be able to change.”)

In any case, you don’t have to inflict congruence on anyone. Congruence is contagious-when directed consciously to creating a safe, nurturing, productive environment. It may spread more slowly than you’d like, but once it starts moving, it’s hard to stop.

Notes:

1. For more on how blaming and other incongruent styles impact software work, see Weinberg, G. M. (1994). Quality Software Management: Congruent Action. New York: Dorset House.
2. For more on incongruence and verbal patterns, see Hardin, S. E. (1989). Success with the Gentle Art of Verbal Self-Defense. Englewood Cliffs, NJ: Prentice-Hall.
3. Brooks, F.P. (1982). The Mythical Man-Month. Reading, MA:Addison-Wesley.
4. For more on undiscussability, see Argyris, C. (1993). Knowledge for action: a guide to overcoming barriers to organizational change. San Francisco: Jossey-Bass.
5. for more on such system dynamics of projects, see, for example:
   Senge, P. M. (1990). The Fifth Discipline: The Art & Practice of the Learning Organization. New Turk: Doubleday.
   Weinberg, G. M. (1975). An Introduction to General Systems Thinking. New York: Wiley-Interscience.
   Weinberg, C. M. (1991). Quality Software Management: Systems Thinking. New York: Dorset House.

convert this post to pdf.

©2003, Esther Derby, www.estherderby.com

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.

convert this post to pdf.

©2003 Esther Derby, www.estherderby.com

Twice a week, I go to the gym and weight train with Brooke Darst, a Certified Personal Trainer. As I perform my exercises, Brooke provides a constant stream of feedback: Minor corrections, “Chin in! Lower your right shoulder. Stand up straight!” Encouragement, “Perfect!” and recognition for improvement, “You held that 10 seconds longer than last week ? awesome!”

It?s obvious that if Brooke waited until the end of the month and then told me ?In the first week of the month, you raised your right shoulder during some exercises,? it wouldn?t be very helpful. I might not remember the specific exercise or session, and I wouldn?t have a chance to correct the problem until the next session. I?d start looking for a new trainer.

Unfortunately, many managers act as if they think it?s best to wait until the yearly performance evaluation to provide feedback.

Delayed feedback has significant costs. If there?s been a pattern of incorrect or incomplete work, it?s too late to go back and correct the work. The opportunity to improve performance and productivity is gone forever. The feedback given long after the event may feel capricious or arbitrary. The highest price is damaged working relationships.

Jackson waited until a yearly performance review to tell Sheila that the defect density in her code was twice as high as the other programmers. Now he was going to move her onto a less challenging project.

Sheila was stunned. ?Why didn?t you tell me sooner?? she asked. ?The defect densities aren?t sorted to show individual differences — I had no idea. When I asked about a promotion in our one-on-one meeting, you never said anything about not being happy with my work! I could have done something differently if I?d known!?

Sheila started wondering what else Jackson wasn?t telling her. And she wondered if this was the start of Jackson pushing her off the team. She accepted the new assignment, but she didn?t really trust Jackson after that.

Feedback is necessary to achieve result and to maintain relationships.

Here are three basic guidelines for providing information to improve the work while maintaining working relationships:

Assume people don?t know. Like Sheila, people are often not aware that their performance isn?t quite up to par. When there isn?t a defined point of comparison or data from the work itself, people may not realize their work isn?t all it needs to be. Some times it?s as simple as asking a question. ?Are you aware that the defect density in your code is twice as high as anyone else in the group?? A question can provide information and set the stage for problem solving.

Provide clear, specific examples. Don?t make the feedback receiver guess what to change. Suppose a manager said, ?You didn?t deliver on last month?s design. I?m disappointed in you.? What does ?didn?t deliver? mean? Was the design late? Was it incorrect? In the wrong form?

Vague statements and generalizations such don?t provide information for the feedback receiver to know what to do differently. If you want to see an improvement, provide specific examples of what was wrong and what the results should be. A statement like ?I found grammar and spelling errors on every page in your design. I?ve marked them here. The design itself is correct, but the number of errors in the text distract from the content,? is more likely to achieve the desired improvement.

Give feedback before you reach the boiling point. Don?t wait until you are ready to transfer, demote, or terminate. Most people want to do a good job. But they may not know what the standard is or how to do it. Give information early so people have a chance to correct the situation before you reach the end of your rope.

Managers don?t need to provide minute-by-minute feedback like my personal trainer does. They do need to provide clear, specific, and timely feedback to help people be as successful as they can be. After all, if the people who report to you aren?t successful, how can you be successful?

convert this post to pdf.

©2006 Esther Derby

A ScrumMaster recently asked me if he should take over
responsibility for year-end performance evaluations since he was closer to the
work than the functional manager for the team. It’s not the first time I’ve
heard this question, and as more companies begin to use Scrum, I’m sure I’ll
hear it again.

It does make sense for a ScrumMaster to give feedback. But
when it comes to taking over (or participating in) the annual appraisal,
ratings, or rakings, my answer is “No. No. No!”

Here’s why.

There’s a fundamental conflict between coaching to improve
effectiveness and evaluating for ratings, rankings, raises, or promotion.

Yearly appraisals, performance reviews, and evaluations
emphasize hierarchy and differences in status. ScrumMasters are in service to
the team; they don’t manage the team. Creating a higher status position
(evaluator) is an impediment to the team self-organizing?and to team learning
how to give each other feedback and manage their own performance.

People who receive high ratings may bask in the glow of
affirmation. However, psychologists know that 80% of people believe their
performance is above average. Statistically that can

convert this post to pdf.

©2007 Donald E. Gray

Models are like kitchen utensils. You need a variety of them, and you should know when and how to use them. They should be useful for more than a single task. I recently started exploring the first explicit model I learned years ago.

The Cybernetic Model

One of my more interesting college classes was feedback control. The class was based on differential equations, Laplace transforms, and a single model that looked like this:

This model is the basis for most of the process control in the world. The controller compares the setpoint to the actual value.The controller uses the error information to take corrective action. If the temperature is too hot, the corrective action might be to reduce the heat in the temperature jacket. After a while, things cool down. All processes have a time lag between the corrective action and when the change arrives at the output. I “borrowed” the “delay symbol” from Causal Loop Diagramming to show this. If it gets too cool, the controller will change the action and add more heat.

I didn’t realize at the time how powerful and versatile this diagram is.

Personal Problem Solving

With just a few word changes, the model can be used to describe how people can solve their problems.

A problem exists when a difference exists between what we want, and what we have. We can solve the problem by changing our actions, and seeing if the world at large responds with results that are closer to what we desire.

I’m trying to lose a few pounds. I can change what I eat (calories, fat, carbs, pick your favorite fad diet). I can change how often I exercise. If I continue with these changes, eventually I should lose the weight.

Project Management

Change a couple of more words, and now we have a project management tool.

In this drawing, I’ve used a dash line connection between the manager (in this case synonymous with leader) and the team. I made this distinction since managers don’t have a direct linkage to the team. Managers can ask, cajole, threaten, and perhaps fire team members who don’t perform the tasks they’ve been asked to do. But the team member always has a choice.

Loops All the Way Down

It is possible to nest the cybernetic model. Consider the Scrum sprint cycle. The sprint cycle overview looks like:

The outside loop is the sprint cycle (usually 30 days or less). Every sprint the product owner sees new product functionality. They compare the current product state with the target and prioritize the remaining user stories. The product owner and team select a subset of the remaining stories which becomes the current sprint backlog.Completing the sprint backlog is the goal (setpoint) for the inside loop. Every day during the sprint, the Scrum team tracks how it’s progressing toward the sprint goal during the daily standup meeting.

A Rose is a Rose

In QualitySoftware Management Volume 1, Systems Thinking Jerry (Gerald M.) Weinberg presents the model in a slightly different picture (page 62).

Jerry says, “The feedback model of a software development system requires feedback of information about the system’s performance, plus requirements for the controller to compare with that information. This is the model that distinguishes Pattern 3 from Patterns 0, 1, and 2. It is also used by Patterns 4 and 5.”

This presentation highlights two systems aspects:

1. Randomness. All systems interact with their environment. Changes in the environment create changes in the system whether the changes are planned or not.
2. The software development system creates “other outputs” that the controller can use to improve the overall system performance.

A Good Place to Start

Like kitchen utensils, you need many different models. I keep a list of models I use here. The list includes:

• the Cybernetic Model
• Diagrams of Effect
• Behavior Over Time Graphs
• systems archetypes
• the Satir Interaction Model
• the Satir Transformation Models
• MBTI (and temperaments)
• abstracting (Korzybski)
• abstraction (Hayakawa)
• the NLP Meta-Model
• meta-programs
• intake modalities
• the Rule of Three

I didn’t consciously start the list with the Cybernetic Model, but that’s where it belongs. Any time I start with a difference between what I want and have, I’ve already started using the Cybernetic Model. I may choose to use other models to help resolve the difference between my desires and perceptions.For instance, if I’m involved in a conversation that doesn’t make sense, I may use the Satir Interaction model to find out why the conversation doesn’t make sense. If a co-worker’s actions don’t make sense, maybe I’ll use MBTI types to shed light on the problem.

But it all starts with the multi-use, handy-dandy, Cybernetic Model.

convert this post to pdf.

©2007 Jerry Weinberg

Contract
professionals, on the average, change jobs more often than employees, so they
are involved in lots of interviews.? One of our SHAPE forum threads was started
by Pat Ferdinandi, an independent consultant, who complained: “I am
continually amazed at some of the ridiculous or inappropriate questions I get
when interviewed by prospective clients. Keeping a straight face and not losing
my cool is sometimes a challenge.”

The Shapers then contributed many examples from their own experience,
and I’d like to recount some of them and the lessons they might carry for
my readers.

Insensitive and Oblivious
An interviewer made the following statement to Pat: “A psychiatrist has a model
that answers to specific questions fall within. So, by having a base model, he
can identify that the problem with the marriage is the lazy wife.” Pat, being
a wife herself, didn’t care for this analogy. The problem here is, of course,
his gender biases, which might exist throughout the company - but even more,
his total insensitivity to the person he was interviewing.

Well, not total insensitivity.
For that award, I have to turn to a story from a
woman who was interviewing with the manager of the department she would work in
if she took the assignment.? During the interview, he said, “I want you to
feel free to come in and talk to me any time, about anything. Think of it like
a young girl talking privately to her father where she can practice her
techniques for sexual advances knowing that she’s perfectly safe with him,
because he’s her father.”

How did she handle this?
Apparently, the same way everybody present handled it when
she told us. We sat there for about five minutes with our mouths open,
not able to make a sound. She then just walked out.
Maybe he’s a masher, or maybe he’s totally out of touch,
but in either case, you don’t want to work for him.

Gender bias is bad enough, but maybe you’re the right gender.
Sexual innuendo is worse, but maybe the interviewer won’t find
you attractive. Insensitivity, however, eventually snags everyone
working in the environment, so stay away
even if you’re not a “wife” or a daughter.

The Nedlog Rule
There’s
a variation of the Golden Rule that applies to these and a great
many other the bad interview lines:

As they do unto others, they will eventually do unto you.

I call this the Nedlog Rule. Here are some examples:

Candidate: “So what happens to the staff from the other sites?” (The company was a merger of several companies)

CIO: “We offer relocation to the ones we want. That’s the nice thing: we can start over and define our culture”

The candidate has just learned how he will be handled should he become excess
baggage. The interview continued:

Candidate: “Given that, what culture would you want to have?”

CIO: “That’s a good question.
I haven’t really thought about it.”

The candidate figured they wouldn’t start thinking about the culture
they wanted just because they hired him.

Here’s another Nedlog example:

Interviewer: “We would like to have you working for us.
I already heard about you from them
(thumb pointing over shoulder at his employees) … By the way, one of them,
namely George is not very productive, but I can’t fire him”

This candidate figured she didn’t want to be called “them,”
nor did she want her performance deficiencies to be discussed with
actual or potential co-workers. If they badmouth other employees,
you have to wonder what they’ll say about you.

Dumb or Ignorant
Sometimes, the questions you’re asked tell you all you need to
know about the kind of people who will be managing you if you
take an assignment. A software consultant was interviewing for
an assignment in a hardware organization whose managers knew
nothing about software. They asked questions like these:

• You know something about software?
• Do you write computer programs?
• Can you type? How fast?
• How long does it take someone to write a computer program?
• What’s a database?
• What programming language should we use for everything?
• What’s the one thing we should tell people to do to cut
  development costs in half?

My own answer to this last question would be,
“Get rid of the managers who ask questions like this one.”

Where do such questions come from?
In trying to understand this, I tried to imagine
what questions I would ask if I were going to interview,
say, a brain surgeon:

• You know something about brains?
• Do you operate on brains?
• Can you cut with a scalpel? How fast?
• How long does it take someone to do surgery on a brain?
• What’s a nervous system?
• What surgical tool should we use for every operation?
• What’s the one thing we should tell people to do to cut
  surgical costs in half?

Looking at these questions,
I realized that any surgeon would know instantly that I
knew nothing about surgery, let alone brain surgery.
I would think that the surgeon’s next move would be to ask me,
“What is your role with respect to the job I’m interviewing for?”
If there was any role at all, no decent surgeon would take the job.

Should it be any different if you’re a software developer,
or tester, or project manager? It’s not the lack of knowledge that’s
the problem; it’s the lack of knowledge about the lack of knowledge.
I can work for someone who doesn’t know beans about my specialities,
as long as they know they don’t know.

Hidden Agendas
Sometimes, what the interviewer says will reveal to you that they’re
not really trying to fill a position. Sharon Marsh Roberts identified
two common types of hidden agenda interviews. The first are
“professional courtesy interviews” - ones which are scheduled because:

1. the interviewer owes someone a favor;
2. the interviewee has some (hopefully worthwhile) connections; and
3. there is time on everyone’s schedule.

Sharon opposes this to the “comparison shopper interview”:

1. the interviewer has someone in mind;
2. Human Resources hasn’t approved the decision; and
3. the corporation demands some sort of record of “due diligence”.

Many of the worst interviews fall into these categories,
and the best thing you can do (since your’ll never get the job)
is save time by getting out quickly. One
young contract professional was invited for an interview,
believing that she was under consideration for a particular assignment.
The interview started badly enough and went downhill fast enough so that
she asked the defining question:
“Is there something that I should be telling you to explain that
I could perform this job?”

The answer communicated bluntly something on the order of,
“No, because I’m interviewing someone who’s isn’t qualified
for this position.”

She gracefully departed. There wasn’t much she could say,
and besides, why waste more time?

Conclusion
There are dozens more ways in which interviewers reveal this kind of
information, and if my readers clamor for them, perhaps I’ll provide
some more. The important thing to know, though, is no matter how
inept an interviewer may be, you?the interviewee?can almost
always get the information you need to make a decision.
Just don’t lose your cool and thereby lose the information.

convert this post to pdf.

In this game,
the only way to win is to stop playing.

(c)2004, 2005 Don Gray and
Gerald M. Weinberg

It may look like a crisis, but it’s only the end of an illusion.

- Rhonda’s First Revelation

The Setup

Sharkey, the sales VP of UberDenke Software Products, firmly believes he needs to have the next release of the UDCRM product in three months. Engelbert, the software engineering VP, estimates a minimum of twice that long - six months - to implement all the new features. During the discussion, Sharkey drops some thinly veiled threats:

• Do you think we need to consider outsourcing this development?
• I wonder why our competitor manages to get software out, but we can’t?
• Perhaps we need to see the company president about the schedule.

Getting the message, Engelbert eventually agrees to “try to get the software done” in three months. Engelbert calls a meeting of the development group leaders and shares the story. “Marketing insists
that we ship the next version of UDCRM in three months. Sharkey already has a quote from an outside vendor, so I had to agree to the schedule. Let me know how we’re going to get this done.”

The developers head to their cubes and start to ponder how they will get the work done in three months. No matter how much they try to shorten their schedule, their estimates range from three and a half to eight months to deliver the next version of UDCRM. Engelbert figures that Pamela’s estimate of three and a half months is close enough to three months, so he shaves off two weeks and declares that as the team’s schedule. He rewards Pamela by making her project lead.

Objectives for Play

In the abbreviated story above, there may or may not be a valid reason Sharkey wants the three-month date. There may be legal considerations (HIPA, EPA, IRS) involved. Perhaps COMDEX is in three months and UberDenke needs to be ready to demonstrate the product. Or maybe a key client has agreed to pay to have UDCRM shipped in three months. Sometimes the “Big Boss” has determined that a date (usually 1 January) is a good day to start using a new system. And just maybe, Sharkey fabricated the date out of pure imagination.

Likewise, Engelbert may or may not have had valid reasons for his initial estimate of six months. Based on the new features and changes to infrastructure, six months could be a valid number - even optimistic. Perhaps previous experiences with marketing have always ended with Engelbert’s estimates cut in half, so this time he doubled his best guess for how long the next release would require.

When Sharkey makes up the needed date, and Engelbert starts by doubling his estimate, they become enmeshed in a Liar’s Contest. A Liar’s Contest is a dynamic interaction arising from a conflict between two people who hold different values for an outcome. The winner is the contestant who emerges from the game with his lie unchanged. The loser is the participant who believes the other contestant’s lie and changes his lie to match. Neither of them is ever forced to tell the truth.

Participants

A Liar’s Contest can happen between the same or different corporate levels as well as between organizations. Sharkey and Engelbert play the game as peers from different parts of the organization. Engelbert and the developers play Liar’s Contest as boss and subordinates. During the competition, one participant generally starts with some type of an advantage over the other.

The participants’ negotiations tend to be zero-sum situations. Winning for one becomes losing for the other. Generally, the interactions between the participants focus on a single value (three months, six months), not a range of values. They never discuss probabilities, even though the future is always uncertain. You can often stop the Liar’s Contest dynamic by creating win-win situations, agreeing on a range of values, or allowing probabilities into the discussion.

And even though Sharkey and Engelbert finally “agree” on a value for the outcome, the real outcome value will almost certainly be something else:

- A miracle happens. No risks occur and the salaried programmers work long unpaid overtime hours, and the product ships on time. This outcome reinforces Sharkey’s original request of three months. “Those programmers! Always padding their time estimates! I KNEW IT!”

- A miracle fails to happen and the product ships “on time” with serious or fatal defects. Sharkey points out that Engelbert agreed to the schedule, so the current mess is his fault. For extra affect, Sharkey can mention that “The only reason we’re not losing more customers is because of the frantic work of the sales staff.”

- A miracle fails to happen and the project ship date slips to six months - or, often, much longer because trying to do a six-month project in three months usually takes much longer than a well-planned six-month project. The product finally ships with minor defects. Sharkey points to lost customers
and lost revenue and blames Engelbert for the dip in quarterly revenues.

It’s interesting to note that in all cases, Engelbert and the software developers are “wrong.” That makes them the losers, but it doesn’t guarantee that Sharkey won’t lose, too. If he’s still responsible for sales, he may suffer the consequences of the failure to produce a miracle.

Choose Your Position

In a Liar’s Contest, one participant usually comes into the competition with one of five distinct advantages:

Positional Given most corporate structures and climates, it’s difficult to argue with a liar from above you who delivers the “Make it so!” ultimatum. That’s why Liar’s Contests often trickle down through several levels of an organization, producing incredibly far-fetched values of estimates.

Negotiation Experience Some people have more experience negotiating, which gives them an advantage when they press for their chosen outcome. They tie into the culture better (”Be a team player”) and have alternate options (real or fictitious) prepared as threats prior to starting the Liar’s Contest. (”We’ll have to go outside if you can’t do it.”)

Interpersonal Skills The ability to understand people provides additional leverage points. We all want to be successful and to feel competent, yet while the feelings are mutual, the participant who first brings them up tends to put the other person on the defensive.

Psychological Strength Anyone who comes to the Liar’s Contest off-center, entwined in other stressful events, or with generally low self-esteem will be at a great disadvantage to a more congruent opponent.

Nothing to Lose The less you have to lose by lying, the more easily you’ll win most Liar’s Contests. Your potential loss involves both the size of the loss if the lie is discovered and the chance that your lie will be discovered.

When a time delay exists between the negotiation and the outcome, it’s possible that neither party (like Sharkey and Engelbert) will be in the same position, or even with the same company when the outcome is
delivered. If the time delay is long enough, or the record keeping is bad enough, nobody will remember the original lie. Perhaps the reason projects keep such poor records of past estimates is that the people love to have Liar’s Contests and not pay the price of losing.

Penalties

After Engelbert and Sharkey have played a round or two of Liar’s Contest together, several different effects may be seen in the long term. Sharkey may no longer accept any of Engelbert’s first estimates - he always pressures for a decrease. Engelbert may compensate by padding his original estimate. Since the “pad” can be negotiated away, the reduction dynamic is reinforced. Engelbert may offer more honest first estimates. This does not change the underlying system, so the personal interactions won’t change. The system goes through another evolution and repeats the previously described activities.
This dynamic looks like Figure 1

Figure 1

If the Liar’s Contest continues to result in reduced delivery times but worse quality, secondary negative consequences appear. The developers will have a reduced view of Engelbert’s overall management abilities. The long hours developers work attempting to deliver the software will result in mental fatigue and burn out, a further drop in output quality (now on a downward spiral to disaster), and interpersonal stress (family life suffers, feeding back to even poorer quality work). If the economy and locale permit, developers will start leaving for greener pastures in more honest environments. Finally, customers may purchase the competitor’s software due to release quality and cycles.

All in all, Liar’s Contests establish the relationships and conditions for bad things to happen, both now and forever more.

Game Over

To end the Liar’s Contest, both parties must realize what is missing in their interaction: the other person and the context of the discussion. In our story, each player in the Liar’s Contest saw only his own role. Sharkey saw Engelbert only as an impediment to his success. Engelbert saw Sharkey only as an obstacle. Neither saw the other as a human in the same boat as himself, nor did either player see himself as just one part of the bigger system. The reality is that Sharkey and Engelbert are both parts of an interconnected system. For Sharkey’s sales to increase, the developers need to deliver a quality product. For client expectations to be easily managed, the sales force has to provide realistic delivery dates.

While early delivery may result in increased sales, these sales come at a cost. Increasing sales may mean more customers, but poor quality software leads to increased support costs. Thus, the company may be less profitable than before. Customers may lose time fighting a faulty product. As support degrades, they tend to switch to a competing product. What both the company and customers need is not software in three months, but software with
sufficient quality as quickly as possible.

When the goal is stated this way, both players can support it. This agreement allows for a number of possible interventions that could end the Liar’s Contest:

1. Include pertinent contexts in the negotiations. If Sharkey explains why the dates are important, it could give Engelbert an opportunity to suggest trade-offs, so they could deliver the most valuable product possible within the time constraints. If Engelbert points out the quality trade-offs that the short schedule forces, Sharkey may see that it could cause customers to choose competing software. Sharkey can then work with Engelbert to find a date that will work for both of them.

Ideally, Engelbert would show the trade-offs by bringing real customers into the discussion, but salespeople who like to win Liar’s Contests generally work to prevent actual contact between customers and developers. If this happens, Engelbert should ask the customers if they want to talk directly with him. If the customers do want to talk to him, Engelbert should ask them to insist on it. He shouldn’t volunteer more than that. Concerned customers will make it happen. If the customers are not concerned about lies, Engelbert shouldn’t be concerned either.

2. Avoid all or nothing discussions. Offer options during the negotiations. Consider a range of features over a corresponding delivery time frame. Say, “If you really need that delivery schedule, here’s a list of functions. Start cutting them one by one and I’ll tell you when you’ve cut enough so we can make the schedule.” Or, if it’s feasible, you might say, “If you give me this and this by such and such a date, then we could make that schedule.” Be sure to ask only for things they can actually get for you - not, for example, promises of “perfectly clean component deliveries.” And be sure to have this in writing, in case they don’t deliver and still expect you to make the date.

3. Say “I don’t know.” Instead of saying “that can’t be done,” Engelbert can engage Sharkey in trying to solve the problem by saying, “I understand what you want, but I don’t know how to give it to you. Do you see something I don’t? Can you show me how to do this?”

4. Let someone else do it. Sharkey might threaten Engelbert, “If you can’t deliver, I’ll find someone who can.” Engelbert may defensively insist there’s no need to go outside, but properly engaging outside help can create the opportunity for the inside developers to learn new software packages, techniques, and skills. Or, if the outside developer fails, the sales organization has a chance to learn more reasonable expectations about software development.

5. Add another information path. Include the company president, developers, customers, or other parties who have skin in the game. Again, invite them to ask themselves in, using their power to get what they want and need. If they don’t want in, then it’s no longer a problem.

Conclusion

Nobody has to engage in Liar’s Contests - unless they enjoy it more than they despise the consequences. Understand the dynamics so you can show other people the consequences of starting a Liar’s Contest. A copy of this article might serve that purpose quite well. It has for us.

< Publication Notice> - A version of this article was previously published in Better Software, May/June 2004

convert this post to pdf.

©2004, Gerald M. Weinberg, www.geraldmweinberg.com

Late one summer, I was called in to help an IT client learn to work better with their customers. I don’t ordinarily travel in the summer, but this sounded like a real emergency, one where I had to be on the scene to calm down both parties. The customers were enraged with the IT manager because a new system wasn’t ready on time, and IT manager was enraged with the customers because they hadn’t delivered some essential information as promised, thus causing the entire project to lag its schedule by 4 months.

It was over 100 degrees outside, but even hotter inside - emotionally. Jeff, the IT manager, would smack the table and say, “You promised that the component pricing data would be in our hands by February first.”

Penny, the catalog manager, would give him a steely-eyed glare and mutter, “We never promised that. Never!”

“Yes, you did!”

“No, we didn’t.”

And then they would loop back to the beginning, raising the temperature a few degrees.

I thought that the problem-solving would go better if I could cool things down, but all I was hearing was “yes-you-did-no-we-didn’t,” back and forth. I decided to attempt to establish some facts that were not a matter of opinion, so I asked for the original requirements document. Both Penny and Jeff seemed a bit stunned by this reference to data, then Penny recovered and said, “Yes, that will prove my point.”

“No, it will prove my point,” Jeff countered. “Good idea, Jerry. Now we’ll see whose fault this is.”

I was a bit surprised at how readily they each found the document. (Lots of my clients seem to lose requirements documents once a project is under way.) Jeff got his open first, and placed his index finger on the following key line:

The Catalog Department should deliver component pricing data by 1 February to the IT Department.

I thought Penny would find some other statement to “prove” her point, but a few moments later, she had her copy open to the same page, upon which the same sentence was highlighted in DayGlo pink. “There.” She said, triumphantly. “There’s my proof. We never promised to deliver that data that early.”

“Yes you did. It’s perfectly clear, right there. Should deliver by 1 February.”

“Exactly,” Penny countered. “It doesn’t say we will, but only that we should. And we did try. But you computer people apparently don’t appreciate the difficulty of getting every single one of those prices signed off by every person involved.”

Well, I eventually got things cooled down, and we moved from blaming to problem-solving, but not before I extracted a promise from both parties to attend a little workshop I designed for them. I designed the workshop because I didn’t want to have to come back the next summer when they ran into the same problem - a lack of understanding of the ambiguity of the English language. The following are some excerpts from that workshop:

Should
I started the workshop with focus of their original problem, the nasty little word, “should.” Jeff read the original statement as

The Catalog Department [must] deliver component pricing data by 1 February to the IT Department.

Penny, however, interpreted the “should” differently, as

The Catalog Department [will make every effort to] deliver component pricing data by 1 February to the IT Department.

What I taught them was a safer meaning, of “should” would be “probably won’t,” so the sentence reads,

The Catalog Department [probably won't] deliver component pricing data by 1 February to the IT Department.

“Oh,” said Jeff, “if I’d realized that, we could have designed the project differently. Could Catalog have delivered parts of the pricing data by February 1?”

“Sure,” said Penny. “We actually had about 90% of it by then, but that last 10% - mostly new items - took all the work.”

“Ah. If only we’d known. We didn’t need the entire table to proceed. Okay, next time we’ll just let you know what we really need.”

Just
Jeff had given me the perfect opening for the next lesson. “Sorry, Jeff,” I said. That won’t do.”

“Why not?”

“Because you’ve managed to sneak in another one of those discounting words.”

“What word?”

“Just.” I went to the whiteboard and wrote what he said:

“Next time we’ll just let you know what we really need.”

“Now, what’s the difference between that sentence and this one? I wrote:

“Next time we’ll let you know what we really need.”

“Well, it’s the same thing, isn’t it?”

Penny chimed in. “I get it. The ‘just’ makes it sound like there won’t be any problems. It discounts the difficulty.”

“Precisely. It’s what I call a ‘Lullaby Word.’ Like ’should,’ it lulls your mind into a false sense of security. A better translation of ‘just’ in Jeff’s sentence would have been, ‘have a lot of trouble to.’”

“I get it,” Jeff said, coming to the board and snatching the marker from my hand. Then he wrote:

“Next time we’ll [have a lot of trouble to] let you know what we really need.”

“You know,” he sighed, “I wish we’d had this little lesson last month. My second-best analyst up and quit on me, and I didn’t see it coming. But a few weeks before, he told me, ‘We haven’t managed to hire another analyst yet, so I’m just working 80 hours a week until they do.’ I should have heard him saying,

‘We haven’t managed to hire another analyst yet, so I’m [having a lot of trouble] working 80 hours a week until they do.’

He was trying to tell me that he was overloaded, but the ‘just’ lulled me into discounting his message. And, because I didn’t hear him, he finally quit. Darn!”

Soon
Penny looked thoughtful. “I know another Lullaby Word that got us into trouble.”

“What’s that?” Jeff asked.

“You remember when we didn’t have the prices ready on February first, and you asked me when we would have them?”

“Sure, but I can’t remember what your answer was.”

“That’s because it was a Lullaby. I said, ‘Soon.’ And what that means is…” She looked at me, and I nodded.

“I think it meant, ‘I don’t know, but don’t keep bothering me.’”

“That’s usually a pretty good translation,” I confirmed.

Very
“Actually,” Jeff chimed in, “what you said was ‘very soon.’”

“Oh, great!” Penny said. “And what did that mean?”

“Adding ‘very’ is like adding a sleeping pill to the lullaby. It makes it even more certain that it’s going to be a long, long time. Maybe never.”

We spent a bit more time on the subject of lullaby words, with examples such as

Only: It’s only a one line change. [That is, I didn't think much about what could go wrong.]

Anything: I didn’t change anything . [That is, anything I thought was important.]

All: All I gotta do is … [A synonym for "just."]

Eventually I noticed that both Penny and Jeff were yawning. I suddenly realized there were many ways to put people to sleep with words, so I stopped talking and they both woke up.

Later, I reflected on the deep lesson underlying all these lullaby words. In effect, they are designed to discourage feedback by putting both the speaker’s and the listener’s minds to sleep. And no feedback means that the meaning of the statement containing a lullaby word cannot be clarified. And, if it’s not clarified, it can mean almost anything - and that’s always the beginning of trouble. If you want to avoid such trouble, start converting those lullaby words to alarm words - waking you up to potential misunderstanding, rather than lulling you to sleep. Just do it!

convert this post to pdf.

©2001 Gerald M. Weinberg, www.geraldmweinberg.com

[Note: In September, 2000, at the SEI's Software Engineering Symposium in Washington D. C., Jerry was the recipient of the 2000 Stevens Award. The award recipient is recognized for outstanding contributions to the literature or practice of methods for software development. In receiving the award, Jerry gave the Stevens Lecture on Software Development Methods, the purpose of which is to advance the state of software development methods and enhance their continuing evolution. The following column is abstracted from part of his Stevens Lecture. ]

I remember one summer day during World War II when my father, Harry, and I were discussing the water restrictions that had been imposed because of drought conditions. I was worried that we might run out of water, and my father said, “Yes, it could happen that we run out of water. Lots of things can run out - water, sugar, meat, gasoline, bread, even air. But there’s one thing that will never run out.”

“What’s that?” I asked, looking for reassurance.

“Reasons,” he said. “People will never run out of reasons.”

Harry was the first change artist I knew. At that time, he was working for Sears, starting up new stores and installing new procedures in existing stores. He often took me on trips, and I got to see him working. I particularly recall the difficulty he had teaching salespeople about Sears’ policy on returned tools and paint.

The policy was simple: The customer was always right, so just replace anything that they didn’t like, no questions asked. If possible, find out what they didn’t like about it, but never, never question their right to a replacement. I’d watched him coach salespeople through a number of these transactions, so I thought I understood what he mean by never running out of reasons. Even though the policy was clear - replacement with no questions asked - the customers always had elaborate stories of why the item wasn’t satisfactory.

But only later did I realize that it wasn’t just the customers he was talking about. He was also talking about the salespeople, who never ceased to have reasons why they couldn’t or shouldn’t apply the policy in each particular case.

Recently, I found myself recalling that summer day, half-a-century ago, when a client asked me to find out why their Software Engineering Process Group was having so much trouble getting people to adopt new software tools. It couldn’t be the tools themselves, they reasoned, because quite a few people had adopted them and liked them. So, I set out to interview both adopters and rejecters, to discover the reasons some were using the tools and some were not. Here are some of the answers I obtained:

Darlene: I installed it because the boss told me to use it.

Porter: The boss told me to use it, so I didn’t use it.

Ursula: I installed it because the boss forced me to use it.

Marcy: The boss forced me to use it, so I installed it, but I don’t use it. He wouldn’t know the difference.

Quentin: I used it because it was like what I used before, so I knew I wouldn’t have any trouble adapting to it.

Chuck: Why should I use it? It’s nothing new; it’s just like what I used before.

Carl: Hey, I used it right away, because it was new and different.

Cynthia: I’m not going to use anything that’s new and different. Too many things aren’t tested, and something’s sure to go wrong.

Mary: Of course I used it. Everyone else was using it.

Roy: Everyone else was using it - what a bore! You won’t catch me following the crowd.

Frances: Why should I use it? Nobody else was.

Edgar: Hey, I got to be the first one to use it!

Mort: I couldn’t use it. It didn’t do all the things I needed.

Alan: The thing I liked best about this tool was that it didn’t try to be a Swiss army knife and do everything anyone could possibly want.

Gerri: It was the perfect tool, because it had every feature I could possibly want.

Chico: Every time I hit a key by accident, it would invoke some obscure feature that I didn’t want in there in the first place. Finally, I trashed the whole thing.

Orion: I’m so busy, I needed a new tool to save me some time.

Belle: I’m so busy, I don’t have time to install and learn a new tool.

May: I’m not that heavily loaded. Why would I need a time-saving tool?

Paul: Well, I wasn’t so busy with other things, so I had time to install and learn a new tool.

Earl: It was freeware, so it was a bargain.

Justine: It was shareware, so it couldn’t have been any good.

Jacob: This tool costs $3,000. It must be good, so I’m using it.

Neelie: I’m saving the company $3,000 by not using it.

Willis: I won’t use it because I don’t like the way Microsoft makes software.

Samuel: I knew it would be good because Microsoft makes it.

—-

Well, there were more, many more, but that’s enough of the infinite reasons to make my point. By this time, you may have noticed that I have arranged these reasons in pairs. Why? So you could see the pattern that I saw:

Every single reason to use the tool was matched by the same reason for not using it - and vice versa!

In other words, these reasons may look like logic, but they’re not logic - they’re just reasons. In logic, the reasoning comes first, then comes the decision. But in real life, it’s usually the other way around - first we make the decision, then we make up whatever reasons we need to “justify” the decision and make it look like logic.

And why would we go to all this trouble? Somewhere along the line, we’ve learned that emotional reasons aren’t good enough, so we have to fool people into thinking we’re more rational than we really are - so they’ll leave us alone to do what we intend to do in the first place.

I recently read about a fascinating psychological experiment conducted in a large office at the high-speed copier. When there was a line of people waiting to use the copier, an experimenter would walk up with a handful of papers to copy and try to butt into the front of the line.

In one set of trials, the experimenter would say, simply, “I want to copy these.” People were indignant, and refused to let him get in front of them.

In a second set of trials, the experimenter would say, “I want to copy these because my boss needs them.” People then willingly let him go right to the front of the line. In other words, if the experimenter had a good reason, then people were willing to let him go first, even if meant they had to wait longer.

But the fascinating phenomenon was in the third set of trials, where the experimenter would say, “I want to copy these because I need to copy them.” And guess what? The people let him go to the front, just as they had done when he had a “good reason,” even though this “reason” was totally vacuous. In repeated trials, the experimenters discovered that any “reason” would work, as long as they used the form, “I want to copy these because X.”

We seem to be conditioned to respond to this kind of pseudo-logic, and we instinctively know how to use it. Imagine telling your boss, “No, I’m not going to use this tool.” You know that the next thing you’re going to hear is “Why not?” So, you’re never dumb enough to “just say no,” but, instead, you’re going to say, “No, I’m not going to use this tool because X,” where you supply the X from the list above or from your own favorites. You might get an argument, but half the time the conversation will simply end there. And, if the boss does continue, you’ll then supply reason Y, then Z, then A, B, C, and D, until she gets tired of the game and quits.

But I’m not telling you all this so you can beat your boss in The Big Game of who gets to tell who what to do. I’m telling you because one of these days - perhaps today - you’re going to be on the other side of the equation. You’re going to be the change artist trying to introduce something new - a tool, a process, a document, a technique, anything new at all. And when you try, you’re going to find yourself faced with an infinitely high wall piled with reasons, mortared in place with that word, “because.” [Or "so," or other forms of pseudo-logic.]

And what will you do then? Rather than go back and forth with a potentially infinite chain of “why-because,” save yourself some time and energy by recognizing that you will always lose this game, so switch to another. One of these new games is to try to convert to real logic.

When you get the first “because,” simply say, “You’re right. There are lots and lots of reasons why you might not want to do it this way, and you’re exactly right to start raising them. Let’s carry this through.”

Then you take out a sheet of paper and draw a line down the middle. On the left, you label the column “Reasons Why Not.” On the right, “Reasons Why.” Then you write their reason in the left column and ask for one in the right column. If they can’t come up with one, prime the pump by showing how their own reason could just as well go on the right.

Continue filling out the columns until you have 6 or 8 or 10 reasons on each side, then say, “Okay, now let’s consider what’s the real problem here.” And off you go, possibly getting into real logic for a change.

A second approach is to short-circuit the game right at the beginning. When they start listing “why-not” reasons, you interrupt and say, “You’re right. Not everybody is right for this tool. Since you don’t have the right qualifications, I’ll go look for someone else.”

Sometimes, they’ll let you go - and then at least you’re saving time. But sometimes, they’ll stop you and start giving reasons why they are, indeed, the right people for this tool. And you can be sure they’ll have an infinite number of them.

convert this post to pdf.

©2000 Gerald M. Weinberg, www.geraldmweinberg.com

You’re entering a new situation, and you’re ready to gather the Big Picture of the other people involved. Whatever you do, don’t try the following process without first getting a Big Picture of yourself, as discussed in an earlier article. If you’re not personally centered, this whole process will sound hollow and even smarmy.

Which others’ Big Pictures? Well, who will the significant others be? Anybody I omit from this survey will potentially appear on stage at a critical juncture and spoil my best-laid plans. The people I usually have to consider are Dani, my wife and business partner; Sweetie and Ruby, my German Shepherd dogs and biggest supporters; Lois and Susie, my coworkers; other colleagues in my network, such as my PSL faculty colleagues; my customer, the one who’s going to pay my bills. In this column, however, I’ll focus on my clients, the ones I’m going to work with on this assignment.

I’ll look for the answers to the three Big Picture questions:

- How do they happen to be here? (Past)

- How do they feel about being here? (Present)

- What would they like to have happen? (Future)

How do they happen to be here? (Past)

When someone talks about past consultants, they’ve given me a free head start without my having to ask one of my “past” questions, such as,

Did Darlene choose to be here, or was she forced by me, or some other factor, like her boss?

What has been her past history on this job? What knowledge does she have that I can tap into? What prejudgments has she made about the nature of this task?

Has she had early personal or cultural experiences that might affect the way she works on this job? With me? These are not excuses for poor performance, but things I have to understand to work well with Darlene.

What’s been her past experience with me? With other contractors? What preconceptions does she bring to the table as a result of these experiences?

How do they feel about being here? (Present)

In this instance, I knew right away that this organization “had consultants before, but none of them made any difference.” Obviously, Darlene felt that this was an important thing to say, but I didn’t know why she brought this up so early in our relationship:

Does she have some reservations, or forebodings, about this assignment? About me? Does our doing this assignment conflict with something else she wants to do?

Is she eager to be here? Is she looking forward to working with me on the task that I’ve agreed to do?

Is she clear about what’s going to be required of her if I take this assignment?

How’s her self-esteem? Does she feel able to control her situation and accomplish her personal goals, or does she feel powerless?

However she’s feeling, is hers the right mood for me to succeed in this job? If not, what steps can I take to help her get into the right mood?

I often seek this information by asking, “And what does that tell you about my tour of duty?” Here are some of the answers I’ve received from Darlene and other people, at other times:

Aaron:

You don’t have a chance, so I’m not going to waste any time helping you.

Bonnie:

You’re going to need my help if it’s going to turn out differently this time.

Carter:

It’s nothing personal, but this will be another of those management vision things, full of sound and fury and going nowhere.

Darlene:

I’m really excited, because you’re different from any of the consultants we’ve had before. This time, our consultant is really going to make things better around here.

Each of these answers is full of information, but I’m going to work differently with each of these people.

What would they like to have happen? (Future)

First, though, I have to know the answer to the third question, “What would you like to have happen?”

Why did X agree to work with me on this assignment? The experience? The challenge? Fear of the boss?

What will success look like, to X? Is it aligned with my success criteria? Did previous consultants solve problems that X failed to solve, thus making X look like a failure?

How long does X want me to be on this assignment? Will I be able to stay long enough to see it through? If the customer extends the project, will X be laughing or crying?

My responses

Assuming each of them genuinely hoped something would change, but knowing that each felt differently about my being here, I would construct different responses, perhaps as follows:

Aaron:

You don’t have a chance, so I’m not going to waste any time helping you.

Me:

I can understand your feeling. I’ll do my best not to waste any of your time, but if I should happen to come up with something that might save you some time, would you be interested in hearing about it?

——————————————————————————-

Bonnie:

You’re going to need my help if it’s going to turn out differently this time.

Me:

Great! What sort of help do you think you can give me?

——————————————————————————-

Carter:

It’s nothing personal, but this will be another of those management vision things, full of sound and fury and going nowhere.

Me:

Yes, I’ve sure seen my share of futile, grandiose projects. I personally think that big changes result from an accumulation of small changes. Would you be willing to work with me on some small thing that would help you in some way? Then we could see if we’re wasting our time, or if things might be different this time.

——————————————————————————-

Darlene:

I’m really excited, because you’re different from any of the consultants we’ve had before. This time, our consultant is really going to make things better around here.

Me:

I’m flattered. Thank you. In what way do you think I’m different from the others, and why do you think that will help?

As a result of learning their Big Picture, I’m no longer knocked off balance. Instead, I’m well centered and already beginning to create a method of working appropriately with each of my clients.

Question and answer

Q: How do you come up with such responses in real time? They make sense when I read them, but in the moment, I often go blank.

A: There’s a pattern, but it won’t work if you think it’s a formula. You must remain creative in order to fill in the pattern, so the first thing you must always do is center yourself. Then, find a way to connect with the emotional content of what they’re saying, relating your own emotional state to theirs. Only then can you proceed to the content — what they want to have happen, and you might do next to move toward what they want.

convert this post to pdf.

©2000 Gerald M. Weinberg, www.geraldmweinberg.com

The editor of Contract Professional chose the name for my column there, “The Big Picture.” He told me he chose the name “because you (Jerry) look at the business of contracting and consulting and the people skills involved, which translate across all skill sets and even industries” — in short, The Big Picture.

That’s flattering — but why would you want to look at the Big Picture? If you’re like me, you’re often called into an assignment because you’re supposed to be an “expert.” You know what an expert is: “someone who avoids all the small mistakes while committing a grand blunder.” So, before I get down to the nitty-gritty of a new assignment, I like to place everything in a grand array. I always make mistakes in my assignments, but this way I can hope they’ll all be small mistakes.

My favorite method of approaching the Big Picture is first to break down the question into three parts: Self, Other, and Context. In this column, I’ll start with Self — that is, the Big Picture of yourself.

Focusing on myself, I then ask three three questions I learned from the famous family therapist, Virginia Satir:

- How do I happen to be here? (Past)

- How do I feel about being here? (Present)

- What would I like to have happen? (Future)

How do I happen to be here?

Here are some Big Picture questions that make an enormous difference in how I approach an assignment.

If it’s the first assignment with this client, how did I make the connection? Was it through a third party, or through a direct contact by the client?

If it’s a repeat, what impressions did I leave the previous times I was here? Did I leave friends, or enemies? Are my old contacts still viable? What assumptions am I carrying over from the previous assignments?

Did I get the contract I wanted, or did I have to make some concessions that might come back to haunt me?

How do I feel about being here?

Am I here reluctantly? Do I have some reservations, or forebodings, about this assignment?

Am I eager to be here? Am I looking forward to the task that I’ve agreed to do?

Am I puzzled about what’s expected of me, or is the assignment clear? How sure am I of the assignment?

How sure am I of myself — of my ability to provide value for value received?

However I’m feeling, is this the right mood for succeeding in this job? If not, what steps will I have to take to get in the right mood?

What would I like to have happen?

Why did I take this assignment? For the money? The experience? The challenge? The possibility of a future reference? If I don’t have my mission in mind whenever I choose a course of action, the client may be happy with my work, but I’ll come away with a hollow feeling.

What will success look like, to me? If I come away with a pile of money but a poor reference, will I be satisfied? How about an ecstatic client who’s enormously impressed by my repeating a solution I’ve done so often it bores me into a trance?

How long do I want to be here? If the client extends the project, will I be laughing or crying?

Using the Big Picture of Yourself

By using these three questions to assess my own state before I start an assignment, I’ve enormously increased my level of satisfaction. I use them to survey my state before I agree to any contract, new or renewed. On one occasion, for instance, I found I was about to renew a long-standing contract with a nice 15% increase in my daily fee. When I checked my feeling, however, I realized that I had negotiated for the wrong thing. Much of the time on the old contract, I felt that I was doing a fine job in solving the wrong problem, and I don’t find this very satisfying. I didn’t mind the extra 15%, but what I really wanted was more involvement in defining my own assignments.

Armed with improved self-knowledge, I halted the negotiation process and asked for more leeway, which the client was only too happy to grant. I was prepared to sacrifice at least some of the 15% increase, but the client insisted that I take it. He commented, “Now that you’ll be helping do the right things, rather than just doing things right, you’ll be worth at least that much more to us.”

Self-assessment doesn’t always pay off this directly. On another renewal, early in my career, my attempt to get more leeway in defining my work led to an irreconcilable difference between me and my client. This client knew — or thought he did — exactly what his problems were, yet I felt his poor problem definition limited my ability to be successful in my terms.

At that time in my life, what I wanted most was experience with certain types of problems and a few outstanding references. On my first assignment with this client, I had helped solve a problem that didn’t vaguely resemble what I really wanted to work on. And, though the solution was innovative and successful, it didn’t really help the client with his true problem — since he was working on the wrong problem to begin with. He attributed his lack of satisfaction to some unspecified shortcoming in my work, and was reluctant to give me a sterling reference.

And, of course, he was right. The shortcoming in my work was my failure to assess the Big Picture — both his and mine — before I took the assignment. As we negotiated for a follow-on, the three questions show me that the extra money he offered wasn’t adequate to overcome my bad feelings about working with him again. Negotiations broke down, but at least I didn’t waste another six months of my life struggling for something I didn’t really want.

It took me a few weeks to get a new assignment, and that cost me a few bucks. The cost is long forgotten, but I still savor the memory of my satisfaction with the new assignment — what I learned, what I earned, and how it put my professional life back on my own track.

Questions and answers

Q: It’s all very nice to say that I ought to be centered in myself before I make big decisions, but whenever I get into some sort of negotiation, I lose track of myself, what I want, and what’s good for me. What do you suggest?

A: This is too big a question to answer entirely, but the first part is easy. When you first notice that you’re starting to lose yourself, STOP whatever you’re doing. Then concentrate on how you’re breathing, and switch to smooth, regular breathing.

Q: I’ve tried the breathing thing, and sometimes it works. But sometimes it doesn’t, like when another person is blasting at me in a loud voice. What should I do?

A: If you can’t get your breathing under control, find a way to leave the situation. If you wish to continue, come back later. If you find yourself unable to leave, then that’s a sure sign you must leave, now, and not come back. This is not the situation for you.

convert this post to pdf.

©1999 Gerald M. Weinberg

External consultants are seldom sent to classes by their customers, but often pay for their ownprofessional development. As such,they’re eager to get full value for their time and tuition.

Moreover, external consultants often find themselves as instructors in classes, in which case, they’re also interested in making sure the class goes well.

But not all classes go well, and often it’s because the mix of participants isn’t ideal. Or, to look at it another way, it’s because the instructor doesn’t know how to handle certain kinds of participants.

Our Problem Solving Leadership workshops are designed for professional development - specifically, to develop leadership abilities in the participants. Because leadership means so many things to so many people, our participants arrive with different expectations, so one of the first things we must do is clarify why each participant is in the room.

Over the years, I’ve seen students who fall into four categories - Customers, Learners, Visitors, and Complainers.¹
Each type of student requires a different approach from the instructor.

A Customer is someone who arrives with a particular problemto solve, for themselves or concerning some other person(s) or situation.If a student is a Customer, it’s possible to gain a relatively cleardescription of this problem. Here aresome examples of Customer problems brought to our PSL Workshop:

“I want to communicate better with my customers when they are trying to tell me
their requirements.”

“I want to do a better job facilitating meetings.”

“I can’t handle my boss when she criticizes my work.”

“My teammates often don’t listen to my ideas,so that they misunderstand them and reject them.”

“I’m putting together a new project team, and I want to do it without making the
same mistakes I made last time.”

The participant as Customer quite clearly wishes to do something about this problem and is seeking help from the class and the instructor. All the instructor has to do to satisfy the Customer is offer a high-quality class. Most instructors wish for a class composed entirely of Customers, but it’s never that easy.

A Learner is someone who comes in without a particular problem to solve, but just wanting to learn whatever the class has to offer.Typically, Learners may state their objectives in ways such as these:

“I heard this was a neat class, so I wanted to learn what you had to offer me.”

“I’m interested in teamwork and how to build teams.”

“My best friend at work took this class and wouldn’t tell me anything about it except that I should come and learn whatever I learn.I like that idea.”

“I’d like to improve my problem solving skills (without mentioning any particular situation).”

Learners are fun to have in class, because they gobble up everything the instructor has to offer. They never ask that hard question the Customers may ask: “What’s the relevance of what we just learned to so-and-so.”

Nevertheless, they can be a danger to the class because they may drift off in any direction just because it catches their fancy.If the instructor gets distracted by Learners, the Customers start getting angry because they’re not getting what they came for.

A Visitor is an uncommitted participant, often involved in the class under some kind of duress, implicit or explicit, and usually because of the concerns of some other person. Typical statements by Visitors might be:

“My boss told me I needed to learn whatever this class teaches.”

“My company bought three seats in this class, and someone cancelled one of them, so they sent me to fill the empty seat.”

“Everyone in our department has to go to this class.”

“I can’t get promoted unless I’ve taken this class.”

The Visitor has no agenda to participate in class discussions, and works on any exercises in the most minimal way. Attempts by the instructor to improve the Visitor’s participation are likely to be fruitless or to lead to “resistance” that can be disruptive to the whole class.

Trying to capture the interest of a Visitor can easily distract the instructor from paying attention to others in the class who are not Visitors.

Instructors need to treat Visitors respectfully, always being open to their contributions, should they decide to start making them. If Visitors do contribute, honor their contributions with complimentary (but not effusive) feedback.Until they volunteer to contribute, however, avoid soliciting their participation or trying to assign them tasks.

They have to make their own choice to transform themselves into Customers, or at least Learners.

A Complainer does have a particular problem (or list of problems), specific or vague, either concerning themselves or about some other person(s). The Complainer’s problems may resemble the problems brought by the Customer, but it’s not clear that the Complainer actually has any wish or hope that these problems be solved. Often, the instructor can distinguish the Complainer from the Customer by the whining, helpless tone in which the Complainer presents these problems - often repeatedly.

Complainers don’t really believe that their problems can be solved by this class, or possibly even solved at all. Therefore, they should be treated initially as Visitors, with empathy. If they display any hope that something can be done about their problems, that’s the time to get them engaged in the class. Often, this display of hope comes in the form of a tentative question that doesn’t refer directly to the Complainer, such as,

“Could this technique be applied to dealing with a boss who doesn’t appreciate your work?”

“But this technique couldn’t be used on a project under heavy schedule pressure, could it?”

Understanding and recognizing the four types of participant is obviously helpful to you when your job is to instruct a class, but what good does it do if you’re a fellow student? And what if you’re not in a class, but just a plain vanilla contract professional working on the job?

As a consultant,I’m seriously interested in my education. When I attend a workshop, I want to get my money’s worth - because I’m paying my own tuition and I’m usually not getting paid for my time. (Sometimes I can get my client’s to pay me for attending a workshop, but that’s a subject for another column.)

Therefore, whenever I’m in a workshop, I watch my fellow students just as I would if I were the instructor. If they’re Customers, I watch to see that they’re shopping for the same learnings I am, because if they’re not, they may steer the workshop into areas that are not related to what I’m shopping for. If they do, I may suggest something to the instructor, such as, “I see that you and Val have a deep interest in this subject, but it’s not my main focus right now. Would you be willing to continue off line with those who are really interested?”

If some of my fellow students are Learners, I cautiously enjoy their excursions into the unknown, because I’m always partly a Learner myself. I do my best to protect them from overfocused Customers (including me), while at the same time keeping my own goals in sight. If necessary, I try to steer things gently, as by offering, “Thank you for that wonderful exploration. I was fascinated, and could probably spend all day exploring it. But I wonder if we couldn’t come back to the subject of …”

If the instructor has a Visitor or Complainer to cope with, I consider myself a junior partner of the instructor and try to help out, generally off line during breaks. This role comes naturally to me, since we usually lead our own workshops in pairs - one instructor “on stage” and one ready to handle Visitors or Complainers one-on-one outside of the classroom.

For example, in a recent workshop, one of the Visitors was using one of our breaks to try to recruit other students to his cause by convincing them that the workshop was a waste of time - which, of course, would make his boss look like a fool for making him attend. Once I recognized that he was a Visitor, it wasn’t very hard to turn the subject toward his problems with his boss, and away from deprecating the very professional job my co-instructor was doing. Eventually, he realized that he had a choice between spiting his boss by learning nothing, or spiting her by actually learning some things that made him a better professional.

And speaking of professionals, I don’t spend most of my time being a student or instructor, so what does all this have to do with my day-to-day work? If you’re a regular reader of this column, perhaps you know by now that I always have my own learning in mind when I negotiate an assignment. I firmly believe that when I stop learning, I’ll stop being a professional - so, I’m always a student.

Yes, I’m on the job to earn money by helping my client, but I’m also there to learn, so I’m always on the lookout for Customers, Learners, Visitors, and Complainers among my co-workers. I believe that any worthwhile high-tech assignment is too difficult to be accomplished without constant learning by all participants, so I’m always working to enhance the learning environment, for me and for the others.And, one more thing.

Like anybody else, I, too, am susceptible to these stereotyped behaviors:

• becoming too focused on just the immediate job at hand (Customer);
• drifting off the subjectinto interesting side tasks (Learner);
• detaching myself from the importance of the assignment (Visitor);
• feeling powerless and whining about everything and everybody (Complainer).

None of these roles enhancemy performance on the job, so I always try to watch myself, too - and bring myself back to a more professional and effective role.

---

¹ At the suggestion of David Schmaltz, one of our PSL instructors, I adapted these categories from my teacher and colleague, Bill O’Hanlon. See, A Brief Guide to Brief Therapy byBrian Cade and William Hudson O’Hanlon ©1993 by Norton in NYC.

convert this post to pdf.

©2005 Steven M Smith

He is wearing his traditional garb — dark suit, white button down shirt, red tie, and black tasseled shoes. The glare off his wire rimmed glasses makes it difficult to see those steely blue eyes. Harry Fox has all the right moves and his quick climb up the management ladder proves it. He is arrogant and ruthless. People who oppose his ideas pay a price. And the payment is extracted when they can least afford it.

We are both participating in a problem solving meeting. Well that’s not quite true, I’m observing and Harry is talking. He just stole the floor from Jim King a few minutes ago by talking louder than Jim. I hate this bully. Harry is dictating his ideas about how the team should solve the problem. But he is wrong. He has missed some crucial facts.

Should I share the facts? Wait a minute. Harry doesn’t care about facts; he cares about looking and sounding good. Harry is connected all the way to the top of the company. I’m connected to the people on my team. I hesitate. Wow, that’s totally uncharacteristic of me: I am known as someone who speaks his mind. I look over at Harry. He has taken his glasses off and is moving them rhythmically up and down as he talks. Although what he is saying doesn’t make sense, it sounds authoritative. Damn, I feel my gut twisting. Is it anger? No… It’s fear.

Harry wraps up his talk. There is a pause. If I want to speak, it’s time. I say nothing.

Safety

The omission of crucial facts and opinions happens in thousands of business meetings every day. If people don’t feel safe, they aren’t going to say anything. And you will have no idea about what you missed.

Too often the participants whose opinions count the most assume that the other members of the meeting feel as safe as they do. This assumption is wrong more often than not. But it is rarely ever tested.

You can help increase the safety of your meeting. Collect data. Share it. Interpret it. And decide how to respond to it. These actions will open the opportunity to transform your meetings. For instance, the opportunity to discuss and take action on previously undiscussable items, such as who was or wasn’t invited; what is and isn’t on the agenda; and how the discussions will or won’t be processed. I’ve experienced the power of this kind of transformation many times. You can too.

Collect the Data

Inform everyone that you will use a secret ballot to poll the participants about safety. Poll people with the following question, “How safe is it for you to fully share your ideas during this meeting?”

Write this question on the board or a flip chart. Clarify that the ballots are not identified, just a number on a slip of paper. Expand on what “fully share” means by listing some controversial ideas that weren’t shared at other meetings that would have made a difference.

An unsafe environment causes participants to share fewer ideas and to carefully filter the ideas that they do share to be sure they’re safe. Poll for the information in Figure 1.

Level	Description	Comment
4	Secure	Everything is discussable without filtering
3	Safe	Almost everything is discussable without filtering
2	Neutral	Most things are discussable without filtering
1	Dangerous	Many of my best ideas are undiscussable
0	Treacherous	Most of my best ideas are undiscussable

Figure 1. A gradient of safety

Pass out a ballot — a small piece of paper, post-it note or note card — to each participant. Ask everyone to write either the number 0, 1, 2, 3, or 4 that corresponds to their level of safety onto the ballot. My experience is that some people will, regardless of the instructions, write a decimal number. Simplify things for yourself by informing everyone that all the ballots will be rounded so that the results fit the range of the gradient.

Ask them to cup the ballot in their hand so that no other participant can see their rating. Stress to everyone that you don’t want anyone to share their rating with anyone else, regardless of how safe they personally feel. Again, emphasize that only you will see their ratings. Have the participants fold the ballot in half and place it in a container, such as a hat.

Share the Data

Ask a participant to help you build a histogram of the poll. I suggest that you use a flipchart so that have a hard copy of the histogram to use when your write up the minutes of the meeting. Pull each ballot out of the container one-by-one and read the score to the person building the histogram. Stuff the recorded ballot into one of your pockets or put them in your briefcase so no one else can or will ever see it. Note, you are not only revealing how safe people feel — you are also building safety by checking in a way that reinforces safety.

Figure 2 shows an actual histogram built during a requirements gathering meeting that I facilitated at a large manufacturing company.

Level	Description	Number of people
4	Secure	**********
3	Safe	*
2	Neutral	****
1	Dangerous	****
0	Treacherous

Figure 2. The histogram of an actual safety check that was built during a requirements gathering meeting. How do the participants who feel completely safe help the participants who feel threatened?

Interpret the Data

Ask the participants, “What is your interpretation of the histogram?” A manager in the requirements gather meeting told all the other participants that they needed to start trusting each other. His management colleagues vigorously echoed his belief. And his colleagues had a lot more to say about the importance of trusting each other. I let this discussion continue for 10 minutes and asked, “What cluster of people on the histogram do you think is offering the most advice?” The room fell silent. The people who felt the safest realized that they were doing the most talking. And they realized that the people who felt threatened weren’t talking.

Telling people how they should feel doesn’t work. And, in my experience, people know that as a fact but forget to put that knowledge to work. It helps to give them a gentle reminder. Ask everyone, “How do the participants who feel completely safe help the participants who feel threatened?” The answers I have heard in meeting after meeting can be summarized in two words: 1) Care and 2) Listen.

During the manufacturing meeting, people did start to care and listen. The participants slowed down and asked each other questions. And, most importantly, they were okay with moments when no one spoke. I believe that silence is a gift. It shows people that you are ready and want to listen. And, in the case of a meeting, silence demonstrates that the group is ready and wants to listen.

These changes made a big difference in the requirements meeting. The discussions were deeper. And the enriched conversation enabled them to discover requirements that would have been invisible to them. They were more effective together than they had ever been.

Other Methods

Another method that can help create safety, especially in large groups, is to let the participants build the safety guidelines for their meeting.

Split the participants into small groups. The ideal size is a triad — 3 participants. Ask the groups to 1) introduce themselves to each other, and 2) create a set of guidelines for conducting a safe meeting. Give them a few test cases to ponder. For instance, someone starts blaming someone else, someone tells an inappropriate joke, someone dominates the meeting, and so on. Let everyone know that they shouldn’t limit themselves to the test cases. You want them to share any guideline that will make the meeting safer.

The hope is that the discussion will help remind people of what they already ready know about safety and remind them to practice what they know. And, just as importantly, the hope is that a connection with a small, manageable number of people will increase safety.

Have each small group introduce their members and share the safety guidelines they created to everyone. You will be amazed at the wisdom that people have about safety. Gain agreement from everyone on which guidelines to accept. Remind them that the guidelines are theirs rather than yours. If someone violates a guideline, you will call them on it.

Ask the group to monitor your facilitation and to inform you if you allowing any deviation from the agreed upon guidelines. When someone mentions a deviation, treat it with the utmost care and respect. It’s the ultimate demonstration of the value you put on safety.

Final Thoughts

Regardless of the method used, you can never be absolutely certain that all the participants feel safe. If someone would have asked me how safe I felt during the meeting with Harry Fox, I would have voted neutral or safe so that Harry wouldn’t find out.

The best that you can do is to solicit and respect everyone’s ideas. The leader that models appropriate behavior in meeting after meeting is constantly renewing and enriching safety and productivity.

Be a leader. Care. Listen. Model the behavior you want.

Acknowledgements

A special thank you to Jean McLendon for making me aware of the importance of safety and how to measure it; Jerry Weinberg for suggesting that the number one isn’t nearly as evocative as the number zero for connoting the absence of safety; and Esther Derby, Don Gray, and Jerry Weinberg for sharing their feedback about this article.

convert this post to pdf.

©2007 Steven M Smith

Do some members of your team make agreements during meetings but fail to support them afterwards?If this behavior is happening, I suspect your team is using an obscure process to make decisions.

Identifying Obscure Process

An obscure decision making process is easy to identify. Ask each member to create a map of the process used to make team decisions. If the individual maps aren’t similar, obscure is an accurate description of the process.

Probe the maps of an obscure process further and you will find false assumptions. Members assume things about the behavior of other members that isn’t true; for instance, some members assume that their teammates will support the decision made by a team and how it was made with outsiders and yet some other members assume that their support is only necessary when they personally agree with the decision.

I believe an obscure decision making process disables teamwork. People aren’t connected by shared principles. They don’t cooperate. They work like a group of individuals. It doesn’t have to be this way.

I have worked with a simple, clear process for making team decisions for over a decade. I have found it highly effective. It’s designed for teams who make their decisions by consensus. If you are the leader of a team, you may object to the idea of a consensus decision. The idea may trigger the word “groupthink” to pop into your head. But as I will discuss later in this post, a leader has more control over a consensus decision than they might initially think.

Making Team Decisions

The aforementioned simple process is called Roman Evaluation. Figure 1 is a map of the process. Using the process creates visible feedback about the state of each member’s agreement on a proposed team decision. That feedback drives needed discussion and eliminates unneeded discussion.

Figure 1. A Map of the Roman Evaluation Process

Follow the following four steps to help a team reach a decision:

1. Propose

A proposal that defines a course of action desired by a member of the team drives the process. Without a concrete proposal, there isn’t any decision to be made.

The first four words of any proposal are “I propose that we…” This wording explicitly announces the proposer’s desire; for example, “I propose that we reduce the duration of this meeting to 60 minutes.”

Note, the word “we” is used to clearly identify that it is a team decision.

Post a written copy of the proposal in the room so that every member is able to read it own their own during the entire decision making process. The proposal may be amended so leave room for changes.

I would write the proposal mentioned earlier as, “Steve proposes that we reduce the duration of this meeting to 60 minutes.” Communicate it to the group using whatever medium you prefer, such as a flip chart, overhead projector or computer projector.

2. Discuss

Let the proposer speak first so he or she can provide context. Start facilitating a group discussion with an explicit duration. The purpose of the discussion is to understand the proposal and its impact. Using the example, I might ask the proposer: “What’s the problem you are trying to solve by reducing the duration of the meeting?” I might ask the team, “What do you think?”

My experience is that groups often exceed the time allocated for discussions so constantly monitor the time and periodically share how much time remains. Whenever either the discussion naturally ends or the time limit expires, close the discussion and vote.

3. Vote

A group recognizes their agreement faster with clear signals. Ask each person to signal their decision with one of their thumbs:

• Up means “I agree.”
• Sideways means “I will accept the majority’s decision and support it.”
• Down means either “I disagree.” or “I have something to say.”

I suggest that you emphasize that a thumb up or sideways means the member will support the proposal. Spell out that support means they will say “We decided to…” when asked about a decision by an outsider (see my post entitled Word Choices — We — Part 2). And they will defend the logic behind why the decision was made. This understanding makes voting a serious responsibility rather than a ho-hum exercise.

The vote gives the team clear feedback about the state of their agreement on the proposal. It enables different choices to be made than are possible without feedback.

Record the vote and verify that you have the same number of votes as members. A consensus is any mixture of thumbs pointing up or sideways. Any thumb pointing down signifies dissension.

4. Process

As you tally the vote, write down the names of people with their thumb down. Ask each dissenter, name by name, what he or she would like to say about their vote. Don’t let anyone interrupt them. When each dissenter finishes, ask them whether their thumb is still down. They may surprise you. My experience is that many people want to say something and once they do, they move their thumb up or sideways.

If there is still dissent, ask the team whether someone wants to amend the proposal. If someone offers an amendment, discuss, vote, and process. Otherwise, reject the proposal.

Considering Consensus

As you may have guessed, I believe in consensus decision making. Some leaders have told me they don’t like it though. They believe it leads to “groupthink.” I understand the thought, but that doesn’t happen. If the leader makes it clear that in the absence of a consensus they will decide on the course of action, groupthink is impossible.

The leader is a member of the team. They vote on a proposal. And, like all the other members, they are free to vote so the team makes the appropriate decision. If they put their thumb down and an acceptable amendment can’t be found, then they are free to make the decision they think is best.

I suggest that leaders don’t make a habit of using this power. But, in my experience, some situations demand decisions in a faster time frame than a team may be able to process them.

Conclusion

Roman Evaluation has a powerful effect on decision making. It connects the members of the team. It creates shared principles. It increases cooperation. It helps build a solid foundation for teamwork.

When reinforced, the act of voting makes it clear that unless a member vetos a proposal, as a member of the team, they are expected to support the proposal. And that’s the kind of thinking that binds a team together.

If your team’s decision making process needs improvement, I can help. Contact me.

convert this post to pdf.

©2003 Johanna Rothman, www.jrothman.com

The project retrospective was proceeding nicely. We’d had lunch, and we entered the mid-afternoon low-energy lull. I decided it was time to change gears for a few minutes, to move the energy back up a couple of notches, so I introduced appreciations.

Appreciations are a special form of thank you. They take the form of:

I appreciate you [the person's name] for [a specific action].

A second optional part that I suggested the participants include is:

[What that action meant to you].

If you’re in the same room, you can walk up to the person, look them in the eye, and express the appreciation. For some people, that seems too emotional, not a work statement, so I make that part optional. But, if you want people to continue repeating beneficial behaviors, include the what-the-action-meant-to-you part.

This project team had no trouble appreciating their colleagues. Here are some of their paraphrased appreciations:

“Hermione, I appreciate you for insisting that we estimate the project assuming we only had 4 work days each week. I had an estimate that was amazingly close to the actual schedule. That’s never happened to me before.”

“I appreciate you Ron, for thinking about the project and testing intelligently. I’ve worked with testers who didn’t know about our projects, and not had the benefits I wanted from the testing. You found things I didn’t know I’d put into the code.”

“Harry, I appreciate you for playing basketball with me when I couldn’t think about that part of the design anymore. You helped prevent me from designing garbage.”

“I appreciate you Dumbledore, for reviewing my first draft architecture write-up so quickly. Because you reviewed it quickly, I was able to reorganize it, and our customers really like the way the product is organized now.”

Notice how appreciations are different from typical corporate thank you’s. Here’s a typical corporate thank you. For best effect, read this with a deep blustery voice, “On behalf of the senior management team, we thank the Foosis project for their time and effort. Great job everyone!”

Nothing personal about that thank you. What did the Foosis team do? Is the company going to use it? Did it make a difference?

When you appreciate someone, you’re thanking a specific person for a specific action, and explaining how that action was personally valuable to you.

Not bad for one or two sentences, eh?

(I appreciate you J.K.R., for creating such wonderful characters that engage and encourage reading by all ages.)

convert this post to pdf.