Tag Archives: trust

I don’t doubt that its possible to have an organization with out traditional managers. I’ve read about Semco and Morningstar Farms. I’ve talked to people who work at Gore. My husband works for a less well know firm that doesn’t have traditional managers.

But those companies didn’t get there by happenstance. They got there by design. People chose, designed, evolved practices and structures to support a specific culture. They didn’t take off-the-shelf models of functional or product based organizational structures. They didn’t slide into typical for people management practices, organizational structures, job levels or reporting relationships.

Most companies settle for practices shaped by management thinking of the first half of the last century–without a second thought. The language of this thinking is mechanistic and dehumanizing. It’s the language of efficiency, compliance, hierarchy, rules.

If you want a different sort of company, start with using a different language.

For example, rather than talk about “managing performance,” talk about giving people the information they need to continually improve or sitting down on a periodic basis to examine how we can work better together. Does that feel different to you? It does to me. Those words offer a different set of possibilities.

Because we are talking about people and complex human systems, not moving parts in some vast machine.

In an earlier article, I said, “Hiring new people for a team should always be a joint decision that involves team members.” After all, who has more at stake than the people who will work with the new person day in and day out?

Consider what happened when a well-intentioned manager decided to hire without involving the team. His rationale was the team had fallen into group-think and needed “new blood” to shake them up. When I visited, I found a fractured team. The new member struggled for credibility. Half the team wouldn’t speak to him. The other half of the team spoke to him–and resented their former teammates for ostracizing him. The team wasn’t stuck in group-think any more, but they were too busy bickering to get much done.

Whatever the issue–workload, projects that require specific technical or domain skills–involve the team in the hiring process. You’ll increase the chance of a good fit and gain commitment to help the new hire succeed. Plus, sharing power with the team helps create partnership.

Describing the Ideal Candidate

Teams often have a good idea about what’s missing on the team and where the bottlenecks are. They know when they no longer have the capacity to keep up with an increasing workload. Look at the current work, and the near-future work. Examine the current skills and work approach of the team. Then, work through a job analysis such as the one posted here.

Developing the Question Set

Involve the team in generating a list of questions that will reveal the candidates’ qualifications. Questions should focus on the skills, qualities and characteristics from the job analysis. Once you have a list, arrange the questions in logical groupings and prioritize them based on elimination factors along with required and desirable elements from the job analysis.

Finding Candidates

Team members may know others who are likely candidates. Activate those social networks! But don’t rely on the team to fill the funnel and sieve the candidates. Enlist HR to recruit and screen. Winnow down the likely candidates through phone screens. Bring the team back into the process when you have a handful of suitable candidates.

Interviewing

Assign one team member to each question area to avoid subjecting the candidate to the same questions over and over, and ensure all areas are covered. If the team members are sufficiently skilled, have them do one-on-one interviews. Or have a lead interviewer present in all interviews and assign a different team member present for each interview segment. The team member can ask the bulk of the questions, but the lead interviewer is there to listen for areas to probe for more information. This is a good option if the team hasn’t been involved in interviewing before.

In the United States, some questions are illegal, while some are okay if you ask everyone the same question. I don’t expect team members to know these rules. Invite your HR representative to brief the team on what’s appropriate and what is not.

You may want to do some practice interviews so team members know what to listen for, how to probe for deeper insights and recognize red flags.

Auditioning

Auditions provide a candidate with the chance to demonstrate relevant skills. Unlike solving puzzles, these auditions relate directly to the work the candidate would perform. You can ask a person to write a small function in a language he claims to know. You can sit him down in front of a product and ask him to test it (after you’ve given him enough background information so he’s not completely lost). You can ask a designer to review an existing design and add some new feature. No matter what the job, you can devise a way for the candidate to show his stuff.

Pairing

Some companies seem to think that as long as a candidate can solve cognitive puzzles and answer technical questions, they’re good to go. Technical skills are a necessity, but not sufficient to succeed in most organizations. This is especially the case when team-based work or communication with other humans is involved.

Pairing–whether to program, test or design–gives a window into technical skills and much more. More and more companies are bringing in top candidates to pair for a half or full day. You will need an NDA (nondisclosure agreement), and possibly need to cover some expenses for the candidate who is probably using a vacation day to participate. But at the end, you’ll know much more about how the candidate responds to new situations, and how he approaches problems. You’ll know how something about how he enters groups, and his ability to interact with people on the team. You’ll know whether the candidate is confident enough to ask questions, admit when he doesn’t know something and is willing to learn from others. You will avoid hiring someone who will rub everyone on the team the wrong way.

So you’ve involved team members in various ways. Now what? It depends on how much you want the team to invest in the new hire’s success.

Choosing

From a legal perspective, an agent of the company must make the salary offer and complete the legal aspects of hiring. But choosing which candidate is the best fit is a shared responsibility. Bring the hiring team together and pool the information. Check for elimination factors and see who you are left with. If you end up with only one candidate, your work is still not done.

Create a gradient of agreement to gage the level of support for the candidate. When there is only lukewarm support, keep looking. If support is bifurcated, explore the reasons for both strong support and opposition. In some cases, hearing another point of view will change some minds. But if not, move on. If you hire someone abhorrent to one member of the team, you’ll have problems in the long run. (Of course, if there is someone who is opposed to every candidate and has no credible reason, you’ve got a different problem.) Strive for consensus–you want the team to support the person, not tolerate him or her. Over-rule the team at your peril–because if you do, you will own every problem with the new hire.

It’s an Investment

Preparing team members to participate in the hiring process will take time–time to coach the team on which questions to ask and which ones to avoid; time to teach the team what to listen for; and time for practice interviews. Is it worth it? Yes! Interviewing is a broadly applicable skill. The abilities to formulate questions and to listen for what is said and unsaid are invaluable in speaking with customers, clarifying problems and devising solutions.

The person who makes the hiring decision has a vested interest in having that person work out. Including the team in the hiring process ensures that the manager is the most invested party. Because the team chose the new candidate, they will be more willing to show the new person the ropes and explain the context and domain. They’ll be more likely to offer help and encouragement. By having the whole team involved, you’ve created a support group to aid the new person with integrating into the group and become a productive member of the team.

Most importantly, involving more people in the hiring decision shares power and creates partnership. And if you want to get the best out of people, that’s what you want to be–partners.

Resources

If you want to learn about hiring–soup to nuts–get yourself a copy of Hiring the Best Knowledge Workers, Techies & Nerds by Johanna Rothman.

Recently, I tweeted, “/Estimating/ is often helpful. /Estimates/ are often not.”

Several people asked, “How can this be?” Let me say more, in more than 140 characters.

/Estimating/ is often helpful.

Estimating helps when the process of estimating builds shared understanding among the people who want the work done and the people doing the work..

Collaborative estimating gives the best results. Diverse experience yields a broader range of perspectives and questions. Questions and perspectives build understanding of the what, why, and who related to the request. That’s helpful.

Group estimating reveals differences in knowledge and understanding. Finding those gaps early is helpful.

Group estimating surfaces assumptions. When we are aware of our assumptions, we can verify–or debunk– them.

When the group knows enough about the “what” to think about the “how,” they can analyze implementation. Working out implementation details reveals more assumptions, and generates more questions.

Sometimes estimating reveals you only know enough to reason by analogy. The best you can do is posit that the desired functionality is about the same size as X.

But sometimes, estimators realize that they don’t know enough to think about size or effort in any meaningful way.

This situation calls for discipline. Discipline to resist guessing and speculation. Estimates born of ungrounded guesses are worse than useless. Rather than guess, experiment, interview, model, sketch designs or do some activity to gain more clarity about needs and context. Then try estimating again.

/Estimates/ are often not helpful.

People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method. Meeting needs fades in priority.

People construe estimates as promises. No one can predict the future, but many people treat estimates as guarantees. Failed predictions fan blame. Trust and openness suffer.

People construe estimates as bids. Bidding usually involves some calculation of profit. That implies a margin. However, managers discourage margins in estimates. Managers view “padding” as a moral failing–but it’s really a contingency for the unknown (or compensation for bosses who are known to cut estimates to fit wishes. See below).

Inappropriate precision in estimates implies that people know more than they do. When expectations and reality meet, people may feel disappointed. More likely, they feel deceived. Trust and openness suffer.

People game estimates. How many of you developers out there have thought long and hard about an estimate, only to have a managers say, “That estimate X is too high. The estimate should be X – Y.” Me, too. Fudging estimates to fit wishes sets off another round of deceit and disappointed expectations. Trust and openness suffer.

“A talented employee may join a company because of its charismatic leaders, its generous benefits, and its world class training programs, but how long that employee stays and how productive he is while there is determined by his relationship with his immediate supervisor.” Buckingham & Coffman

Good managers know how to build strong relationships in a traditional manager-led environment. But when a company relies on self-organizing teams to accomplish work, the relationship between an employee and his direct manager may not be his primary affiliation When organizations form real teams, the strongest bonds may be to the team, not the manager.Managers still need to maintain rapport with individuals, but now they also need to maintain a relationship with the team as a whole.

What does that look like? Strong manager-team bonds come from co-creating, clarity, and coherence.

Co-creating Relationships

As a manager, you need certain things from the teams you support. It’s reasonable to expect teams to make their status, progress, and road blocks visible. It makes sense to track certain metrics from teams to alert you to problems. You need trend information to reason about how the team is functioning, and how the system is functioning. (I’ll write more about which metrics might be useful and the importance of focusing on trends rather than targets in a future newsletter.)

And the team needs things from you, too. But what the team needs might be different from what a collection of individuals needed. Gather the team and find out. Start with two sheets of flip chart paper one of the team, one for you. Draw a line down the middle creating two columns. Label one Need, and the other Offer. Ask the team to work together to fill out their sheet while you fill out yours. Then compare what you wrote and what the team wrote.

Start with the areas where it looks like there is agreement between what the Team wants and what you offer. Discuss what that would look like. For example, if the team needs you to be available, drill down to see what that means. “Be available” could mean:

The team wants you within 40 feet of the team room at all times (probably not something you can agree to), or

They want to you respond to their emails within 24 hours, or

They want you to designate another manager they can go to if they need management support. or

A weekly check-in, or

Something else completely different.

Then, work through the areas where you and the team seem to be close on what you need from them.

This is a negotiation so be prepared to look for the needs behind requests and offer options. Once you’ve worked through areas of agreement, look at the requests that seem far apart. Some of them may be answered by the discussions you’ve had so far. For those that still need discussion, prioritize, and then ask “If you had that, what would it do for you?” You may learn something interesting about the team’s work environment and how they view your role.

As with any relationship, you don’t have to say Yes to every request. Nor does the team have to do everything your way. Before you go into the session, be clear in your own mind about the critical things you need from the team to do your job. But be flexible on how to achieve them.

Clarity around Decision-Making

The previous discussion may have already covered some decisions. You may want to document those in this step. Then identify all the decisions that affect the team over the course of a typical quarter. Group stickies that seem similar, so you can see classes of decisions. Some examples of categories shared by many groups are hiring, training, tools, and technical decisions.

If you don’t find a pattern in one of the decision classes, the category may be too broad. Try breaking the category down.

At the end of the activity, you’ll have a matrix that looks something like this:

Don’t try to identify every single decision that team will make. Work to identify areas where the team has autonomy and authority. Delineate where you and the team will work together on a decision, and where the decision rests solely within your role as a manager. Clarity enables the team to act–without fear of crossing an invisible tripwire. It also reduces the likelihood of being blindsided by a decision, for you and team members.

Coherence in Values and Actions

In some organizations, it feels like there’s one set of rules for managers and another for non-managers. This condition fractures relationships and erodes trust. Simple Rules (1) are a tool to bring bring coherence, and reduce the feeling that there’s one set of rule for “us” and one from “them.” Unlike working agreements, which usually address protocols for how to work together in a specific context, Simple Rules guide behavior in many situations across departments and levels in an organization.

Simple Rules reflect values and aspirations about behavior. Start with a warm up, identifying common current patterns of behavior in the organization. Based on observed behavior, test what unspoken Simple Rules might drive that behavior. Ask the groups what patterns are effective, and which they might want to modify or add. Generate rules that would help that pattern emerge.

Here are some Simple Rules from other organizations. Even if these seem like good rules, don’t copy–create your own!

Teach and learn in every interaction. (From a non-profit educational institute.)

Use every failure as an opportunity to learn. (From an organization that wanted to foster more intelligent risk taking.)

Raise the red flag early. (From a group that wanted early warning of problems and potential problems.)

As you develop Simple Rules, consider the patterns of behavior that you want to foster. Simple Rules should be “minimum specifications,” rather than detailed prescriptions for behavior. Keep the list short–five to seven rules. More that that is too many to remember, and acts against the ability to apply judgment, take responsibility, and self-organize.

Conclusion

In spite of the cries of a few pundits (and a few self-organizing teams), teams still need managers. But if you want the advantages of the self-organizing team effect, you have to make space for great things to happen. Sketch out the relationships boundaries, and Simple Rules to set the stage for creative approaches, solutions, and responsibility.

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

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

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

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

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

“Do you ever say no?” I asked.

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

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

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

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

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

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

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

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

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

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

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

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

I can start on that project after ____________.

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

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

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

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

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

I recently talked to a group that’s forming a new “change leadership” team. Part of the work of the team is improving the organization, and part is capacity building. Four of the people on the team are folks with technical backgrounds who are viewed as having potential to be future leaders in the organization. The fifth person is a manager.

By definition, the manager will have a different role on the team. Because of his role in the organization, he’s accustomed to taking a broader view of the organization. He’s got more experience steering change. He’s led and managed teams. He has more authority, and access to resources. He can approve expenditures.

One of the tasks for this group in becoming a team is to clarify the managers role, and identify decision boundaries. This is something I do with self-organizing teams. It’s especially important when the manager sits on the team. I find that it helps both the manager and team members break out of the common “looking up/looking down” dynamic.

the Looking Up/ Looking Down Dynamic

And, the act of co-creating the relationship helps build trust.

It’s not necessary to list and delineate every decision that could possibly come up. Usually, there are classes of decisions that can be treated in the same way. I start by having the group brainstorm all the decisions they are likely to make as they work towards the team goal. Then, they group the decisions to identify the classes.

Looking at the classes of decisions, I help the group answer these questions:

At the end of the activity, they have a grid that looks something like this chart (though they usually have names, rather than M and T to stand for manager and team).

Clear decision boundaries makes it explicit which decisions are the managers alone, which are the managers, but involve the team. It also identifies which decisions are shared, and which the team can make even if the manager isn’t around to participate in a particular decision.

This sort of clarity make is easier for teams to act on their empowerment. It also avoids the sort of ill will that can come up when the team believes they will be involved in a decision, and the person with a management role believes differently.

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

For example:

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

“He’s difficult to manage.”

What’s missing?

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

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

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

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

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

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

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

And I feel threatened.

And I feel I have to defend my ideas.

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

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

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

A while back I talked to a CEO of a contract development shop. He wondered how Agile could help him with fixed price, fixed scope contracts to deliver software.

Of course, the requirements that come with these contracts are never complete or completely accurate. The first thing that comes to mind is to stop making impossible contracts. For this CEO, that doesn’t seem possible, at least at this time, given the context he does business in.

In any fixed cost/scope contract there comes a time when the two parties must have a conversation about the short-comings of the requirements, the delivered software, and the budget.

In a waterfall delivery, all progress reports are proxies. You’re reporting on intangibles–designs, test cases, or code that isn’t fully integrated or tested. This is all reporting on faith, because it is not verified by working software.

When a change request does come up, it’s unanchored from the experience of how actually using the software. It’s only words, and the impacts are made tangible in cost thinking, how much it will cost to modify existing artifacts, ripple effects through the code, test cases, documentation. There’s usually some accounting for the benefit and risks, but those tend to feel subject to inflation, based on conjecture, squishy. What does feel clear is that the change request process takes up time, and approving the change will cost more money. More often than not, the interaction feels like a tug of war. One side is arguing to spend more money, and the other is working with equal vigor for the opposite.

When the moment of truth arrives–the long tail of testing–it becomes apparent that all the progress reports up until that point weren’t reliable. After you’ve made the up-front promises and signed on the line, you have one big opportunity to build trust. If you blow it, you’re sunk. At that point, it’s difficult to have a conversation about meeting goals–especially when the lawyers get involved.

However, if you are using agile methods, you demonstrate some small piece of software every few weeks. People on both sides of the contract see tangible progress. They have a chance to correct misunderstandings about requirements, and fill in the gaps in each others understanding. People on both sides of the contract can see and experience the short-coming in the requirements, so it’s not the tug of war a traditional change process sets up. People on both sides have more reliable data on which to make decisions.

Most important though, both parties have had many opportunities to build trust based on something real–working software.

So when that point comes, when both parties to the contract must have a conversation about meeting the aim of the contract, it’s a very different conversation. The moment of truth will probably come sooner, when people have more options. The conversation will be based on shared understanding of progress and trust. And that’s a very different conversation.

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

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

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.