Many people are conditioned to say Yes to every request that comes their way.

I met a CIO like that. He told me his policy was to never say No to the business. So he always said Yes, and the business was always angry because things he agreed to didn’t get done, or got done poorly or far later than they wished. His Yes meant nothing.

Sometimes, a clear No is the best response. When there’s no real possibility of meeting a request, No allows the person making the request to adjust accordingly. That may mean changing plans or finding another way to get some work done.

But other times, No is the starting point for a negotiation. Here’s a story about how one new manager learned to stop saying Yes, and getting talked out of No.

Recently, I met with Monroe, a new manager, over lunch. He was feeling overwhelmed, and recited a long list of projects he was working on. Monroe complained that his boss didn’t seem to realize how much work he was doing.

“Do you ever say no?” I asked.

“Of course I do!” Monroe said. “I try to say no, but then he gives me all the reasons it’s important for the company to do this extra project. He does have good reasons for what he’s asking for, so I cave in. But I can’t see how I’m going to get all this work done!”

Monroe isn’t alone in having difficulty in turning down his boss’s requests. Some people have a hard time saying no because they fear offending. Others have rules that say “Don’t disappoint,” or “Always be helpful.”

Rules may keep us from saying no even when we want to—when we realize saying yes doesn’t serve us. Some people don’t consider their own needs when they say yes, assuming (albeit unconsciously) that whatever the requester wants is more important than their own priorities, health, well-being, or ability to juggle one more task.

As Monroe and I talked over lunch, I began to understand that Monroe had a slightly different problem. He could say no, but he just couldn’t hold it. If Monroe stood firm in his refusal, his boss might think he wasn’t up to his new management role. But Monroe was paying a price for backing down.

Since he said yes to all the requests eventually, Monroe was actually training his boss to keep pressuring him until he wore him down. In doing this, Monroe was also bringing about the result he feared most: showing his boss he wasn’t up to his management job by failing to prioritize and follow through on agreements.

Underneath his inability to say no and have it stick Monroe suffered from having a two-speed switch: On (Yes) or Off (No). What he needed was a way to start a negotiation toward an agreement that recognized organizational goals and took into existing work commitments into account .

Monroe and I started thinking of ways he could start a negotiation. Rather than simply blurting out “No!” Monroe decided to start by affirming his boss’s intention by saying, “I can see why that’s important to the organization.” Having something to say would give him a bit of time to think.

Then, depending on the situation, he’d use one of these phrases to start a negotiation:

I can’t fit that project in right now. I can do it ___________.

I can’t do that, but I can do this ___________.

I’d be willing to offer________________. Would that help?

This is what I can do. I can do that instead of _______________.  Which is more important?

I can start on that project after ____________.

I can do that AND here is how that will affect ___________ (other work, commitments, etc.).

If Monroe didn’t have an immediate grasp of the impact, he’d one of these answers to gain time analyze the situation:

I need to check with ________ before I commit to that.

I can’t give you an answer I can stand behind until I review my other commitments.

Monroe and I met a week later to check in, and he reported on his boss’s latest request. “It was sort of funny!” Monroe started. “My boss asked me to take on another task, and I used one of the responses we rehearsed. Then I went over to the white board and did a chalk talk of our current work. When I finished the picture, I turned to my boss and asked him what work I should put on hold in order to fit in the new work.” Monroe grinned. “And you know what my boss said? He said, ‘Now you’re thinking like a manager.’”

When I talk to people about making the transition from technical work into a management role, one of the recurring questions is whether managers need to know a language. There are strong opinions on both side of the argument:

On one side, people say: “You must know a language if you are to understand the work of your staff and have the respect of developers!”

On the other side, people respond: “Knowing a language isn’t necessary. Managers need to understand the work and not pretend to have more technical depth than they really have.”

Of course, the participants in this discussion are talking about a computer language. But what about being an expert in spoken language?

We communicate every day—to our families and friends, co-workers, managers, and teams. Language allows us to go where we want to go, have what we need, and communicate our ideas and feelings to others. Like many daily activities, our use of language is below the radar of conscious examination.

And that can trip us up. Here are some language traps for managers to avoid:

Absolutes

Have you ever heard this conversation?

Fred: You always forget to take out your testing stubs when you turn code over to CM.

Megan: Sure— I forgot a couple of times and you’ll never let me live it down!

Jennifer: You never include enough information in your bug reports.

Tom: Yes I do. Just ask Chase—he was able to recreate that data purge problem right away.

Always and never should never be used; they will always land you in trouble.

Well, I wouldn’t go that far. These words have their place. But be careful of how you use them, especially when you are hoping to influence future behavior. Always and never tend to focus the mind on finding a counter example. Absolutes set up the dynamic we saw with Fred and Megan and Jennifer and Tom.

Missing Details

Have you ever seen something like this happen?

Krista: You need to do better with your defect reports.

Dave: Okay.

Dave goes off and designs a new automated form that captures the memory state at the time of the error. Two weeks later he proudly shows Krista his work.

Krista: That’s not what I meant! I wanted you to describe the clicks that lead up to the error so the developers could recreate it!

Krista might have gotten what she’d wanted if she had filled in the details of the request. (If you are on Dave’s side of such a vague request, don’t guess, ask for clarification!)

Missing Comparisons

Product manager: We need to get this product out the door faster!

Compared to what? Without a comparison, we tend to fill in the blank with our own definition (which is most likely different from the next guy’s definition). Does faster mean one week faster? A day faster? Faster than our competitor? Faster than the speed of light?

We will do much better at meeting improvement goals when we are explicit and specific:

“The goal for 2.0 release of WidgetWonder is to improve mean-time-to-failure by 10%.”

“The Rec_retrieve function needs to complete in 1 second or less.”

“Our goal is to improve our turn-around time on customer identified critical errors by 25% on average.”

Black and White and Gray

Managers need to recognize when they are talking about a continuum (as with the concept fast) or a mutually exclusive category. We have a natural tendency to categorize. And our professional experience may condition us to look for binary conditions: A test passes or fails. A task is done or not. The release criteria has been met or it has not been met. Being clear about discrete conditions can be useful.

But not everything belongs in a mutually exclusive category, especially characteristics and qualities that pertain to people.

Consider this exchange:

Eric: I’m thinking about moving Cyndi into a management position.

Chris: I don’t know about that…I don’t think she could handle management. Cyndi isn’t assertive.

Assertiveness is not a category, it’s a continuum. One end may be doormat and the other end domineering. People can be at any point on that range, and their placement on the range isn’t fixed. In some situations, when Cyndi knows the subject matter and is feeling good about herself, she can be appropriately assertive. On another day, when everything has gone wrong at home, she’s out of her comfort zone, and is dealing with a situation she’s never faced, she may be less assertive.

Before you put someone in a box, check to see if the variable you are describing is continuous or discrete. Look at how the quality plays in different situations and over time.

It may help to know something about Java or C++…But it’s essential to be competent in the use of daily language (whatever your native language) when you are making the transition to management. Communicating clearly and unambiguously with your team will improve relationships, morale, and results.

An earlier version of this column appeared in STQE magazine, May/June 2002

We all have coworkers who rub us the wrong way, get on our nerves, and generally drive us crazy.

Let’s consider these examples of three people who have difficult coworkers:

1. Ted finished working on a difficult bit of code and headed for the team meeting. When he got there, Sandy looked at her watch and glared at him. “You’re late,” she snapped. “Hey, it’s only ten after,” Ted responded.

How selfish! Sandy thought to herself. Ted has no respect for other people’s time.

Meanwhile, Ted wondered why Sandy made such a big deal about arriving precisely on time. It’s hard to put down what I’m working on when I’m in the middle of something important. What’s more important, anyway?  Getting the code done so we can release this fix or coming to a  meeting? Why doesn’t Sandy understand that?

2. When the technicians showed up to install more memory in Frank’s computer, Frank asked Talia if he could use her machine, since she was going to a meeting. “Sure,” Talia replied. When she returned to her cube and logged into her computer, she discovered that Frank had changed the settings. She spent half-an-hour fixing the obvious ones, and stumbled over more of Frank’s little “fixes” for the rest of the day.

Sheesh, thought Talia. He asks to use my computer for an hour, and he acts like it’s his. I’m never letting him use my computer again. I wonder if he read my mail, too.

Frank, however, was pleased that he’d set up several helpful shortcuts on Talia’s machine.

3. Sam greeted Jennifer with a cheery hello as he entered her office. “How was your weekend,” he asked. “Did you do anything fun with the family?” Jennifer scowled. “Let’s get down to business, Sam,” she said.

What a grouch, Sam thought. I’m just trying to be friendly and build a working relationship.

Jennifer, on the other hand, wondered why Sam was so nosey. Doesn’t he get that I don’t want to discuss my private life at work? I don’t want to talk about having to take Chad for a psych evaluation over the weekend.

No one in these examples is a bad person. They aren’t wrong or behaving atrociously. But Ted, Frank, and Jennifer are acting in ways that are different from how Sandy, Talia, and Sam expect people to act.

The opposite is true, too: Sandy, Talia, and Sam are acting in ways that Ted, Frank, and Jennifer find puzzling and irritating.

Conflicting Definitions of Appropriate Behavior

We find other people difficult when they don’t meet our expectations of “appropriate” behavior. The trouble is that each of us has a different definition of “appropriate.” To further complicate matters, some areas of mismatched expectations are easy to see and comment on, but others aren’t.

In the first example, Ted and Sandy have different ideas about how important it is to arrive exactly on time. Sandy believes that not arriving on time shows disrespect for the group. Ted believes it’s more important to accommodate individual needs and be “close to on time.” These mismatches are easy to spot and most people are able to reach some accommodation because there is some external reference point: the clock and the agreed upon meeting time.

Other mismatches are about personal space, personal property, and privacy. What may seem like friendly conversation to one person may seem like prying to another, as in the example with Sam and Jennifer. Fred doesn’t view Talia’s computer as “hers.” To him, it’s company property and, therefore, belongs as much to him as to anyone else who works in the group. There’s no external reference point for these.

Each individual has his own idea of what’s appropriate. Psychologists call them “boundaries.” But, unlike boundaries on maps, we don’t always know where our boundary lines are until someone crosses them. Others don’t know where our boundary lines are unless we tell them.

Deal with Difficult People Where You Have the Most Leverage

We can hope that people we find difficult will realize how unreasonable they are and will change on their own, but they won’t. They won’t wake up and change because they don’t see themselves as difficult or inappropriate. These troublesome (to us) people believe they are acting in a reasonable way. In fact, they may wonder why other people are so upset.

To deal with difficult people more effectively, start where you have leverage. Start with you. When you feel yourself becoming upset, ask yourself if you’ve been clear in what you expected from the other person. Check on your emotional response. If you are having a strong response and wondering why the other person doesn’t get it, it may be a clue that someone just walked all over your boundary lines for acceptable behavior.

Understanding why people drive us to distraction at work doesn’t mean you have to tolerate behavior that you find distressing. Talia could set a boundary with Frank by saying something like “Frank, it’s fine for you to use my computer as long as you return the settings to my preferences when you’re done.” You can always make a request for a change—not for the other person to fix herself, but to respect your boundaries or find a third way that will work for both of you.

Life is too short to let the people we work with fray our nerves. We can’t change those irritating people, but we can recognize the source of our irritation and change our own response.

An slightly different version of this article appeared on stickyminds.com.

A good idea is a valuable asset, and a lot of good ideas are a treasure trove. But what do you do with those ideas? Here’s a little story about an idea maker who isn’t very good at getting his ideas accepted…and 4 tips to keep your own ideas from withering on the vine.

***

Ron was full of ideas. Good ones, too—or at least he thought so. He had ideas about how team members should organize their work, how to report status, how to speed up the build, and a way to save money on white board markers, to name a few.

But, Ron’s teammates hadn’t picked up on his wonderful ideas. In fact, to Ron’s eyes, they had rejected them out of hand. So, he persisted, arguing why his ideas were a better way.

Eventually, another developer agreed to try Ron’s idea for speeding up the build and asked Ron to work on it with him. Ron refused. “I don’t want to get saddled with the extra work,” he huffed. “That’s like punishing me for having good ideas.” The other developer quickly lost interest.

Many ideas wither, not because they are bad ideas, but because of clumsy presentation. Few people are as inept as Ron; but most nascent ideas stand a better chance if you remember these four things:

1. It’s not about you.

Most of the time, people pursue a new idea because they can see how it will help them. Don’t just tell them why you think your idea is a good one. See the world from their point of view, and frame the idea in terms of what matters to them. If your manager cares only about cost, then talking about quality, speed, reuse, or elegance won’t convince him to try your idea. Connect your idea with what’s important to the people you are hoping to influence.

2. It is about who you know.

Bringing your ideas to fruition is a social process. You will need the aid and interest of others to make your idea reality.

Take stock of your network. Who can help you move the idea forward? Who has influence with people who might champion the idea? What do the people who hold formal and informal power care about? Can your idea help them advance their goals?

3. Action creates attraction.

Rather than pushing your ideas on people, try pulling them in—work by attraction. If you think a team task board would help everyone do better, show them; don’t just tell them. Demonstrate the benefits by creating your own task board and making your progress visible. The time to tell is when someone shows curiosity, not before.

There’s another benefit of showing: You might learn something useful about the how the organization will respond to your idea. Suppose you make your own kanban board and start limiting your own work in process. If your manager increases his scrutiny of your work or berates you for not working hard enough, you’ve obtained valuable information—information that will help you move your idea forward (or choose not to move it forward and look for a new manager, instead).

4. Timing is everything.

Your idea might be good but not viable in this organization at this particular time. An experiment—such as the personal kanban board—can reveal what else needs to change for your idea to succeed.

Sometimes people and groups aren’t ready for an idea. They may not have the prerequisite knowledge to appreciate it, or they may be working from a different mental model in which there’s no place for your idea to fit. In this case, you need to prepare the ground with conversations (sometimes many) before planting the seed of your idea.

When you are brand new to a group, you may see many opportunities for improvement. But, ideas from an outsider can feel like implied criticism. After all, how could an outsider understand the tribulations the team is facing? Show you understand by offering an idea to solve something the group views as a problem, not something you see as a problem. Once the team sees that you can solve their problems, they’ll be more likely to listen to your other ideas.

Sometimes a great idea comes a few seconds too late. When a team has too many ideas, they may feel overwhelmed. Or, as team members chase each shiny, new idea, those ideas may not stick. When the team is close to a decision and a new idea enters the mix, the team goes back into analysis, examining the new idea.

You may have an even better idea, but sometimes it’s best to hold that for the next round and get on with implementing “good enough.”

Ron continued to generate ideas—ideas that usually involved more work for other people, and no ownership on his part. His teammates continued to ignore his ideas until one day someone told him to just shut up. So, if you want to stay out of the Ron trap, remember these four points—it’s not about you, it is about who you know, action creates attraction, timing is everything. I can’t guarantee that all your excellent ideas will come to fruition, but many will. And you’ll been seen as someone who knows how to make things happen.

This article first appeared on stickyminds.com.

Tom looked up to see Jonathan, who had just transferred onto the team, standing in the doorway to his office. Jonathan looked red and flustered. “What’s up, Jonathan? Looks like you’ve got something on your mind,” Tom said, waving Jonathan in and pulling up a chair for him.

Jonathan slumped into the chair. “You know I’ve been working with Danielle this week?” Jonathan began.

“Yes, how’s that going?” Tom asked.

“Is she showing you the ropes?”

“I can’t work with her anymore!” Jonathan blurted out.

“Whoa,” Tom said. “That sounds pretty final. What brought that on?”

“She’s always eating cookies, and the crumbs get all over the keyboard. On Tuesday she left chocolate fingerprints on the table,” he said. “And yesterday she put greasy marks all over my printout.”

“Have you talked to her about this?”

“Well, no,” Jonathan admitted. “But I wipe up after her, so she should get the hint.”

Tom took a breath. “If you haven’t talked to Danielle, how is she supposed to know you don’t like it when she eats cookies during your working sessions?”

“Anyone with a clue would know how rude it is to drop crumbs in the keyboard. Besides, giving feedback is your job,” Jonathan said.

“Yes, giving feedback is part of my job,” Tom said. “And it’s part of your job, too, when it comes to improving working relationships. You need to work this out with Danielle. I can coach you on what to say, but you have to say it.”

Jonathan crossed his arms and sank down in the chair. “All right. I’ll tell her,” he agreed grudgingly.

Tom and Jonathan discussed the outcome that Jonathan wanted and developed a script so he could practice what to say.

“Ready to go?” Tom asked.

“I guess so. I’ll ask her if we can talk right after lunch. She’s probably out buying cookies right now,” Jonathan replied.

Tom watched Jonathan walk out the door and then sighed. A year ago I would have fallen into the trap and talked to Danielle myself. Then she would have been hurt and angry. And it wouldn’t have helped Jonathan and Danielle work together—it would have made it worse.

Yes, it’s my job to provide feedback, Tom continued to muse. But it’s not my job to play middleman.

Tom had learned the hard way what happens when a manager delivers feedback for someone else. Last year at review time, Tom had asked everyone on his team to provide feedback for every other team member. He provided a form with a series of questions and a rating scale. At the bottom of the form was a space for additional comments. Tom had gathered up the feedback forms and consolidated the responses. I’ll have some solid information to provide people about how their peers view their skills, he’d thought. But the reviews didn’t go as well as Tom had hoped.

Martha had been mystified to learn her teammates rated her communication skills as poor. “What does that mean?” Martha had asked. “What can I change to do better?” Tom had made some general recommendations but couldn’t be specific.

Ted had been thunderstruck when he found out that Jenny had complained about an incident that had happened back in January. “I had no idea Jenny was upset about that. Heck! I hardly remember what happened. I wondered why Jenny had been cool toward me during that project, and this explains it. If she’d talked to me last January, I could have done something differently.”

Fred had summed up his review experience succinctly. “This feels like third grade—when someone’s upset, he goes to the teacher to tattle.”

Rather than improving teamwork, Tom’s experiment in delivering secondhand feedback had bombed. He could feel the trust level drop as co-workers wondered who had said what. Everyone seemed to be waiting for the next knife in the back. Even the team members who had received positive feedback weren’t basking in the glow—”I’d rather someone thank me directly rather than filling in a stupid form,” one person said.

It had taken months to rebuild trust between team members, and Tom had had to eat crow to do it.

After weeks of watching the team pull apart, Tom had called a special meeting. “I made a big mistake,” Tom began. “I thought it would be helpful for the review process to gather your feedback for each other. But I see now that it wasn’t the right thing to do. You guys aren’t talking and joking like you used to. It’s as quiet as a tomb around here. Most of you are barely speaking, and you sound guarded and careful when you do. It feels like my efforts at second-hand feedback, instead of helping, has destroyed trust.”

Tom had paused. “Do I have it about right?” The members of the team murmured their assent.

“OK, I blew it,” Tom said. “What can we do to move past this?”

Finally, Ted spoke up. “I was hurt and angry to hear that Jenny had complained about me.” Ted turned to Jenny. “Jenny, I really wish you had spoken to me directly.”

“I didn’t know what to say to you,” Jenny said looking at her notebook. “But next time you do something that bugs me, I’ll try.”

“Maybe we shouldn’t save up our feedback ‘til the end of the year,” Fred offered.

The team continued to generate ideas on how to rebuild trust. Tom took an action item to arrange for a training session on peer-to-peer feedback.

It took time, but the team started chatting and joking again. And to Tom’s surprise, team members developed stronger relationships as they learned to give one another feedback directly and respectfully.

There were a few occasions when a team member came to Tom for advice on how to broach a sensitive topic. And Tom continued to provide coaching and feedback based on his direct experience. Tom knew that in some rare instances, he’d need to be involved in a peer-to-peer issue—in the case of harassment, ethics, or safety. And it was conceivable that someday he’d have to step in when peer-to-peer feedback didn’t resolve the issue.

Tom snapped out of his reverie. “These aren’t school kids, and I’m not the teacher,” he said to himself. “No more middleman for me.”

This article originally appeared in Better Software magazine.

© Esther Derby 2001 – 2010

This article originally appeared in STQE May/June 2001.

As test and development managers, we pay attention to developing technical personnel, but what about managers? Do we do enough to help manager and team leads develop and improve their leadership skills–especially when we are those managers?

Some companies, GE for example, have a strong tradition of developing managers from within. Promising employees are carefully groomed through a series of increasingly complex and responsible assignments, with formal and informal mentors to guide them along the way. Along with teaching specialized domain knowledge, mentors coach new managers in the “soft” skills that are crucial for top management performance. How often to you hear of managers being carefully trained, developed and mentored in the software world?

I didn’t go to software development or test manager school, and they didn’t teach much about the people side of management in the school I went to. I ended up in management because I had good technical skills. I was originally promoted to project manager because I was a good software developer, and I stayed in management because I hoped I could do a better job than the people who had been managing me. I meet a lot of managers with stories similar to mine.

As a new manager, I got a clear message: Managers are supposed to know what needs to be done and how to do it (or at least act that way). And that message put me in a kind of trap: if I’m supposed to know what to do, it’s harder for me to admit I don’t have the answer or I need help.

The truth is, few people know intuitively how to manage process, projects and people. Like anyone else learning a new skill, new managers need training, guidance and mentoring. And just like technical staff, experience managers need to keep their skills current and evolve with an evolving workplace.

As managers, we spend time and effort improving testing, configuration management and development processes. What about management processes? What can we do to improve our own management processes? The good news is that good managers are often made, not born. Here are some of the things I’ve done to develop my management capabilities:

Get to know “me.” The most important things I’ve learned that resulted in direct improvement in my management capability weren’t about managing other people — they were about me. How do I cope with conflict, what assumptions do I have about people, how do I respond when I feel angry or hurt or scared? How do my emotions effect the way I make decisions? What are my strengths, my weaknesses and my blind spots? These skill have to do with self-management….if I can’t manage myself, I don’t stand much chance of managing anything or anybody else.

Find a model. Like most humans, my first lessons in navigating relationships came from watching and imitating my parents. I got my first lessons in management that way, too, watching other managers. Only thing was, I didn’t have real good management models in my first few jobs. It took a while to find a manager I wanted to emulate: someone who not only got the project in on time, but build decent software and treated people like adults. I try to learn from other managers who get things done and always have a list of people waiting for a position to open in their group.

Find a mentor. A model shows me what to do; a mentor will tell me when I don’t quite hit the mark. Trust is a big part of a mentoring relationship, and it takes a certain amount of personal chemistry, too. My first mentor [Jerry Weinberg] didn’t work for the company where I was employed, though he was consulting in the organization when I met him. He was a willing to provide feedback, answer questions and help me puzzle through all sorts of management challenges. He’s also given me some of the hardest messages I’ve ever had to hear (and I’m a better manager for it!).

Start a book study group. I don’t have the luxury of reading every book I’d like to. But I can usually find an hour to read a chapter. So I divide the labor and get together with a group and read. Each person reads a chapter and reports on it. Everyone gets an overview of the book, and I can focus later on chapters that are most meaningful to me. Sometimes we meet two or three weeks later and discuss how we’ve applied the concepts from the book in our work.

Keep a journal. I find that recording events, decisions and results helps me see patterns and analyze the results of management actions. It’s not always pretty, but it helps keep me from making the same mistake over and over and over. The habit of reflecting on the outcomes of decisions is a simple and powerful way to improve management abilities.

The key really, is to remember that mangers never really arrive–there’s always more to learn. The more effort I put into improving my management capabilities the more effective I’ll be in managing people and projects. And that means better software.

(c) 2001-2010 Esther Derby

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 cancelled. 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 can 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 in 2001.

© 2003- 2010 Esther Derby

This column originally appeared in STQE, May/June 2003.

When action grows unprofitable, gather information; when information grows unprofitable, sleep. Ursula K. Le Guin, The Left Hand of Darkness

A few months ago, I began writing a “Technically Speaking” column for this issue and just couldn’t make myself finish it. I started over on another topic, but couldn’t work up much energy for it. I started yet a third time, and found myself easily distracted.

The week my column was due, I was still starting over and over and over. I began to panic: “I’ve been writing this column for three years! I should be able to do this!”

I was stuck.

As it happened, I was scheduled to have lunch with my friend, Bob King, a software architect and a writer. Eventually, our conversation turned to writing.

I explained my problem to Bob. “What should I write about?” I asked.

“Why don’t you write about not knowing what to write about?” he suggested.

“Yeah, right,” I said, dismissively.

After lunch, I though about Bob’s suggestion a bit more, wondering if “un-sticking” could make an interesting column. Then I remembered that I’d recently received an email from a colleague who needed some un-sticking with a performance issue. And I remembered another colleague who had spent an entire day stepping through every line of code, determined to root out a bug. By the end of that day, she was completely out of ideas and still hadn’t found the bug—she was stuck.

“Oh,” I thought. “I’m not the only one who feels stuck. Perhaps Bob was on to something.”

So I compiled some strategies that get me moving again when I am at a dead end.

Notice what is happening. Am I making no progress despite several attempts? Am I repeatedly telling myself, “I should be able to do this?”

Take a break. Work on something else unrelated to the problem at hand, especially something physical. Tasks that occupy your body and require concentration occupy the conscious portion of your mind and leave the unconscious parts to work on the problem.

Verbalize the problem. I can’t tell you the number of times I haven’t been halfway through the explanation of a problem when the light bulb switches on. When no one else is around, I explain the problem to my dog. He’s a good listener, and remarkably astute.

Ask for help. Sometimes another person with a different point of view or a fresh set of eyes will see what I cannot.

Sleep on it. Sleeping on a problem can allow the unconscious mind to go to work. This strategy is not suitable in all work environments.

Make a list. Write down all the known facts about the problem. You may find that you need more information; or discover new patterns in the data.

Look where the problem isn’t. Quite often, a problem is exactly where I’m sure it isn’t. It couldn’t be in the subroutine I wrote, could it? Check those places, too.

Brainstorm. Think of twenty ways to solve the problem. Don’t dismiss anything until you’ve considered it carefully.

Sometimes it takes more than one of these jiggles to get going. Looking back on my most recent stuck-experience, I see that I applied four strategies. I noticed that I wasn’t making progress, but was repeatedly telling myself I should be. I took a break by going to lunch with Bob. (And eating is sort of physical, though in general I can’t endorse eating as a problem solving strategy for all the obvious reasons.) I asked for help. At first it didn’t seem like Bob was giving me the help I wanted. Help is often like that. Finally, I considered an idea that seemed way-out long enough to see its merit.

And I arrived here: at the end of another column and unstuck.