Tag Archives: conflict

Team Trap #3: Failing to Navigate Conflict

“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. failure to navigate conflict

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.

Bridging Structural Conflict: Same and Different

No two people or groups are the same, but their differences don’t have to force them apart.

I recently talked to two groups who were feuding. On one side were the development teams, tasked with delivering new functionality every two weeks. On the other were the operations folks, who were charged with keeping the environment stable and available. Simmering resentment was getting in the way of working together. People were talking through proxies and hurling insults.

This is not the first time I’ve seen development and operations at odds.Conflicts like this are almost always structural. For example, the conflict may arise from the way the company is organized to accomplish work, different and conflicting goals, and different professional points of view. But, when people don’t realize the source of the conflict, it tends to get personal. People on each side of the conflict start talking about “those people,” as if the people on the other side are stupid, bad, or wrong.

Welcome to the fundamental attribution error. Humans tend to explain others’ behavior as resulting from personal characteristics and ignore the role of external circumstances. It’s seldom true that people have evil motives, are intentionally blocking progress, or are as dumb as dirt. The people employed in our field are reasonably intelligent, well-intentioned, and come to work wanting to do a good job.

Some structural conflicts dissolve if people are organized differently or when professional concerns are harmonized for complementary action, such as working together to create a software feature. When testers, GUI developers, database developers, and middleware developers come together in a cross-functional team, their differences can be a source of strength rather than conflict.

But, the structural conflict between the development (dev) and operations (ops) groups I was working with wasn’t going away. Dev and ops do fundamentally different kinds of work, with different rhythms and needing different skills. However, these two groups did (as they do in most organizations) need to find a way to dial back the conflict, appreciate each other, and work together reasonably well.

In cases like this, I find it helps to look at how the groups are similar and different. So, I asked the groups to work together to make a chart listing similarities and differences.  Same and Different Lists

As the list of differences grew longer, I felt a niggling worry that there wouldn’t be a difference the two groups could negotiate. So far, the differences they’d listed weren’t going away; they were inherent in the work. The items in the Same list were important—that’s the common ground where people can land when conflict arises—but this list was very abstract and “Mom and Apple Pie.” There wasn’t enough to bridge a gaping chasm.

Then, one of the ops specialists busted loose. He started listing all the ways the dev teams failed to prepare for production turnover.

And, there it was (with a little reframing to get the blame out)—an area where the two groups could work together. Redefining “done” and making a production checklist gave them a chance to work together on a small, bounded project. Working together on a shared goal would help each group understand the other’s context, know each other as people, and understand how their different concerns added up to a similarity: “Our work is critical to the business.”

There’s some wrangling yet to come before these two groups stand down, join hands, and sing “Kumbayah.” Some people may even be reluctant to give up their belief that “those people” are idiots. It is convenient to have someone to blame rather than recognize that some conflicts can’t be resolved, and it doesn’t imply anything about intelligence or motives. It’s not likely—or desirable—that the two groups become of one mind on all things. They do different work; what’s necessary is that they find a way to cooperate and coordinate in a way that meets the goal of delivery and stability.

If you find your group in conflict with another, you can try this exercise to bring some needed coherence. First, discern that it is a structural conflict. Conflicts of this sort tend to happen when there are different departments or goals, different professional interests, different types and rhythms of work, and when the teams do not have an interdependent goal at the level where they do their work. Everyone in a company may have a goal of “producing valuable products profitably,” but at a department level, groups may be at odds. For example, both developers and auditors want the company to be successful, but they have different roles in meeting that goal, which often feel at odds—i.e., structural conflict.

Here’s another check. Some structural conflicts are self-imposed, as when testers and developers report to different managers and are measured differently. Testers and developers do have an interdependent goal: It takes both testing and development skills to deliver a complete and reliable product. If you bring together both on a cross-functional team, the conflict usually dissolves.

If you feel it really is a structural conflict, find someone neutral to facilitate the session. Get both groups in the room. Avoid recrimination and blame, and establish the following ground rules to keep the discussion productive:

No labels. That means neither group can say the other group is lazy, sloppy, or a bunch of slackers. Positive labels aren’t much better; they don’t give specific information, and they imply that one side is empowered to evaluate the other. The power-difference message comes through whether the labels are negative or positive.

No characterizations about motives or intelligence. Remember the fundamental attribution error? People and groups that are in conflict develop stories about the “others.” Over time, these can evolve into harsh judgments about the others’ motivation, intelligence, and general fitness as human beings. The judgments show up in statements such as “They don’t care about quality,” “They don’t get it,” and worse.

When you catch yourself saying something like “They don’t care about X,” rebuild the sentence as “They have a different perspective on X.” Rebuild “They don’t get it” to “They don’t see it the same way I do”—which might just prompt you to think, “And I bet I don’t see it they way they do. I wonder what they see that I don’t.”

Make the list. Write down all the ways the groups are the same and how they are different.

Consider these questions to help the group process the list:

Which differences can be negotiated or changed?

Which ones are most significant?

Which similarities and differences help us do our work? Which ones get in the way?

Would it help us do our work if we were more the same? More different?

Not all differences make a difference, and not all differences can (or should) be eliminated. We need different skills, different points of view, and different professional concerns to create valuable products.

The point is to find something that the two groups can work on together to build a bridge. Then, when conflict arises again (and it will) they’ll have some common ground to land on (the similarities) and at least one experience of working together.

Sometimes, fate intervenes to give two groups a common goal—like a fire or flood in the office. After fighting fire or flood, groups tend to see each other as real human beings, not the sum of misattributed characterizations. I don’t wish fire or flood on anyone, so look around for additional natural opportunities for to work together—but don’t start fires.

This article originally appeared in Better Software Magazine.

Dealing with “Difficult” Co-workers

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

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

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

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

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

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

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

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

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

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

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

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

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

Conflicting Definitions of Appropriate Behavior

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

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

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

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

Deal with Difficult People Where You Have the Most Leverage

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

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

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

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

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