An effective hierarchy provides enough central control for coordinated action in achieving the aim of the organization. At the same time, the hierarchy must provides enough autonomy for subsystems to function, self-organize, flourish.

Yes.  But how to do that? Let me walk you through a scenario that describes the challenge.

I’ve seen a number of organizations decentralize control and decision making, only to pull it back to the home office. If you watch long enough, many of these companies after experiencing centralized control for a while, go back to decentralized control–like a pendulum swinging back and forth.

Here’s how it goes.

As a result of centralized control, decisions are slow.  Slow decisions and top down plans that require an act of god to change lead to poor financial performance, and customer dissatisfaction. Because people are effectively denied discretion, creativity plummets. Rigid plans and targets don’t allow people to take advantage of new opportunities.

When the financial results start to trend down, senior management notices.  They want faster decisions, and front-line people who are responsive to customers. They want creativity, innovation. They want to seize emergent opportunities and respond nimbly to change.  They want better financial results.  Who wouldn’t want all those things.  So they decentralize.

After the initial flush of enthusiasm, they start noticing problems. Visibility decreases. Decision making and spending feel out of control. Some subunits make inappropriate decisions. Subunits optimize at their level, forgetting the overall goal of the organization. Some subunit managers go rogue, and strike out in directions that make no sense for the overall company strategy. Financial results dip.

And the managers want a return to clear lines of communication and authority. They want visibility, coordinated action. They want predictability, consistency. They want CONTROL. So the pull decision making, planning, budgeting back to the center.

While the supposed solution seems to be swinging between two poles, the organization and the people in it experiencing an oscillating effect.

In truth, the company doesn’t want either end of the pole.  They want the upside of both centralized control and decentralized control.  They want enough control to effectively coordinate actions of the various parts of the system to achieve the goal of the organization,  And they want enough autonomy so that all parts of the system can flourish, self-organize and respond to opportunities and change.

Why do systems oscillate?  Delayed feedback and an over-vigorous correction.  This happens on the organizational level, but it can also happen on a smaller scale anywhere in the system where feedback is slow and well-intentioned people over-correct when they do get feedback on system performance.

In order to achieve the upsides, organizations need to manage the downsides.  And that requires faster and more robust feedback loops. Those feedback loops will provide information about system behavior sooner, and allow smaller more nuanced adjustments.

I’ll write about some of those feedback loops next.

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

I’ve been talking about (and using) Human Systems Dynamics tools lately–Rally Success Tour, OTUG, Practical Agility and Retrospective Workshops in Stockholm.

I find Containers, Differences, Exchanges offers my clients (and me) a useful way to see past events and see structures. Working at the level of structures gives both insights and opens up opportunities for action.

My slides (or the March 16 variation of my slides):

And here’s my talk at the Rally Event in February:

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.  

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.

A while back I was contacted by a potential client who wanted to “go agile.”  But they wanted to do it in a deterministic manner.  They wanted a plan, complete with milestones and dates–mostly indicating that other people had changed their behavior as dictated by management.

Sigh.

One could make a plan for mass training (aka sheep dip), I suppose.  One could   dictate that by June 10, 20XX, all teams will practicing TDD.  Or that all projects will be converted to backlogs and loaded into agile project management software.

But that doesn’t seem so agile to me.  It seems like it misses the point of learning and adapting; of embracing values; of understanding systems and patterns, how the work works, what’s working and what’s not.  Without considering the WHY behind processes and learning as you go, you are only going through the motions.

Start with understanding the current state, and what problem you are trying to solve by “going agile.”  Understand how the current structures and goal alignments are supporting or hindering the goal of delivering products to customers, and identify targeted changes that will improve that ability. Identify where and you can change the pattern and establish structures that will help the new pattern take hold.

Make a Road Map, knowing that you don’t know everything and can’t foresee all you’ll discover on this journey of change. Describe the desired pattern and the steps that you can currently envision to get there.  You won’t be able to see all the steps. If your initial actions are effective, your culture will be changing. Any far-future actions you described from the driveway may no longer be what’s needed when you are 100 miles from home.

It’s impossible to know everything at the outset when you decide to make what amounts to a cultural change. You take some steps, observe the effects of actions, and adapt, learning as you go.

Deterministic planning fails with complex software systems, and it fails with organizational change. Organizations are far too complex, and we need to plan for adaptation, learning, and the fact that the organization will be changing as the plan unfolds.

It’s easy to be critical of managers.  A few things to remember.

0. Most people in management roles want to do a good job, but may not know what to do or how to do it.

1. People in management roles are dealing with incomplete and ambiguous knowledge.  It’s a fantasy that they have all the information and know what to do (which may be held by both managers themselves and people who wonder why their managers do clueless things).

2. Most people in management roles receive little or no training on how to be  good managers.  Many people are promoted into management roles because they excel at technical work.   This is not an easy transition.

3. Many people in management roles are working out of a mental model of management that limits their effectiveness.  (See Don Gray’s Managing in Mayberry for two common mental models and one that’s less common.)

4. Many of the role models new managers have aren’t helpful. If people have never experienced good management, you can’t fault them for a lack of imagination.

5. Much of the management training out there is crap.

6. People in management roles are expected to achieve results over which they have no direct control.  They must work thru other people and create work environments and work systems that support other people to do excellent work. Most managers have no training in how to do this.

7. Most people in management roles face demands from their managers and from the people who report to them. The are pulled from above and below.  These demands are not always aligned and may be mutually exclusive.

8. Middle managers receive little peer support.  Most managers face isolation and competition from other middle managers who are trying to meet locally optimized goals, obtain scarce resources and look good to the next level up.  This is even more salient for new managers. Power difference (not matter how slight) changes the relationship with former peers.

9. People in management roles need to see the system and work on system, but receive little to no training in system seeing/thinking/acting.  Relentless pressure tends to hold their focus on short term events and results, making it difficult to see patterns and connect the dots of seemingly unconnected events.

10. People in management roles need to work on the work system; they are also in the system, and their behavior is shaped by the system they work in. Both top managers and middle managers fall into predictable patterns of behavior.

Slides from Team Traps!

Many managers ask me, “How can I motivate my team?”

I’ve certainly seen many efforts to motivate teams.  Contests, prizes, pep talks, badges, points, canned thank you notes, and recognition events. Most of this comes down to using rewards to motivate people to continue certain behavior.

Some of these work for some people, some of the time. But most of them backfire, for most people, most of the time.

Consider these attempts at motivating:

A team lead receives a substantial sum of money when the team meets a critical deadline. Despite pleas from the team lead, management will not divide the money equally between all team members.

A developer worked late into the evening to fix a critical bug.  His manager, wanting to motivate others to show similar dedication, gave the developer a ticket to the opening night of a big movie.  One ticket—another night away from his wife and kids.

A programmer discovered and fixed an error that was costing the company millions. He worked with an account rep to provide data that allowed the company to recover a substantial portion of the money from erroneous invoices.  The VP of the division gave the programmer a gift certificate for $100 at a local restaurant.

A manager singled out one person from a team for public recognition, and didn’t mention the contributions of any other team members.

A VP called a special meeting. When all the developers were assembled. He opened his brief case, which was full of cash.  Every programmer received $300 cash money.  When they got paid the next Friday, they found that the award was taxed, and taxed at a higher rate then their normal salary.  Actual pay was $100 less than than they usually received.

Each of these attempts at motivation backfired. Many people (but clearly not all) know that rewards and other extrinsic motivators aren’t effective; in fact, they often diminish intrinsic motivation.  And making one person the winner makes other people losers.

So why-oh-why do managers do such things?  Do the managers who came up with these ideas (and others like them) ever put themselves in the place of the person they were rewarding, and asked themselves how they would feel if someone treated them that way?

I suspect not.  But then, why wouldn’t they do so?

Some managers still assume that “workers” won’t work without carrots (or sticks). It doesn’t occur to them that carrots might not be the preferred diet.

Some managers don’t understand what motivates people doing technical work. Just look at the surveys that report what managers believe are the key motivators for developers, and what developers report motivates them.  Major mismatch.

Some  managers see themselves as different from “workers.”  For example, they often believe that money is the primary motivator for “workers,”  but they don’t ascribe such crass motive to themselves.  Just like they don’t need carrots and sticks, but “workers” do.

Some managers can’t imagine that “workers” wouldn’t welcome some sign of management favor and approval. This is about power and status, pure and simple.

The zeroth step in boosting motivation is to stop doing things that demotivate people.

A while back I was talking to a manager who complained that “no one” in his organization was “accountable.”  Of course, he exempted himself form that category.

This manager, (I’ll call him Tom) feels like he’s accountable— he knows that if they people creating software products don’t get their work done, he’ll hear from his boss, and it won’t be fun. So, Tom schedules meetings, hands out plans, talks about urgency and exhorts other people to do their work.

I asked Tom to draw me a picture of how the work was organized in his company.  It was quite a tangle.  The development groups (UI, DB, middleware, apps, test….) live in silos and report to different functional managers. The project managers sit is another organization, from where they coordinate project work across the development groups.  Each project manager manages four or five projects. The development folks are likewise forced to multitask, as they spread their time and attention across a similar number of problems (and have 4 or 5 project managers telling them what to do).

The senior managers change their minds about priority—at the project level—every few weeks.  Every one is busy, but not much gets done.  Given the picture Tom drew, I was not surprised  that Tom feels frustrated.

But Tom’s answer is that they need better people in the project manager and development roles—people who will be accountable.

Tom is not an anomaly.  Many managers I talk to believe other people have no innate sense of accountability (what ever that means) and that no one holds them accountable. In fact, most people—regardless of where they stand in the hierarchy—feel that they are held accountable; sometimes they believe that others are not.

How can this be?

Accountability, the way Tom  talks about it flows one way. There’s no sense of mutual accountability or partnership. The person telling the story is doing his job; others are not.  The manager tells other people what to do, and they are supposed to do it—no matter that the deadlines are madness, people are forced to multitask, the goal is hazy, the requirements shift by the minute, and the folks doing the work don’t have all the skills to do the work.

When people aren’t “accountable,” I wonder what gets in the way of accomplishing work and makes the appear to be “unaccountable.” I wonder if the managers see their job as creating an environment for people to accomplish work. Or whether they think their job is telling people what to do, and then blaming them (read: “holding them accountable”) when organizational obstacles get in the way.  And I think about the fundamental attribution error:  When “I” don’t finish work or complete assigned goals, it’s because external circumstances prevented me from doing so;  when you don’t finish work or complete assigned goals, it’s because of a character flaw—no sense of accountability, in this narrative.

When I look at Tom’s picture, it’s clear that the majority of the barriers are of management making.  Deadlines, multitasking, unclear goals , shifting requirements and priorities, hiring unskilled people or failing to adequately train people are all management issues.  But somehow that doesn’t come into the assessment of accountability.

When managers do their part and create work systems that makes it easier—not more difficult—to get work done, they usually find that suddenly they have people who are accountable.  Accountability is about negotiation and partnership; it is not a cudgel to blame people for not meeting unilateral demands.

A couple of weeks ago, I listened to a very funny story about economic incentives on NPR. (Something funny on economic incentives?!)

The story was about an economics professor who decided to use incentives to shape the behavior of his children. He devised an incentive program for potty training–which his toddler gamed.

So when the time came to potty train his daughter, B., he designed what seemed like an economically rational incentive: B. would receive a jelly bean every time she went to the toilet.

Once the new policy was in place, B. suddenly had to go to the toilet really, really often.

A few years later, B.’s younger brother needed to be potty trained. And Gans decided to expand the incentive system: Every time B. helped her brother go to the bathroom, she would get a treat.

“I realized that the more that goes in, the more comes out,” says B., who is now 11. “So I was just feeding my brother buckets and buckets of water.”

I see lots of incentive programs like that–so obvious they could be gamed by a child. What are the people who devise these programs thinking? Sadly, when the simple incentives produce undesired results, they come up with ever more convoluted ways to elicit the desired behavior. (There’s also a tendency to blame the people who gamed the incentive.  Its as if the logic is: “We tried to manipulate you but you figured it out. Now we think you are a bad person for not cooperating with our attempt to manipulate you.”)

Rather than try to manipulate adults in the workplace, why not appeal to intrinsic motivation? Tell people why something you want them to do is important, how it connects to the mission and financial results of the company. Then remove disincentives and barriers to doing the right thing.

Anyone contemplating trying to shape behavior with measurement and incentives should read Austin’s Measuring and Managing Performance in Organizations.  And then, consider that there might be a more congruent way to achieve the desired outcome.