….. It’s Time for the Annual Performance Review

Vague statements and labels, one-sided evaluations, surprises, and secondhand complaints are just the sorts of things that can make a person want to run away screaming from an annual performance evaluation–probably not the best career move. Here are some tips for dealing with these situations in a calm and collected manner.

***

It’s that time again: the ritual of yearly appraisals and performance reviews. If you’ve followed my writing, you know what I think of yearly appraisals and performance reviews. And, you know that the data is on my side.

Still, the vast majority of companies still mandate some form of annual review with ratings, rankings, and bell curves. Except for people who receive top ratings, these reviews can be discouraging, demotivating, and soul-destroying. But, refusing to participate is a career-limiting move.

Four of the most destructive dynamics in reviews involve vague feedback and labels, one-sided assessments, surprises, and second-hand complaints. I hope that your review doesn’t go down that road. But, in case it does, here are strategies you can use to hold on to your dignity and obtain some useful information.

Vague Statements and Labels

Several years ago at about this time of year, I was talking to a group about feedback. One woman shared that she had just had her annual review and received a below-average rating because, her boss said, she was “too nice.”

I’m sorry, but that isn’t useful feedback; it’s a label. There was no way for the receiver to act on that label, other than to start being mean. If your boss uses a label to summarize some aspect of your performance, ask for examples. But, do so carefully, so that your boss doesn’t infer that you are challenging his assessment.

Start by creating an opening by saying something such as, “I’d really like to learn more about that perception, so that I can decide what changes will be most effective in this area. Can we set up a time to discuss specific examples?”

If your boss says no, you’ve got bigger problems than a useless label. Fortunately, it’s unlikely he will respond that way. It’s more likely that your boss won’t have those examples at his finger tips and may need time to think back over the situations that led to his conclusion. Pressing him during the review may make him feel defensive and lead him to label you as resistant–downward spiral, here we come!

When you do have the opportunity for further exploration, ask for recent examples. You need enough information to allow you to recognize and remember the situation. Once you have data that you both agree on, ask to understand how your boss sees your actions affecting your ability to do your job. For example, the too-nice lady might have asked, “How do you see my style getting in my way?” or “How did my style affect my credibility or ability to do my job in the situation we’re talking about?”

Part of everyone’s job growth is developing a greater repertoire of options for action, so ask for some coaching while acknowledging the data. “Yes, I did do that. At the time, I didn’t pause to consider other options. Will you help me think through some other alternatives that would have been more effective?”

One-sided Evaluations

If your boss makes an assessment that you feel doesn’t cover all the facts of the situation, add more information.

Excuses don’t sway most bosses. But, when there are circumstances beyond your control that affect your ability to finish assignments, your boss should take them into account (and work to correct the situation so you can succeed).

It’s almost never a good strategy to argue with the ref, so start by acknowledging what is accurate in your boss’s assessment. You might say something such as, “I can see how that’s a problem, and I’m not making excuses. I would like to share some more information about how that situation came about.”

Share additional information in as neutral a way as you can, and avoid blaming other people. After you’ve laid out the data, own what you can about the situation. Maybe you didn’t raise the red flag to indicate there was a problem early enough. Maybe you didn’t consider more than one option. Whatever it is, if you can own your part of the situation, your boss will see that you aren’t trying to shift the blame.

Then, move to problem solving by making an opening such as, “I would like to discuss how to handle the situation should it arise again.”

Surprises

One of the worst things a manager can do in an annual review is spring a surprise on you. But, sadly, some managers wait until the end of the year to tell people about a problem that’s festered for months.

If this happens to you, acknowledge your manager’s point of view and the importance he puts on the situation. You won’t be able to bring your best thinking to the situation when you are caught off guard. Ask for a follow-up meeting within the next week, so that it’s clear you aren’t trying to brush off the concern.

Secondhand Complaints

Bearing secondhand feedback is a sure way to erode trust. But, some so-called performance-management systems rely on it, and some managers fall into the trap.

Vague or puzzling secondhand feedback presents a problem similar to vague labels–you don’t have enough information to make a choice about what to change. Use a similar opening: “I’d like to learn more about that perception. Can you arrange for me to have a follow-up conversation with the person who gave that feedback?”

If that fails, ask if your boss shares the assessment from the anonymous source, and seek clarification from him.

If the secondhand feedback is a complaint about the way you do your job, ask your boss to arrange a meeting so that you can repair the working relationship.

Most people are open to feedback when they believe that the source is reliable, the receiver trusts the giver’s intentions, the receiver has a chance to clarify, and the process–both how the feedback is developed and how it’s delivered–is fair.

Too many annual reviews violate some or all of these principles, but if you use the strategies in this column, you can restore some of the balance and gain helpful information.

I’ve seen a renewed cry for leaders in organizations lately. Too often in these discussions, the definition of “leadership” boils down to a role where one individual creates a vision for others to follow. That’s not enough. We need more leadership, not just more anointed or appointed leaders.

“Leadership” is most potent when it’s a verb, not a noun. Leadership is taking actions that will help a group create a product, achieve their charter, grow in capability, solve problems, or improve results.

Looked at this way, we can create organizations that are full of leadership, not just individuals in leadership roles. And, sometimes, the most potent leadership action is the quiet act of choosing to follow. I call that being an active follower. Here are three ways to be an active follower on your group or team.

Step Back and Let Someone Else Step Forward

When one person on the team is the most skilled, it’s easy for the rest of the group to over rely on that person. Overreliance on one person poses a risk. On the operational level, there’s the truck factor: If the most-skilled or sole skilled individual leaves the job for whatever reason (and we hope it’s not because he is hit by the proverbial truck), the team won’t be able to function. No one will be ready to step in. In cases of extreme overreliance, the rest of the group won’t be aware of all the work that person was doing. It might take weeks before someone else can identify and pick up the pieces.

There’s also a long-term risk to team health. When person takes the lead, others don’t have the opportunity to learn and develop their own capabilities. If there’s no place to grow, people will check out and leave—or, worse, check out and stay.

Break Gridlock by Deferring to Someone Else’s Idea

When too many people want to be “the leader,” the result often isn’t action but a complete lack of forward movement. If no one is willing to step back and declare “I don’t have to have my way; let’s try your way this time,” the result is gridlock. An active follower seeing gridlock will choose to follow someone else’s lead for the good of the team.

Take a Supporting Role

There’s a reason that the Oscars have an award for best supporting actor. Without the supporting actor, the work of the lead falls flat. Many jobs demand the work of two people, but it’s not equal in every case. An active follower is willing to take that supporting role and let someone else take the lead. You may not get the credit this time, but chances are that if you’re willing to support someone else today, she’ll be willing to take the supporting role another day.

Back up a team mate when he chooses a difficult-to-implement story–or one that’s at the edge of his technical skills. Pair program with him, but let him drive. Offer informal peer review, offer feedback, or coach.

Let a less-senior member of the team make an important presentation. Play a supporting role by offering feedback on a draft, listening to a practice run, and sharing tips and experience that will help the other person succeed.

When only one person leads, the rest of the team members are turned into passive followers. Unlike active followers, who make a choice to allow someone else to lead in a particular instance, passive followers always hang back. Passive followers fall into the habit of depending on others, whether it’s keeping track of time, coming up with ideas, or galvanizing the group into action. Passive followers wait for someone else to step up, not out of an intention to achieve results, but out of habit or a sense of disempowerment.

Over time, the de facto leader may resent being the only one who attends to time or urges action. When only one person comes up with ideas, the team is missing out on a rich mix of ideas to choose from and may be missing good options. Other team members don’t exercise their own creativity, and the team as a whole misses out on their talents. Some people prefer to let others take the lead and the credit (and also the blame). But, most people want at least a slice of the glory. When they’re always in the background, they don’t get that and eventually disengage. They may even undercut the star who won’t move off center stage so they can get their own moments of fame.

Productive teams count on leadership throughout the team and know that each can lead at different times. Likewise, they expect that, at some point, each will follow another’s lead all in the interests of the team and team results.

When you consider your team or group, which sort of followership do you observe? How is that serving your team? What are other ways to be an active follower? Post your comments.

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

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

“Part-timers just don’t seem to fit in with the team,” a manager complained recently. “I do everything I can to impress on them the importance of teamwork and team spirit, but they just don’t gel with the team. What can I do to motivate these people to fit in?”

“These people just aren’t accountable,” another manager declared, referring to individuals who were assigned to four or five projects at a time. “I need people who will be accountable.”

Here’s the news nobody wants to hear:

The problem is not with the part-time people; it’s with the part-time assignment.

When people are assigned part-time to teams they face several hurdles that hinder their ability to contribute. The hurdles are structural, not personal.

Priority

When a person is assigned to more than one team, she’ll gage priority by the proportion of her time that’s allocated to each project. One tester I know was assigned 90% to developing manual test cases and 10% of her time to creating a “critically important” automated test harness. No matter what words her manager said about the importance the test harness, the fact that she was directed to spend only 10% of her time on it communicated a different message.

Furthermore, when she attended meetings or working session with the automation team, she spent most of the time catching up on what had transpired since her last sliver of time with the team. The arrangement wasn’t satisfying for her, and frustrated the automation team. Soon, she stopped working on test automation at all.

Ambiguity

Many people will opt to spend their time on work that has clear-cut outcomes over work that’s ambiguous. The more clarity around the part-timer’s contribution, the more productive the situation will be for everyone. When the assignment isn’t clear–or the relationships between the part-timer and the team isn’t clear, it’s harder for the part-timer to contribute effectively.

Team Cohesiveness

If the full-time team is cohesive, the part-timer may not be able to fit in. Gelled teams develop their own subcultures. They may have unspoken rules of engagement, communication patterns, and established relationships that make it difficult for someone who isn’t full time to fit. Over time a part-timer may acculturate, though the process will be slower than it would be for a full-time team member.

Missing Context

When someone works on a team part time, he is by definition missing part of the context of the team. While the part-timer is off doing something else, the full-time team makes decisions, solves problems, and exchanges information. While the full-time team may document and transmit major events, there are numerous small decisions and communication events that may not seem important enough to pass along but still affect the way the work is done. The adage “You never step in the same river twice” fits this situation. Each time the part-timer re-enters the team, the team has inevitably moved on from the last time the part-timer participated.

Design Before You Assign

So, what can managers and team members do to improve the situation? First look at the work and how the part-timer needs to contribute. Design based on the needs of the work before you assign the worker to the team part-time. As a contributor, if you find yourself assigned, negotiate the dynamic of the relationship so that you–and the team–can be successful.

Here are some of the questions to ask about the work:

Is the contribution time-limited, meaning that part-timers skills are needed for several days, but not for the duration of the project?

Maybe the person only needs to contribute at some critical point. Perhaps he is only needed for one or two iterations, when the team is working on a particular feature. Consider contracting for the person to focus full attention for those periods of time.

Can the contribution be batched so the part-timer interacts with the team for a day or two a week?

Blocking out a day or two a week to work with the team is more effective than having the part-timer spend an hour here and an hour there with the team. This may require more clarity and coordination from the full-time team, but it will make better use of everyone’s time in the long run.

Is the part-timer needed for hands-on work, or can he act as a reviewer, consultant, or coach to members of the full-time team?

Sometimes the full-time team needs to use a certain skill a little bit each day or week, but needs the skill over all long period of time. In this situation, it probably makes sense to develop the skill on the team and have the part-timer act as an expert coach or reviewer until the full-time team members are self-sufficient.

A person can act as a resource to a full-time team without being a member of the team. The team can contract for deliverables, consulting, review, or time. After you understand the nature of the work and the contribution needed, work with the full-time team and the person whose skills are needed to develop explicit agreements. Don’t rely on happenstance and assumptions. Reach agreement on how the full-time team and part-timer will work together, how the part-timer will contribute, and how the full-time team will keep the part-timer in the loop. Don’t expect he’ll gel completely as a member of the team–because he won’t.

Sometimes I see groups in which almost everyone is part time. Sometimes a group working together part time will gel, usually when they have a long, shared history. Don’t expect groups made up entirely (or mostly) of part-timers to gel as a team without time and attention to creating a cohesive whole. And as long as the group is accomplishing its goal and managing the interdependencies between tasks, that’s OK.

It may look simple on paper to say a team needs a specialized skill X amount of the time, but by analyzing the nature of the work and being explicit about part-time arrangements, you will help the team and the part-timer work together more productively.

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.

A recent phone call reminded me of this article that I wrote in 2004. The story is real, the names are not. It’s a story that is all too common.

***

Not too long ago, I had lunch with my friend Sarah. I hadn’t seen her in a while, so I was surprised when she mentioned that she was leaving the company she has been with for almost ten years. The developers, testers, and other managers at this company respect her, and she loves what she does. Her workplace sounds ideal. So, why is Sarah leaving?

Sarah isn’t leaving for a more prestigious position or a higher salary; her boss is driving her out the door. Sarah’s manager blows up when things don’t go the way he wants them to, and she has had enough. “I’m tired of being screamed at,” Sarah said. “Life is too short.”

Sarah’s not the only one who has had to deal with a hostile boss. According to an article in American Way, “42% of US workers reported incidents of yelling and verbal abuse in their workplace.” While some people may feel they have to accept abusive behavior from bosses in order to keep their job, I agree with Sarah: Life is too short.

The Costs of Yelling and Verbal Abuse

Some people I talk to dismiss my concerns about workplace abuse. They tell me I’m too sensitive. “It’s just Frank,” they say. “He blows up, and then it blows over. Nobody takes it seriously.” But there are costs.

People who work for abusive managers often have stress-related problems and illnesses. They miss work due to symptoms, and they are less productive when they are at work. Their energy isn’t going into building software; it’s going into dealing with the emotional fallout of their manager’s behavior.

Yellers also drive attrition – turnover is higher, and it’s harder to entice internal candidates to work for a manager who has a reputation for outbursts and abuse. Many people would rather walk out the door than work for an abusive boss. The people who do stay may feel trapped by the job market or their own beaten-down self-esteem. People who feel trapped or beaten-down are not productive workers.

In my experience, abusive managers fall into three categories. How you handle the situation depends on which kind of screamer you’re up against.

Unaware

Strange as it may seem, I’ve actually met managers who were not even aware they were yelling. Some people come from families where yelling is part of their “normal” communication. They see yelling as expressive, not aggressive. They may not be aware of the effect their yelling has on other people.

Crack-the-Whip

Some managers believe that people are basically lazy and will not work without coercion and threats of punishment. This view is called “Theory X” management. It doesn’t work. I don’t hear many developers or testers say, “I work better when I’m a little afraid. If my boss didn’t threaten me, I’d never get a thing done!” But some managers believe that this is the case. People who hold this view see yelling and threats as appropriate management action.

Sometimes yelling works in the short-term, as people will do what the yeller wants to get him to stop yelling, or keep him for yelling again.  This reinforces the yeller’s mental model of management.  He seldom looks at the other effects of his management methods: stress, illness, information hiding, lack of engagement.

Out-of-Control

Some people are not able to manage their emotions and responses. These are the bosses that react disproportionately, blow up, vent, swear (we’re not talking the occasional “Oh, %#@!”),and generally fly off the handle.

What You Can Do

If your manager is the Out-of-Control variety, you can try solve the problem by working with HR.

When your manager becomes abusive, stand up, state that you will not tolerate verbal abuse, and leave the room. Go to HR and file a formal complaint. Keep in mind that HR’s job is to protect the company’s interests, not yours. In my experience, the higher in the management chain the abuser is, the less likely HR will take action. The company has probably tacitly accepted his behavior for years, but when there are multiple complaints on file, HR may decide that it is in the company’s best interest to deal with the abuser. If there are witnesses to the abuse, talk to them about corroborating your account. And be prepared for an tense and uncomfortable patch while the process works out.

You may be able to manage this situation by making your own power move. Bring a recorder to your next meeting. Don’t hide it. (That could lead to some other problems.) Be quite open, put the recorder on the desk and say “I’m going to record our conversation, so I don’t have to rely on my memory to recall all the important things you have to say.” Start the recorder. This reduces the chance that your manager will yell. And if she does, it’s on tape.

Rarely, I hear from someone who has found a way to survive an abusive boss.  They manage to cope and let it roll off their backs.  The fact that you can’t let it roll off yours doesn’t mean you are too sensitive, thin-skinned, or weak.

Threats of physical harm, retribution, and personal attacks are well over the line. Verbal abuse is never acceptable.

People who cannot manage themselves should not manage others.

No ifs, ands, or buts. No excuses. End of discussion.

Sometimes the HR department isn’t willing to take any action. Consider what you are willing to live with, and start examining your options for another position, in or out of the company, and make an exit. If you do leave, state your reasons for leaving in the exit interview.

There’s more hope for managers who aren’t out of control. Start with the most generous interpretation and the smallest intervention.

Assume your manager isn’t aware that he’s yelling. Comment on the yelling and the effect it’s having on you. In a calm voice say, “What you have to say is important to me, but I can’t hear you when you’re yelling.” This may be enough to jolt the yeller into awareness.

A manager who continues to yell may be a Theory X Manager. You probably won’t change his mind, but you might change his behavior. State again that it’s important that you hear what he has to say, but right now you can’t because of his yelling. State that you will reschedule the meeting for later in the day, and then leave the room. When you meet again, tell him the effect that his yelling has on you. Request that meetings and conversations take place in a normal tone of voice. If that fails, consider bringing a recorder to meetings, and contact HR.

Employees have a right to be treated with respect and dignity in the workplace. Many mega-decibel managers cease and desist when faced with resistance. When you encounter an abusive manager, hold on to your self-esteem, take action, and decide whether the paycheck is worth the price.

***

Reader Jerry Conklin sent this response when the article was originally published (posted with permission):

The manager who uses his position to bully employees is pathetic and worse than useless. The negative effect of such people is powerful. This kind of bullying behavior has produces human misery and project failure. Such people need to be weeded out of management.

Like all bullies, the bullying manager hates himself. Since he cannot face that fact, he uses whatever power he has to dump that hate on anyone perceived as weak and vulnerable. At bottom, he is a cringing coward and can generally be seen to grovel before his superiors. He is drven by fear.

The main responsibility of any manager is to remove obstacles to productivity not to create them. The fulfillment of such a responsibility requires character, integrity and courage. The bullying manager is often tolerated because she has high technical qualifications. When someone has shown herself to have the cited leadership traits, then we can talk about technical capability. The bully is a weakling who is, by definition, devoid of the character traits necessary to lead people.

Well said, Jerry.

Also check out Bob Sutton’s The No Asshole Rule.

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

I recently worked with a team that was struggling. One of the team members, Tad, wasn’t playing by the rules the team had established. When the team formed, members agreed that each day they’d have a fifteen-minute stand-up meeting to report on progress. The team members agreed that they’d chunk their work into tasks that were a day or two long, knowing that would help them stay on track and make progress visible.

But all was not well. When the other team members picked a story off the task wall, they’d break it down into tasks and post them back on the wall. When Tad picked a story, the card disappeared from the wall. At the stand up meeting, his reports were vague. “I’m coding,” he’d say.

After a couple of rounds of such murky reports, two team members, Sally and Will, sat down with Tad.

“What’s up?” Will asked. “Do you need some help?”

“No,” Tad replied. “I’m working on it.”

“But we don’t know what progress you’re making,” Sally said.

“I’m working on it,” Tad replied, staring at the notebook in his lap.

“Tad,” Will implored. “You agreed to report tangible progress every day. We all did.”

Tad closed his notebook. “I’m working on it. Now leave me alone so I can keep working on it.”

The team’s agile coach tried, too. After a vague report in the next stand-up, the coach probed for more information.

“What exactly are you working on, Tad?” he asked.

“The reset feature,” Tad replied.

“When will you finish it?” the coach asked.

“I’ll be done when I’m done,” Tad replied. “I’m working on it.”

“That’s not good enough,” the coach said, laying down the law. “When you don’t report demonstrable progress, it hurts the team. We don’t know if we’re on track or not. We can’t give our customer an accurate read on meeting our iteration goal.”

“I’m working on it,” Tad replied.

The coach tried benching Tad, telling him he couldn’t take any more tasks. Tad took them anyway, working at odd times, checking out code, and keeping a local copy on his machine.

After weeks of Tad’s odd behavior, the coach approached the development manager. “We’ve tried everything we can think of,” the coach said. “We need you to step in and help us get Tad on track.”

“You are self-organizing,” the manager demurred. “You need to figure out how to deal with team members.”

And that was that.

The team tried everything it could think of to induce Tad to report on his work, finish his work, and see his contribution—or lack thereof—to the team’s iteration goals. And as their manager continued with his “hands off” attitude, team members’ morale plummeted. It felt like their manager had abandoned them. He had.

Fortunately for this team, the hands-off manager left the organization. The new manager recognized the team was struggling and handled the performance issue.

Managers of self-organizing teams need to discern when it’s time to step in and when to step back, allowing the team to solve the problem on its own. How do you know when a light touch is called for and when action is needed? Ask:

• Does the team have the knowledge to solve this problem?
• Does the team have the experience to solve this problem?
• Does the team have the will to solve this problem?
• Does the team have the courage to solve this problem?

If so, give the team some time to work out the issue. If you sense team members are stuck, coach them with open-ended questions to recognize the resources they already have to address the issue.

• Is this a new area of responsibility for the team?

If the team is taking on a new responsibility—one that’s been yours in the past—offer a process to help the team make the decision or solve the problem. Be wary of stepping in. If it looks like you are trying to take the decision back or influence the team, your credibility is lost.

• What are the consequences of failure?

It’s been said we learn more from failure than from success. So do you really want to deprive the team of a learning opportunity? Consider the consequences of letting the team learn from its mistakes. Most projects can survive a missed iteration goal. Most projects can survive going a short way down the wrong technical path.

This article originally appeared as a sidebar to an article in Better Software magazine.

There is much more to empowering a team than simply stating “You’re empowered.” Consider the three Ws of empowerment: “what,” “when,” and “why” when creating boundaries that define which decisions are the team’s and which need management approval.

“I want you to be empowered,” Bob told his team at the team meeting. But several weeks later, Bob expressed his disappointment to his colleague Sue. “My team members have a victim mentality,” he said. “They’re too passive. They wait for the team lead to tell them what to do. And the team lead checks everything with me. I want these people to show some initiative!”
Sue cocked her head. “What have you seen that makes you say that?”

“You remember the middleware bug we had last month?”

Sue nodded.

“Well, the team came up with a solution that was all wrong,” Bob said. “It’s a good thing I caught it before they forged ahead. If I hadn’t wandered into the team room and seen the diagrams on the whiteboard, I never would have known about it.”

Sue raised an eyebrow.

“I called the team into a huddle and explained why that idea wouldn’t work. Then I had a meeting with the team lead. I really dressed him down. He should be leading them–not letting them make stupid mistakes.”

Sue’s other eyebrow went up.

“I want the team to dig in and solve problems,” Bob said. “So last week at the team meeting, I asked everyone to offer at least one idea about how we can meet the deadline for our next release without dropping any features.

“One of the team members actually said it was impossible. Another one suggested we could implement a partial solution that included some manual work in the customer care department. When I told her that she hadn’t examined all the issues with her approach, she backed down! How can we come up with creative solutions if we can’t argue our ideas?

“Now they just sit there. It’s like they are afraid to make any decisions at all.”

Sue held up her hand to stop him.

“Bob,” Sue said, as gently as she could, “do you think you might be sending mixed messages?”

Bob looked puzzled. “What do you mean?”

“I wonder how your team members felt when you overrode their technical design.”

“I saved them from a big mistake,” Bob said. “I’d think they’d be grateful.”

Sue shrugged. “Maybe. And I bet they also felt like you told them the decision was theirs to make, and when they didn’t do what you wanted, you took the decision back.”

“But what they were planning was wrong!” Bob exclaimed.

Sue nodded. “No, it wouldn’t have been very efficient. But it might have been more effective in helping team members learn how to think through the issues together. They are new to this and still need to learn through experience.

“Do you remember when you were learning how to drive?” Sue asked.

“Sure. My dad took me to a big, open parking lot and gave me instructions: Ease up on the clutch, press the gas pedal gently. After I mastered the clutch, he took me out on a quiet road.”

“And after you received your license, did he let you drive anywhere, anytime, with no restrictions?” Sue asked.

“Of course not. At first I was allowed to drive to school alone, and later I was allowed to drive after dark. It was months before my dad let me drive with my friends in the car. At the time I hated it, but looking back, he was helping me build my driving skills before he turned me loose.”

“Exactly,” Sue said. “And that’s what you didn’t do with your team. In essence you told your team members they could drive anywhere. Then, at the first small mistake, you pulled their license and showed you didn’t trust them.”

“Oh,” Bob said. “I never thought about it that way. You mean I’ve actually brought about exactly what I didn’t want? I’m making the team more passive instead of more empowered?”

“The key to empowerment is to tell team members what the boundaries are before they cross one by accident,” Sue said.

“Otherwise, they’ll feel jerked around,” Bob said.

Sue nodded. “If you really want to empower your team members, you need to consider their skills and how much you trust them. Find the boundaries where you feel comfortable with the risks and give them free reign within that area. That’s probably not the empty parking lot where your dad started your driving lessons, and it’s probably not the freeway during rush hour, either.”

“I have to work harder at this empowerment thing than I thought,” Bob said.

“There’s more to it than declaring, ‘You’re empowered,’” Sue agreed. “I think about the three Ws of empowerment: what, when, and why.

“What delineates the decisions and the standards that apply when making those decisions.

“When defines boundary conditions. For example, my test team can make decisions about test approaches where there isn’t an existing test bed and when the tools team members need are open source or already available within the company. If they want to try a testing approach that requires a new tool or replaces a functioning test framework, then they come to me with a recommendation.

“Why sets the context. I find that when people see how their decisions fit into the value stream and affect customers and the bottom line, they make better decisions.”

“I can’t just go in and tell them what the boundaries are now,” Bob said. “They won’t believe me.”

“You’re right, Bob. First, you need to rebuild trust, and the best way I know to start that process is to admit you’ve made a mistake.”

Bob gave Sue a pained look.

The very next day, Bob called a team meeting. “I’ve made a big mistake,” he said. “I asked you to make decisions and offer ideas, and then I stepped in and took over. I was wrong to do that. I was worried about looking bad, and in the end, my actions made us all look bad.”

Several team members looked down at the table. The team lead squirmed in his chair.

“Are you willing to try again?” Bob asked. “I have some ideas on how we can all be clear on which decisions are yours and which decisions are mine.”

Tentatively, the team agreed. Together, Bob and his team created a grid that listed decisions and boundaries.

Bob realized that he wasn’t ready to let go of every decision. He specified some areas where he would make the decision based on the team members’ input and some cases where he wanted to review their decision before they implemented it. He was surprised to see that team members were grateful that they wouldn’t have to carry the weight of all the decisions.

Bob asked the team to remind him if he started stepping over the boundaries he’d set.

It took some time for the team to trust him again, but eventually the team saw that Bob really had turned over a new leaf. Bob realized that the team was gaining skill and perspective in making decisions. They weren’t always the decisions Bob would have made, but he had to admit the team’s ideas and choices worked out reasonably well–most of the time. And when the decisions didn’t work out as hoped, the entire team held a decision retrospective to learn from its mistakes.

Several months later, Bob went out to lunch with Sue. “The team is making better decisions and seems to have more ownership of its work,” he said. “Once we agreed on the boundaries, the team stepped up to the plate. Empowerment really can work,” Bob said. “But it works best when the what, when, and why are clear to everyone involved.”

This article originally appeared in Better Software magazine.

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.

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, in which 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, most server installs in their company require a core set of skills.

Josh, Julie, and their coworkers have a connection. They share professional skills, hold each other in high regard, and let each other know what they are working on. They 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 report to the same manager and run test labs for two different products. 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 it’s 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 a different consumer group. 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 one hundred people. Their manager calls it a project team, but they wouldn’t recognize each other if they passed in the hall. Their project is too big to truly be a team, though there are subgroups within the larger project that function as collaborative teams. Groups larger than twelve or so almost always break down in to subgroups–which may or may not be teams.

Collaboration

Abby, Alec, and their four teammates 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 also share mutual accountability. 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?
2. 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 a broad range of skills?
3. Analyze the work. Does it consist mainly of projects that one person can complete from start to end (e.g., individual products)?  Or does the work of several people need to integrate to create a coherent whole (e.g., 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 workgroups that aren’t teams. If you answered yes to the first question in each pair, the work is probably best suited for a workgroup. Your management job is to determine which will best meet the needs of the work. Then, create the environment that best suites the needs of the group or team.

Building a team doesn’t happen by accident, and your job as a manager of a team will be different from the manager of a workgroup.  More on that to come.

This column originally appeared on stickyminds.com.