Sunday, May 23, 2010

Stop That Mole Now

©2010 Steven M. Smith

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

A mole erodes productivity. Stop that mole now.

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

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

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

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

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

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

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

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

convert this post to pdf.

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.

    Tuesday, September 8, 2009

    When Your Projects Are a Program

    ©2009 Johanna Rothman.

    I was supposed to start coaching with a project manager, Trish. She postponed our weekly coaching call–for the third time. I said, “Trish, are you postponing again because you have too much work to do?”

    “Yes!”

    “Then I suggest we carve an hour out of your day sometime sooner than next week and determine why you have so much work to do.”

    She reluctantly agreed.

    When we spoke later that day, I asked her about all her projects. She sent me her spreadsheet of everything she was working on.

    “Trish, I see these three projects. They are unique and stand-alone, right?” She agreed.

    “I’m confused about these six projects here, and those seven projects there. Are they related to each other?”

    They were. The six projects composed Program1 and the seven projects were Program2. Each project in the programs had its own project team, so Trish was trying to manage 13 project teams for the two programs.

    How did we decide these projects were really programs? Without the sub-projects, the larger “project” had no value–that is, the organization could not release the sub-projects or the larger “project.” That interdependency of sub-projects to create one valuable deliverable is one definition of program.

    A program is a collection of projects that all together deliver significant value. Each project may have some value by itself. But the real value is the collection of projects into one deliverable: a program. You might have a program of a number of subprojects all with one release date. Or, you might have a program of phased releases, where each release delivers some significant value.

    Managing one program is difficult enough. Managing more than one plus other unrelated projects is impossible. But the first step is to recognize when you are managing a project or a program.

    Once we collected all her work and decided which were projects, which were programs, and the relative progress on each one, we could start solving the problem of how to manage all that work.

    Trish was very lucky. Of the three projects, two project teams had been pushing at her to let them work feature-by-feature in timeboxed iterations. She?d never managed a project like that so we discussed how to assess project progress. I assured her that once she saw a velocity chart she could let her Gantt charts go. That?s because a velocity chart shows actual progress of completed work.

    She also promised to assign one of the technical leads who had been helping her on each of two teams as the real project manager for those projects. Now we were down to one project and two programs. We discussed the relative importance of the three efforts, and realized that both programs were more important the project–at least, Trish thought so.

    I asked, “Can you really manage both programs at the same time?”

    “No.”

    “Do you have someone you can ask to manage one of the programs?”

    “No.”

    Ok, so now Trish feels stuck. She can?t do all the work and she doesn?t know anyone else to ask. It?s time to ask for help.

    We discussed what she could say to her manager, Ted, so he could see the seriousness of the situation and help Trish with her work.

    “First, make sure you know what Ted wants. Make sure he actually wants both programs and this project completed at the same time. Do you know that he does?”

    “Um, no. We never discussed the real due date. Everything here is due yesterday. It never occurred to me I had some wiggle room on when things needed to be done.”

    “You might not. But you might. Asking ‘when’ might be a big help. If all the releases are staggered, no problem. But I bet they are not staggered, so after the when question, ask which project or program is more important.”

    “JR, I know that Program2 is more important.”

    “How do you know?”

    “It’s obvious.”

    I repeated my request for Trish to ask Ted about the relative importance, and sure enough, when we spoke again, the priorities were not what she expected.

    “Ok, the priority was not obvious. It turns out that Program1 is more important than anything else I?m doing. Surprised me. I could have sworn that Program2 was more important. And that other project? That’s not even on Ted’s list of things to discuss.”

    “Ok, can you stop work on Program2 now, and concentrate on Program1?”

    “Yes! If Program1 is delayed, I?ll be in trouble because that will postpone Program2, but for now, I can work just on Program1.”

    We discussed how to organize Program1’s work, how to have other people lead the project management on the subprojects, and how to see if Program1 was making progress or was in trouble.

    Trish was lucky. Normally managers say everything has to be done–and now! If you want some tips on how to help your manager rank projects, see the next Pragmatic Manager.

    In the meantime, if you are attempting to manage 57 gazillion projects, or develop 30 bazillion, or test 92 zillion projects, first think about whether each effort is unique, as a project or if the work is interdependent and is a program. You’ll make different choices about the work you need to do depending on whether this is a project or a program. Sometimes, it’s much easier to see how things fit together when you know you’re managing a program.

    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.

    Wednesday, July 8, 2009

    Make Your Mission Possible

    Copyright 2008 Johanna Rothman, originally published in Better Software

    Janice strode down the hall and made a sharp right at a cubicle decorated with dragons. “Hey, Steve, got a minute? I need your help with a problem.”

    “Janice, the last time you asked me for my help, I got stuck in that installation mess. I appreciate being one of your team leads, but I get worried when you ask for help with problems. What’s going on now?”

    “We have a problem with customizations for Big Customer2. The good news is that we do these customizations, right?” Steve nodded. “But the bad news is that we have to port them from release to release.”

    “We did that last month.”

    “Well, you did. Then tech support decided to add the extra piece of the reports we discussed last month.”

    “What? Why did they do that? Not to this product-they can’t.”

    “Well, Big Customer2 paid us a pile of money for not too much work. And that’s where you come in. I need you to add that new report to the point release you’re working on now.”

    “How much money? I bet tech support has no idea how much this piece of the report will cost us to support or how much time it will take away from our next release. We can’t just think of this report as a pile of money; it’s a headache. We were never going to put that functionality into the product. We were going to put it in the new reporting system, remember? Now we’re going to have to support that report forever. Big Customer2 is never going to want to change.”

    Steve put his head in his hands. Finally, he looked up and said, “OK. I’ll do it. But on one condition: We decide what we’re doing as a development group once and for all. You asked me to be a team lead, right?” Janice nodded. “Well, I don’t know what I’m leading. Let’s decide what our mission is-whether it’s to support any crazy thing our customers want, or make products, or support installations, or what. Let’s define our mission and write our mission statement. Then we’ll have a basis on which to say no to new work if it doesn’t support our mission. From now on, we will have a reason for the work.”

    A week later, Steve and Janice met to develop their mission. “Steve, I invited Chris so we have all you technical leads in one room. Since you prompted me to think about the mission for our group, I decided to ask my boss for his mission, as well. He doesn’t have one yet, so we may have to revise ours later. But at least we’ll know where we’re going.”

    Janice placed two lists on the table. “Here’s all the work we’re doing in development. One list is a month-by-month portfolio of all of our projects and all the extra things I’m supposed to do as a manager. This other list is the work other people would like us to do that we’re not doing. Now, do you two have work you’d like to be doing that’s not on this list?”

    Chris and Steve nodded.

    Janice handed them a stack of index cards and said, “OK, let’s write all the work we’re doing and the work we’d like to be doing, one project to a card. We’ll organize them on the table into these buckets: work that seems to make sense for our group; work that needs to get done, but maybe not by us; and work that we are doing but we don’t understand why.”

    After a few minutes, Janice, Chris, and Steve had their cards sorted. Chris said, “Wait a minute. Why are we looking at the work? Why don’t we decide on our mission first and then manage the work?”

    “Good question,” Janice said. “Since my manager doesn’t know his mission, yet, I’m not sure we can finalize ours beyond the work we do. Clearly someone in the company values our work, so we have to make sure we continue to do work the company values but that also makes sense for us to do. By starting with an analysis of our work, we’ll have a basis for our decisions-especially when we start looking at the work we’d like to be doing that we never have time to start.”

    Janice, Chris, and Steve discussed their work, bucket by bucket, starting with work it made sense for them to do.

    Next, they discussed the work that they thought the company needed to have done-but not necessarily by them-and put a sticky on the card with the name of the group that they thought should do the work.

    Finally, the trio discussed the work they didn’t understand why they were doing. Janice wrote a sticky with the name of the person she was going to talk to about those projects.

    “Now that we understand our work and the reasons why we have it, let’s discuss our mission. A good mission explains what we do and don’t do. It establishes the boundaries of our work and explains how our development group fits into the organization. A great mission will provide reasonable and measurable objectives for our work so other groups can see what we are responsible for-and not responsible for,” Janice explained.

    “Oh, so I don’t have to add something impossible such as, ‘Respond to all requests in twenty-four-hours’?” Chris asked.

    “No, that’s how we got into trouble with Big Customer1 last quarter, remember?” Steve said.

    “You know, if we were a custom development group, responding to all requests in twenty-four hours might make sense. But we’re not!” Janice said. “Let’s develop a mission that makes sense for us, and I’ll talk it over with my boss. I’ll convince him our mission is on target.” Janice grinned. “But if he doesn’t agree, at least I’ll understand what he wants us to do differently.”

    The three of them worked for a while, until they were satisfied. Janice said, “Read the mission out loud, Steve so we can hear it.”

    “We will enable our customers to organize and see their data by creating products that our company can sell. We will continue to extend each product and family of products so the products provide a cost-effective solution to our customers’ needs.”

    “OK, with this emphasis on products and product families, as well as cost-effectiveness, I now have ammunition to say no to more of these customizations,” Janice said. “Maybe my boss will think about his mission instead of just saying yes to everything that he sees. But if not, we can use our mission to set some boundaries for what we do and what the company does. Thanks, guys.”


    Story Lines

    1. Without a mission, you can’t define the work that belongs in your group and the work that doesn’t belong.
    2. A mission should say what you will do and help you explain what you won’t do.
    3. Beware of missions that promise immediate response or continuous response to the organization unless you do have a 24/7/365 organization and the staff to support that service level.
    4. It’s easier if your manager has a mission, but if your manager doesn’t, start with the work you do (and want to do) to generate your mission. Be ready to revise your mission when your manager develops his.

    Acknowledgments:

    I thank Dwayne Phillips and Esther Derby for their review.

    convert this post to pdf.

    Wednesday, June 10, 2009

    The Blame Game

    ©2007, 2009 Don Gray and Jerry Weinberg

    Engelbert watched Pam nervously chew on her knuckle as she stood in the door of his office, answering his call. “Come in and close the door.”

    He motioned her to a seat, then stood and pointed an accusing finger down at her. “We need to decide how you’re going to explain what happened with the UDCRM release”, he said. “You’ve managed to upset everyone. Sharkey told the CEO the customers are screaming because we can’t ship on time. This makes the entire development staff look bad.” He paused for emphasis. “It makes me look bad.”

    Pam started to respond, but Engelbert shushed her with an open-palm gesture. “I don’t need excuses from you. Or apologies. What I need is a memo accepting full responsibility for missing the schedule.” He reached for a sheet of paper on his desk, then held it out to her. “I’ve drafted something appropriate to make it easier for you. All you have to do is sign it.”

    Pam’s eyes fell to the floor, avoiding the paper. She knew she wasn’t responsible. If anyone was responsible, it was Engelbert. She tried to think of a way to refuse, but Engelbert interrupted her thoughts, thrusting the paper close to her face.

    “Pam, don’t even think NOT signing this memo. If you refuse to sign, I’ll have no choice but to let you go.”

    Pam struggled to keep from crying. Engelbert sat down next to her and put an avuncular hand on her back. “Don’t make me do this,” he said, his voice turning soft and empathetic. “Have you looked at the job market lately? This isn’t the boom time it used to be. There hasn’t been a decent job in the paper in months for someone with your background.”

    He took a handkerchief from his pocket and dabbed at her tears. “I’ll do my best for you in the meeting,” he said gently, putting away his handkerchief and handing her his pen. “After a little time this will all blow over. They’ll probably forget about how poorly you did, and you can try again.”

    The Tangled Web

    It seems that the Software Engineering VP,Engelbert, has a problem. The problem started in the Liar’s Contest when he agreed to play, and thereby lost. By not planning for a disaster (No Exit) he ensured one would happen. This lead to Pam becoming the Identified Patient. The project didn’t succeed, and all Pam has to do is the sign the document accepting the responsibility (blame) for missing the schedule.

    In her distraught state,Engelbert suspected that Pam wouldn’t think clearly. He helped make the experience easier by having her confession already typed and ready to sign. When Pam balked at signing he extorted her. Extortion occurs when a person obtains money, behavior, or other goods and/or services from another by wrongfully threatening or inflicting harm to this person, their reputation, or property.

    We can see in the following diagram that Engelbert had at least three options available to him. He could:

    • Respond negatively, looking for reasons, usually blaming someone else) for the results.
    • Decide no difference exists by ignoring the results and do nothing.
    • Respond constructively, learning from what happened and improving at getting the results we desire.

    Choices for a poorly ending project.

    Choices for a poorly ending project.

    Of the three choices, only the bottom loop, Improve Software Development, reduces the likelihood that the next project won’t fail. Improving software development will involve training for such things as the development method (changing from waterfall to iterative) or support (version control systems, development tools) and time, making it the least likely choice in this environment. Ignoring the failure (or declaring the results a ?success?) leaves the existing system structure in place, and pretty well assures the next project will unfold like this one. Choosing to blame someone for the failure creates new and different problems.

    Let the Game Begin

    Blaming attempts puts the responsibility for the problem “on someone else”. If successful, the blamer becomes exonerated and the “blamee” now has to deal with being the cause of the problem. In hierarchical systems, blame (like many other activities) starts at the top, and flows down from there. Englebert may be getting heat from Sharkey and the sales organization about missing the delivery date. Englebert may be a skilled player, and is setting Pam up for the fall, being able to report, “I’ve already taken care of the problem.” Unfortunately the problem Englebert solved, him being blamed, doesn’t help solve the real problem, how to be more effective at software development and not have bad project results.

    Blame affects organizations on multiple levels creating different problems.

    • Employees quickly learn defensive maneuvers such as CYA. They split their time between making sure they won’t “catch the blame” and doing project work. This affects both focus (context switching between project work and dodging blame) and the time available for project work. This increases the probability the next project will fail.
    • If it goes long enough, people leave. The competent employees leave first, creating a brain drain, which increases the probability the next project will fail.
    • Those that remain have developed dodging skills, not development skills. Thus they’re more likely to be around longer, get promoted, and the cycle perpetuates itself.
    • Attention never shifts to improving the process, so the systemic solution (improved development capabilities) never gets developed.
    Results of blaming

    Results of blaming

    So blame creates problems beyond the original problem. It creates negative emotions, a talent vacuum, and a downward spiral. Talented people won’t work in a blaming organization. The amount they have to pay new employees goes up. This reduces the bottom line, which puts pressure to develop faster, but without improved skills failure actually happens faster, which increases the blame, and around the blame dynamic goes once more.

    Note that all three loops in the Blaming in Action diagram are reinforcing (or positive feedback) loops. This says that once these loops start working, they will continue to grow stronger until something, somewhere else in the system collapses.

    An Ounce of Prevention

    The best way to deal with such a situation is to not get involved in the first place. But in the excitement of a new project, and new responsibility, it’s understandable Pam didn’t see the warning signs.

    The next best advice involves noticing the signs of a failing project. You can learn a lot about a project status by checking for congruence.

    • Observe what’s actually happening. Are people doing what they say they’re doing?
    • Listen to the language people use. Do you hear blaming?
    • Does it feel like there’s an elephant in the room that no one acknowledges?

    No one can come out and actually say the project looks like it’s failing. That would set them up to be blamed.

    Blaming cultures reveal themselves in a variety of ways. Attitudes such as “failure’s not an option”, or “if you can’t do it, we’ll find someone who can” give one such indication. Another tipoff is hearing phrases like ?It’s not my fault.” “She/he did it”, “You didn’t tell me”, and “I didn’t make that decision” (or their inverses). When you see an exodus of employees, it’s probably a sign the blame loop is functioning at full force.

    Multi-level Blame

    Blaming doesn’t start at the bottom of the company. Programmers don’t hunt for someone to blame when the a project is late. They scurry for cover. Blaming starts higher in the organization. In this case, the blame occurred at the VP level, between Sharkey and Engelbert. Blame can be thrown around like a hot potato, everyone looking for someone else to throw to.

    Engelbert wasn’t able to pass the blame at his organizational level, so he passed the blame one level lower by setting Pam up to receive the blame, and extorting her. If Pam chooses to play the game, she in turn could look for a team lead to blame for the late delivery. And then the team lead could hunt for someone on his team to blame.

    What’s A Girl To Do?

    At this time, Pam certainly feels like a “deer in headlights.” If she doesn’t get some space to breathe, and time to think, she’ll most likely sign the paper. Pam needs to do something to break the setting. A deep relaxing breath. Shifting her position in the chair. Standing and moving. Getting some space would provide time to think and distance from the problem (as in being blamed). Get a headache. Go to the bathroom. Anything to create space and gain some time.

    One thing she could do is threaten, “If you fire me, I’ll tell the whole story when I’m on my way out.” This is blackmail countering extortion. Playing this card requires being ready for “on the way out”.

    Confronting Engelbert in his office probably won’t work. Counter-blaming Engelbert won’t work. He has more experience playing the game and can control the flow information to higher in the organization. He’s hoping Pam will placate and sign. Blaming and placating are two of the coping stances available to Pam.

    By adding the context to the discussion, other stances become available. Pam can do this by asking “What have you seen or heard that makes you think that I’m responsible for this failed project?” This opens the possibility for a congruent conversation recognizing and balancing, self, other, and context. Pam can then act congruently. While Pam can’t make Engelbert be congruent, she can demonstrate congruent behavior and work towards the best possible outcome.

    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.

    Friday, May 8, 2009

    No Exit

    Always have an exit strategy.

    ©2005 – 2009 Don Gray, Gerald M. Weinberg

    “The thought that disaster is impossible often leads to an unthinkable disaster.” – The Titanic Effect, The Secrets of Consulting, pg 95

    Engelbert, the Software Engineering VP, sat quietly in his office pondering the current state of UberDenke’s next UDCRM release. Slowly he had realized the release wasn’t going to ship on time. There were many more errors than he planned for, and over half of the code had not even reached the testing group.

    The more he thought about it, the more he felt trapped. The more trapped he felt, the more he wanted out. The more he wanted out, the more he felt trapped. And around, and around his feelings traveled in a vicious circle of trapped and wanting out. But there wasn’t anyway out.

    Or was there? Engelbert’s thinking and actions have trapped him in a reinforcing feedback loop. His feelings are creating an emotional downward spiral that will continue until some system limit is encountered. The system limit may be the when he finally admits to others the release won’t ship on time. Perhaps his health (mental or physical) may break first. Or maybe he’ll change jobs.

    We can all sympathize with Engelbert?s plight, because at some time or another, we’ve all been caught like this–a trap artistically summarized by Jean Paul Sartre’s depressing play about three people trapped in Hell, No Exit.

    Engelbert set up his own No Exit hell right from the beginning, because he, like Sartre’s victims, had no exit strategy. An exit strategy is a planned set of activities to initiate when one party suspects that a relationship isn’t working, activities that should prevent the situation from becoming a hellish trap.

    Dynamic Basics – Getting Started

    The no-exit dynamic generally begins when two (or more) parties agree to work jointly on some project. Sometimes the agreement is not explicit, as often happens when the work of one party depends on another party’s output. This joint work could stem from a voluntary relationship (such as co-authoring articles) or perhaps from a management mandated decision. In Engelbert’s case, his manager told him to use a new process to build the next generation of their software product.

    The parties start merrily to work under the agreement, and all goes well for a while. Next, life happens.

    Perhaps the person with whom you agreed to write an article falls ill, changes jobs, or takes time away from the joint project to deal with pressing family problems.

    Perhaps the other team at work discovers the problem is more difficult to solve than anticipated. Possibly another higher priority project siphons manpower from their team.

    Or perhaps the dynamic starts up when the levels of commitment and interest are unbalanced, or when there is a different understanding of the agreement.

    Locking In

    The first slip or two may not create a problem. We use explanations like these:

    • It’s only happened one time. (Not noticing prior behavior on the part of either party).
    • Things are bound to get better. (Seeing through rose colored glasses)
    • I’ve made a commitment, so I’d better not say anything. (The team player problem)
    • They’ve got a plausible story. (Just one more chance).
    • I’ve already invested so much, a little more investment and I’ll have what I want. (Good money after bad)

    Whatever the reason–and there are hundreds of variations–the slips soon become the norm, not the exception. Since the slips happen individually, separated by days or weeks, the cumulative effect isn’t noticed until it’s too late to do anything reasonable about the slips. The more we become accustomed to the slips, the more tolerant we become as new slips occur. It’s not that Engelbert is stupid. It’s just that he lacked foresight, or was too optimistic. If he had known when starting development that the project would slip several times, he could have planned differently.

    Failing to take early action sets the precedent for continuing failure to act. Failing to act causes negative feelings to accumulate. The negative feelings are there from the first slip, but they are ignored or suppressed until the accumulated value becomes greater than we can tolerate. When we finally surface the negative feelings, we feel trapped by our previous actions. We’ve become locked in the reinforcing feedback loop of simultaneously wanting out and feeling trapped.

    In this dynamic the system continues accumulating more negative feelings until the system experiences a catastrophic collapse. Engelbert may be fired, or quit, or get sick, or ship a system that drives his company out of business.

    Setting up the Exit

    So, what’s the solution? The first step to exiting the reinforcing feedback loop is to become congruent by balancing the factors of yourself, the other party or parties, and the context in which the dynamic is taking place. Most commonly, in this type of a feedback loop, the other becomes lost. As you try to cope with the situation, you start blaming the other person for the problem, and that only tightens the loop. Responding incongruently like this creates stress and does nothing to improve the situation or help find an exit from the loop.

    Becoming congruent allows you to be centered in your actions. Being centered opens a range of responses you can use to change your view, each of which might break the trap. By changing your view of the situation, we can see possible interventions that will change the loop dynamics. Among such interventions are these:

    • Changing how you see your contribution to the problem.
    • Determining why you feel like you’re trapped.
    • Obtaining a better understanding of what you heard during the “agreement” process.
    • Bringing in a third party who adds a compensating loop. Sometimes you do this by just letting the loop escalate until someone else is affected, often by not trying so hard on your side. This is an example of:
    • Doing the opposite of what you’ve been doing. This personally applies Marvin’s Fourth Great Secret, ?If what they?ve been doing hasn?t solved the problem, tell them to do something else.? The Secret of Consulting, pg 41

    Exiting the Loop

    No self-reinforcing loop can last forever. Sooner or later, one way or the other, the loop will exit. If no action is taken, the reinforcing loop will continue its downward spiral until some other part of the system collapses:

    • Personal health (mental / physical) will deteriorate until the exit happens. (This is breakdown of the self.)
    • The interpersonal relationship will decay and animosity replaces the original camaraderie. (This is breakdown of the relationship with other.)
    • A third party starts to be affected and intervenes. Of course, this is the result some people are hoping for (if we make enough noise, Mommy will stop the fight). But, you can also encourage it. (This is where the context intervenes.)

    Another exit option is to become centered, congruent and work on changing the loop dynamics. The key here is to recognize the No Exit dynamic early, and take corrective action quickly. Your plans and strategies must be flexible. While the goal can be constant (exiting the loop), life continually changes, so fixed plans inevitably become obsolete or, even worse, counter-productive.

    When the loop finally exits, there are several possible outcomes:

    • An intervention works and the joint effort continues
    • The “healthy” participant becomes “sick” and the effort ends due to lack of effort
    • One person takes over the entire effort

    This applies to multiple party systems (two or more). In addition to software development this could include:

    • marriage and other long term interpersonal relationships
    • business ventures
    • article or book writing
    • sports or other activities you are doing “for fun.”

    An Ounce of Prevention

    Next time, Engelbert should consider prevention interventions. Prevention interventions can be used to prevent the No Exit dynamic from happening in the first place. Or if it starts anyway, they provide an agreement among the parties as to how to handle it–if you like, a meta-agreement, or agreement on the limits of our agreement and what we’ll do when we reach them.

    In a crisis, it’s much easier to stop and think if you have provided time in your plan for stopping to think. If you haven’t, one party will say, “Here you tell me that we’re behind schedule, but you’re adding this thinking-bit to the schedule. That doesn’t make sense.” With that easy dismissal, everyone quickly hurries back to their unproductive panic.

    Examples of advance preparation of exit strategies include:

    • Periodic check-ins
    • Gate points where either party can exit the activity, if they’re not perfunctory so you can really exit at these points
    • Better understanding and more explicit statement of each party’s expectations, along with a process by which expectations can be modified along with the plans that were based on them.

    A well-designed system will set some limits at the beginning, limits that are not vulnerable to a buildup of tolerance.

    Third Party Interventions

    Most parents have learned some dos and don’ts about what to do when they witness such a no-exit loop. If you find yourself on the outside looking in, you might apply one of these principles:

    • Know when to enter (never do unless you’re asked for help, though you can encourage the parties to ask you).
    • Prevent damage (whatever that is) to others.
    • Decide it’s not your problem and walk away, letting the nature of the no-exit loop take its course.
    • Avoid creating addiction (co-dependent) dynamics.
    • Avoid using fixes that accentuate the dynamics, unless you want to make it worse so it will crash more quickly or lead to enough pain that the parties will work out their own solution.
    • Be careful not to prevent natural learning.
    • Look for interventions that remove barriers and/or increase resource states.

    Exit Levels

    In deciding about intervening, choose which of three Exit Levels you’re seeking:

    • First exit is when participants realize how much pain the feedback loop is causing and figure out a way to break out for themselves.
    • The second exit is out of the situation (as when the parties concur that the agreement has failed). This may lead to a new agreement, or an exit agreement where they continue the relationship with each other.
    • The third exit is where one party opts out of the system by ending the relationship.

    Of course, the best exit is the one you have planned for before you ever get started. Unfortunately, there’s a prevalent romantic notion that real relationships shouldn’t need a pre-nuptial agreement. As Engelbert’s boss argues when he tries to set up some exit strategies before his next project, “Thinking of possible failure is negative thinking. It’s just that kind of thinking that guarantees we’re going to fail. Just like you did that last time.”

    Of course, the last time, they had no such exit strategy, so their failure was much more costly and painful than it need have been. That’s The Titanic Effect: The thought that disaster is impossible often leads to an unthinkable disaster–”Why would we need lifeboats on an unsinkable ship?”

    convert this post to pdf.

    Friday, April 24, 2009

    Is Collaboration the Right Way to Work?

    ©2008-2009, Esther Derby

    As a manager, your job is to organize people and work for success. That includes work design–figuring out whether you have a group or a team, and creating an environment where people can do their best work. I don’t know about you, but work design wasn’t part of my training as a technical person. And it’s not explicitly included in many business and management programs either.

    The default belief seems to be “teams and collaboration are good,”  and in a previous column, I wrote about the benefits of collaboration.  But is collaboration always possible?  Is it even the right thing to do in every situation?

    In this article, I’ll show different levels of collaboration, and lay out the questions that managers need to answer to decide whether they have a group or a team.

    Connection

    Josh and Julie work in a tech support area. The primary responsibility of the unit is to configure, tune, and support servers.  The workflow is controlled by a ticket system where the requestor submits an order with basic requirements and most of the work is handled first-in, first out. Of course, there are exceptions, when there’s extra lead time to order a special server or establish the configuration for a new product. But those orders are the not the rule.

    And though different people excel in different areas and each brings unique talents, the most server installs in their company require a core set of skills.

    Josh, Julie and their co-workers have a connection: they share professional skills, hold each other in high regard, and let each other know what they are working on. Julie, Josh, and their co-workers help each other when asked, but they don’t really collaborate. The workflow in their department isn’t conducive to collaboration, nor does the work require it. They may call themselves a team, but they aren’t engaged in teamwork. And that’s just fine. There’s nothing wrong with being a workgroup if that’s what the work needs.

    Cooperation

    Deb and Doug run test labs for two different products within the same company. Because their respective products are on different release schedules, there are times when the equipment in each lab isn’t fully booked.  They cooperate with each other by loaning resources when its possible and makes sense to do so. Deb and Doug are working together to meet organizational goals. But they aren’t a team.

    Coordination

    Frank and Frannie work in a product development group. Each has responsibility for a distinct product aimed at different consumer groups. They meet on a regular basis to keep each other abreast of release schedules. They consult with each other about market trends as they prioritize features. It is necessary to coordinate, but given the product mix in their company, it’s not necessary for Frank, Frannie and the rest of the group to collaborate with each other to achieve their goals. No team here.

    Conglomeration

    Ellen and Eddy work on a large project-over 100 people. Their manager calls it a project team, but there are people on the “team” they wouldn’t recognize if they passed them in the hall. Their project is too big to truly be a team, though there are sub-groups within the larger project who function as collaborative teams. Groups larger than 12 or so almost always break down in to sub-groups-which may or may not be teams.

    Collaboration

    Abby, Alec and their four team mates work on a software development team. They have overlapping skills all of which are necessary to build the product.  They jointly commit to a goal and work very closely to deliver working software in two week iterations.  They share a goal, they are mutually accountable, and if they don’t work together, they won’t succeed-they are a team.

    So, as a manager, how do you determine how to organize people to accomplish goals?

    1. Consider the work goals. Are people committing to a leader to achieve individual goals, or are group members mutually committing to each other and sharing accountability?
    1. Examine the skills needed to do the work. Does all of the work require the same (or similar) set of skills or does the work require broad range of skills?
    1. Analyze the work. Is the work mainly projects that one person can complete from start to end-individual products? Or does the work of several people need to integrate to create a coherent whole-collective products?

    If you answered ‘yes’ to the second question in each pair, the work is probably best suited for a team.

    On the other hand, there’s nothing wrong with work groups that aren’t teams. If you answered ‘yes’ to the first question in each pair, the work  probably best suited for a work group.  It is important to determine which will best meet the needs of the work.

    Building a team doesn’t happen by accident…. and your job as a manager will be different from the manager of a workgroup. I’ll talk more about that in a future column.

    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.

    Friday, April 3, 2009

    Transitioning to Agile in the Middle of a Project

    ©2008 Johanna Rothman.

    This article was previously published on stickyminds.com

    “My company has decided to transition to agile after the team and I started this project,” Gina complained. “I know what agile is, but I still don’t understand how I’m supposed to transition my active, waterfall project to an agile project. I understand how to start a project in an agile way, but what can I do after a project has started? My managers don’t understand what’s going on. My team doesn’t understand either. I feel as if I barely understand. What am I going to do?”

    Here’s a solution: Start by helping your team find a project rhythm and finish pieces of functionality. If you’re trying to transition in the middle of your project, follow these three simple steps to ease you into agile:

    1. Establish timeboxes.
    2. Finish partly done work.
    3. Build a dedicated cross-functional team that includes developers, testers, writers, business analysts–anyone you need to create a product in its entirety.

    Decide on the Length of the Timebox

    The timebox helps the project team focus on the work they need to complete in a given time period, so they’ll need to estimate how much work they can finish in this time. Most people don’t have a lot of experience estimating, and estimating for the entire team can be tricky. A good rule of measure is the shorter your timebox, the less the team has to estimate, and the faster they get feedback on their estimates.

    Make sure your timeboxes are no longer than four weeks. Any longer, and people can get stuck in “student syndrome” (putting off work until just before it’s due), or they overestimate what they think they can complete.

    Start with a short timebox–no longer than four weeks. This short timeframe makes people feel the urgency of the timebox and teaches them to break work into smaller tasks. You’ll see tangible progress from day one. But be aware that for some teams, even a four-week timebox can be too long.

    Gina started her team with four-week timeboxes. When the team couldn’t finish the features they estimated they could, she went to three-week timeboxes–but that was no better. When she shifted into her first two-week timebox, a tester confessed, “I really need you to tell my manager to stop assigning me to other projects because I can’t do those and finish what I need to do here.” Gina said it would be her pleasure.

    When people work in timeboxes, they cannot work on two projects. As Gina’s team discovered, forcing people to work in short timeboxes exposes some of management’s misconceptions about how people need to work to be productive.

    It wasn’t just the tester’s management who was unclear on how agile works; everyone was confused. Some developers thought they were done with their pieces as soon as the code compiled on their machines, without checking that the code worked across all platforms. One particular developer thought the idea of ensuring that his code worked on all platforms every time that he checked in a change was a “waste of time.” Gina asked him to track his time for an iteration and promised to discuss these concerns with him at the end of the timebox.

    Gina had data on how long it took the other developers and testers to find and fix problems that arose from not checking the code against all platforms as the developers developed it–about twenty-five hours to find and fix problems. The developer spent about five hours during a two-week iteration to make sure his code worked on all platforms. Once the developer saw Gina’s data, he acknowledged that it made sense for him to make sure his code worked everywhere before checking it in.

    Moving to two-week timeboxes also exposed the issues that prevented the team from completing its work. For example, the shorter timebox made it impossible for the testers to work on Gina’s project and other projects simultaneously. Gina knew she had to convince her management that she needed the testers on her project full time. The transparency of the issues allowed Gina, management, and the team members to resolve their problems.

    Finish the Partly Done Work in Order of Value

    If you’re in the middle of a project and you’re transitioning to agile, rank the partly done features by the value you expect them to provide when it’s complete. First, develop the most valuable feature to releasable quality. Then work down to the least valuable feature.

    Gina tried to rank the features for her product manager, but she made the mistake of ranking the features based solely on the project team’s input. When she presented her product backlog of partially completed features, he told her she was wrong–he needed things in a different order.

    Of course, it made more sense to finish some features first because of the way the team had started to implement them. Once the product manager understood this process, he agreed that some features–ones not that important to him–should be finished earlier than he wanted. As he explained his feature ranking, the project team gained insight into why it was important to finish some features earlier than others. This discussion about value was critical to the project team’s understanding of what it meant to finish a feature. In the past, the team had been successful with partially implemented features in the major release and would finish the features in a point release. But once the product manager explained what he needed from certain features, the team understood what it would take to complete the feature.

    When I say finish, I mean doing whatever is necessary within the timebox to reach a level of quality where a feature can actually be used by a customer. At a minimum, this means the feature has to be tested. You might need some documentation, such as help documentation. You might need some examples. Whatever you need, a feature isn’t done until it’s usable.

    If you don’t have a product manager, check with your customer or product sponsor–someone who knows what features the eventual customers will want and in which order. If you have no one, ask yourself why you’re doing this project. This is where a lot of teams trip up in their transition to agile. Your team might be like Gina’s, where the testers weren’t originally full-time on this project, and they had no automated tests from previous releases. When the testers and developers worked together uninterrupted, they created a series of automated, system-level tests. In addition, the developers created unit tests so they would know if they were breaking the code as they finished each feature.

    Gina’s team did not have 100 percent automated system tests, which made testing during the timebox quite difficult. The lack of test automation prevented the team from reaching a velocity they thought they could because they kept adding tests to the backlog. This issue arose during an iteration’s retrospective, and the team decided to tackle the problem so they could actually release the product. For the following iteration, some of the developers created a framework the testers could use to automate most of their tests.

    By the time they finished all the in-process work, the product manager told them they could release–a surprise to the entire team. Gina was convinced it was luck because they had not ranked the entire product backlog, just the in-process work. Regardless, she was willing to take luck.

    Make Sure You Have Everyone You Need on the Team

    At first, Gina wasn’t aware that her testers and writers were attempting to multitask on several projects. The problem surfaced when the team moved to shorter timeboxes, and no one had time to postpone work.

    Gina held a meeting with all of the managers and asked, “Do you care when we release this product?” Each person cared. “Do you care if we release it on time?” The unanimous answer was yes. Gina explained that their only choice was to keep everyone assigned to the project on it full time–no multitasking, no context switching, no quick interruptions.

    One of the test managers asked, “But how do I staff all my projects?”

    Gina said, “You don’t. If this project is more important than the others, you staff this one. You don’t staff all the projects.”

    The test manager replied, “But I don’t have enough people for the other projects.”

    Gina was tempted to say “tough” but realized that wasn’t a career-enhancing move. Instead, she said, “Look, you folks told me this project was critical to the company’s success. If it is, we staff this project. If we have too many projects critical to the company’s success, you folks have to decide which ones really are critical. But if you want me to run this project in an agile way, you can’t pull anyone off or ask them to work on more than one project at a time. They either work on this project or they don’t. This is a binary decision. The team can’t estimate what they can do nor can the project succeed if they have to work on more than one project at a time. Now, if you really think we have two critical projects and we need these people to work on both, we can alternate timeboxes to work first on this project and then the other. But I bet we don’t really have two critical projects.”

    The managers discussed this loudly and long and finally agreed with Gina. If they assigned people to her project, they would not ask those people to work on other projects.

    A Relatively Happy Ending

    Gina and the team successfully delivered their release, just a month after the senior management’s requested date. They had never delivered anything that fast before and with as few defects. However, the team was tired. Instead of maintaining a sustainable pace, they tried to add overtime to their last three timeboxes. Not only was the intensity of the work in the timeboxes something they’d not encountered before, they also realized adding overtime was nuts because it came at a high cost.

    Some people left the company to work where the intensity was lower. But a funny thing happened. Gina started receiving resumes. Since she wasn’t a hiring manager she forwarded the resumes to HR, so they were able to replace the people who left.

    When Gina’s boss told her to take over another project in mid-stream and “convert” it to agile, she said, “I’ll restart it as an agile project. I won’t start in the middle again. And I want some outside help if I have to do this with a new team again.? She got it.

    Transitioning to agile in the middle of a project is difficult. As a project manager, you have to learn to work in timeboxes, help the team plan just enough for a timebox, and resolve obstacles quickly. Management may still ask for a Gantt chart even though you don’t need one.

    If you’re a developer or tester, you need to collaborate closely with your team to accomplish “done” for each feature. If you’ve never worked feature-by-feature before, this can be quite difficult. And while the timebox helps you stay focused, the intensity of the timebox might be different from how you are accustomed to working.

    Moving to agile and seeing how the whole product comes together before the end of the project is a reward in itself. Try it.

    Acknowledgements:
    I thank Esther Derby, Tobias Fors, and Don Gray for their review of this column.

    convert this post to pdf.

    Tuesday, March 31, 2009

    The Technology of Cooperation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    convert this post to pdf.

    Wednesday, February 20, 2008

    How Much Building Is Too Much?

    ©2006 Johanna Rothman. This article previously appeared on stickyminds.com.

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

    Developers receive timely and frequent feedback

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

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

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

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

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

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

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

    Testers receive the option of which builds to take

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

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

    Nightly Builds Might Not Be for Everyone

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

    convert this post to pdf.

    Tuesday, June 5, 2007

    Becoming a Better Estimator

    (c)2007, Dave W. Smith

    As software developers, and managers of software developers, we have a reputation for making pretty lousy estimates. Part of that rap is unfair; many times the requirements that we’re asked to provide estimates for are vague, and change as the work progresses.

    But a large part of that reputation is true. We make lousy estimates, and we don’t seem to get much better as we go. One problem is that the feedback loop between the estimate and the achievement is often long. When you don’t begin working on a task until weeks or months after you estimate that work, the original mental context has been lost, making it difficult to use feedback to learn.

    Here’s a simple way you can begin to shorten that feedback loop and put yourself on the track to becoming a better estimator. All you need is a stack of 3×5 cards, a pen, and a watch or clock.

    It works like this: Keep a few 3×5 index cards in your pocket or within reach. Before you begin a task, which could be a task for a project at work or a task at home, pull out a card and jot down a short description of the task on the front of the card. Short is good?you only need enough to recognize the task, which helps if you interleave work on several tasks and thus will have multiple active index cards.

    Next, take a moment to think through what “done” means for the task, and what you need to do to get there. Now estimate how many hours it will take you to complete the task, and jot that down on the card. If you’re uncertain, write down a time range (e.g., “Est: 1/2″, “Est: 5-6″).

    This process should take less than a minute. It it takes longer, or you can’t first the task description on the card, or if your estimate is larger than 8 hours, take it as a hint that you need to consider breaking the task into smaller pieces. Rip up the card, and start over. One of the secrets to better estimating is admitting when you’ve bitten off more than you can chew, and then backing off to take smaller bites.

    As you start the task, turn the card over and note the date and start time on the back. If you break off from the task, or get interrupted, note the time, or at least make a check mark for each interruption. Seeing how often you get interrupted may surprise you, and the data can be useful when you look at it later for patterns.

    The back of one of my recent task cards (for a writing project) looks like this:

       5/30/07    6/1/07
        ------   -------
          9:00      9:15
         11:30     10:05 phone
    
                   10:10
                   10:45

    When you finish the task, total up the time and write an “Actual:” number below the estimate on the front of the card. And, while memory is still fresh, take a moment to reflect on what happened. If your estimate and actual match, congratulations. More likely, you’ve earned an opportunity to improve. (Even if your estimate was spot-on, you still have an opportunity.) Ask yourself: “What happened? What parts did I forget to estimate? What went harder or easier than I first thought? What could I remember to consider the next time I’m estimating a task like this one? What about my environment interfered, and how can I either change that or account for it in future estimates?”

    File the card away. If you keep a journal, jot down your thoughts.

    After doing tracking task time for a few weeks, you may notice patterns and recurring themes. Are you getting interrupted more at some times of day than at others? Are you better at estimating certain sizes or types of tasks? Are your actuals closer to estimates when you’re juggling fewer tasks? Noticing patterns in your own work will give you practice in noticing patterns in team projects, which improves your ability to help with team estimates.

    Tracking estimates and actuals has shown me that I have several distinct patterns of consistent underestimation. When estimating a writing task, I often underestimate how long a rough draft will take to revise. Now I break out separate tasks for drafting, revising, and final edits, and double my gut estimate for revising.

    Tracking your time can be a simple practice, and can be remarkably revealing. Give it a try.

    convert this post to pdf.

    Tuesday, May 15, 2007

    Approaching a Conflict in Style

    ©2006-2007 Esther Derby

    This column originally appeared on Stickyminds.com.

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

    * * *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    convert this post to pdf.

    Monday, March 26, 2007

    Building a Requirements Foundation Through Customer Interviews

    © 2004 Esther Derby

    “Our customer doesn’t know what he wants,” complained Sandy. “I try to get him to talk about the product and tell me what he wants, but it’s like pulling teeth.”

    Whether you are building a brand new product or working on evolving an existing product, understanding customer business needs is the foundation of a marketable product. But few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about product requirements. 

    Building the right product starts with asking the right questions. The right questions are those that help us get beneath the surface and understand the customer’s world, work, and concerns.

    First Things First

    Before you plunk yourself down in front of the customer and start asking questions, articulate your objective. What do you hope to accomplish by interviewing the customer? Do you want to explore broad options, understand a specific business processes, or learn all you can about how a customer uses a particular feature? Articulating a research objective sets the stage for a successful interview. A wandering, unfocused interaction will yield paltry results and frustrate the customer.

    Once you’ve defined your objective, brainstorm a list of all the questions you might ask related to the topic. Then organize the questions into themes and arrange them to flow from general to specific and familiar to unfamiliar. The process of preparing questions helps to identify key topic areas to cover. Following a set list of questions isn’t the point: successful interviewers invest time in designing and testing questions—but then use them as a guide, not a script.

    As you prepare for an interview, consider different types of questions. Each type will serve a purpose and elicit a different response.

    Context-free Questions

    Context-free questions are useful in the early stages of a project, when you are beginning to explore. Context-free questions help you decide which avenues to investigate and provide global information about the problem and potential solutions. Because these questions don’t imply any particular context, they are useful for any design project.

    Here are some product-related, context-free questions:

    • What problem does this product solve?
    • What problems might this product create?
    • What environment is the product likely to encounter?[1] 

    Context-free questions generate a deeper understanding of the product and project.

    Meta questions—questions about the questions—are a special sort of context-free question. Meta questions, such as “Do my questions seem relevant?” or “Is there anything else I should be asking?” are likely to surface areas where the customer assumes that you already know. 

    Open-ended Questions

    Open-ended questions invite the customer to expand on the topic.

    Use What questions to learn about events and considerations.

    • What happens next?
    • What factors are involved?

    How questions ask about the way things happen.

    • How do you use the product to__________?
    • How do people decide which option to select?

    Could questions ask the customer to imagine or express a wish.

    • Could you conceive of an example when you’d use the product this way?
    • Could you see a way to use the product to solve this problem?

    Closed Questions

    A closed question is one that naturally leads to a one-word answer, usually Yes or No. Questions that start with Can, Do, Are, or Is are usually closed questions. 

     

    Q: Do you have any problems with the wonder widget?  

    A: No.

    Closed questions are useful for confirming specific information, but are deadly as an interview staple. You want to delve beneath the surface, and closed questions won’t help you with that. 

    If you do happen to slip into a closed question, follow with a probing question to uncover more information:

    Q: Can you recreate the problem?

    A: No.

    Q: What steps have you taken to try to recreate the problem? 

    Multiple-choice questions offer a limited set of options and help to establish relative priority:

    • Which would you prefer, A, B, or C?
    • If you had to choose one, which would you choose, X, Y, or Z?

    Like closed questions, multiple-choice questions have their place, but shouldn’t make up the bulk of an interview.

    Past, Present, Future

    Ask questions about past use to understand problems and weaknesses in the product or feature. Use present-time questions to learn about how the customer currently uses the product or how he currently performs his job. And ask questions about the future to learn about trends and anticipate future needs.

    Past: When has the product failed to perform as you expected?

    Present: How are you using the product now?

    Future: How do you see your workflow changing in the next several years?

    Tell Me More

    Don’t stop at the first answer. Follow an opened-ended question with a probe to gain further insight. A good interviewer will elicit a second, third, and even a fourth response. When you want to learn more, use questions like these:

    • What else?
    • Can you show me?
    • Can you give me an example?
    • How did that happen?
    • What happens next?
    • What’s behind that?
    • Are there any other reasons?

    Be sure to probe for more information when you hear emotion or judgment:

    “I hate the way the floo feature operates!”

    “The product does a poor job.” 

    Dig deeper to identify unmet needs or weaknesses in the product. 

    Vague statements like “The product must be easy to use” call for probing to learn what “easy to use” really means to the customer.

    Questions That Aren’t Really Questions

    Some questions don’t elicit the customer’s opinion, but confirm the interviewer’s opinion instead. Biased questions suggest a “right” answer: “My investigation shows that automating the floo process will provide the biggest savings. What advantages do you see in that?” Leading questions make one response more likely than another. Biased and leading questions tend to feel manipulative, and a customer will tune out if he feels the interviewer is leading or putting words in his mouth. Compound questions make it difficult for the customer to respond at all, as in this example:

    “Do you think it’s okay to have a question with two topics—unless there are more than that, or if the topic is complex—and is it better to stick to short questions, except in the case where a longer question is better, or is it a judgment call, except in a special case?”

    Ask one question at a time, and give the customer time to answer. Rushing in with another question can give the impression that you don’t really care to hear what the customer has to say.

    Ask Why Without Asking “Why?”

    Curious children ask “Why?” endlessly. They want to know the answers to everything, even things that are unknowable.

    We want to know why customers do the things they do so we can understand the tasks they perform and the business needs behind the tasks. But an endless stream of “Why?” questions can wear on anyone’s patience. Worse, “Why?” can sound blaming, or feel like the interviewer is demanding a cogent explanation for something that’s unknowable.  

    Avoid putting the customer on the defensive by using How or What questions to dig beneath the surface. 

    • How did this come to be?
    • What was the thinking behind that decision? 

    Or simply ask “Can you help me understand this?”

    Putting It All Together

    Before you rush off to try out your interviewing skills, practice. Start with a colleague, and then try your interview with an internal customer proxy or subject-matter expert. 

    Most people find that maintaining rapport and tracking the interview takes all their attention. To help with this, consider working with a partner who can take verbatim notes during the interview. At the end of every interview, perform a short interview retrospective to identify what worked well and what you might want to do differently in future interviews. 

    Most customers appreciate the opportunity to talk about their work and participate in shaping the products they use. Prepare for your customer interview carefully and hone your interview skills through practice. Invest in learning your customers’ wants and needs so you can deliver the right products.

    convert this post to pdf.

    Wednesday, February 28, 2007

    An Appreciative Retrospective

    ©2007, Diana Larsen, FutureWorks Consulting

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

    “Have you tried AI yet?” I inquired.

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

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

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

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

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

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

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

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

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

    Book Cover

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

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

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

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

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

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

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

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

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

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

    Write down all the answers.

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

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

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

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

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

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

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

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


    For more on Appreciative Inquiry:

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

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

    convert this post to pdf.

    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.

    Collaborating With Other Consultants

    ©2004, Johanna Rothman

    This article was originally published in Diamond Harvard Business Review, May 2003.

    - I?m so busy, I barely have time to think. I don?t have enough money to hire on someone full time, but I?d like to get off the merry go-round.

    - I wish I had more business.

    - How can I take on jobs with more challenge?

    - I?m lonely. I don?t want to keep working alone.

    Consultants have problems like these all the time: living through the feast/famine cycle, inadequate knowledge to take on new work, and loneliness. If you?re suffering through any of these problems it?s time to consider changing how you collaborate with others.

    Collaboration can take many forms:

    • Refer other consultants
    • Write with another consultant
    • Present with another consultant
    • Refer a consultant for a fee
    • Work with one other consultant
    • Create a consulting partnership

    Review the collaboration steps and see where you can improve your collaboration to create an even more healthy consulting business.

    Refer other consultants
    Make a practice of referring other consultants to perform work you no longer perform. When I started my business, I taught test and development techniques to technical staff. I now focus my business on project management and people management, so I refer the testing and development work to other consultants.

    Refer work you no longer perform, even if you?re desperate for money. A colleague, Fred, had this story:

    “I had a slow period, and at the end of three months, I was worried about making the next mortgage payment. I took a contract to develop a system like some I?d developed as an employee. My first mistake was taking a full-time contract. Without making time to market, I couldn?t find new clients. My second mistake was taking development money instead of management consulting money. This client refused to hire me later at my management consulting rates because I?d performed development work.

    What I didn?t realize was that I could have suggested a good contractor or offered to manage the project for them. If I?d done that, the client would have seen me as a management consultant. As a management consultant, they wouldn?t have expected me on site for a full workweek. I would have performed the consulting I enjoyed, not the development work I did to put food on the table. I wish I?d thought of more alternatives.

    I don?t work for that company anymore, because they don?t believe I?m a management consultant. I can?t seem to break them of their initial impressions. I don?t use them as a reference. When the current management leaves, I might be able to consult to them, but for now, I cut off a client by taking work at a lower level.”

    Fred violated most of Weinberg?s Laws of Marketing :

    1. A consultant can exist in one of two states; State I (idle) or State B (busy).
    2. The best way to get clients is to have clients.
    3. Spend at least one day a week getting exposure.
    4. Never let a single client have more than one-fourth of your business.

    Fred had more alternatives to taking on the development work. He could have:

    • Recommended a fellow consultant to the client for no money
    • Suggested that he take over the project and run it for a fee
    • Coached the people performing the work
    • Referred the work to someone who wanted the work and received a finder?s fee

    If Fred had suggested another consultant for the work, he would not have made any money just then. However, he would not have been too busy to market; he would have had time to obtain more exposure; and he would not have allowed this one client to have all of his time.

    Referrals help you build your network. Clients respect you more when you define which work you will perform and which work you won?t perform. When you are helpful with clients and refer them to others, you are consulting?just not for money now. The money will come later.
    Consultants give advice. Some advice we give for ?free,? such as when we speak or write publicly, or when we refer. But when you offer limited free advice, such as referring other consultants, you make life easier for your clients. They will remember and ask you to consult for money later.

    Fred learned this painful lesson, and during the next slowdown, he contacted everyone in his network. He talked to some of his best clients, asking them about their business, suggesting books and papers to read. He noticed when local associations put on programs that were of interest to his best ten clients even when other consultants were speaking, and let them know about them. He became a resource, and after only two months of “free” advice, Fred landed his largest consulting engagement yet. His client said, “You know our business and our problems. We know you have our best interests at heart. We want you to help us solve these problems. With your connections, we know you?ll do a good job.”

    Referrals help your clients see that you have an active and substantial network. A consultant with a large network is an asset to a client. Referrals create immediate business for others. The people to whom you refer work will remember you and refer other work to you, increasing your network and reputation.

    Discretion counts when it comes to referrals: a large network by-and-of-itself isn?t always an asset ? anyone can say they have a ?large network.? What matters is knowing when and how to use it to add value to the client rather than adding value to you.

    Write with another consultant
    Once you?ve created your reputation, try writing with another consultant to explore a subject in different ways. Once you?ve explored the subject, you?ll know how you?d like to work with this person again.

    I wrote an article with Karl Wiegers about project retrospectives . Karl and I have completely different writing styles, so it was both pleasurable and frustrating to write together. Pleasurable for seeing how the article became a combination of both of us. Frustrating because we don?t approach writing the same way.

    However, the benefits of writing the article with Karl were:

    1. We learned how each other writes. If we ever choose to write together again, we?ll both know to write better faster.
    2. Each of us brings a different readership. By sharing my readership with Karl, and with him sharing his readership with me, we each gain an entrée to a different potential client base.
    3. Each of us had specific perspectives on the topic. During the writing, we each learned from the other, to provide better retrospective services to our clients. If we ever chose to facilitate a retrospective together, we could provide a rich environment for the client.

    I?ve written with other consultants. I?m in the midst of writing a book with Esther Derby about making the transition to management. Our writing collaboration has resulted in a more thorough exploration of the subject matter and in better consulting for our clients.

    Present with another consultant
    I enjoy speaking even more than I enjoy writing, so I?ve chosen to collaborate with Esther, Naomi Karten, and Elisabeth Hendrickson on speaking and workshops.

    Collaborating with Naomi helped me bring more humor into my speaking. Naomi combines humor effectively with her message (in both the presentation and handouts), so I was able to learn how to observe her lightheartedness and adapt her style to my speaking and workshops.

    When Elisabeth and I decided to collaborate on a workshop, we chose a subject (communicating with management) that we?d each written about and presented before our collaboration. Because we each had significant knowledge and experience about the topic, we were able to incorporate interactive activities in the workshop. The attendees loved the workshops.

    When Esther and I developed and presented our first public “Making the Transition to Management” workshop, we learned how we each develop material and how to integrated our different speaking styles. Our attendees tell us that they appreciate our different perspectives and styles. They learn something different from each of us. Esther and I have presented many presentations and conference tutorials together. Since we trust each other and know how to work together, we?re comfortable and can be spontaneous with each other and the audience.

    I learned these lessons from my collaborations with Esther, Naomi, and Elisabeth:

    1. The other consultant has a valuable perspective I can choose to share with the audience. I can acknowledge it and explain when that viewpoint is useful when I?m presenting with the other consultant or at another time.
    2. Presenting with others requires more presentation design, role clarification (who does what when), and practice. It?s worth it. The audience loves seeing multiple perspectives on the same topic.
    3. I learned alternative techniques to explain concepts and integrate humor into my presentations. Since presentations are part performance and part education, I?m a better presenter for it.
    4. Each consultant can reach more people together than they can separately. Especially if you?re considering presenting public workshops, you can more easily acquire the minimum number of participants when you speak with another consultant.
    5. Working with new people keeps me fresh, and nothing works better than positive energy in front of an audience.

    I learned a different lesson from presenting with another consultant, Jerry Weinberg. At the first AYE conference, my co-presenter was ill. Jerry filled in and gave me the support I needed to create an outstanding experience for the participants. Our presentation was different from the original planned presentation, and it was just as good. I gained more self-confidence from that presentation, and have since asked Jerry to review other presentation designs.

    When you choose to write or present with another consultant, choose someone who complements your expertise. Discuss how you?ll develop the material and who?s responsible for what (initial editing, article submission, presentation submission, and so on). Then have fun!

    Refer a consultant for a fee
    There are ways to make money while you work with other consultants. One technique is to refer business to another consultant and charge a finder?s fee, a referral fee.

    When you recommend people, you recommend for free. The client is free to take your advice, and the other consultant is free to reject the engagement. You have no obligation to the consultant or to the client, aside from wanting to see the client happy with your recommendation.
    When you refer for a fee, you?ve defined an engagement between you, the client, and the consultant. You?re not employing the consultant, but you make money every time that consultant works for that client, depending on how you?ve arranged the agreement.

    It?s possible to have a successful consulting referral business. I?m listed with a local Boston-area consulting referral group, the Consulting Exchange, www.cx.com. Geoffrey Day, the owner, does not charge the client for the referral. Instead, Geoffrey takes a percentage of the fee for the specific referral. When the initial engagement is complete, Geoffrey takes a smaller fee for ongoing business for up to three years.

    Geoffrey has set up his business congruently, taking the client, the consultant, and his needs into account. His fees are fair. His fees from ongoing work from the initial engagement have an end-date. Geoff realizes that the more consultants he has in his network, the more money he can make with his referrals. If he tries to gouge his consultants, or have them work forever for a substantial fee, he will win the contract and lose the business. Geoff has chosen to make money over the long term, by developing ongoing relationships with consultants and clients, treating each fairly.

    Day does something else that few do: consultants set their own rates, working directly for the client. And he works only on specific projects, making sure that the consultant retains flexibility for existing clients and that crucial marketing time. This attracts a better type consultant and eliminates many problems common with agency type referrals.

    The CX and organizations like it can also help you enhance your own business. While we all have active networks, it is common to run into a situation where you don?t know the right person. Maybe you are in a new city, working in an industry where you haven?t a lot of contacts, or just not happy with your immediate network.

    If you choose to set up referrals for your business, make sure you?ve considered your short-term and long-term profits. A consultant who was referred by another referral company had this experience:

    “I?ve been on contract to this client for over a year. They still need me, but I?m not being paid enough. The referral company increased the rate they bill the client, but the referral company took my entire raise. I can?t keep working for these idiots. If I quit, I can?t go back and work for the client, or even talk to them for two years. Because I?ve been working full-time, I haven?t been marketing. I can?t keep working like this?it?s slavery.”

    This consultant made an innocent mistake?signing up with an unethical referral company. If you choose to refer consultants and make money from their client work, here are some guidelines for success:

    • Be fair to everyone. Don?t be greedy. Set up your fees so that you encourage each client and consultant to work with you over the long term.
    • Charge a small enough amount that the consultant will want to continue working with the client, and not drop the client if a more lucrative engagement comes along. If you?re underpaying the consultant, they have no incentive to complete the work, especially on a long-term contract.
    • Place a limit on the time a consultant can work with the client and still owe you a referral fee. You may have made the initial introduction, but after a few years, the client and consultant have maintained the business relationship without you.
    • If you bill the client, pay the consultant on time even if the client hasn?t paid. If the consultant bills the client, make sure you see a copy of the invoice so you know that you?re being paid according to your agreement.
    • Build this into the legal agreement: Make sure that when it?s time to change the fee, everyone has to agree to the fee change.
    • Make sure a lawyer looks at the agreement and that the agreement is fair to all.

    In my business, I choose not to make referrals for a fee. I leave that to the professionals whose strategic direction for their companies is referrals, like Geoffrey Day.

    Work with one other consultant
    Instead of referring for a fee, I prefer to either recommend other consultants to the client without charging a referral fee, or to accept the consulting engagement myself and collaborate with another consultant.
    When you work with another consultant, make sure you avoid these traps:

    1. Taking care of another consultant.
    2. Creating a master/slave relationship with the other consultant.
    3. Ignoring early signs that your styles don?t mesh.

    John?s client wanted John to teach more students than John could teach in a workshop. John explained that the client could either have two workshops or one workshop with two instructors. The two-instructor workshop would cost the client a premium over the cost of two workshops. The client agreed, and John asked a colleague, Jack, to co-teach. Jack asked for half the entire workshop fee. John agreed ? a big mistake. John had completed the initial marketing and selling work?without which Jack would not have known about the project. Additionally, John provided extra services to the client (organizing the workshop, making all the handouts, and billing the client) and to Jack (initial workshop draft, already-proven exercises, billing the client and payment to Jack). By the time John was done taking care of Jack and the client, John was exhausted. John was resentful of Jack, because John had taken care of everyone except John.

    Unless you and the other consultant come to the negotiation with equal investment and abilities, don?t split the fee 50-50. If you?re the consultant managing the client, the billing, and the intellectual property, you deserve more than half the fee. Don?t leave yourself out of the list of people to take care of.

    On the other hand, you needn?t create a master/slave relationship with a consultant. Early in my career, I agreed to perform an assessment with another consultant as a subcontractor. The primary consultant was concerned with my work, the time it took, and the results. He was even more concerned when the client appreciated my part of the assessment more than his. I had discovered the key piece of information in one week. The primary spent four months and had not discovered the key necessary for the client?s success.

    The client asked us to help implement the changes based on my report. Even though I requested a change in fee, the primary consultant was unwilling to increase my fee. The primary paid me after he was paid. Since the client paid late, I was in the position of reporting to someone who didn?t understand the problem, paid me inadequately, and paid late. I finally decided to end my relationship with the primary consultant.
    Fortunately, I did not have an agreement with the primary prohibiting me from working for the client. I explained to the client that I was not continuing to work for the primary, that they could choose to hire me by myself, they chose to.

    I learned these lessons from that engagement:

    • Negotiate each phase of the engagement separately. It made sense to have one fee for the assessment and for me to adhere to the primary?s style of reporting. It did not make sense to continue the same fee arrangements and reporting into both the client and the primary contractor when I was working independently after the assessment.
    • If one consultant is billing the client, make sure the client understands how quickly they have to pay. In addition, set expectations for subcontractor payment.
    • Make sure all parties believe the arrangements are fair. The client was unhappy about having to pay money for pieces of an assessment that were not useful. The primary was unhappy because his work was seen as second-rate. I was unhappy because my fees were too low for the ongoing work and I had to wait for the primary to bill the client.
    • I hadn?t recognized the early indications that the primary consultant on the assessment was a controlling personality. If I?d paid closer attention to the pre-engagement activities, I would have recognized the signs, and managed our collaboration differently.

    To create a successful collaboration, discuss the fee arrangements early, and decide how you?ll leverage each other?s network.

    Discuss fee arrangements early
    To create a successful collaboration, discuss who is responsible for which pieces of the engagement before you start the engagement.

    Weiss has a formula for revenue sharing that divides the sale, development, and the delivery of the project into thirds, and assigns relative proportions to each piece. Here?s how one consultant and I used that for one $10,000 engagement:

    Person Sale (1/3) Development (1/3) Delivery (1/3) Percentage due Fee split
    Sally 100% 25% 0% 41.25% $4125
    Johanna 0% 75% 100% 57.75% $5775

    Sally made the original contact with the client and sold the engagement, so she deserves the total sale component. I developed the material, with substantial review from Sally. We decided to split the development, assigning 75% of the work to me. Then, I delivered the material to the client alone. If either of us receives follow-up work from this engagement alone, we own the follow-up work.

    We could have split the money down the middle, and for this engagement, that would have been close. However, we?re business people. We don?t want to take care of each other, or take advantage of each other. We?re more likely to work together again because the relationship is built on a solid business foundation.

    Leverage each person?s network
    In this example, Sally?s network provided me the introduction to a new set of potential clients. My material offers Sally the chance to sell different kinds of consulting to her clients. Sally recognized I could provide a particular value to her clients, so she brought me in to perform a specific task. We both win?Sally learns how to perform another piece of the consulting, and I have access to new clients. In this case, Sally?s network is as much of an asset to me as the consulting work is to her.
    When you create a congruent relationship with the client, the original consultant, and the additional consultant, everyone wins. If you ignore one piece of the relationship, it?s not sustainable, and will dissolve to everyone?s detriment.

    Create a consulting partnership
    If you?ve worked with a consultant on a contract or two and enjoy it, maybe it?s time to create a partnership. Avoid employing anyone who?s not a partner?non-partners are overhead that you provide for, not someone who adds value to the business. Partners bring complementary strengths and an additional client base to the business.

    If you?re considering a partnership, use this checklist to make sure the partnership is appropriate:

    • You trust this person with any of your clients
    • You trust this person with your intellectual property
    • This person has already succeeded independently performing the work they?ll do as a consultant
    • If you?re already consultants, the other person has already succeeded as a consultant
    • You have the same goals, including financial goals, for your business
    • Together, you are worth more to a client than you are apart

    The principals, Donna Johnson and Judi Brodman, formed a partnership, Logos International, about ten years ago to perform research for a government contract. Donna and Judi had each worked independently as consultants before they formed a partnership, and had worked together in limited engagements. They found that they could offer more as a partnership than each could alone. The partnership benefited them in these ways:

    • They enjoyed having another person available to discuss ideas
    • They could create other products based on their original work together
    • They were able to bring their current clients more value
    • They were able to bid on larger projects because they had more depth to their company

    Donna and Judi were already successful consultants when they chose to create a legal entity to work together on projects for their clients and enjoy their partnership of equals.

    I know of two other long-term successful partnerships. Both partnerships started when the people who?d performed the work inside companies chose to continue working outside their original employers.

    One partnership, Process Enhancement Partners, Inc., started with two principals who had not been consultants originally, and added two more principals after a couple of years. The original principals realized that one of the two people did not have the same goals. The consultant with different goals left the partnership.

    The other partnership, Process Group, periodically reviews their business ? to make sure their individual and group activities continue push their strategic goals. They considered taking on employees to grow their business, and then decided against it. Adding employees would grow the company, but would not help them meet their individual goals of being able to provide services themselves to their clients.

    Each of these partnerships has people with different strengths. Each partnership developed and continues because the principals have common business goals and a common work ethic.

    When you create a partnership, decide if and the conditions under which each of you can take on work alone and how you?re going to dissolve the partnership, like a prenuptial agreement. If nothing else, one of you may want to retire. If so, what does that mean to the partnership?

    Summary
    Collaborating with other consultants helps you increase your expertise as well as your client base. Referrals help you maintain and grow your network. Writing and speaking helps you access other potential clients, as well as increasing your expertise.

    When you refer others for a fee, or work with another consultant, remember to clarify who?s responsible for what, the compensation each of you receives, and when the arrangement is complete. When you?re ready consider a partnership arrangement to continue to capitalize on what each of you can bring to the client and the business.

    None of us works entirely alone. Consider which options you want when, and your collaboration will provide you and your clients excellent service.

    Acknowledgements
    I thank the following people for their helpful review: Geoffrey Day, Esther Derby, Elisabeth Hendrickson, Naomi Karten, Jerry Weinberg.

    References

    Weinberg, G. M. (1985).
    The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully.
    New York, Dorset House.

    Weiss, A. (1998).
    Million Dollar Consulting: The Professional’s Guide
    to Growing a Practice.
    New York, McGraw Hill.

    Wiegers, K. a. J. R. (2001).
    Looking Back, Looking Ahead.
    Software Development. Feb 2001.

    convert this post to pdf.

    Climbing Out of Technical Debt

    © 2002 Johanna Rothman, www.jrothman.com

    Have you ever had a conversation like this one?

    Vice President: In the last release, you were able to bring the release date by over a month by cutting the testing. Do that again, ok?

    Project Manager: Sorry, boss, we can?t do that. For the past three releases we?ve shortchanged the design work and the testing. We can?t cut any time from this project. In fact, it?s time to re-architect the system, redesign it, and do the testing we?ve put off.

    Vice President: NO WAY!

    Project Manager: Hey, that?s just the way it is. We haven?t taken the time to finish this product yet, and our shortcuts have come home to roost. Our technical debt is too high to work this release the way we?ve worked the others.

    Technical debt, as defined by my colleague Dave Smith, is the debt a company ?owes? to a product they persisted in shipping in an incomplete or unstable condition. This is a situation referred to in Hunt and Thomas?s book The Pragmatic Programmer as ?software rot? or by Gerald M. Weinberg in Quality Software Management, Volume 4 as ?design maintenance debt.? The software isn?t necessarily rotten?the product is incomplete.

    As the technical debt increases, the load on the customer support staff becomes overwhelming, and the developers have trouble adding or changing system features. When developers are stuck on new development and support is overloaded, you face difficult choices about what to do now: have developers support the current product; ignore the current product and continue with development; some combination of support and development; or stop developing and fix what you?ve already got.

    Project managers, development managers and test managers often can see this coming. They know there is a window of opportunity to fix the product before the technical debt overwhelms the company?s ability to do new product development.

    Look for these signs of technical debt:

    • You ship a product and then have to put out a point release before it?s even left the CD duplication house.
    • Testing time increases disproportionately to the development time.
    • The developers tell you that part of the product needs to be re-architected, because the current architecture doesn?t support the current requirements, never mind the additional requirements.
    • Developers refuse to touch a part of the product saying, ?No one but Fred can touch that. I know Fred left three years ago, but no one else can work on it, because we don?t understand it.?
    • Developers spend more time supporting current customers by solving customer problems, fixing defects, and answering customer questions, than they spend developing new product.
    • You hire more testers than you have developers, and you?re still not sure you?ve tested the product.
    • Your developers threaten to leave because all they do is ?maintenance?.
    • You ship the product not because it?s ready, but because the developers? families have abducted them to go on vacation, or the developers are too exhausted to continue the crunch mode you?ve been in.
    • You stop testing because you don’t want to find more defects.
    • Your cost to fix a defect continues to increase, from release to release. (If you?d like to see a picture of this dynamic, check out Weinberg?s Quality Software Management, Volume 4, reference below.

    Recognize your technical debt, and start planning what to do. Before you can plan, you need to know a little about how you came to have this technical debt problem. These questions may help you understand how your product acquired its technical debt:

    How do you staff projects? Do you assign enough people at the time they are needed, or are some positions never assigned or assigned late to a project? If you never assign enough testers, or you don?t have an architect, you will incur technical debt. Don?t blindly accept people starting on your projects late, because you can?t make up time in a project. Have people start when they?re supposed to start, or recalculate the project schedule.

    How do you design your projects? Do you first architect the entire product for its entire lifetime? Do you iterate on the design for several projects? If you don?t architect the product, and update the architecture as necessary, or if you don?t do a high level design before starting to code, you will not have a congruous product. One way to recognize an incongruous product is when you have multiple ways of doing the same thing. At one organization, the developers couldn?t agree on how to open and save data files. Since they couldn?t agree, every time a developer wanted to open or save their data file, they had their own open and save functions. When they moved from a command line interface (CLI) to a GUI interface, they had no easy way to integrate the open and save functionality.

    How do you test the product? Do you have a way to start testing the product at the beginning of the project? Do you only have manual tests through the graphical user interface? If you start limited testing late, you?re guaranteeing yourself technical debt. You have many opportunities to test early and often: requirements inspections, design reviews, code inspection or peer review, unit tests, daily builds and smoke tests (tests to verify the daily build works at least a little bit), peer review of fixes in addition to system test. Decide what makes sense for your environment, and add test capability as early in the project as possible.

    How do you organize your projects? Do you have functional managers who hand off the product from the analysts to the developers to the testers to the manufacturing folks? If so, no one has the same view of what the product should be. At a minimum, assign an overall project manager or program manager, so someone is pulling the entire project together. Projects without project managers are highly risky, and in my experience, always fail. In addition, projects without a sponsor or champion have a difficult time finishing.

    How do you know what done means? Do you have some objective criteria to know when the project is complete? If not, you?re more likely to release an incomplete product. Develop release criteria for every project, so that everyone on the project, and the project sponsor understands what your company will receive for its project money.

    How do you run your projects? Do you stick to only one type of lifecycle and one process? You may need to choose other lifecycles and/or processes to avoid future technical debt. Many project managers are comfortable with a particular lifecycle and/or process, and it can be difficult for those project managers to switch to a different lifecycle for a project. If you?re used to a waterfall lifecycle, you?ll have to learn to plan for an iterative or incremental lifecycle differently. And, you?ll have to monitor your projects differently.

    If you?ve changed your lifecycle, you may need to change your process. What you do and when you do it will make the lifecycle successful and keep down technical debt. If you?ve never planned when to do inspections and reviews, start with something small, such as peer review of defect fixes during system test. I?ve found that a nightly build and smoke test helps find defects faster, and helps everyone realize when the product is not ready to ship.

    Although it feels as if you?re moving faster when you take shortcuts on a project, in reality, your technical debt prevents you from making project progress. You might be able to shortchange your product on one or two releases, but at some point your product technical debt is like credit card debt ? if you don?t pay it off in a planned way, the debt buries you.

    Observe and measure your products, to know when you should act to reduce or avoid technical debt.

    For more information, see

    Hunt, Andrew and David Thomas, The Pragmatic Programmer. Addison-Wesley, Boston, MA 1999.

    Weinberg, Gerald M., Quality Software Management, Volume 4. Dorset House, New York, 1998.

    convert this post to pdf.

    Client 101

    © 2001 Sherry Heinze

    I work as a test analyst for a consulting company. Every 6 to 12 months, I start on a new project for a new client. I love the variety and the opportunity to learn about a new business or a new part of the business. With each new project, we have to work to convince the customer of the benefits they will receive for the money they spend on testing. I can become very tired of fighting the same battle with each new client. Most clients actually believe that I do useful work by the end of the project. Then we move on to another project and start all over again, fighting the same battle. That part gets boring really fast. If you work on test projects, you’ve probably encountered the same challenge.

    On my last project, our client gave us an idea that may make selling the value of testing easier. As we approached the end of development and the “testing phase”, the onsite client representative started to object to the amount of testing planned and the cost. This is hardly an unusual occurrence. The only oddity was that the complaint was not raised as strenuously earlier. Long discussions with the project manager eventually convinced her that we were not just padding the bill. The steering committee was not convinced. Certainly testing by anyone available at their office would be just as useful and a lot cheaper. After all, our developers were supposed to be good, so why would there be problems with the software?

    But the client representative brought up a very good point when she suggested that we should have spent time at the beginning of the project explaining our methodology, specifically, but not exclusively, with testing, both to her and to the steering committee. She even spent a considerable amount of time with the project manager, and then with me, explaining what she thought we should have covered.

    I should mention that every proposal we submit has an explanation of our methodology, from the beginning of the project through to implementation. From our point of view, we did tell them. However, most of us realize that we are lucky if the client browses through it. As much as we hope they do, we don’t really believe they focus on it. The Project Charter contains more information on what we plan to do and how. Again, if it gets read at all, it is not remembered.

    A couple of weeks ago, the head of the Project Management Office at another client asked me to provide any information that I had on the value of testing. She had to make a brief presentation to a user group in an attempt to justify bringing in professional testers on a project they were funding. I have several presentations, all variations on the same theme, which I give to testers, quality assurance practitioners and project team members. While the details are often useful, I am preaching to the converted. Even the junior developers on the project teams are almost all on side these days. But the clients are not yet convinced.

    The clients deal primarily with the sales people. Sales may be aware of what we want to sell, but they don’t really understand why. Sales people are not often knowledgeable enough to make a convincing argument for quality. They do not understand our jobs much better than we understand theirs. So we are trying a new approach. We are developing a new course for clients, “Client 101″. Perhaps if we try preaching to the unconverted at the very beginning, we won’t have to fight so hard later. If it works, I will be very grateful to the client who suggested it.

    convert this post to pdf.

    Choosing Facilitation

    © 2003 Johanna Rothman, www.jrothman.com

    Meetings are a fact of our lives. Most of the time we don’t need a facilitator to help move our meeting along; we can manage to accomplish the goals of the meeting without a formal facilitator. However, there are times when a facilitator makes sense.

    Darcy is a middle manager in a startup. They have enough money for the next eight months. For the last three months, the senior managers have closeted themselves in meetings day in, day out. Darcy knows they’re trying to define the current strategy and tactics to accomplish the goal: drive enough revenue to break even. If they can break even in eight months, their investors will consider investing just a bit more to overcome the slow economy and the company will succeed. If they can’t break even, they’ll be shut down.

    Darcy’s no dummy. Neither are the other people in the company. They all know what these closed-door meetings mean. Darcy is concerned that if the senior management team can’t figure out what they’re going to do soon, the meetings will turn into layoff-decision meetings.

    Darcy’s management team needs a little facilitation to help them overcome their inability to come to a decision and move forward to specific tactics and action items.

    Senior management teams aren’t the only groups who become stuck and need help making decisions. Sometimes, a technical group has the same problem. Desmond, a database developer has on ongoing discussion with George, the GUI developer, and Tina, the tester about how to appropriately design the database upgrade for their product. Desmond, George, and Tina all agree they need an upgrade. They can’t decide how the upgrade should work. Depending on how they choose to implement the upgrade, their work will change, as well as the work the users will have to accomplish. Each of them has different ideas, and each idea is valid. They can’t come to a decision, and they have only a week left to decide.

    In both of these cases, well-meaning, intelligent people are stuck. Their normal ways of managing their disagreements are not working.

    Consider choosing a facilitator under these conditions:

    • When a group has trouble coming to agreement on a strategy or set of actions.
    • When you want to be part of the discussion and decision-making. It’s not possible to treat the group fairly if you want to participate and facilitate.
    • When you want to explore a previous project (retrospective facilitator) or explore alternatives (meeting facilitator)

    You may be able to use people inside your organization as facilitators. Sometimes HR people or others are trained as facilitators. If you’re not part of the problem context or solution, you can facilitate the decision-making.

    Whatever you do, choose when you require a facilitator. Don’t let the problems or conflicts escalate into no decisions, especially when you require a timely decision.

    convert this post to pdf.

    Chinese Contracts

    © 2003 Jim Bullock

    Several cultures contain a fable about a horse, a Farmer, and a wolf. After a time both plagued by the wolf the Farmer and horse agree to work together to defeat their common foe. The horse’s speed and stamina combined with the Farmer’s weapons and cleverness win out. The horse then asks the Farmer to remove the bridle and saddle – their agreement being at an end. “The hell you say.” replies the Farmer, “Giddiyap Dobbin.” as he applies the spurs with a will.

    This parable is a warning about deals that don’t work out so well. It’s charming and memorable as such parables are when they are good, but a little hard to work with in real life. Most contracts are not about donning saddles and bridles to hunt down wolves. So, I’d like to offer a checklist for the mechanics of deals that work out well:

    • Chinese contracts or Avoiding the Cost of Compelling Compliance
    • Symmetric, temporary controls or Avoiding the Dobbin Problem
    • Atomic transactions or Avoiding the Wimpy Problem
    • The never ending story or ?It’s a Relationship, Stupid?

    Dobbin and the poor Farmer don’t seem very happy in the second half of their story. I think if we keep these four things in mind for the deals we make, we’ll create better deals.

    Chinese contracts or Avoiding the Cost of Compelling Compliance

    In The Age of Paradox, Charles Handy describes agreements he negotiated in Malaysia and China as a young man. After coming to agreement with his negotiating partner, Handy begins to complete a paper contract. From the book, Handy’s negotiating partner speaks:

    ?In my culture,? he went on, ?a good agreement is self enforcing because both parties go away smiling and are happy to see that the other is smiling.? . . . I had met a culture where negotiation was about finding the best way forward for both parties .

    Handy calls these ?Chinese contracts? referring to the culture where he learned them. A Chinese contract is a coupling of fates together, making it better for each party that things work out well for the other. A Chinese contract is one in which outside enforcement isn?t really needed, because self-interest suffices. Enforcement is probably a good heuristic for deals, actually. If you have to think through how to enforce the deal you probably don?t want the deal. Enforcement is a lot of work, and a whole different game from simply delivering value.

    One principle of economics is called “utility” ? what something is worth to me isn’t what it is worth to you. I wouldn’t pay you $ 2.50 for popcorn if the popcorn weren?t more useful to me than the money. You wouldn’t sell me the popcorn if the money weren’t more useful to you. In terms of our personal utility, we both gain from the deal. Dobbin and the Farmer were both happier sans-wolf than either was before hand, even considering lugging around an armed Farmer on Dobbin’s part, or the Farmer sitting precariously astride a running horse. Dobbin and the Farmer are a special case of a Chinese contract, where the same result satisfied them both. So why shouldn’t all contracts be Chinese contracts in Handy’s sense?

    The absence of Chinese contracts leaves me confused, doubly so in a free market. My gain in utility is higher when you are in favor of the deal, too. Imagine the Farmer riding a cooperative Dobbin working toward a wolf-free life for them both. Now, imagine the Farmer on an uncooperative Dobbin who sees nothing in it for him to be lugging about this heavy, smelly, armed creature. The Farmer clearly has a better deal ? realizes more utility ? if Dobbin has reasons of his own to be wolf hunting.

    I am skeptical of any “deal” that isn’t a Chinese contract. As anyone who has tried to create an idiot-proof system knows, idiots are very clever. How much more clever is someone trapped in a deal they dislike? If your partner in a deal has something worth trading for, they’re probably clever and effective too. It seems like a lot of work to force someone clever and effective to do anything. Why not apply that cleverness and energy ? theirs and yours – to think up something that’s good for both of you, like one less local wolf. If you can’t think up one thing that’s good for you both, you ought to be able to think up independent asks and offers that each have value to one of you.

    As for Dobbin and the Farmer, their original deal was indeed a Chinese contract. Fulfilling it, however, changed the power relationship between them. So, perhaps a part of a deal should be how it leaves the power relationship between the partners.

    Symmetric, Temporary Controls or Avoiding the Dobbin Problem

    Dobbin and the Farmer have a problem because the Farmer has spurs, bridle and saddle, while Dobbin has no hold on the Farmer. When there are controls, especially asymmetric controls that persist after a deal a relationship becomes strained at best. Their first deal leaves both Dobbin and the Farmer rid of the wolf, but if it leaves the Farmer with a hold on Dobbin. Dobbin is not in such good shape.

    Many years ago I stumbled on a physical analogy about relationships ? talking with my first real girlfriend, in fact. You each hold up a hand, left hand to right, palm to palm.

    • Fingers extended. ?This works.?
    • Bend your fingers over, so you each grasp the other?s hand. ?This doesn?t work so well.?
    • Now one of you extends your fingers, while the other hangs on. ?This doesn?t work at all.?

    The best deals involve both parties staying in contact voluntarily, because there’s something in it for them. That’s a Chinese contract. The best deals also involve the parties declining to apply controls, especially asymmetric controls, to each other. Short of that, however, a deal that involves controls has to release the controls when the deal is completed.

    Controls are hard, and expensive, and don’t work very well. They also create resentment and distrust if abused. If the Farmer forces Dobbin into something, clearly Dobbin would rather be doing something else. Dobbin loses the difference between the utility of what he would be doing absent coercion, and the utility of what he ends up doing for the Farmer. Dobbin ends up with less stuff. If the Farmer’s controls remain in place, Dobbin can expect to end up with less stuff than he might otherwise have, again and again. I think resentment at being coerced is a survival mechanism, wired deep into us, to help us get what we need. It’s hard to live when you don’t get what you need. It’s hard to get what you need when someone forces you into choices against what’s best for you. The Dobbins who learn to avoid Farmers with spurs get more of what they want, and likely live longer and better. Poor Dobbin, certainly, but also poor Farmer. He’d better never let go of that bridle.

    The problem is that the Farmer wants more things from Dobbin, and sees controls as a way to get them. How much better if the Farmer were to offer Dobbin something of use for his further trouble? Maybe the Farmer could retain Dobbin’s help in return for board or better hay. If Dobbin continues to have his speed and stamina to offer, how much better to have those applied willingly to the Farmer’s next problem, vs. fighting Dobbin’s gifts to get a field plowed. Controls make sense only when we believe our own offer isn’t worth much or our partner so weak that forcing them is easy. That seems like a losing proposition both ways.

    Where did the Farmer’s confidence go, in his own ability to make Dobbin a worthy next offer? How sad for the Farmer to admit that he has nothing better than coercion to offer a horse. Of course maybe he does, but forgot because the saddle and bridle seem direct and near to hand. It is wise, I think, to construct deals so that neither party is left with controls on the other because controls are so tempting.

    This is neither theory nor philosophy, but pragmatic reality. For example, asymmetric controls are often part of IT outsourcing deals or technology purchases ? it’s called ?lock in.? Large-scale outsourcing deals are seldom repeated, in part because of resentment, I think. As for technology lock-in, the world is full of people with an ABM ? anything but Microsoft ? bias. In both cases, the vendor has the check and can do what they like, while the customer must stick with the software or service or incur a massive cost of conversion or change. In either case the resentment of being forced masks any real benefits the deal might have provided the customer.

    Often, vendors deliberately create a lock-in, hoping the customer won’t notice until it is too late. This is ultimately self-defeating, I think, but only the vendor controls the vendor’s intentions. Whether deliberate or accidental, the customer could have seen the lock-in coming, I think, and should have considered the long-term control when forming the deal. This is ?the Dobbin Problem?: creating or accepting asymmetric controls that last after the deal is fulfilled. Yet, some deals need controls because the partners are satisfied at different times, by different things.

    Atomic Transactions or Avoiding the Wimpy Problem

    Wimpy from the old Popeye comics constantly bummed food without money. His line was: ?I will gladly pay you Tuesday for a hamburger today.? The Dobbin problem is a special case of the Wimpy problem ? a deal that doesn’t stay atomic. An atomic deal includes satisfying both parties, and releasing any controls put in place to manage the deal.

    Many deals are designed with a current benefit for one and a later benefit for the other. Once the one side has its payoff, there is little incentive to follow through. When the parties get satisfied at different times, often we build controls into the deal to ensure delivery. So, misaligned payoffs can lead to controls. If the controls don’t eventually expire, we end up with “The Dobbin Problem”.

    Many IT service deals include outsourcing IT operations at a loss, recovered in new development later at a profit. (The converse arrangement, new development as a loss leader to profitable operations is even more common.) There is an incredible temptation for the customer to try to split the deal once the IT operations are in place. The later business that was supposed to pay for the earlier loss leader doesn’t happen, and the vendor is in trouble. Or worse, it happens but the customer is resentful from being forced into this later deal by lock-in. Meanwhile, the supplier is tempted to under-deliver on the loss leader, which builds-in resentment before the step where the supplier gets their payoff. Deals like these often include controls to ensure that the deal is completed. That’s fine if the controls expire. Often they don’t. Often, the parties lying to each other complicates the loss-leader game. ?No, no I like outsourcing operations for you. Really.?

    The conversation really has to be about the whole deal or it won’t work: both payoffs and all controls together. A good deal must be atomic in exactly the formal sense of database transactions or critical sections of code ? all or nothing. The consequences of non-atomic deals are similar to non-atomic transactions: people left in strange states, bits of the deal lying about here and there, and blocking of other work.

    Dobbin and the Farmer had it easy, actually. They were both rid of the wolf at the same time, so they don’t have the problem of sequential satisfaction that Wimpy’s proposal includes. Had they agreed that Dobbin would pull the Farmer’s plow for a season once they were free of the wolf that would be a Wimpy deal. Perhaps the Farmer might ask for some controls, to ensure that his field gets plowed. If the Farmer were clever, he might offer Dobbin a share of the crop that they would work together. The saddle and bridle in this case were things that helped the Farmer and Dobbin work together that happened also to be a control on Dobbin. The Farmer was tempted once the deal was concluded. So, to keep deals atomic look also for accidental controls ? things like vendor lock-in ? as well as deliberate controls and conditions of satisfaction.

    The Never Ending Story or, ?It’s a Relationship, Stupid?

    Working together is best when the parties have a series of mutually beneficial transactions. The poor Farmer really wants to borrow Dobbin’s speed and stamina for other things. He thinks himself relatively unable to make another valuable offer to Dobbin. With asymmetric controls in place, the Farmer tries to take those benefits. That relationship may last for a while. It won’t be much fun. As a colleague told me during the process of editing this article:

    ? . . . contracts are relationships, even if we try to treat them as transactions. ?

    Each contract is a relationship and a little, fractal-like image of the larger, longer relationship. When each party in a transaction considers the larger future they might have, this deal becomes a trial run for future deals. If we want something more from our partner, later, we are motivated to make our deal work this time. A good deal builds confidence in your ability to deliver, and mine. If Dobbin was strong enough to be helpful with the wolf this time, why wouldn’t he be just as strong later? If the Farmer had a valuable offer of dexterity and tools, where did his confidence in himself go? The Farmer must not think much of himself at the moment. Poor Farmer indeed.

    Unfortunately for both of them the Farmer made any cooperative future unlikely. I think the Farmer’s reasoning is flawed. At best the Farmer has lost the cost of enforcement in any future deal with Dobbin. More likely they have both lost the new futures that they might create together, as Dobbin is unlikely to have anything to do with the farmer after this. I like to think it is Dobbin who proposed that they work together to rid themselves of the wolf. In that case, the least they have lost is any deals Dobbin might propose moving forward ? why would he? They both have smaller stories than they might have. If Dobbin has friends, the Farmer has a much smaller story than he might have – word gets around.

    The Farmer isn’t showing himself to be too bright in this story. More cleverly self-defeating, I think. The Farmer misbehaved because he forgot that he and Dobbin are both caught in ?The Never Ending Story.? They’ll both have offers to make the other, or not, in the future.

    Bad Business and Good Deals

    I have become clearer about my visceral distaste for some business practices, especially job practices in recent years. The language is all about getting all you can from a partner in distress. In the current job market, it’s: “We?ll underpay them because we can.? ?We’ll be extra demanding because we can.? ?We’ll be obnoxious because we can.” Some of this is backlash. As the dot-economy was booming employees were obnoxious in exactly these ways. Neither businesses nor employees have been paying attention to good deal mechanics lately, and we are seeing the results: mistrust, no loyalty, controls, legalities, and anxiety. It’s a much thinner story because of past deals with bad mechanics. I wonder how much of the hesitation in the economic recovery, especially in technology, comes from both sides keeping their best offers to themselves.

    Maybe we ought to track another economic measure the way we track idle factory capacity or losses due to sick-time: ?Losses due to treating your deal partners like dirt.? There are direct costs, like enforcement and monitoring. Harder to measure is opportunity cost ? the great ideas, deal adjustments, or thousands of little offers that don’t happen along the way. Employees who practice sharp dealing train their deal partners just as surely as employers do. Maybe we need four measures, to track each kind of loss, based on who’s sharp dealing is involved. Maybe we need eight measures to separate losses and lost opportunity within a company from those across companies (to capture the cost of sharp dealings between vendors and customers.)

    I think good deals are simply good business – utterly pragmatic for individuals, individuals in organizations, and organizations. Everybody ends up with a richer future when we practice good deal mechanics. So, I have thought about what makes a deal that works well, and written it down, as much for myself as for anyone else.

    Good Deals

    A good deal has these deal mechanics:

    • Ideally, it is a Chinese Contract, avoiding ?The Cost of Compelling Compliance.?
    • If there are controls it uses Symmetric, Temporary Controls, avoiding ?The Dobbin Problem.?
    • It is an Atomic Transaction, avoiding ?The Wimpy Problem?
    • It leaves the deal partners ready to invent a richer ?Never Ending Story.?

    These mechanics are all, in the end, votes in favor of your own competence to offer more value later, your partner’s to do the same, and a rich world where you can find an offer that benefits you both. I’m for that.

    Good deals pass some hygiene checks as well, that others can explain far better than I:

    • Congruence. Use the Satir congruence model to check that the deal takes care of your self, your partner and the context.
    • Mindset. If you need a deal to happen more than you need the contents of the deal, you can get all tangled up. So check on what you are really trading for. Is it self-esteem? Is it money?
    • Intention. Is the deal creating something you want? The best deals will make a richer world for yourself and your partner.

    The best deals satisfy all these mechanics, and hygiene checks. A good deal can be a wonderful thing, which suggests one last hygiene check:

    • Celebration. You should want to celebrate your deal. Otherwise, check the deal mechanics and hygiene. Something needs fixing.

    I think Dobbin and the Farmer celebrated their first deal, but I’m not so sure about the second.

    References

    The Age of Paradox, Charles Handy, Harvard Business School Press, 1995 (paperback)

    Getting to Yes, Negotiating Agreement Without Giving In, 2nd Edition, Roger Fisher and William Ury & for the 2nd Edition, Bruce Patton, Second Penguin Edition, 1991

    The Win-Win Negotiator, Ross R. Reck, Ph. D., and Brian G. Long, Ph. D., Pocket Books, 1987

    The Armchair Economist, Economics & Everyday Life, Steven E. Landsburg, The Free Press, 1993

    The Satir Model, Family Therapy and Beyond, Virginia Satir, John Banmen, Jane Gerber, Maria Gomore, Science and Behavior Books, 1991

    Understanding Computers and Cognition, A New Foundation for Design, Terry Winograd, Fernando Flores, Addison-Wesley, 1987

    The 7 Habits of Highly Effective People, Stephen R. Covey, Simon & Schuster, 1990

    Wimpy is a character in the Popeye comic strips created by E. C. Seger. Wimpy has his own tribute page here: http://www.theneitherworld.com/popeye/wimpy/main2.htm

    The NeverEnding Story is a feature film by Barret Oliver.

    The story of Dobbin and the Farmer appears many places. It is found in Aesop’s Fables as The Horse, Hunter and Stag. Find that version here: http://www.pacificnet.net/~johnr/cgi/aesop1.cgi?2&TheHorseHunterandStag

    convert this post to pdf.

    Charting a Course for Requirements

    © 2002 Becky Winant, www.beckywinant.com

    This article originally was originally published on www.StickyMinds.com

    Projects are like voyages; they both start with a launch. Ever wonder what happens before we get into the boat and it pushes off from shore? I might assume that someone has planned for this journey, but what if the plan isn?t in the boat with us! Analysts need to explore requirements. We need a clear target for our investigations. What could point us in the right direction and guide our exploration? A project charter.

    What Is a Project Charter?

    At some point, interested parties convene to discuss a potential project. They usually bring numerous opinions and loads of data, but might hit an impasse when prioritizing what must be done. What should we talk about first? What is most important? Chartering can lend structure to identifying a focus, a true motivation, and support for this project.

    Here is what a project charter document contains:

    1. Statement of Purpose: Explain why the organization wants to undertake this project and how this project supports organizational objectives. This is the business case.

    2. Project Contributors: List who is involved or should be, and why and how they might be involved. You might name individuals or organizations and include customers, sponsors, stakeholders, domain experts, people who?ll use the system, and the proposed project team.

    3. Project Context and Scope: Identify what directly affects or is affected by this project and do the same for the proposed system. What in the system?s environment drives its behavior? You might list markets, organizations, people, devices, and other systems. Describe system boundaries and information that will be needed and produced by it. Analysts use this to establish event lists, use cases, and context views.

    4. Goals: Goals state specific project targets that achieve the desired project purpose. The targets state something you can measure. For example, a threshold may be specified: ?We?ll be using new tax rules software by January 1 of next year.? Proof through observation may satisfy a goal: ?Support sales with a functioning product demo of the three key new features.?

    5. Expectations: Consider these perspectives when describing expectations about project completion: the customer, the project team, and management.

    6. Constraints: Both the project and system have limitations imposed by customer request. A second set may be imposed by the organization. Constraints include reuse, needed technology, safety, security, standards, ergonomics, governing regulations, time, and cost. This information feeds into the architect?s plans and work.

    7. Risks: A risk is a potential problem that might keep us from successfully achieving a goal or fulfilling our customer?s needs. Each risk carries a probability that may be designated simply as high, medium, or low. A risk might be failing to meet a constraint, or losing a resource or key contributor. It also might cite broader industry or economic events that could obstruct or stop project progress. The risk list requires contingency plans and affects management decisions about the project.

    8. Resources: This category includes what we need to successfully undertake this project. An estimated budget, necessary software and hardware purchases, training and staffing, and partner participation are all useful entries.

    9. Acceptance: The person supporting and funding this project signs the document. An agreement with an outside partner may have more than one signature.

    Creating Project Charters

    The project charter process surveys both opportunities and necessary realities. Just as we might weigh the pros and cons when purchasing a house, we need to evaluate this project?s usefulness, desirability, and viability.

    On one well-run project, the project manager, Jane, began with a meeting. She brought in the departments who would have a stake in the completed project: a technical architect, team leads, her boss (the sponsor), and me as requirements facilitator for their project team. We spent the morning developing a statement of purpose, which everyone agreed to. Many of us proceeded to the next step of defining charter items. Jane assigned tasks to gather information, to develop lists, and to develop the charter entries. Over the next three weeks we met for about seventy-five minutes each morning. We discussed anything that seemed inconsistent with the project purpose and where we had problems. We reviewed a draft at the end of each week. By the end of the third week, we had a charter good enough to present to Jane?s boss. Four months later when a significant change was suggested, that charter was crucial for the negotiation.

    When something is presented to a sponsor, expect these possible outcomes: a) acceptance of the charter, b) feedback that prompts a revision cycle, or c) a no-go decision. Cancellation at this point may be due to project risks not worth taking or goals that aren?t feasible at this time. Far from disappointment, this might be the best outcome.

    Like any process, chartering can go awry. Here?s an example I experienced some years ago. Ted, the president, proposed a project that involved collaboration with a new business partner. He asked department heads for opinions and observations. I identified a risk that we would be dependent on this partner for specific expertise we didn?t have. Another person noted an inherent conflict with the suggested partner. After everyone contributed, Ted announced what we would do, totally ignoring our input. Soon after the project started, the partner dropped their commitment to the project.

    Charters That Work

    Here?s a quick list of the minimum elements you need for a charter that works:

    • involve people who have a stake in the outcome and in shaping the problem statement and solution
    • have an idea of how you want to structure meetings and tasks
    • conduct sanity checkpoints for assessing the process and document integrity
    • expect insight, not precision
    • be concise, clear, and to the point, like a project resume

    If you have no project charter, create one! Write what you believe is the charter, and pass it around. The feedback may reveal large gaps in expectations, or not. Either way you will have a better fix on where you are and where you can go. Then you?ll be ready to launch!

    convert this post to pdf.

    Change That Fits

    © 2003 Esther Derby, www.estherderby.com

    Cedric moved through his office packing up his personal belongings. His boss, Sheila, stood in the doorway, looking uncomfortable. As he started the last box, Cedric sat down in his chair. “How did it come to this, Sheila? I thought I was doing the right thing putting quality processes in place.”

    Sheila sighed and leaned against the doorframe.

    “We’ve been over this before. The processes you put in place are good practices, Cedric. Just not the right ones for us, at least not yet.”

    Cedric had been hired nine months earlier to address quality problems that ShipFast, a small, fast-growing software company, was experiencing. Cedric had been eager to take on the challenge of finding defects and putting quality processes in place.

    So Cedric set about establishing a test group from the ground up. He hired testers, built a development environment, purchased defect tracking tools and various other test tools, and established entry criteria, test standards, and procedures. He trained his new testers in classifying defects and writing good defect reports.

    Then, Sheila made it clear that Cedric’s group would test the next release for all projects.

    Not surprisingly, there were some grumblings and protestations that testing would delay delivering software to customers. But Sheila stood firm and laid out the case for testing, and eventually, the development managers agreed.

    Cedric’s group tested three projects in the first four months after they were up and running. Sure, there were glitches, but for the most part, Cedric’s attention to structure and process produced results. The testers found various defects and wrongly implemented requirements, and they duly wrote bug reports, logged the bugs, and ranked their severity.

    Cedric produced metrics and reports and showed them to Sheila. He thought things were going well.

    And then the grumbling started again.

    “I don’t see what value Cedric’s group is adding,” fumed Marisa, one of the development managers. “The system crashes as much as it always has.”

    “Sure, he’s finding defects,” chimed in Jason. “But half of them are known defects with workarounds. The other half are minor. If Cedric would ever talk to the helpdesk or us, he’d know that those bugs never happen in production. Those aren’t the bugs that are crashing the system—the reason the system crashes is that all the different applications are stepping all over each other on the desktop and bringing the network down.?”

    “In the long run, I’d love to fix all these minor defects,” Marisa said. “But right now, I just want to keep the software from crashing.”

    When the development managers tried to talk to Cedric, he dismissed them. “You don’t understand quality and process,” he sniffed. “You just want to hack.”

    By the end of six months, the software was still crashing—and so were Cedric’s working relationships.

    Where Did Cedric Go Wrong?

    Cedric’s approach to establishing a test group isn’t an unreasonable one, and he’d been successful with this approach in the past. But the practices and processes that Cedric implemented weren’t addressing ShipFast’s most important problems.

    Cedric’s first mistake was implementing his test group without understanding the context of the current environment. He came in believing that he knew exactly what the test group should be doing, and how they should do it. Cedric didn’t talk to the development managers or business people to understand what problems they were experiencing, and how he could help solve those problems.

    Understand What’s Working and What’s Not

    In almost every organization, some things are working well or the company wouldn’t still be in business. Investigate what’s working, as well as what’s not working. Part of any change is deciding what to keep.

    If Cedric had investigated, he might have realized that functional testing was not their number one concern. The development managers were aware of many of the defects, but to them, and to the customers, system stability was more critical than the bugs they knew how to avoid.

    Build Alliances

    People are usually not receptive to a newcomer waltzing in and telling them they’ve been doing their jobs wrong. Understand what’s giving people a pain in the tush, and then help them see how your goals will help solve their problems or create the situation they want. People who see you as helpful are likely to reciprocate in the future. People who feel badgered and looked down on, as Cedric’s colleagues did, are generally less cooperative.

    Work within the Current Situation

    Cedric came in believing that there was one right way to do testing and one path to get there. When the development managers at ShipFast didn’t see things the same way, he dismissed them. Cedric may have established a test group in record time, but in the end, he failed in the goal of improving the quality of the ShipFast product.

    Practices that fit at one company may not fit well in another organization, may not fit right now, or may not fit at all. Even “best practices” need to be adjusted to suit the current situation. The right practice is one that helps the company meet its goals.

    Whether you are establishing a new test group, implementing requirements modeling, or bringing discipline to project management, successful change starts where people currently are. Understand the context, adjust practices to fit that context, and build relationships and alliances. The road may be less direct, but some of those detours—helping others to solve problems before putting out your own agenda—will help you reach your destination faster in the end.

    convert this post to pdf.

    Change is a Disease

    © 2000 James Bach, www.satisfice.com

    “That idea won’t work here, because we’re different.” is a refrain familiar to the ears of consultants everywhere. Some people respond to this defense by using evidence and argument to persuade their clients that they are not so different, really, and this new idea will work if you give it a chance. I don’t know how successful that strategy is in general, but it doesn’t work well for me. I use a different tactic: I say “you’re right, it might not work here, because you are different.” This works pretty much every time.

    Oh, I don’t mean that I convince them to do what I recommend, every time. By “this works” I mean that my response helps defuse the emotional energy behind the response by honoring the fear that sustains it — the fear that they will accidentally lose their identity as an organization if they pursue certain ideas too far. It’s a legitimate fear. Sometimes companies do lose touch with what makes them unique and special. Their fear is legitimate and honorable even when it’s important that they give up an old identity and take on a new one. Identity change is like dying. That’s why Peter Pan was afraid to grow up. Few organisms want to die, even for some reward in the afterlife — or later life.

    I suspect a lot of problems with the diffusion of ideas come down to problems of preserving the integrity and identity of an organization. That’s why I’ve found it useful to look at change artistry in terms of pathogens and immune systems. I’ve learned to think like a disease in order to help my clients achieve what they desire. I didn’t say it was a pleasant metaphor, but it works for me.

    Avoid triggering the immune response Everyone I’m asked to help has a psychosocial immune system in addition to a biological one. If I’m going to help them, I need to avoid triggering an immune response that will engulf me and my contributions. Here are some principles I’ve learned for doing that.

    Share their identity

    Get to know their DNA. Immune systems specialize in telling the difference between us and them. If I pass the “us” test, I get to contribute. If I fail the “us” test, I get isolated. Sharing their identity means that I understand their culture: the rules, protocols, values, vocabulary, etc. and honor it. I clothe myself in the familiar, and offer the unfamiliar only when coated in the “protein” of the familiar. I persuade clients using with their own familiar experiences, as much as I can.

    Co-opt the immune response

    I’ve found it helpful to accompany my work with self-criticism and other ideas for how my client can put the brakes on at any time. This makes it easier for the client to dismiss my work, but also makes them less frightened of me and thus less likely to raise an alarm. Thus, my own efforts to carefully explain the limits and caveats of my work can serve as a sort of proxy for an organizational immune response.

    Co-opt whole the immune system

    Assure that the goals of the immune system are achieved, and maybe it won’t flare up. Appeal to the opinion leaders (not just managers) as people. Find out what they want and need. Give them that. Sometimes I’ve been allowed to do certain things I wanted to do because I’ve been able to guarantee that certain stakeholders get what they want.

    Avoid suspicious behavior

    The immune response is triggered by certain patterns (of behavior, vocabulary, etc.) and evolves sensitivity to certain pathogenic strategies. So, I avoid the common strategies. For instance, I avoid hyperbole of any kind. I avoid using anyone else’s data. I avoid quoting authorities. I avoid flashy brochures. I embrace details. If I’m speculating, I say so. If my actions don’t match my plan, I try to be the first to point that out.

    Small doses at first

    Small efforts, perhaps even shielded from the eyes of management, are less likely to trigger alarm. That way, a successful outcome can prepare the way for a larger one that will withstand the immune response, and an unsuccessful one may not be so noticed that it inoculates the organization against future attempts.

    Educate the immune system

    If the immune system considers me a helpful vitamin, they let me alone. The challenge with that is that they don’t know, starting out, whether I’m helpful or harmful. So, I use the other principles, above, to get just enough time to show results. Eventually success will cause my DNA to be absorbed into the system, and become the new status quo.

    Don’t kill your host

    Successful pathogens leave their hosts alive. That’s why the common cold is so common, and we don’t talk about the “common Ebola.” What this principle means to me is this: even if my idea is expelled from an organization, the experience may still provide the basis for a future success or relationship, assuming that organization is not too sick of me. Furthermore, a favorable impression left with people in that organization may sow the seeds for future work with someone else.

    Sometimes I’m glad to trigger an immune response from a client, because that may be an excellent indicator that I’m not a fit for that situation. Immune systems are designed to skeptical, because skepticism happens to work well as a defense against constant organizational disintegration. If it sometimes causes a client to reject an idea that I think is good for them, well, that won’t kill me. It may cure me, though.

    convert this post to pdf.

    The Black Hole

    © 2003 Naomi Karten, www.nkarten.com

    A black hole is a place in the cosmos where things get swallowed up, never again to emerge. Although I love to travel, it’s not the sort of destination I’m eager to visit. This is not just because it seems like such a dark, dank, distant place, or even because it’s a point of no return, but because it’s overflowing with problems.

    How do I know it’s overflowing with problems? I know because of the comments I’ve heard from so many customers. When I ask them about the service they’re getting from their suppliers, vendors and providers, they tell me that when they ask a question or submit a problem, it goes into the Black Hole. These are their exact words.

    When I ask customers what they mean, they say they submit problems or requests and never hear back. No response, no follow-up, no clue as to the status of the situation — or even when they’ll be advised of the status. Who knows, maybe after a hundred thousand years or so, the Black Hole will eject its contents and customers will finally get the responses they’ve been waiting for. But most customers aren’t that patient.

    Not for customers only

    It’s not just customers whose problems make the Black Hole such a congested place. I also hear complaints from service providers who depend on support from colleagues and co-workers in order to do their job. In one situation, I asked a Help Desk group about their experience with the technical problems they transfer to a Level 2 support group. “Often, they just disappear into the Black Hole,” one woman told me. And what about the customer who’s awaiting a resolution to the problem?

    Same thing from another group for which I was reviewing the findings of a customer survey. For the most part, customers were pleased with the service they were receiving, but interspersed with the high ratings was a noticeable subset of low ratings. What are these? I asked. Oh, those, said the service manager. (“Oh, those” is usually a signal that bad news is about to follow). Those ratings, he told me, were associated with problems sufficiently complex that they couldn’t be resolved within the timeframe set by the front line staff, so they’d been passed to the R&D group for investigation. A group, he explained, that had actually been dubbed The Black Hole because problems submitted to them seemed to never again emerge.

    Are you guilty of making the Black Hole such a crowded, congested place? Do you provide status information to those who submit problems to you or who can’t go about their business until you resolve a malfunction, outage or delay? Are you aware that not knowing the status is one of the most singularly frustrating experiences for customers everywhere? Sometimes, in fact, not knowing the status of the problem is even worse than not having a resolution to it. Not knowing, and not knowing when they’ll know, makes people angry. It doesn’t matter if you’re actually working on the problem. If customers don’t know you’re working on it, their perception is that you’re not. After all, they have no information to suggest otherwise.

    Adding to the Black Hole

    This frustration can emerge in any type of relationship where one party is awaiting status information from another. I was once invited to give a keynote presentation at an event for which the date had not yet been finalized; it was to be one of two days. I told my client I’d reserve both dates, and she could let me know when the final date was set. Time passed. No follow-up. More time passed. Nothing. Then I was invited to speak at another event scheduled for one of the two dates I had reserved. Now I needed to know.

    I called my client. She wasn’t there. I left a message with a co-worker. My client didn’t call me back. I called again. This time I left a voice mail message. She didn’t call me back. I sent a fax and an email, and left a few more phone messages. She didn’t call me back. The Black Hole filleth.

    Now here’s the thing. When you’re waiting for information that isn’t forthcoming and you don’t know what the situation is, you start imagining things. They forgot about me. They lost my problem. They’re angry with me. In my case, I wondered if my client wasn’t getting my messages. Or if she was avoiding me, though I couldn’t imagine why. Or if . . .if . . . if. . .

    I finally called her one day at a time that must have been too early for her to have been elsewhere. She answered. I identified myself. She sounded friendly as could be. I told her I didn’t know if she knew I’d been trying to reach her. “Oh yes,” she said, “I’ve received your messages, but I didn’t have the information you wanted so I didn’t call you back.” I was flabbergasted.

    Was she being malicious in not calling me back? I don’t think so. Nor do I believe that she was being deliberately rude or thoughtless or inconsiderate. More likely, it just didn’t occur to her that any response would have been better than none at all. She wasn’t in charge of selecting the date, and was dependent on others who didn’t yet have the information. But it never occurred to her that if she had told me she didn’t know and would contact me when she did, she would have given me something to know rather than something to wonder about. It was getting no response whatsoever that was annoying.

    I don’t know when I’ll stop not knowing

    It’s hard to call another party and say, I don’t know and I don’t know when I will know. But most customers would rather know that than nothing at all. Savvy professionals don’t let their customers feel ignored or forgotten, and that’s true whether or not they’re actually working on the problem, and whether or not they know the status of the problem. They regularly give customers updates, even if those updates consist of stating that there’s been no change since the last update.

    If customer satisfaction is important to you, get in the habit of asking yourself, Who is expecting a follow-up call from me? Who is awaiting a status update? Who has submitted a problem and wants to know what’s happening? Then contact those people. Don’t contribute to the Black Hole. It’s crowded enough there without your help.

    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.

    Beyond Belief

    (c) 2001 Esther Derby, www.estherderby.com

    This article originally appeared in STQE, March/April 2001.

    Let me tell you a little story, a true story, about how our beliefs influence what we see in the world and affect our ability to solve problems.

    Two years ago my friend Julia, who was forty-four and a bit portly at the time, starting experiencing troubling physical symptoms. She was fatigued, depressed, and generally uncomfortable. After several weeks, she went to the doctor. The doctor didn’t find anything specifically wrong.

    Julia was sent home with a vague diagnosis and a prescription for Prozac. After a while her mood lifted and she felt less tired, but the discomfort continued. Finally, after several months and several more visits, her doctor determined she had a fibroid tumor that was increasing in size. He decided to remove the tumor.

    Julia wasn’t happy to be facing surgery, but was relieved that after seven months of discomfort there was a diagnosis and a concrete plan. Two days before surgery, Julia went in for an ultrasound to precisely locate the tumor.

    Based on the ultrasound results, Julia’s surgery was canceled. Julia was sent home to prepare for the birth of her daughter–who arrived, full-term, two months later.

    Now I’m willing to bet that you guessed the end of this story by the middle of the second paragraph. It’s obvious…if you don’t already have any particular beliefs about Julia.

    Julia and her doctor, however, did have a belief, built up over years, that Julia would never become pregnant. And over the course of six months of office visits and medical exams, no one ever suggested pregnancy as the cause of Julia’s symptoms.

    We could say that the medical staff were incompetent, but I would say they suffered from a belief problem. Their belief caused them to overlook information that was readily available–and also limited their application of the information they were using as they diagnosed the cause of Julia’s symptoms.

    What does this have to do with software?

    We all have beliefs about the world and other filters that affect what information we take in. Our beliefs, built up through education and experience, form the internal maps that help navigate the world we live in. Our internal maps can enable us recognize and categorize the vast flood of sensory inputs and think quickly. And often they are very helpful as general models of how the world works.

    Other times, our beliefs keep us from seeing what is blindingly obvious to someone with a different set of eyes. It’s “as plain as the nose on your face” to someone looking at it without our particular set of blinders.

    Take Tom the test manager, for instance, assigned to a team that had always operated on participative and consensus-based decision making. Tom’s framework for managing relied on his belief that, as a manager, he should entertain input from the group but make all final decisions on his own.

    Soon after Tom was assigned to the group, the team was assigned to finish an evaluation of testing tools. Tom read the reports and listened to the group discussion, then closed his office door and decided which tool he favored. At the next team meeting, as he discussed his decision, he reminded the group that “we decided this at our last meeting.” Tom didn’t notice that most of the other heads in the room were shaking back and forth, indicating “no, we didn’t.”

    Was Tom a bad manager? Maybe, but it’s hard to say based on one incident. What we see is that because of his belief about how decisions should be made, Tom didn’t ask questions that might have given him direct information about how the group operated, and he also filtered out valuable non-verbal information that would have given him additional clues. As a result, he was far less than effective in working with the team…at least until he became aware that his map didn’t match the territory.

    We often don’t consciously account for the existence of our internal maps, which makes them more likely to trip us up–just as Julia and her doctor, and Tom, our test manager, stumbled when their maps didn’t show all the ups and downs of the territory.

    Our thinking process happens so fast that it’s extremely difficult to pause the process in the middle and ask, “What unconscious beliefs, filters or maps are influencing me right now?” The challenge is to pause between the time we reach an initial conclusion and the time we act on that conclusion?kind of like how we test a piece of software before we ship it to understand the quality of the product and the risk associated with releasing it in its current state. I have four questions I use for this pause in the mental process:

    1. What have I seen or heard that led me to this belief?

    This question reminds me to really look at what data my response is based on. If I hear myself saying something like “because its always been like that?” I send up a tiny little internal red flag

    2. Am I willing to consider that my belief or conclusion may be mistaken?

    If I’m not willing to consider that I might be wrong, it’s a sign that I’m reacting out of a belief I’m pretty attached to?and it’s a clear sign I need to go to the next question.

    3. What are three other possible interpretations of this situation

    If I can’t think of any other interpretations, it’s time to get some help shaking up my assumptions. I find a colleague I trust and we brainstorm as many different interpretations as we can.

    4. What would I do differently if one of these other interpretations were true?

    This gives me a wider range of responses to choose from, and increases the chance I’ll choose one that will help solve the problem.When I start to test my conclusions, I can surface and examine my beliefs–my assumptions–about the situation. If I’m willing to admit that my initial interpretation might be inadequate, I can gather more information and represent the situation more accurately. And when I do that I open up the possibility of making better decisions, working more effectively with people, and–coincidentally–building better software.

    convert this post to pdf.

    Beware of the Quick Fix

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

    P.T. BARNUM said there’s a sucker born every minute, but Barnum was a conservative estimator — or else he didn’t know any IT managers. For more than 45 years now, I’ve watched an endless stream of technical “solutions” being promoted, sold, and quickly put on the shelf and forgotten.

    Come to think of it, forgetting these “solutions” is not such a bad result. As someone once said: “A problem is the solution to the previous problem.” At least forgotten solutions don’t become bigger problem than they were supposed to solve.

    Remember COBOL? What was it supposed to solve?

    As Jean Sammet recalls in her History of Programming Languages, the users for whom COBOL was designed were two subclasses of those people concerned with business data processing problems.

    One is the relatively inexperienced programmer for whom the naturalness of COBOL would be an asset, while the other type of user would be essentially anyone who had not written the program initially.

    Little solutions

    In other words, the readability of COBOL would provide documentation to all who might wish to examine the programs, including supervisory or management personnel. Little attempt was made to cater for the professional programmer.

    I have clients today who are maintaining, with professional programmers, tens of millions of lines of COBOL code — and no supervisory or management personnel would dare to look at a single line, let alone change one.

    COBOL solved some little problems, but left us with a much bigger one. Because these organizations are busy chipping away at the incredible mountain of maintenance, new development work of organizations falls behind.

    Like addicts deprived of their drugs, the customers are eager for a “quick fix,” and ready to deal with any pusher. One quick fix is called “rapid prototyping.” Almost all of the “rapid prototyping” I’ve so far seen hasn’t been all that rapid, but that doesn’t matter, because it hasn’t been prototyping either.

    I know that statement will bring letters from a hundred vendors agreeing with me – except as far as their product is concerned. But that’s not the battle I want to fight. Nor am I concerned that where prototyping works, it often works backwards. In building airplanes, for example, a prototype often leads to a higher rate of failure in the final version because the prototype makes the builders overly ambitious about the successor.

    But let’s put these little quibbles aside and assume that everyone’s rapid prototyping system is both rapid and prototyping. Let’s grant that they work (after all, COBOL worked) and contemplate some of the consequences.

    Santayana said that those who failed to study history were condemned to repeat it. I suggest we study the history of that earlier rapid prototyping language, COBOL, so perhaps we won’t all repeat it.

    Although many today consider COBOL a failure, objective analysis says it was a great success. If it hadnít been a success, we wouldnít have billions of lines of COBOL code to maintain.

    Here is a riddle: How do you accumulate a billion lines of COBOL code? Answer: one line at a time. In most cases, thatís literally true, because very few of those billions of lines consist of original code. Over the years, as requirements changed, the COBOL programs have changed. Studies indicate that in a mature COBOL program, there have been three lines written for every one that remains in the code.

    It took many programmers many years to accumulate those billions of lines, one line at a time. But we’re lucky, because now that we can program so much more rapidly, we won’t have to wait as long to accumulate our mountain of rapid prototype code.

    In fact, now that we’ll eliminate the professional programmer, we’re going to have 100 times as many people developing prototypes. It took us half a century to get into the COBOL mess, but with rapid prototyping we can surpass that in a few weeks.

    It’s not just the volume of COBOL code that causes the huge maintenance effort. Volume must be multiplied by a quality factor, because low quality code takes more effort to maintain. Yes, I know rapid prototyping languages are supposed to produce more readable code — but have you looked at any? Have you seen what happens after the users have made a few changes?

    Lessons of history

    History teaches us that when the users do actually make those changes, their ambition quickly outstrips their skill and the capacity of their language. At this point, they turn to the more experienced — the professional programmers who already are buried in COBOL code.

    Again from history, we know that the more different people using code or data, the more constraints there are when it comes time to change. The amount of constraint makes each change more difficult, so a constraint factor must be added to the maintenance effort equation.

    There may be some hope of controlling all this, but history teaches that most IT managers are going to go into a dopey daze in the sand while this quick fix enters the bloodstream of their organization. They can look forward to more maintenance, more difficult maintenance, done under greater constraints, with greater shortages of professional staff. Because they’re in a dopey daze, however, they won’t be looking forward at all.

    The only people who can resist a quick fix are those that are not addicts. The only organizations that can avoid turning the maintenance solution into a maintenance trap are those that already have their maintenance under control. But that takes good management, for which there is no quick fix.

    The moral of this story for my readers: Don’t despair of these hard times! There will always be enough work for those who are willing to slowly fix those quick fixes.

    convert this post to pdf.

    At What Cost?

    © 2002 Esther Derby, www.estherderby.com

    This column originally appeared in STQE magazine, July/August 2001

    Not long ago, I reread a discussion about Internet Time on Jerry Weinberg’s SHAPE Forum (www.geraldmweinberg.com), and it got me wondering: Now that many dot-coms have become dot-bombs, have we heard the last of Internet Time?

    I’m afraid not. Internet Time has been with us for a long time, and it will probably be with us for years to come.

    I first encountered Internet Time in 1985. It just went by another name; in that time and place, it was “Wall Street Time.”

    Back then, I worked for a mutual fund complex. Every afternoon, as soon as the New York Stock Exchange closed for the day, we went on Wall Street Time. We worked in a frenzy to get all the mutual funds priced and send the prices to The Wall Street Journal for publication the next day.

    No one step was particularly complex, but the process required a coordination of effort and had to be completed in a tight time window. If we missed the cutoff, the funds showed up in The Wall Street Journal the next morning with no price.

    Our managers constantly exhorted us, “We’re on Wall Street Time here! Don’t miss the cutoff!” Making the Journal was important and urgent.

    Most of the time we did make the cutoff. Once in a while something went wrong?transmission problems or a program crash?and we’d have a mad scramble of fixes on the fly, manual workarounds, and high stress to make the cutoff. And a couple of times a year, we’d miss it.

    Every missed cutoff was followed by a failure review. The big shots would gather us in a room at 7 A.M. for a recounting of the chain of events that led to the failure. The mood was usually dour and the blame flowed freely. “It costs us when we don?t get a price in the Journal,” the head of the department would say in a vaguely menacing tone.

    One day, I worked up my courage and asked, “What’s it worth? How much does it cost if we miss the cutoff?”

    It turned out that the answer was “Not much.” As long as we fed an accurate price into the programs that calculated shareholder value and got the holdings valued by start of business the next day, the costs were intangible?a possible loss of confidence and reputation. No one could point to an actual cost or an instance where a shareholder dumped her holdings after seeing a fund wasn’t priced in the paper.

    On the other hand, if we transmitted an incorrect price to the shareholder valuation program that ran late at night, there were high tangible costs.

    Clearly it was important to have a price in the Journal. But not more important than sending a correct price to the valuation program.

    If you’ve experienced the joys of sixteen-hour days and living on pizza, or snagging three hours of sleep under your desk so you can release a product fast-fast-fast?you might want to ask the same questions. How much is it worth to make the date? How much do you lose if you make a slightly later date? How much will it cost to deploy something that will need to be patched over and over? And how much will a mistake cost besides the cost to fix it?

    Internet Time, Wall Street Time?there are a host of similar phrases. Phrases like these stop us from thinking about tradeoffs and what it?s really worth to make a date, accept lower quality, and give up our personal lives. They create a sense of urgency that isn’t always justified by the true costs and benefits.

    I don’t know what the next phrase will be?but you’ll recognize it when someone uses a slogan to gloss over the need to take a little time figuring out the real value of making a date or the real cost of accepting lower quality. STQE

    I wish to acknowledge contributors to the “Internet Time” discussion thread on Jerry Weinberg’s SHAPE Forum (http://www.geraldmweinberg.com/shape.html), especially Shannon Severance, Bill Seitz, and Jerry Weinberg.

    convert this post to pdf.

    Are We Solving the Real Problems

    © 2001 Nynke Fokma, www.moebius.nl

    The meeting had been underway for about half an hour. Our departmental and quality assurance managers were debating what specifications should we measure against and what database would we need to keep the data in. The meeting had been called by the Engineering Process Group (EPG) of our R&D Optical Networking Business Unit, weeks after an ISO assessment had been done. I was attending as an internal consultant to the EPG.

    I felt rather lost. Finally I mustered up what remained of my energy, and asked, "What problem are we supposed to be solving?"

    After an odd silence followed by a chaotic discussion on what my question actually meant, an Engineering manager answered: "We are working on customer satisfaction issues!"

    My mind wandered to the CMM and ISO Process Improvement activities of our Business Unit. The general perception in the trenches seemed to be that the process assessments were needed to "sell" our product to potential customers. That had nothing to do with our "real" problems of course. Storms come from Above and we just hide until they blow over. Some wished to use CMM and ISO assessment results to solve some of the real problems: The people in the EPG, for instance. In the EPG we were maintaining an overview of problems with an affinity grouping and interpretation of first order measurements (observed data).

    History

    The "old hands" of the Business Unit told us that earlier process improvement attempts had failed. "Failing" meaning "never meeting written down goals." They were cynical of our attempt but very happy to share why they thought earlier attempts had failed. With further inquiry it seemed to boil down to "mixed messages from executive management" like

    "Speak your mind but don’t ask too many questions; Be passionate but don’t show your real feelings; Improve quality and production but hurry up and get it right the first time!"

    Deployment

    In a haphazard fashion, in between peek pressures for deadlines, problems were investigated, solutions found, a single one chosen for all project members to use and then described. And that was it. Problems were considered "solved" after a new procedure or process was created and placed under version control in "approved" state. The solutions were virtually unknown to others. Nor were they used much.

    Management Process

    Management asked the EPG to support the transition to a next CMM level, but support from management processes for the improvement activities was not visible and clear enough through actions and resources. Unknowingly, problem solvers in many different small Process Improvement (PI) teams spread over all departments and locations in different countries were working on same or similar problems. And every time a deadline came near, which was nearly the case at all times, people dropped PI work to do "the real work."

    We seemed to be too busy using our crippling processes to improve them. Were we solving non-problems then? The Business Unit definitely had problems. And seemed not very effective at solving them. And the waves of jokes on mixed messages from executive processes, showed clearly what the "distribution speed of information in the organization" could really be: highly effective! Why did these messages get through, when other formal communication seemed to be blocked and bottled up?

    My mind fled to the larger context. I also had a role in teaching systems architecture and facilitating retrospectives and architecture reviews in the larger organization, providing me with some more experiential and grounding information. I could easily recognize many organizational patterns and problems playing in this Business Unit:

    Prioritization

    There was a lack of visible organizational priorities in the operational part of the BU. A list was available however, on a web page on the intranet. A web page that hardly any techie ever visited. These prioritized issues changed often, and not always on the web page: The page was last updated a year ago. Every time a Big Boss from the US visited the site, the CMM level that we were supposed to "go for" in our Process Improvement efforts went way up -if not in reality then rumored- only to be lowered again a couple of weeks later at the cost of EPG members spending time and energy on managing the managers.

    Negotiations

    Projects were often trying to do everything. Promising customers too much or working on too many projects at the same time happened regularly. The Guessing Game, where one is only to guess at and agree with what others want to have happen, seemed part of the culture. And the Guessing Game can make requirements, specifications and planning documents untrustworthy beyond simple recoverable mistakes. This opens up many spaces for wishful thinking.

    Problem Definitions and Requirements

    One of the moments I realized this, was during a simulation where participants in a workshop were challenged to meet a customer’s expectation. To the participants, the customer requirements seemed to change while in actuality they didn’t: The participants had been sorting cards according to their own assumption of what "the order of sorted cards" means, instead of asking the customer for more specific requirements. I heard a participant say with a frustrated undertone, "The customer doesn’t know what he really needs."

    As a result of wishful thinking about what a customer needs and wants, problem or project statements were unclear, incomplete or even missing. In some projects the related documents became unstable, so much that many techies stopped caring or bothering. In others they seemed to be written in stone -considered unchangeable- while their contents was no longer very useful. It’s not amazing that there was no project wide understanding on the purpose of these projects. And without project purpose it is impossible to do explicit expectation and goal setting in relationship to project purpose and significance to the business.

    Organization

    In turn, without explicit expectation and goal setting, getting clarity on roles and responsibilities becomes impossible. And we found hardly any explicit management of internal (organizational) interfaces and relationships between components/groups, so developing them wasn’t happening either. Indeed, the engineers seemed to have no clue about the impact of their work on the development departments, and the development departments no clue about the constantly swamped testing & integration department.

    Testing and Quality

    We were trying to test quality in! Which quality?? What is quality to whom?!?

    The global organization had a list of 5 company values for all thousands of employees all over the world. One read "Exceed Customer Expectation." How many projects had we shipped in the last year that did not live up to customer expectation, let alone "exceed" it? I had no idea. None of us was directly in touch with customers and users so how will we know how we are doing?

    Hhhmm, maybe the real problems could be found in our models, or rather in mistaking models of reality for Reality itself. We are extremely good at drawing cause and effect relationships, and that predisposes us to stepwise programs for making improvements in our organizations. Maybe this "blocks" change or improvements?

    What were some of the dangers of modeling I had experienced, fallen prey to or seemed to have seen around me in this organization?

    A Staircase To Heaven

    Many of us like working with ideas and models and Quality and Process Improvement models can be interpreted as an architectural description for designing an Universally Successful System, The Essence. We are attracted to abstract models of perfection whether the object is a project, an organization or the entire company.

    Visualizations of models can suggest we could be walking up a staircase to Heaven. For instance, the CMM framework can easily be seen like that. Heavenly visions can land any organization, small or big, in a mode of discussing and wanting to do "the essential thing to solve all problems" and never getting around to doing anything in a more earthly manner.

    Causality Loops

    If there is a best way, and if I see It and if you are one of the best modellers like me, you will understand my solution and that it is True. It’s nearly like a mantra. But when we think we can choose a solution before we can experience it we may be caught in a causality loop. Older organizations in routine state seem especially susceptible to causality loops by use of their own standardized and consistent core -essential- processes:

    We have procedures that have guided us effectively and fast (in the past) — Their description covers our mental models of "the way to do things"

    The problem must be solvable using our guides — Else, it is not a problem that can be solved.

    We do not have to try a new way of doing things — For we already have our (perfect) guides. Go To 1.

    Cultural patterns that might be related, were

    When people made an agreement, it was often assumed that all involved were thinking the exact same thing.

    A problem was considered solved as soon as the till then experienced as fastest thinkers had reached an answer.

    People were often discouraged from speaking out, even with verbal messages from management like "open door," "feedback" and "doing together".

    People rarely gave accurate descriptions of the opinions and reasoning of those whose opinions were at odds with their own.

    Questions were often perceived as challenges, as being questioned means one has possibly done something "wrong" " I am "wrong??" That can’t be!

    Systems architecture and engineering were seen as a primarily pro-active effort, before development, and development before testing.

    The Treadmill

    When finally organizing a change, checklists of which all items need to be in place are a relief. Now we "know what we’re doing" Ö with the details of the modeled solution replacing reality. We can be problem-solutioning instead of problem solving if we’re not careful. When only putting a structure in place we run the risk of Only Going Through The Motions. The actual problems hardly get solved while some non-existing problems do get solved. And who would notice?

    The Business Unit is in a paradoxical state? If the management process could provide direction based on feedback, the organization would already be in a much better state for satisfying its customers? Models and standards do not provide enough transformational model or guidelines, simply because the "where to go" is unknown territory?

    I came out of my reverie and discovered the meeting had continued: We were now discussing how to measure how well implementations were meeting our engineer’s models of customer wants and needs. And the schemes envisioned were big and costly.

    I thought, "Customer Satisfaction? Can we start by asking our customers?"

    (1) None of the symptoms, problems, perceptions and categorizations in this article are to be taken as absolutes. This is absolutely not intended to contain the last word, but more some words to stimulate thought, sharing of observations, discussion and (other) actions.

    convert this post to pdf.

    The Appreciation Gap

    ©2004 Esther Derby

    In a recent workshop, I described an exercise for expressing appreciation. “That won’t go over here,” stated Patty, one of the managers in the workshop. “These are engineers; they don’t want that mushy stuff. Besides, they know that we value them.” Patty didn’t notice that several of the engineers were shaking their heads in disagreement.

    The engineers in Patty’s company aren’t the only ones starved for notice and appreciation. A recent Gallup Poll report quoted this statistic: “…the number-one reason people leave organizations is that they don’t feel appreciated, notes the U.S. Department of Labor.”

    Given the high cost of replacing knowledge workers, reducing the number-one reason for turnover seems like a good investment. And when you consider that this investment doesn’t cost a dime, why not eliminate the appreciation gap?

    An Appreciation Primer

    When you offer appreciation, appreciate the person, not just the work. Most people like to hear “you did a good job.” But a comment on the quality of work is an evaluation. I like to use this form, which I learned from the work of Virginia Satir:

    [Name of person] I appreciate you for [contribution, action, quality].

    I might say, “Tom, I appreciate you for moderating technical reviews. It’s really making a difference in our code quality.”

    I?’l admit that this felt awkward the first time I tried it. But I also noticed that these words had a very different effect than “You did a good job” or “Thank you.”

    Appreciation Guidelines

    Be authentic. Authenticity means that you really do believe what you are saying. Pavlov proved that it’s possible to shape canine behavior by providing rewards for a desired response. People, however are not canines, and they are quick to recognize manipulation. Going through the motions isn’t enough.

    Appreciate privately. Most people don’t need or want their manager to gush over every accomplishment in public. In fact, public recognition is uncomfortable for many people. A word in private will let people know that you do notice and appreciate.

    Appreciate weekly. “Atta boy” once a year during a performance evaluation isn’t enough. Notice and comment on a contribution every week.

    Traps to Avoid

    Don’t dilute the value of appreciation. Some well-intentioned person devised the “praise sandwich” as a recipe for delivering feedback. A praise sandwich surrounds criticism between two bits of praise. I suspect this person wanted to ensure that the feedback recipient was in a receptive mood by making them feel good. In reality, the praise sandwich conditions people to expect a slap after a positive stroke. If you have feedback to offer, do it! Don’t dilute the value of appreciation by only giving it along with bad news.

    Token rewards anger as often as they delight. One colleague received a movie ticket from his boss after he’d worked well into the evening to fix a critical defect. His response to the reward was one of anger. “After I already spent one evening away from home, he wants me to spend another one? without my wife!” he stated in disbelief.

    Don’t wait. When Sara handed in her resignation, her boss told her she was the best project manager he’d ever worked with. “Why’d he wait until I quit to tell me?” Sara fumed later. “Maybe if he’d let me know that he noticed what I did for the company I’d still be there.” A few simple words a week could have kept Sara on the job.

    You may feel awkward when you first try giving appreciations–I know I did. Practice in a low-risk situation, maybe by telling a store clerk you appreciate her for helping you find just the right item. Watch what happens and practice until it feels natural. Then try out this simple practice at work.

    convert this post to pdf.

    Always Be Second

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

    These days, with all the talk about “internet time,” professional workers are always trying to be the first with new ideas. But is that really the only path to success? Is it, indeed, a very effective path at all? What about being second?

    Our culture certainly encourages people to be “first.” In school, the emphasis ranges from who raises a hand first in class to who graduates with the highest grade-point average. The valedictorian – first in the class – gets lots of honors, but the salutatorian – second in the class – has to make the speech (phooey!).

    Sports competitions also honor the “winner,” and books on problem solving and business often borrow this metaphor – emphasizing finding the “winning” idea before anybody else. But most problem-solving areas of life are not, in fact, like sports. It?s not having the idea that matters, it?s what you do with the idea that counts.

    And, in fact, ideas don?t count that much in sports, either. Anyone can have the idea, “Hit a home run now and win the game,” but there?s a lot more to hitting home runs than simply having the idea. To have a fair chance of hitting a home run, you have to practice, practice, and practice. As in most of life, the key issue is not who is there first with the idea; the key issue is how you develop the idea once you have it. It?s not your ideas alone that win, but ideas plus capability and the will to develop your ideas.

    If you think having ideas first is the issue, consider this. Every year, tens of thousands of individuals start businesses based on being the first with a “new” idea. If that was all it took to be wildly successful, many of these firms would quickly displace all of the giant firms and become giants themselves, every year! Yes, we all know stories of small firms that had a better idea and indeed succeeded at becoming giants, but most of the time, the giants persist and the midgets fall humbly by the wayside.

    Giant companies survive the onslaught of little start-ups with one of two strategies:
    1. Exploring many parallel ideas and developing the few good ones.
    2. Letting others do most of the searching for ideas, then developing the few good ones.

    What can the individual professional learn from these strategies?

    Exploring many parallel ideas depends on having huge amounts of capital, which the individual professional cannot manage. But even giants couldn?t afford to have so many explorations in the pipeline if they didn?t know how to kill the ones that show no promise, and kill them early. So, for the individual, the lesson of this strategy is to learn how to let go.

    For me, letting go means not trying to maintain leading-edge competence in every field in which I was once competent. I used to be one of the world?s great IBM 704 assembly language programmers, and I suppose there are still some jobs maintaining such code, but I don?t think I?d want them anyway. I?ve let go of that one, along with dozens of others.

    Letting go also means that I don?t try to pursue every new fad I happen to hear mentioned at a conference or on the web – which leads me into the second strategy – letting others do most of the searching for me.
    In a field where capital costs are low (like software development), chances are better that some small firm will come up with the good idea first because there are tens of thousands of such small firms out there. In that case, the big successful companies don?t rely on coming up with every good idea first. Instead, they pursue an “always be second” policy, and support it. They maintain some minimal competency in a wide variety of areas, so that they?ll readily recognize one of these good ideas when it comes along – from another company, or often from one of their customers. Then, they?ll either copy the idea, buy the rights, or buy the company.

    I?m not able to buy companies, or even their licenses, but I am able to learn from them. And, under some circumstances, I can ally with them. That way, even a single individual can pursue an always-be-second strategy.
    To be a great second, I use a process that resembles the way a breeder produces improved plants and animals, with three essential elements: variation, selection, and retention. Variation provides the new ideas; selection weeds out the ones lacking promise; and retention propagates the ones that survive the selection.

    Variation (new ideas) for an individual, comes from using a network to supply information from literally hundreds of sources. By communication with people in my network, I can be sure that few new ideas escape my attention. I have created a huge virtual organization, far larger than any real organization I could afford. The AYE Conference is a central element of that network, where I can meeting many of my “nodes” face-to- face once a year and exchange ideas and experiences.

    The network provides some of the selection, too. First of all, any idea that nobody passes on to me is unlikely to be a worthwhile idea. Conversely, when I hear of the same idea from three separate sources, I raise its “score.” Of course, in order for this selection process to be meaningful, I have to consider the reliability of my sources. For example, if I hear an idea supported enthusiastically by certain people, I reduce it?s score.
    I work hard to keep my network alive and healthy so I can depend on it to do a good job of variation and selection. Ultimately, though, I have to rely on myself to select which ideas are worth retaining and developing, but the whole process is designed to keep me from developing “neat things” that don?t fit the market.

    I don?t know how to automate the retention and development of ideas, so it takes a lot of work, and I can?t afford to develop very many new ideas the way a large organization might. Sometime I can share work by co- developing ideas (seminars, books, articles) with colleagues from my network. But ultimately, I have to develop in my own way, to create the unique service I can sell to my clients. This is the place where it pays me to be first – I may be satisfied being second in the race to market, but I always try to be first in quality.

    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.

    Confessions of a Confused User

    © 2000 Naomi Karten, www.nkarten.com

    I was doing something dumb in using one of my software packages. Modesty prevents me from boring you with the details. Suffice it to say that although it didn’t keep me doing my work, it did slow me down. Plus, I just couldn’t seem to get the package to do several of the things it was supposed to do.

    I knew I should ask for help, but I couldn’t bring myself to admit to anyone that I was having these ridiculous problems. It’s one thing to do something dumb; it’s something else altogether to admit it out loud. I figured that when I had some time, I’d take an introductory class for experienced but confused users (under an assumed name, of course), and I’d get the explanation without having to ask.

    Another reason I couldn’t ask for help is that I didn’t quite know how to articulate what my problem was. I was sure I was doing everything right, yet strange things were happening. That’s about as precise as I could get, and tech support gurus claim that’s not a whole lot to go on. I knew I should try to find an explanation in the manual, but when I’m completely stumped, the manual might as well be written in linear algebra, because it makes about as much sense.

    Then one day I went to a computer show at which the vendor had a large booth with a section devoted to technical support. Unfortunately, I was leery about this vendor’s support because of a negative experience at the same show the previous year. At that time, I was having a quirky printer problem with another package from the same vendor. I showed one of the tech reps an example of my problem. His response was, "Gee, that’s strange." He couldn’t explain it. But he said he’d forward my example to the person in charge of quirky printer problems. He said I should call him in a few days, which I did.

    Or at least I tried to. The first few times I called, I was put on hold for what probably would have been the rest of my life if I hadn’t hung up. A week later, I finally got through and was told, "Oh, he left the company a week ago." I gave up.

    Reluctantly, I decided to ask the vendor for help with my newest pesky problem. I explained to the tech rep that I’d been having a silly little problem and described what it was. She quickly set up a simulation on her computer and asked me a question: After I did A, did I then do B? The question told me she totally misunderstood what I was talking about. Of course I did B. That dumb, I’m not.

    Needless to say, therein lay the solution. Because, of course, you weren’t supposed to do B, and when you do, strange things happen. In less time than it takes to pull the plug on a week of work, she solved my problem. Her solution not only explained the complications I was aware of; it also explained almost everything else about this software that had struck me as odd.

    The thing is, I’m positive I’m not alone in having this type of experience. I’m convinced that many people have problems they can’t admit or explain, so they’ll never contact their help desk or tech support group. Instead, they’ll limp along, doing things in a muddleheaded manner, just barely managing to bungle their way through.

    However, given the right circumstances, they may gain the courage to seek help. My experience suggests that it can be worthwhile to provide alternative types of support, such as occasionally dropping by a customer’s office and offering to answer technical questions, or calling this or that customer to say "Hi, anything I can help you with?", or running a quarterly Strangest Problem You Ever Had competition. Don’t assume that traditional methods of supporting customers will always work, because for some people, they won’t.

    Give me a call and I’ll tell you exactly what my problem was. Who am I kidding? No, I won’t.

    convert this post to pdf.

    Consulting Lessons From My Shiatsu Therapist

    © 2000 Becky Winant, www.beckywinant.com

    Shiatsu is a type of bodywork that involves stretching and applying pressure at points to release or contain energy. Before he practiced Shiatsu, Ron had a career as an audio engineer — he understands technology and the engineering environments I often am working in. Even though we sometimes we talk about that, his most valuable advice for me comes from his Shiatsu training and practice.

    Last fall I was listening to Jerry Weinberg explain to a colleague about how your intent to help others keeps you from doing harm. Where had I heard that before? From Ron, a Shiatsu therapist. I had taken a Shiatsu course to learn how to help ease the back pain of my partner, Robert. Ron instructed us as beginning students: Don’t worry about technique — that comes in time. Your intent to help alone will improve how the receiver feels. As I tuned back to Jerry talking about consulting intent and technique, I wondered what other parallels there were.

    Shiatsu is a type of bodywork that involves stretching and applying pressure at points to release or contain energy. Like Swedish massage and other forms of bodywork, human touch becomes a tool for healing. Unlike Swedish massage, Shiatsu is based on eastern beliefs about the indivisibility of body and mind, the relative nature of reality, balance, life force energy and a system of diagnosing health based on meridians.

    Before the light went on for me connecting physical therapy and business and system consulting, I had missed the full import of this statement from a book called Bodywork Shiatsu: "Contrary to the biomedical models that currently dominate medical treatment, we are not just a collection of chemicals, tissues, and functional organs. We are also a collection of processes, habits, and developments, in active relationship with the forces within us and around us." There it is — I believe that might easily read:

    Contrary to current organizational theory people are not just human resources with the necessary technical and managerial skills to fulfill specific jobs. We are also a collection of processes, habits, and developments, in active relationship with the forces within us and around us.

    Before I decided to learn more about Shiatsu from Ron, I had been his client and still am. He has loosened my tight muscles and improved my attitude in addition to my physical well-being. Some of this help comes from his physical skills as a therapist and some comes from the philosophy that has shaped his desire to do what he does and share it with others, like me. Before he practiced Shiatsu he had a career as an audio engineer — he understands technology and the engineering environments I often am working in. Even though we sometimes we talk about that, his most valuable advice for me comes from his Shiatsu training and practice.

    So, here are more lessons from Ron that I have found applicable to my consulting work.

    Keep breathing

    The basic idea is this: when we are tight or blocked we can only work through the situation if we remember to keep breathing. Breathing integrates the body and mind. In Shiatsu this aids in the release of energy.

    In consulting good deep breaths can help us center and let go of our personal feelings or thoughts. This frees us from our own biases that may be blocking understanding and improves our ability to listen to our clients.

    Stretching promotes flexibility

    In Shiatsu stretching is part of forcing the body to release tightness and to move to points of greater flexibility. Ron usually finds that point beyond which your leg or arm just doesn’t want to go — usually signaled by a degree of pain. His application of stretching helps you extend your leg or arm further than your previous threshold. This usually results in a place of comfort where you can relax because you’re not using tight muscles to hold a more restrictive position.

    Jerry has an exercise he does with his students, which I think he may call a Stress Module, but it could be called a Stretch Module. I have lost the original name, but it doesn’t matter since the two are related. The set up is for a situation which creates a problem for someone. The module is designed to increase the intensity of the situation. This causes the student to reach further — often with a certain amount of pain — yet the final result is the realization of new choices. The joy of new flexibility and realizing new choices for behavior often outlasts any momentary pain.

    I have been aware of clients who have experienced a certain amount of pain as I’ve stretched them to think in new ways about system development. This endures only until that moment when they discover how this new practice frees them from a rut. Once freed they develop new creative ways to apply the new practices.

    Effective treatment relies on the awareness of the therapist and the participation of the client

    In Shiatsu there is a need for a connection between the therapist and the client. I believe it is a body and mind thing. For the therapist it is important to use his senses to assess the client’s situation. What he feels, smells, hears and sees all are part of the diagnostic process. Ron has said he finds himself breathing together with the patient as he works. In the beginning Ron would tell me to imagine a mid-point between his hands, one of which represented safety and the other doing the work. The working hand is the one that finds your pain. "Ow!" tells Ron he’s found a spot. As I found that mid-point, Ron would say, "Direct your breath to that point." I did. Over the years I have found Ron able to work miracles, but he assures me he is just assisting me as I make the miracle happen. This mirrors a core belief I have about consulting. I can’t help someone if we aren’t there together.

    My success is always their success first

    Jerry talks about entering the world of the client to better interpret what is going on. I have experienced this. When I am tuned in and place myself there with my clients, I get a fuller sense of what is happening to and for them. Once there I gather information by listening, looking, feeling and … smelling? … well, yes I guess that would tell me something. Use pressure points to move energy Shiatsu involves acupressure. Acupressure, like acupuncture, uses the points along the body meridians to find "blocked energy." However, it doesn’t involve sharp little needles, just strong hands and pressure. Different meridians relate to different organs. So, for example, there is a heart meridian and a large intestine meridian. If these should be blocked there is not always a literal translation to a heart problem or intestinal problem. More often these relate to classes of problems which could be physiological — for several possible parts of the body — or emotional or even behavioral.

    In my consulting I associate the notion of blocked energy with client blocks about how to fix their problems. As a consultant you can observe where the energy goes. In some cases clients spend extraordinary energy to ignore what you or I might see as clearly a problem.

    For example, a colleague asking for help with his current employment situation was in a company where employees were being treated like expendable pawns. Yet, managers expressed a concern that they were losing employees. Why weren’t employees getting the message they were valued? You already know the answer. And, not surprisingly two weeks later our colleague reported a huge layoff. The energy told us there was a problem. We even knew where to poke. But, we weren’t able to fix, which may have been due to a number of reasons. One of those was that we didn’t have the connection and participation stated above.

    I just realized two minutes ago that I hadn’t considered the diagnostic aspect of meridians. I wonder what the consulting analogy is for the meridian system. If a client is blocked about a particular problem what might that indicate? I’m not sure. I guess there’s more for me to learn!

    Keep open to more learning, keep practicing

    This is my own addition, but I’m sure Ron would approve. It is how I approach Shiatsu sessions with Robert and how I approach my continuing work as a consultant.

    I hope you forgive me if I tell you that the facts of my explanation of Shiatsu easily could have technical errors. If you really want more precision, I suggest you go to a professional. My personal recommendation would be someone like Ron Barron of Downingtown, Pennsylvania, my Shiatsu guy and a consultant’s consultant.

    convert this post to pdf.

    Convincing Management That Context Switching Is a Bad Idea

    © 2005 Johanna Rothman (This article previously published in Better Software.)

    The last few times I’ve taught project management, I’ve explained that multi-project context switching wastes time. The project managers agree with me. But then they ask the question, “How do I explain this to my management? They refuse to believe me.”

    Managers, especially senior managers, don’t believe context switching wastes time because all they do is context switch. Senior managers frequently have several projects in the air, most of them waiting for input from other people. But that’s not how technical projects work. Most of the time, technical people are not in wait states, but can continue to work productively on projects. Senior managers don’t understand or remember that the work technical people perform is substantively different from the work they perform.

    So to reach managers and convince them that context switching is a bad idea, make sure you speak their language. First, set the stage by explaining how technical work is different from management work. Next, help your manager determine the relative priority of each piece of work. Finally, block out the work, and keep your management apprised of the status.

    Technical work is different from management work

    Here?s one example I’ve used when explaining how technical work is different from management work. Assume you work for a bank, and you have three post-release fixes to complete. One fix is for the branches, for a particular type of new accounts. One fix is to change the format of particular data you send to the Federal Reserve. And the last fix is in the reporting software that the branches use to report a variety of measures to headquarters.

    You’re the technical lead for a group of four other people(a total of five people), and each fix will take two calendar weeks to complete. That’s a cost of ten person-weeks for each fix, a total of 30 person-weeks. Because the fixes are in unrelated systems, you can’t batch any of them together. If you perform the work for each fix serially, at the end of six weeks, you’ll have all three fixes ready. (see Figure 1.)

    Week 1 Week 2 Week 3 Week 4 Week 5 Weeks 6
    Start Fix 1 Finish Fix 1 Start Fix 2 Finish Fix 2 Start Fix 3 Finish Fix

    Figure 1

    If you context switch, the best case is the first fix is finished at Week5. The best case assumes that each person working on a fix spends the entire week working on a particular fix. Between each week is a bit of time context switching to remember the state of the fixing. In my experience, it’s more that the first fix would not be ready until about week seven, the second fix at week nine and the third at about week eleven ?if not later (see Figure2).

    Week 1 Week 2 Week 3 Week 4 Week 5 Weeks 6 Week 7 Week 8
    Start Fix 1 Start Fix 2 Start Fix 3 Work on Fix 1 Finish Fix 1, Work on Fix 2 Finish Fix 2 Work on Fix 3 Finish Fix 3

    Figure 2

    But that just represents the pressure on the technical staff. Don’t forget the pressure on senior management. In this example, in between their meetings, presentation development, document review, voice mail, and more meetings, three people are calling your VP and leaving urgent voicemails, emails, or stopping by your VP’s office.

    Stacy represents the Federal Reserve auditor. She says, “I really need that fix for the Fed, and I need it right away. Your guys are working on my fix, right?” Betty represents the branch managers. She’s left your VP several emails and voicemails, each saying “Another call from a branch manager. This problem is costing us a fortune in back-office support to create those accounts with those workarounds.” And Dan, the CFO, represents the Board when he says, “We need the data from the branches. And we need it before the end of the quarter, so we can get ready for the end-of-quarter financials.”

    Your VP is under tremendous pressure to fix all of these problems at the same time. So, first explain how you work, and how working on one fix at a time will get one customer off your VP’s back. Now, help your VP determine the relative priority of each fix.

    Determine Relative Priority for Each Project

    Each of these three fixes is critically important to the welfare of this organization. And, because there are a limited number of people, management will have to choose a relative priority for each fix. One question I like to ask about priority is, “What are the consequences to the organization if we select this project first?” Then I ask the same question as we review the project list.

    Typically, I ask about consequences and risks in terms of regulatory issues, loss of customers, revenue, and ongoing operations costs. Your organization might rank these issues in a different order or modify this list. Then I ask about the data that says this project is urgent. When I worked with this client, we called Stacy and asked about the auditor?s needs for the data. Stacy was being proactive, but the real deadline was another quarter away.

    Next, we called Dan, and asked, “Would you rather save this much money in back-office work or receive the branch reports?” Of course, Dan said both, and we explained he had a choice of one. If he didn’t make the choice, we would. He chose saving money in the back-office, a choice that surprised both my client and me.

    I’ve been in situations where we really did need to have three things done at virtually the same time. In that case, we staffed each fix with its own project staff, and stopped working on new development work. Now we have three projects in priority order: fix the accounts, then the reports, and finally implement the data format changes.

    Keep Management Apprised of Status

    As you proceed with your projects, make sure you maintain progress on each project. Since you?re not context switching, it’s easier to do that, especially on smaller projects like fixes. Report your progress to management periodically, so they understand you are making progress.

    Some of you may be saying, “Well, now I know how to do this for small projects. But I?m managing three big projects, all with the same thirty people. Each project is a year long. How the heck do I stop context switching on these projects?”

    Extend the risk analysis for larger projects

    First, perform risk analysis for all of the projects, developing a list of projects in relative priority. For larger projects, your management may not be able to or willing to define the relative priority for each project using the issues of regulation, loss of customers, loss of revenue, enhancement of revenue, or reducing operations costs. Two projects may appear quite similar. In that case, either consider how you prioritize projects (which may be out of your control) or consider changing how you develop projects (in your control).

    Consider moving to iterations for projects that appear to have the same priority

    One technique I’ve used is to move to month-long iterations when two projects are competing for the same people at the same time. Even after attempting risk analysis, if my management still can’t make a decision, I either assign half the people on one project and half to the other, or I select one project. Either way, everyone works on their assigned project for one month, and shows some visible progress. Then I ask management to look at the progress we?ve made. One technique to accomplish this is to implement by feature. If no one looks at the demo or our visible progress, I stop work on that project and move everyone to the other project. If management reviews our progress, I verify that this project is still the highest priority,and continue work. If I’ve staffed both projects with half the people, and management is happy about our progress, we continue with that staffing. Otherwise, if this is enough project work on this project for now, we move to the other project.

    Context switching at a one-month boundary isn’t great, but it’s better than the alternatives. But in order for this to work, you need to show demo-able software. It doesn?t have to be release-able, but people outside your project have to be able to see your progress.

    Stop the madness

    Context switching is insanity, because it guarantees everything will be late. You don?t have to live with multi-project context switching. It requires an understanding of the differences in work between technical people and management. You may need to lead the risk analysis and ordering of projects. And when you’ve selected a project and started working,make sure you can show people your progress at reasonable time periods. It’s hard work to stop multi-project context switching. But the rewards are worth it.

    Acknowledgements

    I thank Dwayne Philips and Leo Hepis for their review.

    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.

    Creativity in Accounts Receivable

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

    The introduction of the new $20 bill has me thinking about the Bureau of Printing and Engraving today. They’re one client I ever had who couldn?t use the slow-payment excuse that they’re short of cash, since they print the stuff. One of the most irksome parts of being an independent contractor is the client who doesn’t pay, or at least seems like they won’t pay in time for you to pay your own bills.

    First of all, this is not a new problem, so it’s important not to take it personally. Taking it personally only gets you annoyed and out of your best thinking mode. True, some clients believe that contractors don’t need to think creatively: “Just keep your ideas to yourself and get back to coding,” they say, but they’re wrong. Creative thinking is your best ally when it comes to getting your fair share of the cash.

    There are, of course, traditional ways of enticing your clients to pay you on time. My father was in the auto painting business, and I recall how careful he was to pay his paint bills on time in order to earn his “2% discount for payment in less than 30 days.” Knowing that this discount strategy worked well to motivate my father, I once tried it on a slow-paying client.

    This multi-billion-dollar company had typically taken 4-5 months to pay my tiny bills. I started adding that “2% discount” clause to my bills, and sure enough, it motivated them to change their behavior. They still paid in 4-5 months, but they now deducted 2% from every bill.

    I learned several lessons from this experience. The first lesson is that large clients have payment patterns that no rinky-dink contractor is going to change. I call this Gilb’s Law, because I once asked Tom Gilb about a recruiting firm in Europe that wanted me to do some work with them. I’d had some trouble getting payments overseas, so I asked him about their payment practices. “Oh,” he said, “they always pay. Eventually.”

    In short, their consistent pattern was reliable, but slow. The second thing I learned was that I can use the client’s consistency to my advantage. Knowing that they typically paid 6 months late, I inflated my normal billing rate by an amount equal to 6 months of interest on that rate. If they wanted to compete with my bank for my CDs, that was fine with me (but I did add a tiny bit more because they didn’t offer Federal Deposit Insurance).

    This strategy has worked well for me ever since. The most important part is that I no longer get annoyed with my clients for playing financial games with my money. It’s never a good idea to get annoyed with your clients, so it’s never a good idea for someone like me to feel that I’m a victim of my client’s lack of adaptability. After all, if I’d wanted to be a helpless victim of a large corporation, I could have been their employee?and gotten health insurance to pay for my psychiatric bills.

    A few clients actually understand their own slow-pay patterns and have worked out solutions that I have adopted as my own. (As Tom Lehrer says, “if you steal from one person, it’s plagiarism; if you steal from many, it’s research.”) I gave a short course once at a large government agency, and I was picked up at Washington National airport by Chuck, my contact at the agency. As we drove to the agency, Chuck asked if I was in a hurry to get paid. “How much of a hurry?” I asked. (That’s another good consulting technique?answer difficult questions with other questions.)

    “Well,” he answered, “we seem to have a difficult time processing this kind of payment in less than eight months.”

    “In that case,” I said, “I’m in a hurry.”

    “I thought you might be,” said Chuck. “But don’t worry, we can pay you in cash.”

    This wasn’t the Bureau of Printing and Engraving, so I was rather surprised that they could actually do cash business. I told Chuck of my doubts, but he reassured me. “In fact,” he said, “we’ll get you paid in advance, just in case there’s any hangup.”

    And, sure enough, when we arrived at the agency, he took me directly to a barred window marked “Cashier.” The little guy behind the window lacked a green eyeshade, but otherwise looked just like the teller in a bank about to be robbed in a Clint Eastwood Western. He didn’t even blink when Chuck slipped him a hand-written voucher for $2,500. He asked me for some identification, then a signature, after which he counted 25 hundred-dollar bills into my hand. I was then led to the classroom where I gave a stunning class, never once being distracted by worries that I might not be paid.

    I’ve now added “cash in advance” to my repertoire of payment possibilities. It’s especially useful in cases of doubt or complication, such as working overseas. There can be drawbacks?every solution creates new problems, as every consultant knows. Once, after an extended tour of Japan, my sponsor had me in for a tea ceremony, during which he handed me an envelope wrapped with a red ribbon and containing, I presumed, my fee for the visit?in cash, as our contract had stipulated. I thought it would be discourteous to count it in front of him, but as I was about to slip it into my inside pocket, my translator suggested it would be rude not to count it.

    Knowing that cultures differ, I opened the envelope and counted over $10,000 in crisp new American money. The amount was correct, but counting it raised my anxiety about carrying so much cash. I wanted to take it to a bank and convert it to some sort of non-negotiable instrument, but I was told, regretfully, that it was “Honor Old People Day,” so the banks were closed. That night, I slept with the money under my pillow (and not too well).

    The next morning I had to leave for the airport before the banks opened, so I had to carry the cash with me all the way home. I learned, also, that when you carry more than $10,000 cash into the USA, you have to have a friendly discussion with the customs agents?a discussion in which you must convince them that you’re neither a counterfeiter nor a drug dealer. I also discovered that it wasn’t even that easy to deposit that much cash in my own bank?once again, lots of rather personal questions.

    In other words, cash has some disadvantages of its own, in addition to the disadvantages of money in general. Disadvantages of money? Yes, life is never as simple as we contractors think it should be. Indeed, the worst accounts receivable situation I have had to solve?the one that took all my creativity and more?was when, Lily Gilding Limited (LGL), one of my best clients paid the same bill twice .

    The bill was $4,240. (It would have been $4,000, but I had added the interest for their 4-month pay cycle.) The first check arrived right on schedule?that is, four months late. Unfortunately, even before I had time to spend all of it, a second check arrived?same invoice number, same amount, same date.

    LGL was a good client, so it wouldn’t have been good business to try to pretend that we didn’t get the second check. We called their Accounts Payable Department right away to tell them of their double payment, but they said, “No, you must have made a mistake. We couldn’t possibly have paid you twice. We have controls . You’d better have the manager of your Accounts Receivable Department check your records.”

    I smiled, thinking of how Lois would feel being called the “manager of the Accounts Receivable Department,” but I kept my mouth shut. A/P departments can only talk to A/R departments, not to the do-everything-person-named-Lois in a small consulting firm. Lois checked everything again, and I double-checked Lois’s records. Same result. LGL had definitely paid twice.

    After about twenty calls back and forth, I became convinced that LGL could never admit to such a mistake. I then brought the matter to the attention of my contact person, Nel, and she made a few phone calls on my behalf. Next time I was consulting at LGL, Nel told me, “I’ve tried everything I can think of. My advice to you is just to keep the money.”

    “But I can’t do that,” I protested. Mostly I was thinking that LGL might someday discover their error and think I was dishonest. It’s always harder take being thought of as dishonest when you really are dishonest.

    “No, really,” Nel said. “Even if you could finally get us to take it back, it would cost us more than $4,240 to get it cleared up. Believe me, this is the best solution for both of us.”

    Well, she was right, of course, but Lois is one of those honest Nebraska farm women who simply couldn’t keep money that didn’t belong to her. She simply wouldn’t accept any solution that involved us keeping their money, so I turned the problem over to her?having exhausted my own creativity. And, as usually happens when I have the courage to admit I can’t solve a problem, Lois found a way.

    Her solution may not always work for you, but since LGL was a good client, Lois simply deducted $4,240 from the next bill she sent them and called it a rebate. Apparently they were happy to receive a “rebate,” and we never heard another word from them. Another accounts receivable problem solved, and another happy client!

    What?s the moral of all this? It reminds me that when you?re in business for yourself, your problems never end, and even that wonderful event – getting paid – can be one of your worst problems.

    convert this post to pdf.

    Danger: Couple at Work

    I swore I wouldn’t write about consulting done by married couples. It’s a trite discussion, as far as I’m concerned.

    But then I read Dilbert on December 12, 1999. The Pointy-Haired Boss hired two new engineers — a couple. The female was the target employee and the male was "brought along for the ride." The female was competent and the male was incompetent. The female was normal and the male was schizoid.

    I guess that’s how most of the world sees couples.

    I’ll admit that Dilbert at least turned the scenario and made the woman competent.

    The challenge is how to present two people who are otherwise competent, personable, and useful. Can this marriage be promoted?

    Can this contract be saved?

    I realize that in a large corporation there is a larger issue: power. But let’s face it. My husband and I each own a portion of this consulting firm. I own 51%, since I started the company. (Additionally, I see that women-owned businesses are sometimes favored by those corporations wanting to promote equality.) No two-person business can operate with the independence of two divisions. So, now that we’ve eliminated the nepotism issue, we proceed right back to the real question. Can a married couple work together?

    I imagine that the many sitcoms of the fifties and sixties contribute to concern about couples. After all, would Lucy of "I Love Lucy" be able to manage Ricky’s band? Wasn’t Laura always a little at the periphery of Rob’s writing team on "The Dick Van Dyke Show"? Would any good sitcom mom have time to review an operating budget?

    Let’s move to the nineties. In fact, let’s not. Though I love "Friends," I don’t profess to understand how any of them could work together. The characters of "Ally McBeal" seem much too busy to practice law. And they hardly ever have good team interactions.

    "Star Trek: Voyager" wanders between Janeway (female) as Captain and Janeway and Chakotay as a potential couple. But "Voyager" stays a few steps from making them a constant team.

    So, I don’t see the answer in TV. I remain filled with questions:

    • Should I always work with the other competent men and women I know?
    • Should I always recommend my just-as-competent female and male friends to work with my husband?
    • Or can I just say, "The person who can best do this job with me is my husband, my business partner, and one of the best. I picked him on his merits."
    • Or isn’t that believable?

    OK, that’s off my chest. Let’s carry on with the "real" articles.

    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.

    Decisions, Decisions

    © 2000 Sue Peterson, www.cowgirlcoder.com

    My husband bought his father’s business last month. It was not an easy decision. Like most modern managers, I’ve been taught that the best decisions are the product of logical, deductive thinking. But we didn’t have time for that. Was our decision the absolutely best one we could have made?

    My husband bought his father’s business last month. It was not an easy decision. Like most modern managers, I’ve been taught that the best decisions are the product of logical, deductive thinking. You should analyze the situation, generate and then compare all of your options, and judge the probabilities. In an ideal world, we would have reviewed the financial reports of our existing business, examined the finances of the company we were considering buying, built models of future cash flows under varying conditions, and then unemotionally followed whatever course of action would maximize our profits while minimizing our risks. But we didn’t have time for that. The opportunity dropped into our lap with no prior warning. We had less than a week to make the decision and to finish all of the paperwork, or we’d miss some crucial advertising deadlines. And in our industry, no advertising means no business.

    The rational judgment model

    Traditional economic theory teaches what is called the "rational judgment" model. This theory holds that the best possible decisions can only be reached by comparing all of the relevant information and by statistically weighing all of your options. Decisions should be logical, deductive, and thorough. Unfortunately for the theorists, this whole process seems to have very little connection to what actually happens in real life, where information is often missing, incomplete, misleading or just plain wrong. In real life, we rarely have the luxury of all the time we need. In real life, pesky emotions intrude on the most logical of decisions, forcing us to take into account more than dry statistics and profit and loss sheets. In real life, even if we can isolate all of the relevant factors, the combinatorial explosion that occurs when we try to account for how everything affects everything else quickly makes the exercise unrealistic.

    The Nobel Prize winning psychologist Herbert Simon (1957, economics) described an alternative to the rational judgment model more than 40 years ago. His theory of "bounded rationality" states that it is often impractical or impossible in real life to calculate an optimal strategy. In fact, in many situations, there may be no single best strategy. Instead, he believed that people use heuristics — simple rules of thumb based on their experience — to reach a good enough, decision.

    These days, bounded rationality is gaining renewed attention in such divergent fields as psychology, economics, artificial intelligence, and animal behavior. I just finished reading the book Sources of Power — How People Make Decisions, by Gary Klein (ISBN 0-262-11227-2). Unlike most of the popular business press, which is often anecdotal with little data or rigor behind it, Sources was written by a cognitive psychologist and is backed by his many years of field research. Klein is interested in naturalistic decision-making — "the study of how people use their experience to make decisions in field settings." He says, "We all have areas in which we can use our experience to make rapid and effective decisions, from the mundane level of shopping to the high-stakes level of fire-fighting." He wants to know how we do it and how we can get better at it.

    Four mental strategies

    In particular, he describes four mental strategies — sources of power he calls them — that effective decision-makers use when they are under pressure. Klein shows how we use intuition, metaphor, mental simulation, and storytelling to draw on our experience and to make instantaneous judgments about our present situation. Intuition helps us to size up a situation quickly. Metaphor draws on our experience by suggesting parallels between the present and the past. Simulation lets us mentally follow a series of steps to a conclusion before we actually carry them out.

    Intuition

    Storytelling helps us abstract and consolidate our experiences so that the lessons we’ve learned will be available to us and to others in the future.
    Klein defines intuition as "the use of experience to recognize key patterns that indicate the dynamics of the situation." Once the decision-maker has zeroed in on the patterns that identify a familiar prototype, he has available at least one reasonable course of action that has worked in the past, and he can start acting immediately. Intuition can be spooky — some decision-makers almost seem to pick a decision out of thin air. In reality, of course, these patterns are subtle and don’t always reach a conscious level of our awareness.

    Spooky or not, psychological studies have indicated that intuition is based in biology, as some brain-damaged patients lack the intuition that normal subjects show as a matter of course. Since intuition grows out of experience, it can be cultivated by deliberately seeking a wide range of experience. It can also be formally trained. If the experts in a field compile a list of the perceptual clues that they use, they can then use those lists to bring trainees up to speed quickly and to spread a common experience base amongst their peers.

    Trained intuition is remarkably effective, I relied on mine a lot last month. My husband and I have owned a similar business for 20 years, so I had a gut-level feeling for what kind of cash flow, income, and outgo we could expect with the new company. Of course, intuition isn’t perfect and that gave me a few nightmares while we were struggling to make our decision.

    Mental simulation

    Mental simulation is the natural partner to intuition. Intuition helps us see what is there, mental simulation helps us imagine what may be there in the future or what might have been there in the past. Klein defines mental simulation as "the ability to imagine people and objects consciously and to transform those people and objects through several transitions, finally picturing them in a different way than at the start." Mental simulation allows a decision-maker to mentally experiment with several different options and to try out various steps, before he chooses a course of action.

    I learned to rely on my "mental movies" as I called them, long before I knew the formal term for the technique. I remember one incident in particular that happened many years ago. I borrowed a friend’s horse one afternoon so I could take my husband trail riding. Smoky was gentle, but I’d recently seen him get nervous when cross-tied. I happened to look up while I was saddling another horse, to see my husband standing in front of Smoky. I was uneasy for some reason, and asked him to move. A couple of minutes later, Smoky reared without warning and went over backwards. If my husband had stayed where he was, his head would have been kicked off. As it was, I caught the horse, soothed him, and we had a nice ride. My husband still thinks I’m clairvoyant. I learned to trust my mental picture shows.

    The very fluidity of a mental simulation is both its greatest asset and its greatest bane. Working with thought-stuff, we can construct simulations that would be impossibly expensive or time consuming in the real world. This is an incredible advantage when time and resources are short, but if we’re not careful we can use the very power of our simulations to explain away any inconvenient facts. Nobelist Murray Gell-Mann’s book, The Quark and the Jaguar (ISBN 0716727250), tells a story about two physicists who were climbing near Aspen, Colorado. When they started their descent, they got turned around and came down on the wrong side of the mountain. As they descended, they looked down and saw a lake, which they identified as the familiar Crater Lake and which they were expecting to see about then. One of the men casually mentioned that there was a dock on the lake. Crater Lake has no dock. Unfazed, his friend replied "They must have built it since we left this morning." They did make it home finally, several days later.

    We can smile at the impossibility of building a dock in a morning, but these were not stupid people. Just the reverse, they were smart enough to fit any inconvenient facts into their mental simulation of where they were. Luckily for us, we can improve the way we use mental simulations. I know several software managers and consultants who like to use what they ca