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

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.

Steve gives his answer:

It’s another gift from Virginia Satir, a pioneering family therapist. Her Interaction Model helps you update your own internal communication, which changes your external communication, so you can interact better with others. The updates change how you treat your perceptions, interpretations, feelings, and past experiences.

Satir viewed an interaction as a process. She carved it into six phases where internal communication typically breaks down. Analyzing an interaction using these phases enable me to slow it down and use both logic and emotion to shape how I respond to someone.

Satir was aware of the critical impact that feelings on communication. For instance, when I feel angry, I know exactly what the other person is thinking. If I succumb to my anger, I may stop the other person in mid-sentence and say, “You mean X. Say no more (shut up). Let me tell you…” If I think of the Interaction Model, I can stop myself from saying something I’ll regret later by asking myself, “What other meanings can I make from what I heard and saw?” That question helps me recognize I can’t recall a single thing I heard or saw and I have interpreted only one single meaning, which means I’ve missed literally everything. My internal dialog will often change my feelings. Being aware of the breakdown, I might say, “I was angry. I’m not sure why. I missed what you said. Would you please repeat it?”

We all learn and grow through our interactions. Not only does the Interaction Model help me be a better communicator, it helps me be congruent, which helps me feel better about myself, which helps me take more risks, which helps me change my rules, which helps me be a better communicator… The model shows how all these qualities are connected.

I love the Interaction Model.

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.

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

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.

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.

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.

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.

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.