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.

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:

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.

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

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

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.

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.

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

The article was lifted from the handouts for the AYE Warmup Tutorial so it also serves as an example of the quality of the material that Don Gray and I share during that session. I thoroughly recommend that you join Don and me for that session. It’s a lot of fun.

Controversial? During a Temperature Reading, the facilitator does NOT accept a complaint without the sender providing a recommendation for fixing the problem. In other words, no whining. If you disagree with this idea, please leave a comment. I would be happy to backup the reasoning with a separate article.

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.

Here are a half-dozen criterion to consider:

• Limited attendance. AYE is limited to 75 participants to ensure high-quality interactions. It’s not a huge event where you’ll be like one of thousands of struggling through crowded halls to get to the next powerpoint lecture.
• Interactive, experiential sessions that focus on your learning, not the presenters ideas of what you should learn.
• High caliber presenters. The AYE hosts have years of experience with experiential learning and are all published authors. We don’t rely on unknown or untested presenters to fill out topic tracks.
• Ample time and space for networking, one-on-one coaching, and meeting new people. You’ll meet lots of interesting people at AYE. Our participants are thinkers and learners, not warm bodies sent to simply swallow powerpoint bullets.
• No sales pitches masquerading as learning opportunities. We aren’t here to sell you the latest tool (though we will happily sell you our books!).
• No canned presentations. We aren’t dialing in the same lecture we’ve done dozens of times. Even when we do repeat a session, it’s different because the people are different and bring different dynamics and insights.

We hope you’ll choose AYE. We love to meet new people and enjoy our old friends.

Take advantage of the Summer Discount $1500 per person, $ 300 less than the full registration. Read more about the discount below!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Tenth Annual AYE Conference will be November 8 – 12, 2009 in Phoenix, AZ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can see the schedule and session descriptions on our Program Page.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Summer Discount Ends July 31, 2009
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From May 1 to July 31 conference registration is $1500. After July 31 the standard registration of $ 1800 applies.

If you have any problems registering, call and discuss them with our registrar, Susie Brame at (503) 799-5132. You can also contact Susie at susie.brame@ayeconference.com or register online at http://www.ayeconference.com/register . We’re committed to helping you come and thrive at AYE, regardless of the obstacles.

Team Registration Special Continues
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Right now you have two ways to save money while attending this year’s conference:
When you and your teammates register and attend together, you qualify for our team discount. That’s $1200 per person for 3 or more, $300 per person less than the Summer Discount price and $600 less than the full fee.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Meet and learn with the AYE Hosts at these events:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jerry will be participating in CAST 2009, in Colorado Springs, Colorado, July 13-16. On July 13, he will be presenting a tutorial: Ensuring Testing’s Proper Place in the Organization

Don will lead the Agilely Delivering Business Value simulation at agile-knoxville on July 14, 2009.

Esther and Diana Larsen will be leading Secrets of Agile Teamwork July 21-23 in Redmond WA.

Johanna will be part of a panel discussion on Agile Teamwork: The People Issues on July 23 at the Agile Bazaar in Boston, MA

Esther and Johanna will be at AgileRX in Phildelphia July 30-August 1.

Don, Esther, Jerry and Johanna will be presenting at Bizconf August 20 – 21, 2009. Part two of Jerry’s interview with Obie Fernandez is posted here. (Read the first part of Jerry’s interview about consulting, dealing with clients and permanent employment.)