Monday, March 15, 2010

Self-Facilitation Skills for Teams

(c) 2004-2010 Esther Derby

Self-organizing teams don’t just organize the technical work. They make technical (and non-technical) decisions. Not every situation requires facilitation, but when a team faces an important decision, applying facilitation skills to the problem saves time and yields better results.

Jason was frustrated. The Release 6.0 team had been chewing on a major design decision for two weeks. Jason knew they had to make a decision or they’d run out of time to pursue any option. Jason pulled the five other team members together and told them they weren?t leaving the room without a decision.

Jason started restating the option that Sara had put forward last week.

“I don’t see how that?s going to work,” Josh said.

“Well, I don’t hear you coming up with any better ideas,” said Sara.

“We could go back to the idea Alan suggested last week,” offered Jen.

“Look, we?ve been going back and forth between two ideas, and we’re no closer to a decision now than we were two weeks ago.” Jason sighed and looked around at the rest of the team members seated at the conference table. “You guys got any other ideas?”

Alan and Keith shook their heads. Jen shrugged.

“Fine. We’ll go with Sara’s idea,” Jason said. “We need to move forward or we’ll miss the market window for Release 6.0 completely.”

The Release 6.0 team filed out of the conference room. None of them really liked the idea–not even Sara. But after two weeks of rehashing two competing ideas, the team was tired of talking.

Like the Release 6.0 team, many groups struggle with decisions. Some groups pounce on the first plausible idea only to find out later that they’re down a rat hole. Other groups discuss and argue endlessly and never reach a decision. Still others choose by default or let the loudest voice decide.

In order to make timely decisions that the group can support, teams need to be able to:

  • Generate ideas
  • Narrow the number of options
  • Reach agreement
  • When I see teams who argue endlessly, can’t decide, or pick an option no one supports, one (or more) of these elements is missing.

    There are dozens of techniques and methods that can help teams reach decisions. Here are three that will help with decisions that require broad support and buy-in. I’ve chosen these methods because I’ve seen teams use them successfully without extensive facilitation skills or a great deal of practice.

    Generating Ideas

    There’s no shortage of good ideas in the world. But sometimes, when people are under pressure, ideas are elusive. Many teams generate one or two alternatives and then stop. That’s not enough. Teams need at least three alternatives to have a real choice. Plus, thinking of three alternatives helps the group explore the problem.

    Consider using a combination of brain writing and affinity clustering to generate many ideas in a short period of time. [1] Pairing these two techniques allows the group to integrate ideas and find common threads. Traditional brainstorming results in a laundry list of ideas and favors the people who are most vocal. This technique includes individual work, so people who need a bit of quiet time to think can participate fully.

    Here’s how it works:

    Write down the problem the group is trying to solve in the form of a question and post it where everyone can see. This question will help the group focus their thinking. Here are some examples from groups I’ve worked with.

    “What are the risks of implementing the foo feature without backward compatibility?”

    “What are ways that we can increase throughput in the amortization function?”

    “How can we effectively test the risk areas of the product with our current hardware resources?”

    “What are practical ways we can improve communication on the team?”

    “What are the most important values we hold as a team?”

    Allow 5-10 minutes for individuals to write down their own ideas. Ask for at least ten ideas. When the time is up, form groups of three or four to share individual lists. Have the small groups identify the best ideas and write them on sticky notes. There are bound to be duplicates between groups, but don?t worry–duplicates show where there is common ground.

    Using a wall or a whiteboard, post the ideas and cluster them into affinity groups. Don’t start with a set of categories; allow the categories to emerge from the ideas. As people move the ideas into affinity groups, they’ll talk about how ideas are related, which are distinct, and how they fit together. These conversations help the team learn about each other’s ideas. When the affinity clusters are settled, name each cluster. The name represents the group’s agreement on the underlying ideas in each cluster.

    Brainstorming and clustering will generate 5-7 alternatives in about 30-40 minutes. Sometimes the alternatives warrant further development before the team evaluates them. Organize small working teams to flesh out just enough detail to permit an assessment.

    Narrowing Options

    When I see a team stuck evaluating alternatives, it’s usually for one of two reasons: 1) People don?t have a common definition of the options under discussion, or 2) the group is talking about all the options at the same time.

    To ensure that everyone is working from the same definition, write the key points of each alternative on a flip chart and post it where everyone can see it during the evaluation step. Review each alternative and clarify as needed before starting the evaluation.

    Overcoming the second problem takes some discipline: Evaluate each option on its own before comparing options to each other.

    You can do this by drawing two lines on a piece of flip-chart paper, creating three columns. List the “plusses” and “minuses” of the options in the first two columns. Make a note of what’s interesting about the option in the third column. Answer all three questions for one alternative before moving on to the next.

    Alternative 1
    Plusses + Minuses - Interesting

    After the group has completed this activity for all the options, it’s usually obvious that some of the ideas are unsuitable.

    Agreeing On an Option

    An individual making a decision may agonize over it, but when more than one person is involved, it can turn into an argument. Teams need a way to test their agreement, discuss concerns, and arrive at a decision that all can support.

    The Romans indicated their will in the gladiator’s arena with a thumbs up or a thumbs down. A modern modification of Roman voting helps teams arrive at a decision.

    Thumbs up = I support this proposal.

    Thumbs sideways = I’ll go along with the will of the group.

    Thumbs down = I do not support this proposal and wish to speak.

    If all thumbs are down, eliminate the option. On a mixed vote, listen to what the thumbs-down people have to say, and re-check agreement. Be cautious about choosing an option if the majority are thumbs sideways: This option has only lukewarm support.

    This technique generates consensus. Consensus doesn’t necessarily mean complete unanimity. Consensus means that everyone must be willing to support the idea, even if it’s not his personal first choice.

    Sooner or later, you’ll have a situation where one person withholds support for any option. Manage this situation before it happens. At the start of the consensus process, set a time limit:

    “We’ll work really hard to reach consensus until the end of this meeting. If we don’t have agreement by that time, we will

    turn the decision over to _________, or

    take a vote, or

    __________ (a technical expert, coach, manager) will decide.”

    Most people don’t hold out to be obstinate; they are responding to a deeply held value or belief. Often the lone holdout will move on, but not at the cost of relinquishing an important belief. Respect the belief, use your fallback decision-making method, and move forward. However, when a group seldom reaches consensus, but instead relies on voting or deferring to authority, it’s a sign there are deeper issues at play.

    Putting the Techniques to Work

    When the Release 6.0 team held their project retrospective, the team identified decision-making as an area they wanted to improve. Of course, not every decision requires a formal process; but when important decisions come along, the team saves time and energy by applying techniques like the ones I’ve described.

    If you notice your teams are stuck in one (or more) of the three decision areas, point out what you’re observing. Ask the team if they are willing to try something different to help reach a decision. Then hand them a copy of this article and try the appropriate technique. Teams who learn to self-facilitate spend less time churning and more time on the business of the business.

    [1] Adapted from the Technology of Participation methods, The Institute of Cultural Affairs www.ica-usa.org
    convert this post to pdf.

    Thursday, March 4, 2010

    Skills for Software Smoke Jumpers

    ©2007 Don Gray

    Do you know about smokejumpers? They’re brave, self-sufficient firefighters who parachute into remote areas wearing eighty pounds of gear and ready to fight a forest fire. If the jump goes well, they land safely. After extinguishing the fire, they may have a ten-mile hike out. It’s not a job for the faint of heart, slow of mind, or weak of back.

    Have you considered that you may be a smokejumper? Think about it: Many of you join software projects midstream because sometimes a project needs additional contributors – some add brains, others brawn. Sometimes mentors are needed to improve project performance. Sometimes management needs an outsider’s view of the project status.

    No matter why you join a project after it begins, you will encounter challenges. To be successful you must:

    • Determine your role
    • Build trust
    • Learn the territory
    • Gather information
    • Do your job
    • Declare victory

    Determine Your Role

    “If you don’t know where you are going, you’ll probably end up somewhere else.” – Laurence J. Peter

    Smokejumpers work on well-defined teams. Everyone has a job to do and knows how to do it. Before jumping into a project you should determine your role. Ask:

    • What specifically is my sponsor asking me to do?
    • How can I demonstrate to my sponsor that I have been successful?
    • What will my relationship be with others on the project?

    Knowing what my sponsor wants keeps me focused. Difficulties arise when the sponsor has trouble explaining the problem. He knows the project is late and he wants better quality, but he can’t say exactly why the project is late or what’s creating sub-standard quality. Generally, the greater the pain (lateness, poor quality), the less articulate about the problem the sponsor becomes. When this happens, I like to use the SMART acronym Johanna Rothman describes in “Release Criteria: Is This Software Done?” (STQE magazine, March/April, 2002). SMART reminds me to get a problem definition that is: specific, measurable, attainable, relevant, and trackable.

    Next, I need to know what “done” means. Knowing how I’m going to demonstrate “done” gives me information on what to track so I can provide my sponsor the information needed to prove the fire is out. A good question to ask is “What will you see, hear, and feel when this problem is solved?”

    I often use a simple reporting format when I check in with the people for whom I’m working. I describe what we’ve done since our last discussion, what we’re currently working on, and any barriers to progress we’re encountering.

    Last, but not least, I need to know who I will be working with and in what capacity. Based on what I’m being asked to do (brawn, brains, mentor, or project review), I’m going to relate to the team in different ways. I may be a coworker, a coach, or an investigator. Knowing which role I’ll be in guides me as I work on getting a demonstrable “done.”

    Currently, I’m working with a client whose staff has been trying to solve a problem for a month. In our kick-off meeting, we established that my job was to get the project “done,” and they don’t care how. On this project, “done” means all the applications have been switched to the new server and tested and the old server decommissioned. I’m going to function primarily in the brains/brawn role, as a coworker helping solve the problem. Along the way, however, I’m going to be asked, “Why couldn’t the team solve the problem?” which will put me in an investigator/reporter role.

    Build Trust

    “The first thing to build is trust.” – Brad Appleton

    Smokejumpers work in integrated teams to put out small fires before they spread or to provide additional manpower on larger blazes. As a project smokejumper, it’s likely you’ll be joining a pre-existing team. So when your boots hit the ground and your chute is secure, you’ll need to hook up with the team. Your success in working with this team will depend on how well you understand them and how much they trust you.

    Building trust is a relatively straightforward activity. If you say you’re going to do something, do it. If you say you’re not going to do something, don’t. The team – and its management – will be looking for discrepancies between your words and your actions. Building trust is an action-based activity. When I hear “Trust me!” from someone I do not know well, that is a red flag that throws me into the “Put up or shut up” mode. So make commitments and meet them.

    Keeping activities, information, and decisions visible helps build trust. It’s not always possible to achieve immediate success (however minor it may be). Keeping things in the open helps allay fears, enhances communication, and enables better decisions. On one of my jumps, a team member heard me discussing a spreadsheet I was using to keep track of assets, current status, and needed changes. He asked for a copy of the spreadsheet and later returned it to me with the names and phone numbers of the key people I should coordinate with at each plant. By sharing the information I had, I received more.

    Asking questions opens the door for team members to share what they know about the fire. Listening to and understanding their answers creates rapport and builds trust. This also helps you learn the territory and gather information.

    Learn the Territory

    “You gotta know the territory.” – Meredith Willson in “Rock Island” from The Music Man

    “I know the territory.” – Meat Loaf in “I’d Do Anything For Love” from Bat Out of Hell II

    Smokejumpers work in an ever-changing environment where understanding the territory can be the difference between putting out the fire and not making it out alive. Their territory includes fuel types, wind direction, and the topography where they’re working. Changes in any of these can change the possible outcomes quickly.

    Project smokejumpers also work in highly dynamic environments. Personality differences fuel the project flames. Some team members may be more equal than others. Who’s really in charge? Even though someone can’t help me, can he hurt my ability to succeed? Changes in any of these can quickly change the possible outcomes.

    In all my years of jumping, I never have landed in a situation that lacked energy. Most situations follow the pattern of a jump I did a couple of years ago. For reasons no one could determine, a stable, proven process suddenly started generating a 25 percent defect rate. The Big Boss flew in from the home office to handle the situation personally. On Saturday, I got the call to jump. When I arrived Monday morning, I surveyed the situation, listened to the management screams and the worker apologies and decided it was a good time to be calm. I took a deep breath and started asking questions.

    In her book Communication Gaps and How to Close Them, Naomi Karten lists my three favorite questions:

    1. How did you happen to come here?
    2. What do you expect will happen here?
    3. What do you hope to accomplish here?

    She also says, “Notice that the first question elicits information about events from the past; the second, the present; and the third, the future. All three questions provide a starting point to help you determine what’s important to the person or group with whom you’re trying to communicate.” These questions represent starting points for learning the territory.

    The responses to the questions indicate how safe the person feels. Short, simple answers may be a tip that the person isn’t feeling safe. Perhaps there’s a blaming corporate culture and whoever’s holding the blame when the music stops gets fired. It could be personality conflict on the team. Unresolved conflicting management agendas can cause a “CYA” environment. If the environment isn’t safe for the employees, it’s not going to be safe for the smokejumper, either.

    The key to success and survival hinges on the smokejumper’s ability to ferret out information about why the person doesn’t feel safe. If I haven’t created a trusting relationship, I won’t get the information I need to learn the territory. I talk to as many people as possible, which allows me to draw a more accurate map to help me navigate the territory.

    Do the answers’ content and delivery style agree with each other? I remember one project manager yelling at me about how well he had done on a previous project and how this project wouldn’t fail. I wondered why he chose to do this project differently, but decided to keep

    my mouth shut. He was partially correct. The project didn’t fail, but he and his company (the management team) were terminated six weeks later. It took us another year of development to complete the estimated twelve week project.

    Gather Information

    “As a general rule, the most successful man in life is the man who has the best information.” – Benjamin Disraeli

    Smokejumpers receive information about the fire before they board the airplane. How big is the fire? What are the weather conditions? Which way is the fire headed? Are there obstacles to overcome? Where are the safe zones? As soon as they land, their first action is to verify the information and determine if anything has changed. Project smokejumpers start gathering information during the first conversation with the client. What’s the nature of the problem? How long has it been going on? What already has been tried to solve the problem? You need to gather information about the technical fire you’ve been asked to put out.

    I once jumped to solve a “three systems quit working” problem. After listening to the problem description, I thought about the symptoms and several possible cause/effect scenarios came to mind based on other successful jumps. I continued to ask questions, and one by one

    ruled out the possibilities. When I jumped, all I knew for sure was a problem existed. (For the curious, the software quit working because someone created separate IP subnets, and the computers couldn’t talk to each other because the inexpensive routers couldn’t bridge the subnets.)

    Project smokejumpers compare this information against their past experiences. What appears to be the same? Is something new or novel? This provides the project smokejumper with an initial problem assessment. This is both good and bad.

    The difficulty with this initial assessment comes when it leads us to ignore new data. Since we have an idea of what the problem is, we may believe we have the answer. As Lee Copeland points out in “Believing Is Seeing” (Better Software magazine, December 2006), the Bruner-Postman experiment shows that our experience can blind us to reality. Keeping an open mind and being willing to change conclusions go against our own biology, but both are necessary when you’re jumping into complex situations.

    Try to find both positive support and negative indicators for the problem you’re trying to solve. In my career as an emergency medical technician, I was taught to evaluate data and revise my understanding using the following checklist:

    • I expect to see something, and I do.
    • I don’t expect to see something, and I don’t.
    • I expect to see something, but I don’t.
    • I don’t expect to see something, but I do.

    We can use this new data to modify our problem assessment. This forces a rethink and possible restructuring of our problem assessment. It takes time but opens the door to a better assessment and solution. The other choice is to ignore the information or modify it to fit our problem assessment. This doesn’t require rethinking and restructuring our assessment. It also opens the door for high-impact learning when the information we ignore comes back to burn us.

    The technical problem could be something as simple as finding that the computers are on different subnets and thus cannot communicate. Maybe it’s helping the team come to grips with the “process du jour.” Perhaps the team’s engineering practices need modification to achieve the project goals. Whatever the technical problem may be, expect that it will be difficult to solve. If the problem had been easy, the team most likely would have solved it already.

    Do Your Job

    “For every complex problem, there is an answer that is clear, simple, and wrong.” – Attributed to H.L. Mencken

    Smokejumpers use different tactics to extinguish fires. If the fire is small enough, they may directly confront it. For other fires, they may use an indirect approach of control lines and backfires to deprive the main fire of fuel. When the fire really gets going, they may have to wait for something to change – the type of fuel, the weather, the topography – before they resume fighting the fire.

    As a project smokejumper, how you attack the problem is affected by your role in the project, your ability to build trust, your understanding of the territory, and the information you’ve gathered together with the problem’s complexity.

    A brain/brawn role and a straightforward problem generally lead to direct action. This is how I dealt with a “software quit working” jump. I sat down at the computer and started checking settings, properties, and configurations. When I discovered two network cards, I started investigating more, and voila! There were the two non-mappable subnets.

    Mentoring or complex problems often require indirect approaches. I once spent three months helping a hardware team as it worked to get a hardened mobile router into beta production. Since management complained about not knowing where the team stood, I created a burn-up chart in the engineering space so everyone could see what remained to be accomplished and when we anticipated that it would be completed. The semiweekly status meetings asked the basic Scrum questions: What have you done since our last meeting? What are you going to work on? What problems are you having? I made sure I had the necessary equipment, so if there was a question, I could go in and work with the team. We made the target date with a few days to spare.

    Each style of doing things has natural consequences. If I decide to take control and work directly, I’ll miss an opportunity to let others learn through experience. If I let others learn through experience, what happens to putting the fire out? I like to use the following questions to help me understand the implications of my (mentally proposed) actions:

    • What will happen if I do?
    • What will happen if I don’t?
    • What won’t happen if I do?
    • What won’t happen if I don’t?

    The process of understanding your role through doing your job goes on the entire time you’re fighting the fire. It’s a continuous refinement process as the project smokejumper learns more about the technical problem, the team, and the interactions between them. And it’s not a linear sequence. Other than starting with determining your role, the rest of the activities happen randomly, simultaneously, and continuously.

    Declare Victory

    “The Lone Ranger Fantasy: When the clients don’t show their appreciation, pretend that they’re stunned by your performance – but never forget that it’s your fantasy, not theirs.” – Gerald M. Weinberg

    After they ensure the fire is out, smokejumpers head back to base, clean up, and repack their gear, getting ready for the next jump.

    Prior to heading out, project smokejumpers need agreement from their sponsors that the fire is out. This task combines defining a specific goal at the jump’s start and keeping progress visible. If you don’t know what you’re shooting for and when you need to hit it, you’re probably going to miss the target. Hitting the target gets you praised and paid.

    Declaring victory creates the opening to review your contributions to the project. Project smokejumpers often make technical contributions on a project. These are generally obvious, and most people would agree to them. Often more important are the less-obvious personal contributions. No one but the smokejumper may ever know the many little bumps, nudges, and guidance provided during the jump.

    I’ve just finished working with a sponsor who a week ago said, “Again, today, the reports did not get sent out. I guess all of our work was for nothing.” I reminded him that the problem involved two different systems, we had only corrected one, and that things would get better when we solved the problem with the second system. Today I heard the happiness in his voice as the second system came on line.

    The Smokejumper’s Life

    “You live and learn. Or you don’t live long.” – Robert Heinlein

    The smokejumper’s life consists of:

    1. Qualify for smokejumping
    2. Train
    3. Go to the fire
    4. Put out the fire
    5. Go to 2

    Over years of jumping, the training will change as the jumper becomes more practiced at current skills and learns new skills. Smokejumpers use all their skills, all the time. Being able to call on their training when they need to can mean the difference between an extinguished fire and an unhappy outcome.

    Project smokejumpers follow the same pattern. Somehow, somewhere, you start solving problems, and then someone asks you to jump in to help them.

    Project smokejumpers need to train continuously. Your technical skills may get you started, but it’s your people skills that help you solve the problem and keep it solved. In addition to reading magazines and books, I recommend attending experiential conferences or training courses where you’ll be able to learn new skills and practice them in a supportive environment.

    Jumping isn’t for everyone. Over the years I’ve missed birthdays and anniversaries. I once left a weeklong vacation after only two days to make a jump. Fortunately, my family loves me. It occasionally gets tense, so a sense of humor works to my advantage. Being an adrenalin junkie helps too. And it’s all worth it when a client says:

    “You know, Don, a couple years ago I watched you ‘join a team’ and help them work together better, when your charter was actually to get something shipped. You weren’t there to ‘fix them.’ But, you ended up helping that team and another team be better together.”

    That still gives me goose bumps.

    This article was originally published in Better Software, September 2007

    convert this post to pdf.

    Sunday, August 23, 2009

    Framing Your Thoughts for Management

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

    Danger = Blaming ©2009 Steven M. Smith

    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.

    Thursday, August 6, 2009

    Coaching Whiners

    (c) 2009 Steven M. Smith

    Ban whining. It’s destructive communication inside organizations.

    Why is whining destructive? How can a whiny complaint be transformed into a constructive, actionable proposal?

    You ask Anthony, who reports to you, “How are things going?”

    Anthony unloads on you like a dump truck unloading fertilizer, “I’m sick and tired of the mandatory meetings that your management is forcing me to attend. Management schedules these meetings at the last minute, which forces me to reschedule conflicting appointments and meetings. I’m losing credibility. And I’m pissed off about the poor organization of the mandatory meetings. I sit and listen to things that don’t matter to me. Attending these meetings wastes my time. Will this stupidity ever stop?”

    Please, whatever you do, don’t say, “I’ll see what I can do about the problem.”

    Utter those words and you take ownership of the problem. Anthony will rightly expect that you will do something about his problem. You are setting both Anthony and yourself up for disappointment.

    When you accept responsibility for the complaint embedded in the whining, you add to your own burden; you make communication indirect; and you fail to train your people effectively.

    Step back. Do you know what will satisfy Anthony? You can’t. I haven’t given you enough information to know. If you think you already know the problem and its solution, then you are assuming too much.

    By unloading on you, Anthony may already be satisfied. Ask him, “What would you like me to do?”

    You may be surprised to hear Anthony say, “Nothing. I know your management. That’s the way they do business. You can’t do anything.”

    But if Anthony says, “I want you to talk with your management about the problem.”

    Start training Anthony by replying, “Tell me the problem.”

    “I thought I already told you the problem.” says Anthony.

    “No. I heard a lot of things, but I didn’t hear a clear problem statement.”

    Antony looks down at your desk as he ponders your statement.

    “Uh…” sputters out of his mouth. “Uh… Scheduling mandatory meetings at the last minute isn’t fair?”

    You ask, “What’s the impact on you of scheduling meetings at the last minute.”

    “I have to reschedule other meetings and appointments at the last minute.” answers Anthony.

    You ask, “What’s the impact of these scheduling changes to the business?”

    “Some of the meetings I have to reschedule are with clients and some of them don’t like last minute changes.” replies Anthony.

    You verify the problem by saying, “So I gather the problem is that last minute mandatory meetings are hurting relationships with our clients.” And you ask, “Is that close?”

    Anthony looks you in the eye and says, “I know where you are going… That definition is close enough.”

    Continue coaching by asking, “What do you recommend that my management do?”

    Anthony continues looking you in the eyes as he replies, “I realize your management will need a few emergency meetings so I recommend that 90% of all mandatory meetings be scheduled at least one week in advance.”

    “Sounds good. Email me the complaint and recommendation so I can forward it to my management?”

    “My name will be on the message?” asks Anthony.

    “Yes, of course, it’s your problem. Right?”

    “Let me think about it. I’ll get back to you.”

    convert this post to pdf.

    Monday, July 20, 2009

    Temperature Reading

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

    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.

    Friday, July 10, 2009

    The Virtual Cyber Cudgel

    by Gerald M. Weinberg

    In 1977, Tom Gilb and I published a book called Humanized Input: Techniques for Reliable Keyed Input. We hoped to improve the pitiful state of input design for computer systems, and ten years later, we imagined we were beginning to see some improvement. On-line systems were coming into vogue, and we expected their use could only improve the interface between humans and computers.

    Alas, though some systems improved, there’s been a steady decline, especially in those parts of systems where the average user has to communicate something exceptional to a computer. Clueless developers of the computer system “design” whatever sort of interaction pops into their minds, while the poor user of their system has to conform to these designs, or else. It’s like arrogant nobles assigning tasks to powerless peasants. It’s a one-sided conflict?the developer side side has all the weapons. while the users have to take their lumps and just grin and bear it.

    But the Medieval world had its checks and balances, something we need in modern computing. In ancient Denmark, the laws of chivalry required that if a noble should ever duel with the peasant, the peasant had the right to choose the weapon. The nobles were trained in fancy weapons such as swords and dueling pistols, but the peasants had a preference for pitchforks and cudgels. As a result, any sensible noble went to great pains to settle disputes graciously with any peasant, no matter how gross and crude they might seem.

    We need something like a cudgel to redress the balance between ordinary people and poorly crafted systems produced by thoughtless designers. Cudgels and pitchforks, however, could be found around any peasant household. Furthermore, there was a legitimate reason for them to be there. If the nobles wanted to eat, they could hardly outlaw pitchforks.

    One way to fight the arrogance and insensitivity of computers is to use your own computer as your cudgel, but you don’t have to own a computer to be arrogant and insensitive. For those readers who lack a peasant’s pitchfork experience, I have catalogued a number of specific thrusts and countermoves. I’ve learned these tactics from the enemy, from the online and paper forms I’ve had to navigate to request support, report bugs, reconcile billing disputes, claim rebates, or register products.

    1. Insist that any communication with you will have to go through your computer, and thus conform to the computer’s requirements, because “everyone knows that computers cannot be made to change in response to every trivial problem that people are having.”

    2. The required information will have to go on a form, one copy of which you’ll supply upon written request on another form.

    3. They will have to use the original form?no copies, please. If they should make a mistake in following the simple and convenient rules, they may write another letter and request another form. Without the original form, “our computer might not be able to read it.”

    4. Every piece of information requested on the form must be supplied. Nothing must be left blank, even when you already have that information recorded accurately in your computer’s files. To leave something blank would “require our computer to spend extra time accessing the information.”

    5. Where information requested duplicates information already in our computer files it must be identical, character for character, including spaces. If someone asks you why it must be identical, you say that “our computer will be confused if it checks the information and finds differences.” If they ask why the information is needed, inasmuch as our computer is going to access the original in order to check, you reply that “the computer may decide not to check, and we can’t tell in advance which cases it might check.” (This is true by default because you don’t really have a computer.)

    6. Every item you fill in on the form must adhere strictly to our specified format, otherwise reject the form. Don’t accept alternatives that might be clear to human beings, because “they will require extra coding steps.”

    7. The specified formats must be chosen to be unfamiliar to people, such as,
    a. Last name first, first name last
    b. Fill in all leading zeros, the more the better
    c. Year, day, month
    d. Local phone exchange, number, then area code
    e. Zip code, followed by street address, then state and city
    f. Numbers in scientific notation
    g. Binary coded numbers
    (And, yes, believe it or not, I’ve encountered each of these cases.)

    8. Because you can’t be certain that the formats in [7] are unnatural to people accustomed to working with computers, require that each time a similar item is needed, a different format is requested. For instance here are some variations in the dates I have had inflicted on me:
    a. 2009 July 17
    b. 17/7/09
    c. 17/07/09
    d. 17 VII 2009
    e. 17-JUL-09
    f. 7,17,09
    g. July 17, 2009?but be careful of this one, it’s almost understandable.

    9. When numbers are needed, it’s best to have them be as long as possible. If they don’t have any long numbers, make up some. Since human memory is pretty reliable up to seven digits, it’s best to require at least 10 digits, but do not allow any internal punctuation. If you ask for 234-789-4001, they might get it right half the time, but 2347894001 will cut that percentage down to size. Also, every extra digit beyond 10 will pay huge dividends in erroneous forms, which can then be returned with rude notes implying inferior intellectual development. An effective technique is to pad out the number with large numbers of leading zeros, as in 00000002347894001. (How many zeros is that, anyway?)

    10. If you can get away with it, use at least two pages, back-to-back, for paper forms. A second page gives lots of special possibilities, such as,
    a. Information on the back that has to be copied onto the front, and vice versa.
    b. Information on the back that’s needed to understand the items on the front, and vice versa. For instance the set of codes that are to be used on page 1 can be listed on page 2. This technique works well with pages on websites, too.
    c. Consecutive pages should be printed on opposite sides of one very porous and translucent sheet of paper. This technique guarantees that material from the other side will show through when copying. It also allows ink to flow through from one side to the other. Naturally, you don’t allow pencil, and require both sides to be clear of extraneous material.

    11. Because multipage forms allow copying from page to page, you have the opportunity to impose difficult copying tasks. For instance, on page 2 you can require copying the form number from page 1, just to make sure that “the two sides of the paper don’t get separated.” An appropriate form number is 1783562812354678-1A.

    12. Limit names and addresses to 20 characters each?or 18 if you dare?but do not allow truncation. If Daniela Schimmelpfennig complains, tell her she has no right to have a name that confuses computers. Suggest that she change her name to something more reasonable. Or, simply truncate her name in any way you like? Daniel Schimmelp, for example.

    13. When a limited field is required, allow far more space on the form than is allowed in the computer. For instance, if a number is limited to 12 digits, use a 13-digit space on the form. If possible, make no comment, but if your conscience bothers you, write an instruction saying, “For type A use leftmost 12 digits. For type B, use rightmost 12 digits.” Be sure there are several A’s and B’s on the form, thus creating doubt as to which is meant. This technique ensures that at least half of the forms will be wrong just as if you had given no instructions.

    14. Where the required information is essentially unlimited in length, use a space that is patently too small. An excellent example is these instructions:
    “Please explain your problem in your own words, giving all relevant information that might bear on our providing you with better service in the future.” Then limit the response to 40 characters and/or follow this instruction with a space no longer than three quarters of an inch.

    15. If you can’t make the instructions actually contradictory, as suggested in [12], at least use sufficient jargon to ensure that they can’t be understood, as in [13]. If you do this well, the people using the form will feel like fools.

    16. Jargon from [13] can be combined effectively with instructions given in the form of computer programs as in
    “If the audit interval is greater than the contemplated discount, then enter the appropriate rate code from the conversion table on page 2 in place of the discount code, unless the audit interval falls within the operating system recovery. Or line 17 of page 2 will be left blank when following the instructions on that page under item 2.1.7.3.9.2.4/a.”

    17. When giving programmatic instructions, it is best to have at least one backward reference, such as (on line 5-1 on page 2), “If this figure is negative, change the value in line 17B., page 2 to zero.” Working in ink, this is sure to confuse, but just in case they have the sense to make a trial copy, include at least one cyclic reference. For instance, back on line 17B on page 2, you could say, “if this value is zero, change any negative value online 5.1, page 2, to positive.” (Notice the inconsistent notation: 5-1 in one place, 5.1 in another. Inconsistency always helps increase confusion.)

    18. Set rigid deadlines for receipt of the form, and indicate that if the deadlines are missed, you cannot guarantee any particular date for a response. Then mail the blank forms so they arrive on the deadline date. (The next day is not as good as some people just give up in despair. It’s better if they try to meet impossible deadlines and spend much money on special postage.)

    19. Naturally, the forms may not be folded, spindled, or mutilated in any way.

    20. Following these rules when responding to cyber crud ought to equalize the odds a bit in the never ending battle of peasants against the nobles. But just in case the above 19 rules don’t quite convince them that you actually have a computer, here’s one more that’s sure to crush all the remaining resistance:
    Make sure your form is 1 mm wider than the handy return envelope you provide.

    A Word to Designers

    Maybe next time you design one of these interfaces, you’ll take off your cloak of nobility and, for a few minutes at least, don the shabby rags of us poor peasants who are forced to use your product. You can do that, because, like me, you’ve also been on the peasant’s side more than you’d like.

    convert this post to pdf.

    Friday, May 29, 2009

    Drawing Out the Facts: The Art of the Discovery Interview

    (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 steve@stevenMsmith.com.

    convert this post to pdf.

    Monday, April 6, 2009

    Catch Them Doing It Right

    (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.

    Sunday, March 5, 2006

    Communicating Up

    © 2004 Esther Derby

    This column originally appeared on Stickyminds.com

    Imagine this scene – you’ve just gotten back from lunch and you’re checking your email. The first email you open is from the VP:

    Effective immediately, starting with the release currently under development, our flagship product, SalesSupport, will be converted to use a proprietary data base in place of the current SQL DB . Deploying SalesSupport with our ClientMaster(SM) database will enable us to realize cross-marketing opportunities and increase revenue substantially.

    As you read the email, you start to feel queasy. You realize that changing to this database means that the third-party contact management component you are using won’t work. You’ll either have to get the vendor to build a one-off that will access the ClientMaster(SM) database or modify the component in-house.

    Good luck waiting for the vendor to make the new version. And if you change the component in-house, it won’t be a one-time job: every time the vendor comes out with a new version of the component, you’ll have to customize that code, too.

    How could the VP make this decision? How could he be so dumb?

    You know this will cost money and customers. You hit the reply key and start to list all the reasons this is a really bad idea.

    If you’ve ever been in this spot, you know that sometimes telling the big boss he’s about to be an idiot works and some times it just gets your butt kicked.

    Communicating effectively up the chain requires some finesse:

    Suspend Judgment
    Most likely, the managers in your company aren’t stupid people. The decision may make sense from a perspective that you can’t see right now.

    One day I came to work to read an edict that every project must provide evidence of compliance with a certain of-the-shelf methodology. Never mind that most of the department had no training in the methodology and didn’t have access to documentation for it. Development managers were told they must comply or provide evidence explaining why their project should be exempted from the requirement.

    In terms of changing the way teams developed software or improving project performance, this was about the most nonsensical thing I had ever heard.

    Then I learned that top managers in the company had made a strategic decision to enter a heavily regulated line of business. In order to receive approval to compete in this arena, the company had to pass an audit – an audit to establish that the development area adhered to a repeatable development process.

    That bit of information explained the focus on compliance and producing documentation for exceptions. The goal of implementing a methodology wasn’t to improve the quality of the software or the predictability or projects. As long as the methodology helped the company past the audit, it was a success.

    If you can’t imagine a scenario where the management decision would make sense, ask around. But ask in a way that doesn’t imply anyone is stupid. Questions such as “What’s the intent behind the database decision? I’m puzzled about how the vendor upgrades will be handled,” will work better than “Didn’t they think about the upgrade path?”

    Perhaps you aren’t the one missing some information. Perhaps management is missing some information. Hierarchy tends to act as a filter: often at the top of the company, managers are making decisions based on financial statements and cost benefit analysis (CBA). Top management may not be in touch with all the detailed operational aspects of how employees actually move product out the door.

    If this is the case, you may have information that will help them make a better decision. Figuring out how to get information up the chain effectively requires some savvy and some planning.

    Assess the Lay of the Land
    Hold off on the reply button a bit longer and don’t barge into the VPs office just yet. Look around your organization to see how information flows up. Can the newest programmer sit down and talk to the VP of development? Does communication follow the org chart? If you’re not sure, watch for a while. What happens to people who bring up problems to their bosses boss? Do they get a fair hearing without retribution? Or are they sidelined forever?

    If your organization communicates only along the chain of command, work the chain. If you hit a brick wall at the first level, you need to decide how important it is to you to push the issue further. Is it worth having your boss chew you out? Is it worth loosing your job? I’m not saying those responses right, and it is the reality in some organizations. Look around and decide how much it’s worth to you.

    Some organizations are different in different areas. I worked in one company where it was ok to skip levels in the development organization, but not in the test organization. The key managers in the test organization were ex-military. In the test organization, issues went step-by-step up the chain of command or they didn’t go at all.

    Speak the Same Language
    State your position in a way that maps to management concerns and in language they’ll understand – which usually means money. Going technical on a manager who has never worked in the technology arena will cause his eyes to glaze over.

    First, identify one-time costs like development, testing, additional hardware or infrastructure, documentation, conversions, and rollout. Then list on-going costs: continued maintenance and support, modification of new versions, licensing agreements, and so forth. Don’t forget customer-related costs and consequences.

    Do Your Homework
    Don’t just walk in and say “Hey, this will cost a lot.” A complete cost analysis isn’t necessary, some level of factual information is. If you aren’t fluent in budgets and capital expenditures, find someone who is knowledgeable to coach you. If your manger is supportive of your efforts, she can help you with fully burdened development costs, equipment costs, or license costs for the product you work on. And I have found that the folks in accounting are often quite happy to explain how budgets work.

    Sum up your findings in financial terms and lay out customer consequences.

    Persist, within Reason
    If the manager you approach doesn’t take you seriously, ask “What information would you need to see to reconsider this issue,” or “Who would you trust to tell you that this is an important issue?”

    If the manager tells answers positively, dig up the information and interview the people he mentioned. This can be a lot of work – but it show that you take the issue seriously; you’re not just a whiner.

    If he answers that nothing will convince him to reconsider or there is no one he’d listen to, be willing to drop it.

    Take a little trouble preparing how communicate up the chain. It may take a little while, but if you do it right, you’ll look like a leader and you may save the company a serious misstep. When the SalesSupport team showed the VP that it would cost $2 million to migrate existing customers to the ClientMaster(SM) database, he changed his mind.

    convert this post to pdf.

    Communicate Early and Often

    ©2002 Naomi Karten, www.nkarten.com

    Have you ever had an experience where you gave your all for your customers and still they were unhappy? One possible reason for their reaction is that you implemented a major change without preparing them for it. In the absence of information about what they can reasonably expect, customers form their own conclusions about your motives.

    In two organizations I visited, I came across situations which aptly illustrate how the failure to communicate with customers can have serious repercussions for the reputation and credibility of the provider. Unfortunately, these situations are far from unique.

    Situation 1: Doing to customers, rather than with them

    This first organization embarked on a technological upgrade that entailed replacing a significant amount of the desktop hardware and software that employees (internal customers) had grown accustomed to. Not a trivial transition, to say the least.

    For many people, mandated change from the familiar to the unfamiliar is unsettling, even when the change will ultimately yield many benefits. Given the magnitude of the upgrade, information for customers about the upgrade and how it would take place would have been wise.

    Unfortunately, however, customers received no explanation from upper management to prepare them for the upgrade. As a result, they had no basis for understanding its purpose, scope, or business benefits. To make matters worse, they lacked an appreciation of the steps they could take to contribute to its success, which only made the job harder for the technical staff. In short, those most affected were unprepared for the change.

    Is it any wonder that customers reacted with intense negativity when technical staff arrived to “tamper” with their computers? And since many customers experienced an unanticipated period of degraded system performance, they saw the upgrade as a colossal disruption. Their widespread reaction was, “Why are you pushing this down our throats?”

    Customers often complain that they don’t understand the reasoning behind the policies and standards imposed on them. After all, no one has communicated with them, prepared them, or involved them in the effort. As a result, they perceive the efforts “on their behalf” as arbitrary, thoughtless, and in some cases, even malicious.

    Under such circumstances, customers understandably lose trust in their service providers, and providers face an overwhelming challenge and invariably, much more time that they anticipate to build back that trust.

    Situation 2: Keeping customers in the dark

    A Network Support Group concluded that the network in a particular customer area faced looming problems and needed to be taken offline for maintenance. The technical Wizard-In-Charge scheduled this maintenance during work hours. A thoughtless decision? It sounds like it, but his decision was based on sound financial thinking: Network maintenance was handled by an outside firm which charged A Big Chunk of Money for daytime work, and A Big Chunk and a Half for after-hours work.

    So sure was the Wizard that the more cost-effective daytime maintenance was the right thing to do that he didn’t think to tell his customers the reason for his decision. Neither did he ask for their input. In his view, they were just a bunch of complainers, always grousing about one thing or another. Besides, this was a technology matter, and what did customers know about that? As a result, his customers were kept in the dark and so, during peak hours, was their network. All his customers knew was that the network was done and they couldn’t do their work.

    Penny-wise and pounds of foolish

    When efforts are undertaken on behalf of customers without keeping them in the loop, the affected customers often see the effort as yet another hare-brained scheme by those #$%!@& people who want to sabotage their productivity and complicate their already complex lives. The offending party, meanwhile, doesn’t understand the customers’ negativity. The sad part is that customers can sometimes offer options that provider staff might never have thought of.

    And so it was in this network situation. The customer manager contacted the Wizard to ask why the network was done. The manager’s confrontational attitude puzzled the network maven, but he was certain that his explanation about the Big Chunk and a Half would impress the manager. Instead, the manager became even more upset, and said: “If I had known that was the situation, I would have gladly offered to pay the difference between the daytime and after-hours rate so that we could have kept the network in operation during the day.”

    How often do you make decisions that affect your customers without considering their perspective, communicating your plans, explaining your rationale, and inviting their input? What changes do you need to make so that your answer to this question is “Never”?

    convert this post to pdf.

    Bi-Quinary Search

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

    “1,073,741,823 lines of correct code, but one unknown bug is going to send us into that Sun.”

    “Do not panic.” Peri said, using Calming Voice. “We have adequate time to find it.”

    “Peri is correct,” echoed Setho. “Remain logical. We must divide the code in half and allow the simulator to find which half contains the defect. Once we repeat this process 30 times, we are guaranteed to find the culprit.”

    “I know I couldn’t have designed this ship,” I said, “and you’re absolutely right about the process. But you have no concept of time. Each test will cost us 10 minutes, and in 4 hours we’ll pass the point of no return. Yes, an hour after that, we’ll be able to unlock the controls, but it will be too late. Perhaps you Zaard will be satisfied to choose your personal sunspot for cremation, but it doesn’t do much for me.”

    “We will remember our ancestors,” said Peri, twisting into the Zaard meditation posture.

    “Yes,” Setho agreed, in posture as in words. “Termination of existence is the only logical conclusion, so remembrance of ancestors is the only logical action.”

    “Don’t go to sleep on me. There is a way, if we’re lucky.”

    “Luck is a human concept,” Peri said, his voice slowing and sinking. “Do you really think you can find one out of a billion lines of code by luck?”

    “Peri,” said Setho’s Chastizing Voice. “Please be respectful. We must not interfere with his religious beliefs, no matter how preposterous they are to us. Proceed with your foolishness, John, if you wish. We shall watch, and pray for your soul.”

    “I could use more help than that. I figure that if I can guess a division of the code that puts the bug in the smaller half, I can accelerate the process.”

    “Your assumptions are incorrect. Though you name it ‘code,’ we know it is Leethaa, not some simple computer instruction.”

    “Doesn’t matter what you call it. If we find the Leethaa, or code, that’s wrong, we can change it through the console.”

    “True. We can change it, but if we merely know it is wrong Leethaa, that still does not mean we know what is right Leethaa.”

    “Of course you’ll know. You built it.” Peri and Setho exchanged another look, and the odor in the compartment changed. “I’m just a passenger, remember, like any human, taking advantage of your intergalactic freight service. You’re the designers.”

    Setho turned several of his eye to me, but spoke to Peri. “Since we are all to end our existence, in a few hours, can there be harm in telling him?”

    No, the memories of our ancestors will not be harmed.”

    “Tell him what? And don’t talk about me like I’m not here.”

    “We Zaard are not the designers of these ships. We, too, are passengers, enjoying these gifts from our ancestors, countless time in the past. We do not know how the Leethaa operate, but only how to repair them when they fail.”

    I was quickly rearranging all I thought I knew about the Zaard. Too bad I wasn’t going to be able to tell anyone. “Then how can you repair it?”

    Setho was about to reply, but Peri raised an appendage and used the Interrupting Voice. “We use the binary search, using the simulation logic, as I explained. When we locate the offending Leethaa, we alter its state – le to eth; eth to aa; aa to esu; esu to culara; culara to le. Those are the five possible states, as I believe you well know from observing us through these months we have flown together.”

    I didn’t know they had been watching me watching them, but what did it matter now. “Fine,” I said. “So once I locate the right Leetha through my guessing, you can make it right.”

    “True, but guessing depends on luck, and we do not believe in luck. You will not find it.”

    “Moreover,” said Setho, “even if we were to assume your false premise about the existence of luck, then we would logically have to accept the existence of bad luck as well.”

    “And with bad luck, your guessing process would actually take longer.”

    “Hey, we’re going to fry anyway, so what more do we lose if it takes longer? Besides, I need your help.”

    “We cannot help with luck. We can only remember our ancestors.”

    I swept my gaze over the full circle of consoles. “Then call it ‘intuition,’ if you don’t like luck. You two know a lot more about this vehicle than I do, and your guesses may actually be better than mine.”

    “But we already told you, we don’t believe in guessing.”

    “Well, one thing for sure you do believe in is arguing, and arguing for sure isn’t going to save our skins. While we’ve been having this lovely philosophical discussion, I’ve been running my first guess. It should be done in 30 seconds.”

    “We noticed,” said Setho, who seemed the more alert of the two. “… And there it is. You see, it seems that the flaw is in the larger of your two parts – not the smaller one chosen by your guess – and now the process will take even longer.”

    “Okay, so it was bad luck. But if my luck turns better, we can make up the lost time.”

    The two Zaard merely exchanged more glances that I couldn’t interpret, so I made my second guess. “I think the transporter code is the most likely place, so I’ll make that one of the halves.” I entered the cutting point and restarted to testing process. “If it’s in there, we’ll be down to less than a million lines of code.”

    But it wasn’t there, and by the time we found out, I had already lost 20 precious minutes without reducing the problem significantly. Setho and Peri didn’t seem to mind, lost as they were “remembering their ancestors.”

    I started feeling warm, even though I knew that the sun’s heat would not be affecting our interior temperature for another couple of hours. Setho must have noticed.

    “Do not be distressed, John. Having remembered our ancestors, we are now at peace. Do you not have ancestors to remember?”

    “Most of my ancestors aren’t worth remembering.”

    “How sad. No wonder you solve problems by guessing. But surely your ancestors must leave you some worthy memories.”

    I paused to enter my third guess. It was even more risky, but I had to make up time. I felt it was more of a gesture than anything useful. Three hours and thirty minutes – 21 guesses – was all that was left.

    “None of them ever knew the Zaard even existed, so none of them ever toured effortlessly around the galaxy. What memories could they leave that would do us any good?”

    “True. Your history is so strange to us that I never thought that you might not have useful memories. How unfortunate that we know each other better only now.”

    “But your ancestors’ memories don’t seem any more useful than no memories at all, if they can’t help fix a failure.”

    “Oh, but they can. We have memories of all ship failures in the past, and how to repair them.”

    “Then why aren’t you fixing this one?”

    Setho gave me a look that even on his/her strange face seemed to say, “Don’t be a stupid Human.” What s/he actually said was, “Because our ancestors never encountered a bi-quinary star system such as this one, so there is no memory of this particular failure.”

    “But there were failures before?”

    “Of course, but not this failure.”

    “And how often do you have these failures?”

    “Among the entire fleet, perhaps once every thousand of your years. Would you like to know exactly?”

    “You mean you have a record of them?”

    Peri now joined the conversation. “Of course. We told you that we remember our ancestors.”

    “All of them?”

    “Yes, of course. What would be the logic of forgetting errors. We have a saying, ‘A Zaard who forgets his/her ancestors forgets how to stay alive.”

    My mind was racing, but my mouth was having a hard time keeping up because I was trying to keep my chest from swelling with hope. “Okay, how many have there been, since the beginning? Or is that too hard?”

    “Why should it be difficult? Approximating the time, in the past 180,000 years, there have been 674 distinct ship errors.”

    I did the arithmetic in my head. “That’s a mean time between failures of about 250 years.”

    “267,” Peri corrected.

    “Not bad, but not perfect, either. Maybe your ancestors weren’t as perfect as you thought.”

    “We do not think our ancestors are perfect. If they were perfect, we would not have to remember them. But, to their credit, these failures are in a fleet of more than a million ships, so the mean time between failures on any one ship is greater than 267 million years. They are not perfect, but they are very, very consistent.”

    I was impressed, but I wasn’t going to show it. “Sure, that’s great. But we’re on one ship, and it’s failing right now.”

    “Fortunately,” said Setho, “the signals have already been broadcast, so we will be remembered. You will have the honor of becoming the first Human Zaard ancestor.”

    “Oh, thanks, I hadn’t thought about that. But I’d rather live and be forgotten, so what else can you tell me about these errors?”

    “What else would you like to know?”

    “I’d like to know the distribution of errors across the various Leethaa components – like, which component has had the most errors per element?”

    Peri paused for a moment, then announced, “That would be the Nisoog-arthl component, with 402 of the 674 errors, if I have remembered our ancestors honorably.”

    “You have,” said Setho, “Most honorably.”

    Now my heart was beating audibly, and fast. “And how large is the Nisoog-arthl?” I’m not superstitious, but I crossed all my fingers as I waited for their reply.

    They replied in unision, in the Data Voice, “The Nisoog-arthl comprises Eight-hundred seventy-seven thousand nine-hundred and twelve Leethaa.”
    As they spoke, my pad displayed the number: 877,912. I could do the necessary calculation in my head. “That’s it, then. One more guess and we’re done!”

    I stopped the current simulation, now useless, and entered the boundaries of the Nisoog-arthl as my fourth guess. Now all I had to generate the patience to wait ten minutes to know whether I would live or die. Since Peri and Setho showed utter disbelief, I explained.

    “You told me that your ancestors were very, very consistent, but not perfect. When they built these ships they didn’t make many mistakes, but they did make some. And if they were as consistent as you say, then their mistakes would be consistent, too. They would consistently make most of their mistakes in the same parts of the Leethaa. And the one part they most consistently made mistakes in was the Nisoog-arthl – so I’m guessing that’s where this mistake will be found. We’ll know in seven more minutes.”

    “Yes, that’s quite logical, in a strange sort of logic, but what good will it do?”

    “Yes,” said Peri, also using the Query Voice. “That was a logical guess, but that only narrows the problem down to the Nisoog-arthl. We have no more refined data, so what logic can you use for your next guess?”

    “But if the error is indeed in the Nisoog-arthl, I won’t need any more guesses. I can switch to a pure binary search and be sure of narrowing the search to a single Leethaa in the remaining divisions.”

    “Aaah,” they said in the Simultaneous Voice, “so in the end you can be logical.”

    “And in two more minutes,” Setha continued alone, “we will all know logically whether or not we will visit that sun.”

    convert this post to pdf.

    Beyond Blaming

    © 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 article1 , 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 blaming2):

    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 Brooks3 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.4 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.5

    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.

    Communication Disconnects

    ©2007 Don Gray

    “Why doesn’t my manager listen when I explain the details?”

    “Why doesn’t the developer just give me what I ask for?”

    If you’ve ever heard these complaints-or made them-you’re not alone. Questions like these are a symptom of a communication disconnect. Communication disconnects happen every day for a variety of reasons. Three common reasons for disconnects are:

    • Where we get information
    • How we store and “re”present that information
    • What we do with what we know.

    Getting Information

    Information exists in two primary places; outside us, and inside us. Some people tend to focus on the “out there information”, what they’ve seen, heard or touched. They seek specific concrete and factual experiences. You could call them “sensors” since they get information through their five senses.

    Others find the information “inside” based on their experience, knowledge, and insights. With minimal external influence, these people dive inside themselves, and start looking for possibilities, meanings, relationships, and patterns. They’re more interested in “what does it mean” than “what”. These people could be called “intuitors”, since their intuition guides their actions, rather than data.

    The disconnect happens when “sensors” and “intuitors” try to share information. A sensor asks a question expecting to get specific data points, and instead gets a rambling (to the “sensor”) discussion of patterns and possibilities. Instead of a general idea and pattern of information, the intuitor hears a flood of boring minutia leaving the requestor wondering what the other is blathering about.

    To reconnect, a sensor can ask “what have you seen, heard or experienced that leads you to this conclusion?” Intuitors could ask “what does all this data mean?” Even better is to know yourself whether you’re an intuitor or sensor, and what the other person is. This enables you to respond to the other person’s style.

    You can practice being the other type. If you tend towards “intuiting”, try to notice several “out there” things every day. Carry with a small notepad at all times and jot down your observations, for example, a dirty brown-and-white dog sleeping in the street; a programming error that prints out the message, ‘RANK ERROR,’ then crashes Windows; a tall young woman in the next cubicle wearing Jovan perfume, making the noise of sharpening a gross of pencils.

    Sensors can periodically pause and ask questions about the data in front of them. Is Jack’s current coding difficulty related to Jill being on vacation? It looks like progress is slowing, why? The Rule of Three encourages having at least three possible choices before selecting one. Use your imagination and explore beyond the first obvious answer.

    Storing and “re”presenting Information

    We store information internally in our mind as sights, sounds, feelings, or abstract concepts. The way we store information is called our representational (rep) system, since that is how we “re”present our experiences.

    Take a moment and think back to a particularly enjoyable experience you’ve had a work. What came to mind? Did you see your teammates, maybe a particularly gnarly chunk of code you to which you finally saw the answer? Were there sounds of laughter and joking? Maybe you recalled feelings of happiness?

    If you primarily saw the enjoyable experience, you use a visual rep system. Recalling memories and hearing sounds involves the auditory rep system. Primarily noticing the feelings (touching) means the kinesthetic rep system is being used. Remembering abstract concepts (the lack of visual, auditory, or kinesthetic descriptions) indicates a preference for the digital rep system.

    Like most preferences, no rep system is better than another. They’re simply the way the way we tend to store and recall our experiences. We can (and usually do) use all of the rep systems, but most people have a preferred way of representing what’s in their mind.

    The disconnect happens when interactions become intense, and the rep systems get crossed. Suppose you say, “That doesn’t sound right to me,” and I respond with “I can see that.” We just crossed rep system boundaries. You now have to translate my visual response into its correct translation in your auditory processing. To stay connected, I could have said, “Yes, I hear what you’re saying.”

    To reconnect, listen for sensory words. When words appear like bright, clear, display, see, conceal, the speaker has a visual orientation. When you hear words like asked, talk, explain, complain, harmonize the speaker has overtones of a hearing orientation.

    Feeling words such as touch, soft, smooth, pressure or excitement slipping into the conversation push towards a kinesthetic, or touch preference. When you become aware of words like believe, consider, decide, know, learn, process, perceive, the speaker is using the digital rep system.

    To improve communicating, try to match the sensory mode of the other person. That way they won’t need to translate words from one sensory mode into another. A good time to practice this is when you reply to email. You can scan the incoming message for sensory words, and match the rep system in your reply.

    Mind Reading

    “I know what you’re thinking.” You’re thinking this is a lot of new stuff, and feeling overwhelmed with the ways communication disconnects happen. Which brings us to another disconnect called “mind reading”. Mind reading works on three basic (and faulty) assumptions:

    • You take in the same information I do.
    • You process this information as I would.
    • You come to the same conclusions and decide to behave exactly as I do.

    In short, I project my reality onto you, and tell you what you’re experiencing.

    The disconnect happens when we mind read, and then take action without confirming what the other person really thinks. This creates misaligned goals, actions, and often hard feelings.

    A developer made a decision that I thought should have been made by the customer. When I asked the developer if he should ask the customer, he said (and you can’t make up stuff like this), “I’ve been doing this for 20 years. I know what he wants better than he does.”You can avoid this disconnect by not mind reading. Rather than assuming you know the answers, ask questions. I’ve had people become irritated when I asked clarifying questions in order to avoid mind reading. If you find someone mind reading you, you might ask them “How specifically do you know how I feel (think, whatever)?” or “What did you see or hear that leads you to that?”

    Calibrating Communications

    When I work with a client, I first try to understand where they get information. Do they look for data (sensors), or rather hear about how this fits in the grand scheme of things (intuitior)? Sometimes it’s not an either/or. Perhaps they need the fit in the grand scheme with supporting data.

    When I supply the requested information, I try to match the requestor’s rep system. This saves time and effort since they don’t have to translate my meaning.

    Lastly, to avoid mind reading, I ask how the communication went for them. Did they get what they needed, in the format they could use? If not, I have new information that allows me to change what I’m doing. If they got what they needed, I’ve avoided the communication disconnects.

    convert this post to pdf.

    Communication Gaps

    ©2003 Don Gray, www.donaldegray.com

    I just got off the phone with Joel. We worked a project 12 years ago where he was the client’s technical rep, and I supplied some specialty software to his company. As we renewed acquaintances, he said that the portion of the project I worked on was never implemented. It didn’t fail because of our efforts, but because the users and the owner never did agree on exactly what the software was supposed to do, or how it was supposed to be used. Using Jerry Weinberg’s definition that “Quality is value to some person(s)”[1], I would now say that even though the software performed as specified, the software had no quality, since it wasn’t valuable to the people it was written for.

    So what happened? Did Joel’s company willfully, with forethought and intention, decide to waste money on a software project? Not likely. Why did it take 12 years for Joel and me to have a conversation about the project? Technically the project succeeded, in spite of the fact that the owner and users couldn’t decide what to do with it. At least, we agreed that the software was working as requested. Or did it?

    This project suffered from communication gaps. In her latest book, Communication Gaps And How To Close Them, Naomi Karten defines a communications gap as “a situation in which miscommunication, or the complete lack of communication adversely affects the work as well as the relationships among the people carrying out the work.”

    “Gaps are frequently caused by misdirected, one-way, poorly time, or badly worded communications. In addition, some gaps result from misunderstanding, misinterpretations, and miscommunications.” [2]

    Communication is how we share ideas, get information, request help and assign tasks. The importance of communications to software quality is why communications is included in the CSQE Body of Knowledge. Simply put, good communication is critical to software project quality. Gaps form when the message sent isn’t received, or differs from the message received. Understanding and applying the concepts in Communication Gaps will help us determine how the gap happened, what we can do about the gap, and how we might prevent the gap in the future.

    There are several possible reasons messages aren’t received. One reason is the receiver’s preferred communication mode. Recently I tried to initiate contact with a new person. I sent an email saying I would call the following week. When I called, I got the voice messaging system. I left a message, and four days later, after hearing nothing, sent another email asking how the other party preferred to communicate. It turns out they are on extended leave, and email works best for them at this time. They were also kind enough to introduce me to the person I should be talking to in the mean time. Had I continued to try calling, it would be another 2 weeks before I would get a response.

    “But both parties to miscommunication too easily forget that although they are using the same words, they speak different languages.” [3]

    Another reason messages aren’t received is they get lost in the background noise. I process over a hundred emails a day (and sometimes more than double that, and even more if you include newsgroups). I do use technology to segregate as much as possible, but there are times when I just give up and everything in the inbox gets deleted and the newsgroup gets marked read. If the communication is important, make it stand out. If it’s not important, distinguish yourself and don’t send it.

    Naomi describes and explains several models that are useful in understanding communications gaps. These models involve personality types, interactions, and change. Each of these have a unique influence on communication, and examples are provided of how communication might develop gaps, and what can be done to prevent gaps and improve communication.

    The main personality model presented is the Myers-Briggs Type Indicator (MBTI) that is based on Jungian psychology. The MBTI differentiates 4 traits into 2 categories each (called preferences), Extravert/Introvert, Intuition/Sensing, Thinking/Feeling, and Perceiving/Judging. Understanding how the different preferences prefer to communicate can explain a lot of meeting behavior. When I send out a meeting notice, I include a list of topics so people can prepare for the discussions. This enables the Introverts to consider what and how they want to present their thoughts, thus giving them equal footing with the Extraverts who are happy to think out loud as they form their thoughts

    A very useful model for diagnosing gaps or untangling communications is the Satir Interaction Model. The Interaction Model consists of four steps:

    1. Intake: what is seen and heard
    2. Interpretation: how the recipient interpreted the message
    3. Feelings: how the recipient felt about the interpretation
    4. Response: what the recipient communicated in response

    In most interactions, the sequence happens naturally and with no major impediments. However, when a gap appears, using the model may help re-construct what happened. I recently asked for what I thought was a minor change to a document. The scathing email reply left me wondering “What happened here?” As we worked through the interaction, I found out that the other person was taking pain medicine, and the “simple” changes would require 2 hours of his time. This shed light on the response, and we were able to find a solution that didn’t require re-working the document.

    Perhaps the largest communication gaps occur in the area of change, and as we try to improve quality, we’re changing things.

    “Alas, no one can get anyone else to willingly do something that person doesn’t want to do or doesn’t know how to do. In a fantasy world, all those affected by a given change would welcome, endorse, and support it, openly and joyfully. But in the real world, change is unsettling.” [4]

    Several change models are presented since no single model embraces all possible situations and solutions. The Satir Change Model provides an excellent framework for the personal stages of change :

    • Old Status Quo – characterized by the known, familiar and the predictable.
    • Chaos – This stage starts with the Foreign Element, which is something that throws the system (individuals or groups) into an unsettled state of decreased or impaired performance. If you’re involved with process improvement, you will at times be the cause of foreign elements.
    • Practice and Integration – Transforming Ideas are new ways and approaches as people start to adjust to the changes brought by the Foreign Element.
    • New Status Quo – The return to relative stability with respect to the Foreign Element.

    Communications is critical during change, and the “what and how” you communicate changes in each stage (and possibly with respect to each individual’s preferences).

    Other topics covered include Understanding the Other Party’s Perspective, Gathering Customer Feedback, and Service Level Agreements.

    Will reading, understanding and using the information in Communications Gaps enable you to prevent all future gaps? As Naomi says:

    “Although I’ve described some effective ways to close communication gaps, truth in book-writing compels me to reveal that you can’t ever be gap-free.” [5]

    What you will experience is fewer gaps, and when gaps occur, you’ll have a set of tools to analyze and learn from the gap.

    [1] Gerald M. Weinberg, Quality Systems Management, Volume 1, Systems Thinking (New York: Dorset House, 1992) page 7.

    [2] Naomi Karten, Communications Gaps and How To Close Them, (New York: Dorset House, 2002) page 5
    [3] Naomi Karten, op. cit., page 65
    [4] Naomi Karten, op. cit., page 304
    [5] Naomi Karten, op. cit., page 347

    Communications Gaps and How to Close Them, © 2002 by Naomi Karten, ISBN 0-932633-53-6. Published by Dorset House, 353 West 12th Street, New York, NY 10014

    convert this post to pdf.

    The Dismal Theorems of Contract Negotiation

    ©1999 Gerald M. Weinberg

    My friend Brad, a Los Angeles cop, mentioned that he regularly sold traffic tickets.

    “But it’s not what you think,” Brad smiled. “I work at night and go to school
    during the day. If I have to appear in court, I miss classes. ‘Selling the ticket’ is
    convincing drivers that they really were speeding, so they won’t take the matter to
    court.”

    “That’s a side of police work I never considered,” I said. “You have to be a good
    salesman.”

    “It’s not that hard,” Brad explained. “You see, I give dozens of tickets every week,
    but most of the speeders only get one in a year. I get lots more practice than they
    do.”

    Negotiations between speeders and police can never be equal, because speeders are
    amateur negotiators while cops are professionals. By the time you had enough
    experience at speeding to become a professional, you’d be in jail.

    Negotiations between contractors and agencies can never be equal, because
    contractors are amateur negotiators while agencies are professionals. By the time
    you had enough experience at contracting to become a professional, you’d be dead.

    Unfortunately, you need to negotiate every new contract:


    “There will always be issues and disputes between contractors and agencies. The
    key, and perhaps the best that can be hoped for, is to understand the other side a
    little better

    convert this post to pdf.

    Getting Some Good Out Of Bad Interviewing

    ©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.

    The Liar’s Contest

    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 - Liar's Contest Basic Dynamic

    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.

    Lullaby Language

    ©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.

    Reasons

    ©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.

    Seeing the Other Person’s Big Picture

    ©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.

    Seeing Your Own Big Picture

    ©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.

    Treaties to Deal with Communication and Conflict

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

    On a typical day, I get 100-200 email messages, and some of my clients in large projects receive even more. Though emails improve my ability to communicate clearly and quickly, they may also prove a hindrance to certain kinds of communication. In particular, email does not adequately serve as a medium for recording an important agreement. An important email may be too transitory, too easily lost among volumes of less important communications, too easy to misunderstand, and too easily lead to unnecessary conflicts.

    Although email can reduce the need for personal contact, it cannot entirely eliminate contact between teams building components that must work together to form a system. Separation of teams tends to create language differences that lead to misunderstood emails. Teams develop local goals that may diverge from project goals and actually conflict with other teams’ goals. With different language and divergent goals, interfaces stop being stable, clear, stakes in the ground. Instead, they can easily become the disputed border between two warring states or two different cultures. To prevent border wars, I prefer the ancient solution – writing and signing treaties.

    A software treaty is more or less identical to a treaty between political units. I like my treaties to be written on a single piece of paper with a fancy border, like a gilt-edged stock certificate. A typical treaty might contain.

    1. A reference to the technical terms being agreed to – such as a reference to a specific version of a document in the project’s repository.

    2. A statement that all signatories agree to the technical terms in (1).

    3. A statement that the treaty will remain in effect unless and until renegotiated among all the signatories.

    4. Dated signatures of each team’s official representative – most often the team leader. The treaty implicitly recognizes the independence of the signatory teams and their ability to enter freely into agreements on technical matters.

    5. (Possible) Management signatures witnessing the treaty.

    Although a manager quite likely acts as facilitator to the negotiations, treaties will not work if parties are coerced into signing something they don’t understand, or don’t agree with. Nor will they work if some affected party fails to participate in the negotiations and sign the treaty, so management must ensure that all affected parties are represented.

    After signing, however, good management becomes mandatory to enforce the pact the parties agreed upon. In other words, once each party freely gives its signature, the matter is no longer a purely technical one, but becomes political.

    Why political? Because after the agreement, one party could disrupt the project and/or make the other party look very bad by covertly changing the agreement. A written treaty seals off this avenue for expressing any animosity or mistrust that exists between the parties. When people understand that management will rigorously enforce each treaty, they can quit bickering and get down to the business of building. Moreover, teams can work with the assurance that anything not in a treaty is not a commitment – and will not become a commitment without going through the treaty process.

    With signed treaties covering all interfaces, no single team can disrupt the project by covertly changing the rules in the middle of the game. Woe to any team that fails to meet the interface specifications agreed upon in their treaties.

    What happens if one party to the treaty decides they made a mistake, or got a poor deal? For instance, during the negotiations, I might have agreed to pass error-free data in return for two milliseconds more of execution time, but now I find that I cannot scrub the data that fast. I can then call for a renegotiation, but I may have to trade something else for the relief I seek – even something that will simplify my enemy’s job.

    Such a concession may prove a bitter pill for me to swallow, especially as the renegotiation is done in front of management, but I have to understood that unilateral changes to my treaties will damage the project and make my life much less pleasant.

    The startup of a treaty system will sometimes seem awkward, unfamiliar, and overly formal. I know from history, however, that this degree of formality is needed if former antagonists are to work together cooperatively. White ties are optional, however, and quite soon the awkwardness dissipates.

    We frequently see one party resist actually signing a treaty, but such resistance always indicates that the resisting party is uncertain. Because the whole treaty process is designed to eliminate uncertainties, resistance tells me what I want to know that there is still more definitional work to be done.

    Treaties are especially helpful for contractor professionals, who may rush into a poorly understood commitment in their eagerness to improve their cash flow. But no matter how much I hope that the definitional job is finished, the strong commitment implied by a signature prevents me from mistaking hope for reality.

    By keeping communications on the level of reality, rather than hope, I may create a few problems today, but I avoid bigger problems tomorrow.

    By making agreements between cooperating parties a strategy for peace, I avoid the hardest problems of all, the misunderstandings that lead to interpersonal conflicts.

    convert this post to pdf.

    The Big Picture: Four Different Ways of Participating

    ©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.1
    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.


    1 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.

    Yielding to Pressure

    ©2005 Gerald M. Weinberg

    In a previous article, I wrote about the usefulness of treaties between technical teams, but I didn’t give much detail about the actual negotiation process that goes into making a successful treaty. To learn about such negotiations, let’s look at two scenarios of negotiations that went wrong.

    Here’s Scenario Number One:

    Bob (the Boss): Fay, what’s your estimate of when that component will be ready to ship to testing?

    Fay: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.

    Bob: <looking disappointed> Oh.

    Fay: Isn’t that okay?

    Bob: Well,…

    Fay: I suppose I can really push and get it in 12 weeks.

    Bob: <still looking disappointed> Oh.

    Fay: Darn. Well, if everything goes exactly right, I can make it in 10 weeks.

    Bob: <brightening a little> Did you say eight?

    Fay: Okay, I guess I can push for eight.

    Bob: <smiling> That’s terrific, Kay. I knew you could do it!

    Here’s Scenario Number Two:

    Darlene (the boss): Ira, what’s your estimate of when that component will be ready to ship to testing?

    Ira: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.

    Darlene: <standing up and raising her voice> Ira, that’s simply not acceptable. I want it in eight weeks, not a day later!

    Ira: <eyes lowered to the his shoelaces> Uh… But there’s just too much to …

    Darlene: <turning red, and raising her voice another level> Ira! I hope you’re not about to say something negative! You know we’re a team here, and we don’t have room for nay-sayers!

    Ira: <trying to swallow when his throat is dry> Well… I suppose I could…

    Darlene: <breaking into a tight smile> …you could do it! I knew you’d find a way, Ira. <turning towards the door> All right, then. I have your commitment, so don’t disappoint me. See you in eight weeks! <out the door>

    —–

    Q: What’s the important difference between these two scenarios?

    A: Nothing. Nothing important, that is. Bob used a soft approach; Darlene used a hard approach, but nothing was really different. Successful negotiations usually involve trade-offs among schedule, resources, and technical specifications, but these two contain no trading off at all – just different kinds of manipulations to make one person submit to another person’s desires.

    Here’s Scenario Number Three, which should produce a better result:

    Annabelle (the Boss): Myron, what’s your estimate of when that component will be ready to ship to testing?

    Myron: If I get the equipment I’ve requisitioned, I’m pretty sure I can have it ready in 14 weeks.

    Annabelle: <looking disappointed> Oh.

    Myron: Isn’t that okay?

    Annabelle: Well, not really.

    Myron: If the schedule is that important, we can look at alternatives.

    Annabelle: I can’t give you any more people. We’re shorthanded already.

    Myron: Darn. Well, actually, new people right now might be more disruptive than helpful. Well, something has to give – we can’t reduce schedule and hold resources and specs constant.

    Annabelle: That’s certainly true. But I do need something to show to my marketing team in eight weeks. There’s that business expo where we have to do a demo, and I can’t change that date.

    Myron: Okay, I guess we’ll have to see what features we leave out of the demo, or perhaps fake a bit.

    Annabelle: <smiling> That sounds like what we’ll have to do, Myron. Let’s take a look at what you can give us that will look good in eight weeks.

    —-

    And so Annabelle and Myron get down to the business of examining which features will contribute most to a good demo (her problem) while at the same time being within Myron’s team’s capabilities (his problem). Nobody was forced; nobody was manipulated. The negotiation stayed open and based on facts, not speculation or screaming or placating.

    Of course, this kind of negotiation takes trust – trust in the other person, but even more, trust in yourself.

    • You must feel that you can be honest without being taken advantage of.
    • You must be confident that you understand the trade-offs on your own side of the business.
    • You must have enough self-esteem to be able to say what you don’t know.
    • It also helps to know that agreements forged through manipulation will be weak and unreliable agreements.

    In my experience, at least half of the problems developers have with customers are the result of poor negotiation – usually the result lack of skill and will to deal with various forms of conscious or unconscious manipulation by their negotiating partner.

    Do you understand what I?m telling you? Well, you?d better understand, unless you?re too incompetent to do your job! From now on, I?m assuming your commitment to learn to do better at dealing with manipulation, so don’t disappoint me!

    (Of course, the way you?ll disappoint me is by yielding to my attempted manipulations.)

    convert this post to pdf.

    Waiting For People Who Arrive Late

    ©2007 Steven M Smith

    What does it say about the participants of a weekly meeting when the meeting consistently starts 5-10 minutes behind schedule?

    Answer, the participants are cooperating with each other to start late.

    Starting late is the status quo.

    Let’s explore:

    1. Are you cooperating with the participants of your meetings
      to start late?
    2. How do you feel about that?
    3. How do you feel about feeling that way?

    Let me share how I would have answered the questions in 1990:

    1. Yes, I have cooperated with others to start late
    2. I feel powerless to change the status quo
    3. I feel angry about feeling powerless

    I have never liked feeling angry. But I felt powerless to change the status quo so what could I do about the situation?

    I had more power than I first thought. I took a deep breath. I decided to arrive before the scheduled start time. I encouraged other participants to arrive early. I worked to become a meeting leader; and, when I became a leader, I demanded that people arrive on time.

    Arriving early and encouraging other participants was successful at bringing more people into the room before the scheduled start time. Becoming a meeting leader and demanding that meetings start on time was a failure.

    Despite my embarrassment, let me share just five of the many interventions I tried as a meeting leader to cause meetings to start on time:

    • Rescheduling the meeting to a start time all participants agreed
      would work
    • Contracting with the participants to arrive on schedule
    • Locking the door to the room at the scheduled start time
    • Cancelling meetings when an agreed upon quorum wasn’t present
    • Publishing the names of the late arrivers in the meeting minutes

    After gaining feedback from these interventions, I realized that successfully starting the meeting with all of the participants required the cooperation of, surprise, all the participants. The decision about whether we started on time was theirs to make.

    Rather than fighting the status quo, I thought, “Why not make the status quo visible so every participant can decide for themselves whether it is acceptable?”

    So Agenda Item #1 for all my meetings became Wait for people who arrive late. All the agenda items in my agenda have durations. I assign the duration for item #1 as the difference between the actual start time and scheduled start time of the previous meeting.

    The agenda item looks like following:

    #1. Wait for people who arrive late. 10 minutes

    Regardless of why the status quo existed, its existence is out there for everyone to see.

    What happened?

    Reactions varied: Some participants didn’t react to the agenda item. They seemed to think it signaled nothing. Some participants commented that they thought the agenda item started the meeting out on a sour note and wanted it eliminated. And some participants thought starting late was unacceptable and they wanted to do something about it.

    It’s easy to sense which reaction creates an opportunity to change the status quo.

    Agenda Item #1 offers the opportunity for people to choose whether they want to continue the status quo or start changing it. I wish I could tell you agenda item #1 always triggered a change that caused a meeting I led to start on time. It didn’t. It does, however, always offer an opportunity for the participants to choose again. And sometime that’s all that’s need to trigger the change process that creates a new, more effective status quo.

    You may be wondering, Does starting meetings on time truly matter? I believe it does. If people are the organs of an organization, then meetings are the organization’s lifeblood. These gatherings are where people come to define, solve and status problems. The more healthy a meeting, the more healthy the organization. And, conversely, the sicker the meetings, the sicker the organization.

    If the people who participate in a meeting can’t cooperate to start their meeting on time, what chance is there they will cooperate to start a project on time? I you were a member of a relay team running a race against another team, would you agree that everyone on the team can arrive for the race whenever it fits for them?

    The same people who participate in meeting are the same people who are responsible for the tasks in a project. A meeting is nothing but the simplest of projects. My experience is that attitudes of participants at meetings mirror their attitudes to their task work and the project as a whole. How could they not?

    How healthy are your meetings? If they are sick, gaining cooperation about starting on time and actually starting on time will make them healthier. It’s not easy to change the status quo, but it can be changed.

    convert this post to pdf.

    Tell Him?

    ©2006 Steven M Smith

    It’s ironic that the Baseball Writers Association of America named Joe Girardi the National League’s 2006 Manager of the Year. Giardi was recently fired by the Florida Marlins despite managing a young, low-rated team into contention. It seems his problem wasn’t performance but rather communication.

    Baseball reporters speculate the Marlins fired Giardi because of a run in with owner Jeffrey Loria. During a game on August 6, Loria made his outrage about the calls of home plate umpire Larry Vanover loud and clear to both Vanover and everyone near Loria’s seat behind home plate. In the dugout, Giardi heard Loria chewing out Lanover. He leaned out and yelled to Loria, “You aren’t helping.”

    When asked about the incident, Loria replied, “Everything is, you know, fine. But I don’t want to talk about it.” After the incident, Loria talked about the success of the organization but never about Girardi’s role in it.

    So what does that story have to do with management? For me, it highlights a typical communication problem.

    Reading between the lines, I interpret that Loria was mad that his behavior, which most people would agree is bad behavior for an owner, was commented about in public by someone who worked for him. If Girardi would have made the same comment in a private meeting, Loria may have taken no offense.

    Loria may have been upset that Girardi, a employee, made any comment at all to him about his vitriolic display. Some executives never, ever want the hear anyone “beneath” them make a negative comment about whatever they do.

    If a manager above you wants to hear neither public nor private comments about their inappropriate behavior from subordinates, you already know what to do and don’t need any suggestions from me.

    I do, however, have suggestions about a situation where you have complete control. Consider what comments you will or won’t accept from people who are below you. If you are behaving inappropriately, is it okay for them to inform you?

    For instance, during a meeting, you loudly argue with a client. Is it okay for a manager in your organization to say to you, “You aren’t helping.”? How about an employee? Should they let you keep arguing? Will you be embarrassed about being called out? Does your personal embarrassment require retribution?

    I suggest pondering these questions:

    • What are you willing to hear from subordinates in public?
    • What are willing to hear in private?
    • What communication is out of bounds whether it’s public or private?
    • What are you willing to hear from an employee that you
      aren’t willing to hear from a manager?

    Answering these questions will enable you to gain clarity about the types of communication you desire from your managers and employees. That knowledge will enable you to craft and communicate your desires.

    convert this post to pdf.

    Safety Margin

    ©2005 Steven M Smith

    Jake tossed and turned. He looked at the bedside clock. 3 AM. “I need sleep,” he thought to himself. But sleep would not come. Only worry about tomorrow’s meeting.

    Edmund, Jake’s manager’s manager, enjoyed probing managers in his organization to discover how well they were doing. He expected his managers to lead people so they wanted to follow. And he expected them to have complete command of their business. “There are no bad soldiers,” the retired Army Captain loved to say, “only bad officers.”

    “Am I a bad officer?” Jake wondered. “How would Edmund even know? He doesn’t understand Storage Resource Management (SRM), and that’s my organization’s total responsibility — everything from provisioning to backup to disaster recovery.”

    His eyes were wide open as he stared at the ceiling thinking about what questions Edmund would ask him. His mind raced through the standard list, contemplating his responses.

    “Where do you stand versus budget?” (I’m square on that, with the paperwork to back me up.)

    “What are our biggest risks?” (My risk spreadsheets should toss out this one.)

    “What are we doing to mitigate those risks?” (Yep, the spreadsheet will handle this, too.)

    “What’s the morale of your staff?” (Hmm, that’s harder, but I’ll ask my most vocal people this morning.)

    “So why am I tossing and turning?” Suddenly he sat up in bed, wide awake. “It’s storage utilization. He’s going to ask me why utilization is only 50%.”

    “He’s going to ask about that, first thing, because it looks like a glaring management problem. Especially since just last week I made a procurement request for more storage — which he hasn’t signed yet. Sure as heck, he’s going to ask me why.”

    The alarm sounded. 3 hours had passed. Jake hadn’t slept a wink. 4 hours until the meeting with Edmund.

    Jake slid out of bed and stumbled into the bathroom. He looked in the mirror and saw the big bags under his eyes. He fired up the shower, tested the water, which was just right, and jumped in. He did his best thinking in the shower. He needed a revelation.

    “I must be managing better than the data shows,” he muttered to himself as we washed his hair, “The utilization number doesn’t tell the whole story: I need all the storage I have and more.”

    The shower water began to cool, and he hadn’t finished rinsing. “Darn,” he thought. “I should have installed a bigger hot water heater.” Shivering as he rinsed away the suds, the idea snapped into his head. “Of course. Data storage is just like the hot water.” He scrambled out of the shower and grabbed a towel.

    He wrapped the towel tightly around his freezing body, but his mind was running a mile a minute. “Data storage is like the hot water — it requires a safety margin to prevent the business from being impacted by a shortage.”

    Clarify the Story

    In my experience, Jake isn’t alone. Managers of storage organizations everywhere face the difficult task of providing a simple explanation to upper management about resource utilization.

    I have faced this problem many times throughout my career. I have never forgotten the words of the CIO of Consolidated Freightways, “Steve, we never send our trucks out half full. I expect us to fully utilize all of our IT resources in the same way we fully utilize our trucks.”

    His comparison is the first clue to explaining resource utilization to upper management. The utilization that you report is compared with other resources that may have much different utilization characteristics. 100% utilization may appear possible in the packing of a truck but it isn’t possible with storage. Show me a fully utilized disk array with dynamic data and I’ll show you a broken system.

    Compounding the explanation problem, upper management wants to understand resource utilization and its relationship to cost with minimal understanding of the underlying technology. They pay you to understand, manage and measure.

    Storage managers typically answer the following questions:

    • How much storage do we have?
    • What percentage is allocated?
    • What percentage is unallocated?
    • What percentage is allocated but not being used (free space)?

    Note, it’s easier for everyone if the percentages all refer to the same quantity, namely the total amount of storage.

    A manager who answers as follows will trap themselves:

    1,000 Terabytes
    95% Allocated
    5% Unallocated
    50% Free

    Why a trap? Because upper management will sum Unallocated and Free and ask the inevitable question, “Are you telling me that 55% of our storage isn’t being used (my costs are more than twice the amount truly required)?”

    Caught flat footed, the typical storage manager answers, “No, uh-uh…. I mean yes,” followed by a long, complicated explanation that doesn’t satisfactorily answer upper management’s question and, most importantly, wasn’t desired.

    Upper management will certainly doubt whether the manager of a storage management group is effectively managing his or her costs if they hear unused space is greater than 40%. Don’t trap yourself.

    Save yourself a lot of grief by adding answers to the following questions:

    • What percentage is a safety margin?
    • What percentage is now free after factoring in the safety margin?

    What does Safety Margin mean? It’s space reserved for growth. A dynamic file system or database must have free space for growth. Let’s use a conservative 20% rule of thumb for the Safety Margin for each file system, for instance a 100 GB file system would thus have a 20 GB reserve as a safety margin for growth.

    Upper management needs to know that without an adequate safety margin they risk an unplanned system outage. A series of requests for more storage than is available will cause an outage, which may impact a critical business function.

    And, finally, upper management always likes numbers to add up so transform the percentages so their sum is 100%. That means rather than reporting Allocated, you report all its elements — Utilized, Safety Margin and Free.

    With answers to the fifth and sixth questions and transformation of the percentages, the storage manager can say:

    1,000 Terabytes
    50% Utilized
    19% Safety Margin
    26% Free
    5% Unallocated

    Calculate Utilized as 100% minus what we previously called Free (50%), which equals 50%. Calculate Safety Margin as 20% of Allocated (100% minus Unallocated), which equals 19%. Calculate Free as Allocated (100% minus Unallocated) minus Utilized minus Safety Margin, which equals 26%.

    When upper management now sums Free and Unallocated, they arrive at 31% rather than 55%. They will ask for better results, but they won’t think you are an ineffective manager.

    And everything you are sharing with them is a fact. You have simplified the story so they don’t become frustrated by unneeded and undesired explanation.

    Tell the Story

    Jake arrived at the office at 7:30 AM. The meeting with Edmund loomed over him, but he was determined to put to use what he discovered in the shower.

    Without the revelation, Jake would have shared with Edmund the following state information:

    2,500 Terabytes
    95% Allocated
    5% Unallocated
    50% Free

    Jake used the safety margin concept to transform the state information as follows:

    2,500 Terabytes
    50% Utilized
    19% Safety Margin
    26% Free
    5% Unallocated

    He discussed morale with two of his most vocal people. They reported that they felt good about things and they thought others did too. He walked into Edmund’s office at 10:00 AM feeling fully prepared.

    Edmund asked him the usual questions. And Jake felt good about his answers. Edmund was pleased to hear that the morale of Jake’s people was high.

    Edmund asked Jake, “What is the utilization of the storage?” Jake shared with him the five numbers and explained to Edmund the safety margin concept. He nodded and said, “You are telling me that we need a certain percentage in every file system as a reserve to prevent application outages.”

    Jake smiled and replied, “Exactly. It’s just like with the disk on your PC. If you want to put more files on it, you must have available space.”

    Edmund smiled back and asked, “Why 20%? Why not 10%.”

    “20% is a starting point. I will monitor and calibrate it as we get more experience. And I’ll report what my team thinks is an appropriate safety margin each time we talk.”

    Edmund wasn’t finished, “Okay,” then he frowned and asked, “Tell me why you have asked for more storage when I see that 31% of the storage isn’t used?”

    Jake thought to himself, “That’s the question I was worried about but not anymore.” He paused and then replied, “We have a new application that will consume all of unallocated space and more.”

    “We are monitoring storage closer than last year and now know the clients who are wildly exceeding the expected safety margin for their file systems. But going back now and releasing that free space requires downtime to reallocate and move the data, which puts the business at a bigger risk than if we wait until the next technology refresh on the storage array that contains the file systems. With the storage technology we use, freeing storage during the technology refresh is the safest time to reduce allocation sizes and thus return the free space to the pool of unallocated storage.”

    Edmund smiled and said, “Jake I have enjoyed talking with you. You have a strong command of your business. I was thinking of raising your salary…”

    “Oh, boy,” Jake thought.

    ” …but I’m not sure I have enough safety margin in my payroll budget.”

    convert this post to pdf.

    Safety Check

    ©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.

    Rethinking Stand-Up Meetings, Part 2

    ©2007 Steven M Smith

    I argued in my first article about stand-up meetings that the right participants were the key to a successful meeting rather than whether the participants were standing up or sitting down. Despite my dislike for forcing people to stand up, I mentioned in that article my positive regard for other elements of the standard stand-up meeting.

    What elements do I like? Why do I like them? How can we innovate?

    Three elements of a SCRUM stand-up meeting stand out for me:

    1. Knowing the agenda
    2. Limiting duration
    3. Minimizing participants

    Knowing the Agenda

    A daily SCRUM stand-up has each team member answer the following three questions:

    • What did I accomplish yesterday?
    • What will I do today? and
    • What obstacles are impeding my progress?

    All the participants know what is expected. I like this a lot. If the participants know what’s expected of them, they are more likely to prepare.

    I think there are opportunities to innovate on this solid agenda. Rather than verbally report status information, ask each participant to write their status on sticky 3×5 cards. Ask for a separate card for each element of their answer to the three questions. For instance, 1) Completed refactoring of module Gamma, 2) Created automated test cases for module Delta, 3) Will begin coding module Delta (expect 3 days to develop), 4) Intermittent failures on server Toledo are slowing my efforts.

    As you do the round robin, ask each person to read their cards and post them on a community white board. Using cards will cause the participants to prepare something before they arrive at the meeting. That will increase the pace of the statusing. It will provide information for publication to people who are interested in the project but could not attend. It can be compared with 3×5 cards from the day before to detect problems.

    I also think there is an opportunity to add a fourth agenda item?What do I propose? For instance, I propose we divert our efforts on accomplishing X and use them to accomplish Y. The answer to this question notifies the team that a member wants the team to make a decision. As with the answers to the other questions, the team is notified but it doesn’t discuss or decide during the daily stand-up. That’s done at a separate meeting.

    Limiting Duration

    The objective for the duration of a daily stand-up meeting is 15 minutes or less.

    I like short meetings. As a participant, I also like to have enough time to share my answers.

    I suggest you divide 15 minutes or whatever you plan for the duration of your meeting by the number of participants. Is that enough time for a person to effectively status their work? For instance, if you have 10 participants, there is an average of 1.5 minutes available for each participant. Is that enough time? That’s 0.5 minutes to answer each question. That’s enough time for me to status, but is it enough for your participants?

    I recommend that someone perform the role of time keeper. Alert each person, I like to use a chime, when they are 30 seconds from their time limit. And again when 10 seconds remain. Stop them and move to the next person when their time limit expires.

    Please, don’t stop someone in the middle of their report in the first few status meetings. At a point where the participants have had sufficient time to practice delivering status, it may be time to stop them. Without being at the meeting, I can’t know whether stopping them is appropriate. But you can.

    Time in a meeting is like money in the economy. It’s capital. Use it wisely and you will increase your return.

    Minimizing Participants

    A principle of a daily SCRUM stand-up is the separation of participants from observers. The less the number of meeting participants, the more time is available to each participant to share status information. This is a smart action and I like it a lot.

    I interpret there is more to this element than merely minimizing the number of participants. It’s about gathering the right people together and demonstrating to them that they have the authority, power, and responsibility to produce the
    product.

    If your hiring process isn’t putting the right people in the meeting, minimizing participants will be less effective than it could be.

    Gathering Feedback

    There isn’t a feedback component that I am aware of in the standard stand-up meeting format. I believe a status meeting becomes more effective when it adapts to its environment through the use of participant feedback. Without
    feedback to improve a meeting, it becomes a picture of a sprinting cheetah rather than a real sprinting cheetah. Pictures of cheetahs don’t turn when its prey makes a turn, but a real cheetah does.

    Find out what turns your team needs to make by gathering feedback about the meeting. See my blog post Measure ROTI (Return On Time Investment) to learn how to gather the feedback. Note, I don’t recommend gathering feedback every meeting: I suggest instead gathering it every third or fourth meeting. When you do gather feedback, respond to it; otherwise, a picture of a snoozing cheetah is apt visualization of the state of your meeting.

    Final Thoughts

    Too many people believe that stand-up meeting are more effective than traditional status meeting because the participants are forced to stand up. That’s a fallacy. Increased effectiveness results from the other elements of a stand-up meeting — knowing the agenda, limiting duration, and minimizing participants. The elements are classic elements of any effective
    meeting. The actual application of these elements is the root cause for a stand-up meeting being more successful than a traditional status meeting.

    A possible benefit for forcing people to stand up is notification. Participants who have continually experienced ineffective status meetings — those with poor agendas, poor participant preparation, poor adherence to the meeting schedule, and poor choices about who will participate — may benefit from physical notification that the meeting has changed. Once the notification is complete though, standing up loses its value.

    I know people from an earlier era who believe wearing a tie makes developers more alike and more disciplined. I don’t buy it. And I don’t buy the idea that participants should keep standing up once they understand the rules for participation. Forcing a developer to continue standing up is like forcing them to wear a tie. Both actions will make them uncomfortable and neither will improve their productivity.

    Use the standard stand-up meeting format as a starting point. It’s a solid foundation. Don’t worship the format. Encourage innovation so that your status meeting better responds to the unique needs of your team.

    For More Information

    Jason Yip, It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings. It’s an excellent article.

    You will find an abundance of information about this topic on the web. Search for “stand-up meetings” using your favorite search engine.

    convert this post to pdf.

    Rethinking Stand-Up Meetings

    ©2007 Steven M Smith

    Stand up meetings are popular in software development organizations now.

    What makes a stand-up meeting more effective than a traditional meeting to socialize status information?

    Nothing. The effectiveness of a stand-up meeting, like the traditional status meeting, depends on the participants. If you have the right people at the meeting, you can be effective whether the participants are sitting down, standing up, or standing on their head.

    The theory behind a stand-up meeting is that a physical reminder of the duration of the meeting will keep it shorter. The longer the meeting, the more your body signals it’s time to stop. The proponents of stand-up meetings like this natural time-boxing signal. Every participant feels the signal to some degree.

    The signal may be too strong, however, for people who have a physical problem that make standing difficult. For instance, I twisted my ankle recently, it’s painful when I stand on it.

    If I am a good teammate who listens and participates appropriately, does it matter whether I’m standing or sitting down with my ankle propped up? No, of course not. It matters how I participate, not the position of my body.

    I have heard that proponents of stand-up meetings claim that the meetings helps build teamwork. If your teamwork is better, I am THRILLED for your team. But I doubt whether the stand up component made the difference.

    When I started my career, I had to wear a tie every day. The next job required a suit. Management told me clothing built teamwork. I think standing up during a meeting is like wearing a tie. My teamwork isn’t any better wearing a suit and tie than it is when I wear shorts and a t-shirt And I don’t believe my team’s effectiveness changes whether they are standing up or sitting down during a meeting.

    If you want to have effective meetings of any kind, you need leaders in the room. That’s the kind of people I referred to as “the right people” earlier. Leaders who organize the meeting; leaders who lead the meeting; and leaders who follow other leaders.

    If you have people who see no value in meeting with their teammates, having people stand up might help the meeting from lasting too long. But there is more to an effective meeting than preventing people from being trapped in a room.

    convert this post to pdf.

    Don’t Tell Doreen

    ©2005 Steven M Smith

    Jarrett, Doreen and I were on the verge of a closing a big sale. We had crafted the Statement of Work (SOW) for two weeks and had finally reached the point where it satisfied both the customer’s desires and the needs of our company.

    But at the last second, before the document was sent to the customer, Jarrett, the salesman, decided to reduce the asking price.

    He waited to tell me about the change until Doreen had left our office to fly back to headquarters, three thousand miles away, then added a caution: “And don’t tell Doreen about the pricing change.”

    Each word hit my head with a thud. Doreen was part of our team. She had invested hours helping us change the SOW so it would satisfy the customer. After the sale, she would be responsible for the service we were offering and held accountable for its profitability.

    Hoping that I had misunderstood him, I asked Jarrett, “What did you say?” The same series of thuds ricocheted off my head.

    “But Doreen helped us. She deserves to know about the change,” I sputtered.

    Jarrett calmly replied, “No, we need to get the document to the customer now and there is no time for further negotiation with Doreen.”

    I thought the notion of withholding information from Doreen was ridiculous, and just plain wrong. She had gone well beyond the call of duty to help Jarrett and me, but Jarrett seemed, as if playing checkers, intent on jumping over her position.

    My heart accelerated and I felt the thumps. A gentle voice inside me urged, “Slow down. Breathe.” I took a long breath. As my lungs inflated, I noticed that my spine straightened which caused me to sit up straight. I looked directly into Jarrett’s eyes.

    I struggled to show my empathy with Jarrett’s position. “I understand your desire to save time.” I took another breath and continued, trying to make him see my position because he had ultimate control. “Doreen is a stakeholder in this document too. If you decide to not tell her about the change, it becomes your change and I will not support it.”

    Jarrett’s eyes narrowed as he fired out the words, “I don’t need your agreement or support: It’s my decision and I’m moving ahead with it.”

    Years ago, those words would have struck fear into my heart. I regularly have to deal with Jarrett face-to-face. He’s a malicious person, a sales person who is trained to manipulate situations, and he could easily destroy my reputation in our office. On the other hand, I rarely see Doreen and she can’t help me locally. But if I go along with Jarrett’s idea, I will violate my own principles and destroy how I feel about myself.

    “It is your decision,” I said calmly, “I’m surprised though that you think Doreen and my support wouldn’t be an advantage when our management questions you about the pricing change.”

    I had Jarrett’s attention, but he said nothing, so I went on. “You’re going to need my support and especially Doreen’s. Our customer listens to me and trusts what I say. Remember, I’m the one who helped them define their requirements. And you’re going to need help explaining to your management why a pricing change makes sense. Doreen is the only person who can do that for you.”

    The muscles around Jarrett’s temple moved up and down as he repeatedly tightened his jaw. “I don’t like to be threatened,” he spit out.

    “My intent is to help rather than harm you,” I said. “Doreen will find out about the change. She will trust neither you nor me and that will cost both of us dearly in all future negotiations with her. You may be willing to pay that price, but I’m not.”

    His eyes looked toward the ground. Silence.

    “I’ll think about it,” Jarrett said.

    Did I make a difference? My answer arrived the next day when I received a copy of his message to the customer. Rather than discounting the services that Doreen and I had helped him develop, he cut the price on another part of the sale.

    So, did Jarrett change for the right reason? The answer depends on how you define “right.” My definition is different than Jarrett’s. His principles are narrowly focused on doing whatever it takes to win this sale. My own principles are broader and focused on sustaining relationships that win business both now and in the future.

    If you’re focused on short-term results, keeping secrets may have great appeal. But if you care about building relationships for the future, pay careful attention whenever you hear the words, “Don’t tell …” The words that follow will invariably violate a relationship.

    convert this post to pdf.

    Decide As a Team

    ©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.