Tag Archives: personal effectiveness

Self-Awareness Matters: Finding Your Filters

I remember sitting in a project meeting back when I worked for a Big Company. The project manager, Ted, announced the top three priorities.  When I offered a different view point, Ted declared, “You’re wrong. We decided on these priorities yesterday.”  He didn’t notice six out of eight people at the table  shaking their heads “No.”  

Ted didn’t notice the responses and reactions of people around him. He also didn’t  notice that he didn’t notice.

We all have filters. That’s a good thing–our cognitive systems can’t process all the data that’s available. But most people filter out useful information as well as extraneous information (for example, the size of loops in the carpet or shoe styles). What any one person filters depends on his preferences for big picture vs. detail processing, intake style (verbal, visual, tactile) and training.

Learning about your own filters builds self-awareness. Knowing what you tend to filter allows you to choose to ignore that information or make a conscious choice to notice it.

Ted deprived himself of the choice to notice people’s reactions. Ted was continually surprised when people “resisted” or “backtracked” on decisions. He didn’t pick up on the fact that after he made a few sharp criticisms, people stopped offering ideas.

People who lack self-awareness don’t realize their own observational biases or notice the impact of their behavior. They wonder why things don’t work well (or work well) but don’t see their part in the situation.

One relatively small action by a manager can send ripples or shockwaves through a system. Ted’s lack of self-awareness suppressed the groups effectiveness. Some people ignored Ted’s dictates and did what they thought was right–which splintered the group’s effort. Others left for positions where they could participate in solving problems rather than carrying out the managers prescriptions, driving turnover. Since hierarchy amplifies biases, it behooves people in management roles to build their awareness and find their filters.

Here are two exercises to build awareness of your own filters.

1. Work with a colleague who has different type preferences or a different sensory intake style. Make an agreement to share observations after meetings or working sessions.  What does your colleague consistently notice that you miss?  What do you miss by missing that?

Work on noticing those things that you have missed up until now.  Notice what insights you gain about yourself and the group.

2. Reflect on a recent meeting.  Did  you notice anything about the flow of conversation?  For example, in what order do people speak? Who interrupts whom, and how often?  Did you notice anything about physical arrangements? Or who is on their iPhone? Did you notice what emotions came up?

Choose an aspect of human behavior that you normally don’t notice. Then, practice noticing it.  Notice what insights you gain about yourself and the group.

If it fits for you, report back here. If you would like some help honing your self-awareness, drop me a note.

Yes. No. Negotiate.

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

Fill in the blanks

I’ve been noticing what’s missing lately. In some ways, its harder to see what’s not there than what is. But there’s lost of useful information in what isn’t said, as well as what is.

For example:

A manager, talking about one of the people who reported to him said:

“He’s difficult to manage.”

What’s missing?

“He’s difficult (for me) to manage.”

“(When he does X), he’s difficult (for me) to manage.”

“(When he does X,) he’s difficult (for me) to manage (because I don’t understand his actions).”

“(When he does X), he’s difficult (for me) to manage (because I don’t understand his actions and I don’t know what to do).”

There may be another follow-on sentence, that hints at the crux of the matter.  That sentence might be…

And I’m worried that if I can’t bring him around, I’ll miss my goals and my boss will think I’m not competent.

And I have judgements about that behavior because I was criticized for that when I was in school.

And I feel threatened.

And I feel I have to defend my ideas.

I know what I’m asking doesn’t make sense, but my boss told me to do it.

It may have been more comfortable for the manager to say the first sentence, as he did.  He may even believe it.

As long as the manager deletes parts of the sentence, it’s easy for him to see the other person as the problem. As long as the problem resides entirely with the other person, there’s not much he can do to improve the situation (other than fire the “difficult to manage” person).  But the deletions contain important information that could help him improve the situation.

What examples would you add?

There’s I(ntelligence)Q, and then there’s I(nfluence)Q

People who work in software are smart people who take pride in their abilities to understand complex information and solve difficult problems. But much of the work isn’t only about smarts. Creating most software requires the help and cooperation of other people. Telling, convincing, and winning arguments won’t work to bring people along, change their minds, or help them help you. That requires influence.

To some of people, influence is a dirty word. The word may bring up images of sleazy organizational politics or strong-arm tactics along the lines of “I made him an offer he couldn’t refuse.”

But influence doesn’t have to be slimy or manipulative. Simply put, influences is the capability to affect the opinions and actions of others. You don’t have to be in charge to have influence; the elements of influence are available no matter what your role.

Let’s eavesdrop on two conversations to see what we can learn about influence.

The Alpha team is working towards their next release. One of the major goals is to make it easier for customers to migrate their existing data when they install a new version of the software.

Brandon knows there are two stories in the backlog that will require table updates: one story is scheduled for this release and one for the next. He has figured out how to design the table to accommodate both requirements with one table change, which means customers will need to do only one database conversion, instead of two. Plus, they can roll out the improvement with this release rather than the following one.

Brandon wants to convince Cindy–who is working on the story that’s part of the current release– that his idea is the right approach. Brandon stops by her desk to chat about his idea.

We’ll pick up the conversation after Brandon’s sketched out his candidate design.

Cindy: You can’t do the tables that way, Brandon.

Brandon: Let me tell you why I this this will work, and be easier for the customer…

Cindy (cutting Brandon off): We’ll have to write lots more code with this table setup. Did you think of that?

Brandon: It might take another access call, Cindy, but it makes it much easier for the customer to install the new release.

Cindy: We’re going to have to write ten percent more code, at least. And then we’ll have to test it all. It’s a bad idea.

Brandon: I don’t agree, Cindy. It’s not going to take that much more code. And there are several advantages to this approach.

Cindy: Do you really want us to blow our iteration goal? Is that what you want?

Brandon (trailing off): No, of course, I don’t want us to miss our commitments…

Brandon felt like he was being backed into a corner and it felt like Cindy was picking a fight.

After a couple more brow beatings from Cindy, Brandon gave up.  Arguing with Cindy wasn’t worth it.

Cindy, however, felt a little rush of pride. She believed that her powers of argument had moved Brandon to see things her way.

Cindy is exhibiting one sort of influence, perhaps a sort that gives influence a bad name: browbeating and emotional manipulation.

Brandon is missing the influence boat, too. He didn’t ask Cindy what she needed or what her concerns were to see if they had some common ground.

Brandon made two other mistakes:

  • He responded to Cindy’s objection by explaining his position rather than exploring her objection.
  • He responded to her second objection by arguing the facts.

In another part of the country, Jason and Tom are working on a virtually identical project:

Jason: Tom, the customers are really screaming about having to convert their databases with every release. I think I’ve found a way to eliminate a conversion for the next release–three months earlier we thought we could. I think they’ll love it. Is this a good time to walk through my idea?

Tom: Sure, show me what you’ve got.

Jason walked through his approach.

Tom: Well, the way you have it set up, we’ll have to write another call every time we access this table.

Jason: Ah. That’s true. When I was fleshing this out, I saw there would be an extra call. Can you tell me more about the impact you think that will have?

Tom: Well, I’m worried about writing and testing those calls.

Jason: Can you tell me more about that? You’re not concerned about performance?

Tom: Performance shouldn’t be a problem (but we’d need to test that). I’m worried about Teddy. Teddy is sweating the release plan. He just added a a big new feature, and he’s worried about upholding his commitments to one of our key customers.

Jason: Oh, so your concern is about what we can fit into the release.

Tom: Yep, I don’t see what we can take off the plate to fit this onto the plate.

Jason: I see. Well, what if we talk to Teddy about the tradeoffs and see if we can shift something around to make this work?

Tom: Okay. Let’s to talk to Teddy. And let’s talk to the rest of the team. They may see something we’re missing.

Maybe Cindy would need Prozac to be this mellow. But most people will hear more and be willing to cooperate when they feel like you have heard their concerns and understand that your goals intersect with their goals.

Here’s what Jason did:

  1. When Jason approached Tom, he checked to make sure it was a good time to walk through the design before he started.
  2. Jason stated his goal explicitly, and tied it to something they both cared about, customer satisfaction.
  3. When Jason heard Tom’s objections, he asked for more information rather than starting to explain his position.
  4. He acknowledged Tom’s concern, and obtained Tom’s agreement that he’d heard the concern correctly.
  5. He showed his willingness to help Tom overcome that concern by talking to the Teddy, the product owner.

in short, he connected, listened, learned, and found a potential ally.  That’s high IQ.

Entering Groups

Most of the time, people integrate into groups well enough that we don’t really notice how it happens.  But a recent rocky experience got me noticing.

Looking back over several teams I’ve observed and groups I’ve been part of, here are three (rather spectacular) examples of a newcomer failing to integrate.

***

A skilled XP programmer joined a group that was adopting agile engineering practices.  On his very first day as part of the team, he told his new team mates that they needed to start doing TDD, and gave them a lesson in refactoring.  Over the next several weeks, he found the opportunity to coach each member on his programming skills.

He was quickly ostracized.

***

A newcomer to a loosely organized professional group decided to join a two-day informal retreat organized by the group. The night before the retreat started, he announced to all within earshot that the group was highly dysfunction….and he was going to “fix” the group.

He started right in the next morning, issuing challenges and confronting people. When one of the organizers offered the newcomer feedback, the newcomer shouted at him.

It was later noted that that was the most dysfunctional event the group had experienced in their relatively long history.  The newcomer did not become an old hand–he was not invited back.

***

A new team member joined a distributed team that met face-to-face only twice a year.  The team arranged to hold one of their F2F meetings to coincide with the new member joining the group. The group hired a facilitator and worked with her to design an agenda that would share group history, revise working agreements to reflect the new group, and identify priorities for the year.

Without consulting anyone, the new member set up a meeting with representatives from a commercial product company. The new member announced he’d arranged a breakfast meeting prior to the main meeting to discuss the product and that five people from the product company would be present.

The “old” members declined the breakfast meeting. The group had been wrestling with the question of product endorsements and had decided, after much heated discussion, to remain neutral.  The newcomer felt the group was “resistant” to his ideas, and that set the pattern for his participation. At the  end of the year, he was asked to leave the group.

***

In each of these instances, the new group member wanted to contribute.  Why did their efforts backfire?

The new members failed to:

make contact and establish relationships before offering help and ideas.

understand the group, how the group viewed issues and develop empathy for their struggles.

orient to the group’s goal, history, and context and see how their ideas could fit in.

In contrast, when people enter groups successfully, they:

Get to know the other group members and become known by them.

Learn something of the group’s history and context.

Orient themselves to the goal, tasks, and priorities of the group.

Look for ways to contribute that line up with those goals and priorities.

People have different needs for affiliation and inclusion, which affect how they go about entering. But  you can’t skip these processes, if you hope to become part of the group.  And this is especially important if your views are divergent from the rest of the group.  Coming in loaded for bear won’t help you be effective. Showing empathy for the groups journey will.

Looking back on the three examples I described above, the result isn’t surprising.  However well-meaning the newcomers were, they failed to integrate into the group.

I suspect all three wanted to be helpful, and to do something meaningful for the group. I suspect they wanted to be valued by the group and were trying to prove their worth.

But without entering the group before they tried to turn it, their actions assured the opposite result.

 

Peer-to-Peer Feedback

One of the traps people fall into on teams is withholding information that’s critical for the team to function. Sometimes the information is about friction between team members. When team members don’t have a way to talk about small frictions, they turn in to big events, damage relationships and spill over onto the team.  So here’s how to have one of those difficult conversations.

***

Not long ago, a developer approached me for advice about a problem team member. The developer reported that one team member was causing resentment, alienating other team members, and generally making life difficult for all. No one wanted to work with him.

“What is he doing to cause all this?” I asked, wondering what sort of wildly dysfunctional behavior was going on to cause these problems.

The answer surprised me. “He picks his nose,” the developer said.

“He picks his nose? Have you talked to him?”I asked.

“Of course,” my developer friend replied. “I talked about the importance of manners at our team meeting. And I talked about how we all had to be careful about spreading germs.

“He still picks his nose,” he continued. “It’s gross. The only thing I can think of is to start picking my own nose to see how he likes that.”

Nose picking is an unattractive habit. But the real source of this team’s problem isn’t nose picking. The real problem is that team members don’t know how to have an uncomfortable conversation—peer-to-peer.

How to talk about a difficult subject.
Remember, the over-arching goal of feedback is to improve working and social relationships. When you think of it that way, it’s easier to find a respectful way to deliver a difficult message.

Use “I” language.
Talk about what you see, and what you feel. Start your feedback with a sentence that starts with “I,” rather than with “you.”

Describe what you have seen and heard.
Stick to the facts of what you have seen and heard. Describe behavior rather than applying a label. For example, “Yesterday in our team meeting I heard you call Sara an idiot.” rather than “Yesterday you were rude.” Labeling the other person only puts him or her on the defensive.

Own your own feelings about the situation.
Some people advise using this formula to give feedback: “When you do X, I feel Y.” But this construction implies that one person is the cause of another’s feelings. No one else can make you have feelings. To remove the implied cause and effect, you might say, “When I hear you call Sara an idiot, I feel like you are disrespecting her,” or “I want to tell you about something that you do that’s a problem for me.” Then describe the behavior.

Talk about the effect the behavior has on you.
People often don’t realize the effect their behavior has on other people. Explain (briefly) how the behavior you are talking about effects you. Explaining the impact gives the feedback receiver information so they can choose what to do with your feedback. If there’s no impact, then a request seems arbitrary. The conversation could start with “When I hear you call Sara an idiot, I feel like you are disrespecting her. I worry that you talk about me that way when I’m not in the room.”

Make a request.
Most people don’t like to be told what to do, even by a peer. (Telling someone what to do implies that you are not actually peers.)  Ask for joint problem solving to work out a different way to work together.  But there are times when you want a particular behavior to change or cease.  Then make your request clear:  “I want you to stop calling Sara and our other co-workers idiots,”  or “Please check with me before you commit my time to a meeting.”

Don’t sell past the close.
Sales people warn about “selling past the close.”  Selling past the close happens when the prospective buyer has made the buy decision, but the sales person keeps selling.  This breaks the relationship because the buyer feels pressured and senses that the sales person isn’t actually listening to him.  And there goes the sale.

The same think can happen with feedback.

It’s helpful to prepare what you want to say–as it is in any situation where you feel anxious.  But don’t just stick to your script.  Pay attention to the other person, and listen to his response.  When he signals that he’s gotten the point, zip it.

If you open with “Laura, I want to talk to you about the meeting yesterday,”  and she responds “Oh, it’s about how I interrupted it you…I’m so sorry, let my enthusiasm carry me away. I know I do this, and I’ve asked Sara to help me monitor myself….”  Stop.  She’s got the point and continuing your feedback message won’t help your relationship.  Sometimes the feedback receiver gets it at the description, or when you state the impact (“Oh, I didn’t know my speaker volume irritated you.  I’ll turn it down.).

Don’t expect an admission of guilt or contrition.  Often, people need time to absorb what you’ve said, especially if this is the first time they’ve heard about a problematic behavior.  And after all, the feedback is about you, not the Truth about them.

It’s not always easy to give feedback. I still feel anxious when I prepare for a difficult feedback conversation. I have almost always found that the pre-conversation anxiety is worse than the actual event. And the pay off for having the conversation is well worth the effort.

So what happened with the nose-picker?
I advised the developer to have a private conversation with the offending team member. “Give him the benefit of the doubt,” I said. “What if he’s unaware he’s picking his nose? It may be an automatic habit. And even if he’s aware he’s picking his nose, he may not be aware of how if affects you and other people on the team.”

The developer agreed reluctantly, and we worked out a little script. Here’s what he decided to say to his nose-picking colleague:

“Joe, this is really awkward for me. I want to tell you about something that you do that’s a problem for me.”

[Pause]

“I’ve noticed that during our team meetings, you pick your nose.”

[Pause and wait for a response. This may be all you need to say.]

“When I see you picking your nose, I feel worried about you spreading germs. My reaction is getting in the way of our working together.”

[Pause and wait for a response. This may do it.]

“Would you please stop picking your nose while we’re working together?”

The next week, he reported back.

“You’ll never guess what happened,” he said. “You were right, he wasn’t even aware he was picking his nose. But it was really awkward,” he continued. “He was embarrassed but he was also grateful I told him. I guess I shouldn’t have waited so long.”

It is hard to address interpersonal and work issues directly-even when the issues aren’t as awkward as someone picking his nose. Respectful feedback can improve working relationships. And handling issues directly keeps little irritations from growing into major divisions.

An earlier version of this article appeared on Stickyminds.com.

Are You Ready to Coach?

Agile coaches are expected to help teams learn agile methods, engineering techniques, and improve the productivity of the teams they work with.  But before they can do they need to be ready to coach.  Being ready to coach means that you have coaching skills, relevant technical and process skills.

But the  foundational skill in coaching is skill in managing yourself.

Your attitude will contribute or detract from your ability to make contact, assess what coaching is needed, and actually help the client.   So,  before you begin, ask yourself a few questions.

Are you aware of your own emotional state? Manage your own emotions before you coach. Coach from a neutral, curious, and encouraging attitude. If you’re feeling angry or impatient, your emotions will leak into the coaching. Anger, frustration, or impatience won’t create a helpful interaction. Look inside to see where your emotions are coming from: Are you expecting an inexperienced person to perform as well as a master? What are your assumptions about what the other person should know or be able to do? Rather than blame the other person, reframe your judgment as “He doesn’t do that as well as I wish he did” or “She doesn’t know as much about this topic as I wish she did.” Shifting your attitude will make you a better coach.

Is coaching the best learning opportunity? When the team struggles and puts the team goal at risk, ask yourself: Where is the biggest opportunity for learning? Will the team learn most from making their own mistakes and learning from the consequences (That’s the beauty of short iterations—if the team misses a goal, the risk is limited by the length of the iteration) or will the team learn most if you coach them in a different direction?

Does the other person want coaching? Coaching always works better when the other person actually wants help. Try to wait for the person or team to come to you for help rather than immediately stepping in the moment you see trouble. Many people learn from solving problems on their own. That doesn’t mean you always have to wait until someone asks you for coaching. Coaching is part of your job, so you can always offer. But remember that it’s an offer—so ask before you inflict help. However, if you see a pattern emerging—a team member repeatedly refuses help when stuck—you have an opportunity to give feedback on how that pattern of behavior affects the team as a whole.

Does the other person want for coaching from you? Sometimes people want help, but they want it from someone else. Don’t take it personally if a team member would prefer to receive help from someone other than you. But again, look for patterns. If a team member is open to coaching from everyone but you, it’s a clue that the relationship may need repair.

Are you clear on the goal? If you aren’t clear on the desired outcome, you risk setting up a frustrating cycle called “bring me a rock.” “Bring me a rock” happens when success criteria are vague (or nonexistent). Here’s how it goes. You say, “Bring me a rock.” The other person goes off and finds a rock, and brings it back to show you. You look at the rock and realize it’s not the rock you had in mind. You hand the rock back and say, “Not that rock.” And the cycle begins again. The result is frustration and de-motivation—guaranteed! Of course, sometimes the goal isn’t known in detail. In that case, make it clear that the goal is to explore options and gain clarity.

Are you open to other approaches? You may have a very clear idea of how to accomplish the work or handle the interaction. But is it the only way? In most situations, there are many reasonable and acceptable paths to success. If you find yourself expecting things to be done a certain way, ask yourself if that way is simply your preference and not the only correct method. Help the person you are coaching think through different options and discuss the pros and cons of each approach. Then let the person choose the one that fits best for him or her. Team members gain capability when they develop based on their own thinking modes, strengths, and talents.

Are you ready to encourage rather than evaluate? Coaching is about helping another person develop skills and capabilities; it’s not a time for evaluation. Evaluation hinders coaching by creating a “one-up, one-down” dynamic. Most people have enough trouble asking for help in our culture without adding this burden. Stay away from comparative words such as good, better, worse, and bad. When you think the other person is headed down a rat hole, ask questions about risks and impacts rather than criticizing. Then help generate new ideas. Offer encouragement to let people know they are moving in the right direction.

When you can answer “Yes” to these questions, you’re ready to make contact.  And then you  can start to coach.

Should a manager know a language? Yes. One that enables communication with people.

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

Dealing with “Difficult” Co-workers

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.

4 Tips for Getting Your Ideas Accepted

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.