Every team needs leadership, even self-organizing teams.

When I make this statement, some people assume I mean that every team needs a designated leader.  I can’t blame them, most people are accustomed to thinking of leadership residing in a role or a charismatic individual—a “born” leader.

On self-organizing teams, there isn’t one leader.  Agile teams may have a coach; however, the coaches job is to help the team see where they need to improve and help them learn specific skills.  The coach may lead at times, but the coach isn’t the leader.  In fact, if the team looks at the coach as the leader, they’re in trouble. Holding up one person as leader will hamper team development.

Before we go any further, let’s define leadership: leadership is creating an environment where everyone can contribute to solve the problem at hand.

On teams that function well, every member of the team leads.  Each person takes responsibility for helping the team move forward.

But acting at random or on gut feel isn’t enough. Empowering leaders can be more effective when they work out of a model that helps them make sense of what they see happening on the team.

One such model is the MOIJ model articulated by Jerry Weinberg.

1. Every team needs motivation—and I don’t mean pep talks, cheerleading and extrinsic rewards.  Teams do best when they are intrinsically motivated, when they derive satisfaction from the work and team relationships.

Team members lead when they work for appropriate harmony and consensus—and engage in constructive conflict.  Leaders pay attention to how other team members are participating, so that everyone can use their talents and creativity. Leaders pay attention to how the whole team is working together, and building a team culture that supports achievement and good working relationships.

When only one person on the team pays attention to motivation, the team doesn’t learn how to create the environment for their own success.

2. Teams need organization.  Organization is more than the boxes on an org chart.  Organization includes physical space, time, and structure.

Leaders make sure that the workspace supports the team with appropriate equipment and information. Teams need someone to lead by pay attention to commitments and the ticking clock.  They need to figure out how to allocate the work so that it gets done and there’s a balance between people expanding their skills and relying on experts who can do the work most quickly. Teams need structures that help them work effectively together, for example, working agreements or configuration management.

When only one person pays attention to organization, he comes across as a nag. After a while, people ignore nags.

3. Teams need information.  They need to see a vision, generate ideas, bring in data and analyze and connect the dots.

Along with a flow of ideas, sometimes, a teams need a Devils Advocate.  A Devil’s Advocate challenges habitual thinking, checks solutions against foundational principles and values.  Without a Devil’s Advocate, teams can slip into group think, or miss risks and weaknesses when they consider options. But like the nagging organizer, no one enjoys a habitual naysayer. When there’s only one Devil’s Advocate he’s likely to be marginalized.  Like all the other leadership activities, it’s important to spread this one around.

Team members also need to know when they have too many ideas, and it’s time to slow the flow. We usually don’t think of following as a leadership activity.  But I’ve seen teams where everyone wanted to have his or her way.  I’ve seen teams sidetracked when members keep throwing in new ideas each time they come close to a decision.  Those teams argue and debate endlessly and don’t make forward progress.  Knowing when to zip the lips and follow is leadership, too.

4. Finally, every team needs people who can recognize when they are stuck and need a jiggle.  My favorite jiggle is a paradoxical question: “How can we make the situation worse?” Simply commenting on the stuck-ness can sometimes shake a team out of their rut. Changing position—standing up if the team has been sitting–can jiggle the team into productive action, as well.

***

What happens when only one person on the team—whether a formal or informal leader—tries to do all the leadership?  I suppose there are the rare individuals who can do it all. But on most teams that aren’t sharing leadership, are missing some leadership ingredients.  When teams rely on one individual they flounder when the leader isn’t available.  Worse, they don’t develop their own capabilities and slide into dependency.

Leadership is about making sure the team is functioning well and creating an environment where everyone can do his or her best work.  And it takes a whole team of leaders to make a self-organizing team.

I was talking to my friend Penny the other day about a team she coaches.

There’s a really smart guy on the team. I’ll call him Bob. Most of the time Bob is an asset to the team. But when the team needs to decide on a technical solution under time pressure, he’s not.

“But Bob is a smart guy,” you may say. “How is it he’s not an asset? Won’t he have the best ideas?”

When it comes time to solve a technical problem, Bob is always first to offer his idea. Then, Bob dominates the conversation with a constant stream of words, leaving no opening for another to insert facts, ideas, points of view. When someone does find a voice and interrupts the torrent, Bob cuts him off, declaring “I’m not finished.”

When Bob does finish, and another team members asks a question, Bob implies that the other person doesn’t get it, and might be too stupid to see the brilliance of Bob’s idea.

When another team member proposes a different idea, Bob shreds it. He points out the flaws in the other person’s idea, while pointing to the strengths of his own idea.

When he does let others speak, it’s pretty clear that he isn’t listening to learn. Bob is figuring out how to score his next point.

I don’t believe Bob has bad intentions. I believe he wants to be helpful, and believes he is. Bob is helping the team in many ways, but he’s also hurting the team. Here’s how:

1. The team don’t have enough ideas. Due to Bob’s style, there is seldom more than one idea (Bob’s) that receives serious consideration. That’s not enough. Even if Bob is smart, so are the other people on the team. But Bob is the most extraverted and the best at argument and debate. That’s not the same as having the best ideas.

2. Over time, Bob’s style will wear down the other team members. It’s really not terribly satisfying to be browbeaten, or have all your ideas shot down. At some point, other people will stop offering ideas, and acquiesce rather than endure another argument with Bob.

3. As long as Bob’s ideas prevail, others don’t have a chance to develop their ideas.They are deprived the opportunity to learn, think about problems and risks, and increase their capability. Over the long run, that’s bad for the individuals involved, bad for the team, bad for the organization.

Penny has given Bob feedback on the effects of his behavior. It’s made some impact, but when there’s pressure to come up with a solution, Bob–as most people do–falls back on his default behavior. Chances are, Penny won’t get Bob to change that. Bob’s behavior is driven by his natural tendencies, and years of cultural exposure that taught him that competition and argument are the way to find the best ideas.

However, Penny can change the process so that the team has sufficient ideas to consider, and that credible ideas receive due consideration.

Here’s how:

Separate generating ideas, explaining ideas, exploring ideas, and evaluating ideas. As it is now, all of these are mashed together (and done mostly by Bob).

Equalize participation. From what Penny has told me, I suspect Bob is a strong extravert and the other team members are introverts. That means that Bob is very comfortable thinking out loud, and the other team members need a bit of time to organize their thoughts. Before they have time to do that, Bob is on a roll. One way make room for more participation is to start the process with a few minutes of silent brainstorming. Then, ask each person explain (orally or through sketching) the essentials of his or her best idea.

Apply the Rule of Three. If you don’t have at least three ideas, you don’t have enough ideas, and you probably don’t understand the problem. You may end up with deciding the first idea that came up is the best one…but you may not, or you may refine the first idea based on further discussion.

Test for agreement. Some teams get carried away with voting. But when a decisions are routinely highjacked by one individual, it can help to test for agreement using a gradient of agreement or fist of five.

Establish a small set of tests for technical solutions. In this team, some of the tests that make sense might be:

The solution …

• is the simplest thing that can work.
• doesn’t add to technical debt.
• can be implemented in the timeframe required by service level agreements.

Bob may have the best ideas on the team. We don’t really know if that’s the case. No one else’s ideas are fully considered. We do know he doesn’t have a perfect record. Some of his fixes don’t work the first time. Some of his fixes break something else.  If the team had a process to consider and refine ideas, that might not happen as much.

It may sound like it will take more time to separate generating ideas from explaining, exploring, and evaluating them. It may seem like a lot of effort to find more than one idea and test the ideas for soundness and test the level of support for a given idea.

But in years of observing teams, I find that slowing down and separating the steps of the choosing a solution helps the team speed up. A mashup process forced by a dominant individual may appear to save time in the very short-term. That’s seldom true if you account for all the time costs and other effects incurred.

Bob Sutton recently posted a piece on Team Guidelines.  The guidelines–all Mom and Apple Pie–where handed down by a new boss for the team to follow.

The list starts with “Show Respect.”

I find it ironic that the new boss is advocating treating people with respect. Arriving with a set of rules for other adults you’ve just met doesn’t feel respectful to me.  And I’m pretty sure that imposing rules won’t have the desired effect.  Modeling behavior, engaging the group in discussion about patterns of interaction, yes. Coming in with the rules like a kindergarten teacher–not so much.

But the post got me thinking about how teams develop norms.

Teams develop norms whether they are paying attention to norms or not.

Teams build up a pattern of interaction and implicit understandings of what people can do, should do, should not do, must and must not do in various situations.  It’s part of being in group of humans.  Often, the patterns form without much thinking about the implications.  Norms form around where people sit in meetings, or acceptable late arrival, and whether someone should bring cookies on Tuesdays.

Effective teams have a shared approach to work (though not a rigid process).  They explicitly work out agreements about “How we do things.” The team’s agreements evolve to address both challenges and aspirations.  Teams find a way to talk about what matters, and decided how they’ll act out those priorities day to day.

When a team develops agreements, it helps to know what they are trying to accomplish, because different sorts of agreements serve different purposes.

Values

…are statements of what is important.  Value may guide behavior, but are not, in themselves, actionable. Values often represent the espoused beliefs in the organization–which don’t always match the values in action.

Example:   Balance work and life. (But pay attention to what really happens.)

Group Norms

…are informal, often implicit standards of behavior that develop from the interactions of the group.

Example: (By observing the group, we can deduces that…) It’s acceptable to be late for meetings.

Ground Rules

…are statements of expected behavior for specific times, places, and situations.

Example: (Posted in the meeting room) Don’t interrupt each other.

Working Agreements

…are protocols that the group develops and agrees to follow. The protocols aim to forge commitment and a shared approach that will help the team meet their goal.

Example: Code is *done* when all programmer and acceptances tests pass, the customer accepts the story, and the code is checked into the development branch.

Simple Rules

…are short statements that guide interactions and  decision making within the group and across other groups within the organization.  Simple Rules can generalize across many situations, and make values actionable. Simple Rules aim at brining coherence across the organization.

Example: Use every failure as an opportunity to learn.

All of these represent social contracts between group members. Effective teams use all of these tools to create a pattern of interaction and results that enhance their ability to reach goals and improve quality of both work life and results.

Reaching collaboration and high performance is possible without explicit agreements.  It’s much easier (and more likely) for a team to reach high performance when they pay attention to the pattern they want to create and use these tools to help shape the pattern.

Values, ground rules, working agreements, and simple rules each serve a different purpose. Some teams find it useful to both simple rules (which help make values actionable) and working agreements (which address specific practices).

For both simple rules and working agreements, the list should be…

• focused on amplifying desired patterns of behavior
• aimed at helping the team achieve their task and team-work goals
• generalizable
• minimum specifications
• short: no more than seven items on each list (fewer than seven is even better)

Many teams I meet have some variety of agreements about how to act. The groups that do best have a short list, and refresh it as needed.  I visited one group that had a list of 20 team rules.  That’s too many for anyone to remember. And, such a long list is indicative of a different issue–probably that the group members hadn’t developed common language around practices and had very different mental models of how software development works.

I don’t think every group needs to have a list of values, ground rules, group norms and simple rules. The point isn’t to explicitly govern all aspects of behavior.  I visited a group once that had a list of 20 ground rules. It’s always interesting to see how and whether team members hold the group and individuals to their espoused standards.  So look at the posted rules, and then observe how people really act.

“However they arise, such rules test a group’s own credibility. For example, if everyone agrees to make team meetings a top priority and then members fail to show up, it signals that the group may not be able to manage even the simplest of details, let alone conquer its performance challenges. The rules must be enforced. One team we know decided on total confidentiality to encourage open discussion. Early on a member violated the rule by talking to outsiders. When the rest of the team learned that the leader had gently, but firmly, reprimanded the offender, team discussions became even more open, free-wheeling, and, ultimately, creative.”

 

I recently set aside my analog wrist watch and started wearing a runners watch. It’s accurate to the second on the face, and to a 100th of a second on the split timer.

I’ve noticed that when I have a precise measure, sometimes I use it, even when precision isn’t necessary.  For example, when someone in a workshop asks me how much time is left in a simulation or exercise, they don’t need to know that there are 2 minutes and 27.15 seconds remaining.  “Two minutes” would be an adequate response.

But there are times when a bit more precision is helpful– like in the way we name the social units that perform work in organizations.  Take the term “team,” for example.

I hear the term used for any group of people who share almost any common characteristic.

In some organizations functional groups are referred to as “teams” even though the people in those groups don’t work on a common project and their work isn’t interdependent or aimed at creating a whole product.

Teams have these characteristics:

Teams….

• Share a compelling work goal, and that goal is well-understood by all members of the team. Some person(s)  in the organization eagerly await the product the team is producing–else there is no reason for the team. Without an external goals, a group may form a social unit, but they are not a team.

• Members are mutually accountable for achieving the external goal. Team members do focus on completing their work; but they know that completing individual tasks–by themselves–isn’t enough for success.  Success comes from achieving the overall goal.

• Are doing interdependent work that requires the skills of all to create a finished product.   Their skills are complementary and it is the combination of their skills that enables them to reach their goal.  It’s not like a ski team where everyone has the same skills, and the team result is the sum of individual scores.  On a team, the results aren’t additive, they’re integrative, generative, and collective.

• Have a shared approach (though not a rigid process).  Team members make agreements on how they will work together.  They choose methods that fit the work and the goal.  They need enough constraints on their process so that they can work creatively–avoiding both anarchy and stifling routine.

• Teams almost always have fewer than ten members. Some say five is the sweet spot.  When there are fewer than five members, there’s not much sense of teaminess.  When there are more than ten, the work is so big that it breaks on along natural lines…and so do the people, falling into sub-groups that act more like a team than the bigger unit.

• Have shared history/identity.  This implies that a group is not a team on it’s first day together.  It also implies that shaking up groups every few weeks or months ensures that you’ll never really achieve the surpassing results that cohesive teams are capable of.

But what about a group of 100 people focused on a common goal of creating a whole product?

At a local user group, there was discussion about such “teams.”

That stretches the definition of “team” too far. Teams are small enough that they can coordinate planning and the flow of information necessary for day-to-day work themselves. They may use task boards, build lights, and other mechanisms to help disseminate information and reduce the load on interactions between individuals.  But they seldom need a person whose job is coordinating efforts of individuals. They’re small enough that they don’t break down into sub-groups.

One of the participants in the discussion asked how teams that large made decisions quickly.  The person advocating large teams (100+ people) described  how the overall manager pulled together people and information and then /he/ made the decision.  That’s a perfectly reasonable way to handle decision-making when there are 100 people working towards a whole product in a commercial enterprise.

But if there’s an overall coordinating structure, it’s not a team.  Teams are small enough that  they don’t need additional coordinating structures and people in coordinating roles who are not working members of the team.  (They still need managers who provide support and create an enabling conditions.)

Some times it does require the coordinated effort of hundreds of people to create a whole product.  Within that collection of people there may be units of social organization that are teams.  There may be work groups and individual contributors.  And there are people whose role is the efficient coordination of communication, activity, and decision-making across the various sub-units within the overall structure.

Each of these units–work groups, real teams, conglomerations of workgroups and teams–are different social organizations and have different needs.  Each requires different support structures, boundaries, and infrastructure.

Calling such disparate arrangements by the same term causes confusion, inappropriate expectations, and mismatched actions.

So let’s have a little more precision, please.

“The absence of conflict is not harmony, it’s apathy .” Eisenhardt,  Kahwajy and Bourgeois

“(….or acquiescing, or avoiding).” Esther Derby

Conflict is inevitable at work. Sooner or later, people will disagree about what to test, how to implement a feature, what “done” means, or whether “always” means 100 per cent of the time or some thing else. If team members can’t muster the involvement for a disagreement, you’ve got problem. 

Conflict holds the possibility for building trust or tearing it down. How team members choose to approach conflict will affect the outcome, relationships, and ultimately the ability of the team to function.

Conflict often feels personal–but often it is not.

Structural Conflict

Systems and structures drive behavior, and in almost every organization structures create conflict.  Misaligned departmental goals, reward systems, emphasis on functional roles , and differing priorities can all engender conflict

But often people don’t recognize the structural source of the conflict. When the structure  behind the conflict isn’t visible people personalize the conflict.  I hear this when developers talk about how stupid the marketing people are or when testers complain that devs don’t really care about quality.

Communication Misfires and Mismatches

Once structure is ruled out, the most common source of conflict in groups stems from communications where language is misunderstood, mis-construed or data is missing.  These sorts of conflicts are usually easy to fix.

Many English words have precise meanings.  But there are plenty of common terms where definitions vary between professions or among people. When I worked in a mutual funds company the term share price was used to refer to the monetary value of an individual investment vehicle (a share of stock), and the monetary value of a share in an mutual fund.  If you didn’t know which area a person worked in, it was pretty confusing. Confusion can escalate to conflict when people don’t recognize that they are using one word with two (or more) definitions.

Entrenched Positions

Advocacy isn’t bad in and of itself. But when advocacy proceeds without inquiry, it can become a position conflict.  Position conflicts are often easy to recognize. Each person (or party) argues forcefully for a preferred solution without reference to the problem they are trying to solve.

When neither party is willing to explore the other option, examine assumptions, and  generate additional candidate solutions, advocacy turns into conflict.  Once people frame advocacy as win-lose, it’s hard to back down. Doing so might look weak, feel like giving in, or imply that one was*wrong.*  Most people will go to great lengths to avoid admitting they were wrong, especially when eating crow is part of the bargain.  Backing down from a strongly held position can feel like eating crow, especially when the other person crows over his victory.

At a recent workshop, a participant asked “Why wouldn’t you start by advocating your own idea?”  It’s an understandable question; in the US we grow up on in a system where the best argument (or at least the loudest one) wins, where competition is valued and zero-sum game thinking is the often the norm.

The first reason not to advocate is that when you advocate, you are not learning.  You’re defending and pressing your idea, not examining the problem and seeing different points of view. You aren’t learning about another possible solution or seeing improvements for your own.

Different Values

Arguing points of view and potential solutions is one thing; some times a conflict goes deeper and touches basic beliefs about what is valuable, true, and good.

This sort of conflict can look like a position focus conflict.  The difference is that each proposed solution seems as if it could solve the issue or be a reasonable approach. But either or both may leave out key elements of what the other party describes as “reality.”

Different Preferences and Styles

Differences in how people process information, make rational judgements, and plan their day can provide the fuel for conflicts.  So can differences in boundaries, social needs and styles, times-sense and ideas about ownership.

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.

All Roads (May) Lead to Personality Conflict

Some times conflict does get personal–usually when a string of smaller unresolved conflicts fester.

From the outside it may look like two people plain don’t like each other.  At it’s worst, it looks like the warring parties are out to destroy each other, no matter what the personal cost to career prospects or the productivity of the team.

It starts with one interaction that goes off track, an irritation that’s not addressed, or an action that’s interpreted as a slight or attack.  When these situations aren’t checked an corrected, one person starts making up stories, stories about himself, and the other person.

The story he tells about himself portrays him as someone whose motives are pure, and bears no responsibility for the situation.  The other person is portrayed as the perpetrator, the one who is insensitive, crass, or down right evil.

Once you have some idea about the source of the conflict you can apply different strategies to steer back towards productive discussion.  Conflict isn’t bad, and it doesn’t have to be painful or confrontational.  Conflict–handled well–is an opportunity for learning, creativity, and building trust.

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.

One summer, long ago and far away, I was on a softball team.  It would be an exaggeration to say I played softball, but I did participate in practices, showed up for games and imbibed of the general post-game joie de vivre (beer).  There were a lot of team members like me. It didn’t matter so much if everyone turned out, or if some people didn’t show. Friends of friends were invited. They might play half the season and then disappear.  It didn’t matter because it wasn’t about reaching a goal, it was about socializing.  

Too many teams have boundaries like that softball team. It’s never clear who will show up, and who the team can count on to play. If you care about getting work done, don’t mess with team membership.

The fundamental criteria for a team is stable membership.  To be a team, people need to know who the team members are. Weak membership boundaries make it hard for any team to do it’s work. Unstable team membership leads to miscommunication and misunderstanding.  And that adds up to time and money. Team members can’t be mutually accountable if they don’t know who is makes up “we” when they commit to deliver.

Some organizations assign people who in between projects (or managers) to what ever team seems (operative word “seems”) to need more staff.  This is the warm-body theory of staffing, that holds that you can plug a person with roughly the right skills into a team and achieve productivity right away.  (There’s a related fantasy, that full utilization is desirable and efficient).  The reality is that plugging people into a team creates a revolving door effect and the effort to bring people up to speed slows down productive work (see Brook’s law).

In terms of getting work done (and keeping people engaged) organizations are better off it people who are “in between” work on their own special projects, attend training, or just take a breather.

The belief that a group can start working at full potential the first week they are together is a fantasy. It’s also a fantasy that teams can function with who ever shows up.

I’m not talking about information related to the task and context, here, though that can damage a team. Withholding that sort of information is unacceptable, and probably pathological. I’m talking about a different sort of information: information about your internal state .

Let me tell you a story about a team I coached. They’d asked me to observe them solving a problem, help them see their process and offer advice.  Ten minutes into the task things started to go awry.

The team was standing around a  whiteboard, and had generated a list of possible solutions to the problem. They’d started filtering the options, testing them against the requirements of the assignment, adding notes as they went.  As they eliminated options the guy with the marker, Jon, crossed off the options.  Until he got to Harry’s idea.  The board was getting crowded and when Harry’s idea didn’t pass the tests,  Jon erased it.

Harry tilted his chin down.   Then he crossed his arms over his chest, and took two steps back from the group. Everyone else was focused on the white board and didn’t notice as Harry withdrew.

When he didn’t rejoin the group within a few minutes, I approached him, touched his elbow and asked “What’s happening for you?”

“They rejected my idea,” he said. “Wiped it right off the board, like I’m nothing.”

(Notice that he equated rejecting his idea with rejecting him. Easy for us to say that’s not the case; you have to start where people are, not where you think they should be.)

“You have to tell the team,” I said.

He shook his head.  ”No one is even notices that I’m not participating anymore.”

“All the more reason to let them know. They’re engrossed in the task, and they’re missing some important information about what’s happening to the team.”

Harry gave me a blank stare.  “You are withholding information that the team needs to function well,” I explained. “They need to know that one of their members has just checked out.  Will you tell them?”

He nodded, got the attention of the group, said his piece.

He was right, no one had noticed that he’d checked out, and that surprised everyone.  Jon was surprised that his erasure had affected Harry so. But he didn’t try to talk Harry out of his feeling or get defensive.  ”Gosh, Harry, ” he said, “I didn’t mean it that way.”

Harry rejoined the group.

This sort of thing happens all the time.  One member of the team feels like he’s not being heard, or isn’t valued and withdraws. The rest of the group goes on, discusses, makes decisions, starts to act. The team is missing out on the intelligence, creativity and participation of that member.  They won’t  have his buy-in for decisions, and won’t have his full-hearted support for action.  When situations like this aren’t handled, relationship fracture and drains away.  When you’re part of team, you need to be willing to say what’s going on for you, so that the team stays healthy and connected.

I anticipate that at least one reader will judge Harry as thin skinned. Someone will assert that people need to “man up” and stop being so sensitive.

What I’ve noticed is that some people talk that way until they feel rejected ….and they they act pretty much the way Harry did (though sometime less grown up).

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.

What to do when your (so-called) MVP is destroying team productivity.

Luke, the manager of the Rev 2.0 team, was walking on eggshells. He’d had another blow up with Shelly, the team architect. He tried to talk to her about the way she had treated the newest employee, Brent, in the design review meeting on Tuesday. But when Luke asked Shelly to be more patient, she exploded.

“Look, my time is too important to waste explaining the obvious to the stupid,” Shelly snapped. “It’s not my fault you hire unintelligent people who can’t understand this stuff.”

“But, Shelly,” Luke said weakly. “It’s important that everyone on the team gets along.”

Shelly snorted. “Hire some smart people, and we’ll get along just fine. In the meantime, just remember that I’m the one who was smart enough to figure out the algorithms for this system.”

She didn’t need to add “You need me,” but the threat was hanging in the air.

Luke’s face burned every time he thought about that conversation. He knew they needed Shelly, but her abrasive behavior was upsetting the team. They avoided her, struggling silently to support her code rather than risking her wrath by asking a “stupid” question.

So when Luke attended a workshop on giving feedback, he asked for some coaching on responding to difficult people.

“Describe difficult,” the instructor prompted.

“Well, I have this architect,” Luke said. “She gets defensive when I give her feedback, and she doesn’t accept what I say. She thinks she’s always right.”

“Tell me more,” the instructor coaxed.

“Well, she’s brilliant. And she’s an order of magnitude more productive than anyone else on the team—she really cranks out the code. But while most people can hold six or seven thoughts in their heads, she can hold fifteen or twenty. Everyone else has trouble following her code, and when they ask for help, she’s disdainful.

“When I talk to her about it, she gets mad. I can’t afford to lose her. I need to find a way to coach her to be more patient with the other team members.”

The instructor paused a moment, then said, “So the way she writes code and the way she interacts with the team make everyone elseless productive?”

“I’ve never thought of it that way,” Luke said on reflection.

“I wonder what would happen if she left the company?” the instructor asked.

“Oh, that would be a disaster. No one knows the code the way she does, and no one can figure it out.”

“That sounds sort of risky.”

“You bet!” Luke agreed. “But what can I do? We need her.”

“Do you really? Or are you being held hostage?”

Luke mulled that thought over during the rest of the workshop. Back at the office, he spent a week observing the team and examining metrics. He listened carefully in one-on-one meetings and probed to gauge both current morale and aspirations. As he listened and watched, he formed a new picture of the dynamics within the group.

The following Monday, he asked Shelly into his office.

“Not another sermon on manners,” Shelly sneered.

“Nope,” Luke said. “We need to have a talk about how your code and your style are affecting the rest of the team.”

Shelly sat across from Luke and glared. “I can walk out the door any time and find a new job in two days.”

“I’m sure you can,” Luke agreed. “I want talk about each issue separately.”

Luke described the behavior and work results that were getting in Shelly’s way. He described the impact her behavior and style were having on the team and the department.

“Shelly, if you make some changes, you’ll be successful in this job. And you’ll put yourself in the position to be even more influential across the company. Are you willing to work on these issues?”

Shelly thought for a while, then gave a quiet “Yes.”

She and Luke worked out new expectations for code maintainability. Then, he coached her about different ways to work with the rest of the team.

Shelly didn’t experience an overnight transformation. She’s still gruff and has to count to ten in her head to keep from snapping at less-experienced colleagues, but she’s working on it. She has worked to simplify the code and has explained it to the other people in the group. She listens to questions and suggestions, and even pairs with less-experienced programmers to help them learn the code base.

Six months after their first frank conversation, Shelly asked Luke what he would have done if she’d walked out the door as she’d threatened.

“I would have let you go,” Luke said. “The way things were going, I was putting the company at risk and denying the other team members the chance to develop. I was underestimating the cost of turnover with the rest of the crew and not considering how their productivity was suffering. In a way, I feel I owe you an apology for letting the situation go on so long.”

“That was a tough conversation,” Shelly said. “But looking back, I’m glad you told me. No one had ever explained to me that my attitude was hurting my prospects. And now that I’ve gotten to know the other guys better, they aren’t so dim—just young and inexperienced.”

Luke smiled and thought, “I sure did talk my way out of that crisis!” {end}

This article originally appeared in Better Software magazine in 2006.