We’ve long lived with the assumption that the people at the top of the organizations are the ones who understand the business.  They understand the market, the product, the customers.  They hold the financial information about how the company makes money and the current financial status.  Since they hold this info, they also know what the company should do—on a strategic and tactical level.

One assumption behind this model is that the brains are at the top of the organization and the brawn is at the bottom. Knowledge flows down, but mostly on a “need to know” basis.  So it filters down as a trickle, not a torrent.

At the same time, the hierarchy acts a filter from the bottom up.

Day-to-day knowledge about how things really work, who to talk to when you want to get something done, how to work the (doesn’t work as defined) process, work arounds, greasing the skids, what the status really is and other useful stuff is concentrated at the bottom of the organization.

The higher in the organization, the more the day-to-day reality of business is abstracted to numbers. And because the people at lower levels in the hierarchy don’t want to displease people at higher levels, they tend to minimize bad news—so the picture becomes rosier with each level it ascends.

One can argue that this model of knowledge concentration has worked. There are many companies that started this way, and they are still around.  But I think the days when it served us well are over. It doesn’t meet the needs of the our times or our industry.

For one thing, we aren’t pouring ingots. We do knowledge work. We need to know about the context, customers, and cash flow in order to make the right products.

We live in a time of fast change. The competitive environment and customer preferences can change on a dime.

This bifurcated concentration of knowledge does not serve us.  It makes companies slow as requests for approval work their way up the chain.  Worse, it makes companies stupid. Think about it.  How many times has a decision from top management looked silly, misguided, or malicious given the realities of implementation?  How many times has management countermanded a decision made close to the work because the people who made the decision were missing some piece of information about market context, customer needs, or how cash comes in the company door?

If we want our companies to succeed, we need to make the over-lap between contextual knowledge and implementation knowledge bigger.

This article first appeared on Stickyminds.com.

Recently, a reader wrote to me with a concern about retrospectives. “We make decisions,” he wrote, “but we don’t have the discipline to carry them out. The team is starting to feel like retrospectives are a waste of time.”

If the team fails to resolve issues and make improvements after their retrospectives, they are wasting their time. But the problem may not be with the retrospective; the problem might be with how the team views the changes they’ve identified in the retrospective. I’ll share my story of two personal changes to illustrate what I mean.

A Tale of Two Changes

Last fall, I decided to make two changes in my life. First, I decided to save some money by giving up my personal trainer and going to the gym on my own. I thought this would be easy because I know how to design a good workout. I’m familiar with all the equipment in the gym, and after working with a trainer for years, I know enough exercises and variations to avoid falling into a rut.

I also decided to lose ten pounds. I expected losing weight would be quite difficult. In my thin days, I’d listened as friends complained about losing weight. I’d watched other friends go on and off diets and witnessed the gustatory gyrations of a colleague following Atkins as she traveled twenty weeks a year. I knew it would be hard, but I had to try.

It’s now been a bit over six months since I resolved to make those changes, and I can report that I followed through on one decision and the other fell by the wayside. I failed on the “easy” change. After making it to the gym once in three months, I re-hired my trainer. However, I exceeded my goal on the “difficult” change by losing 25 pounds.

What enabled me to succeed at the difficult goal? What allowed me to fail at the easy one?

Lesson #1

I didn’t have a well-formed goal for the first change. I saved money by not paying a trainer whether I went to the gym or not. I guess you could say that’s success. But there was a second, implicit part to the goal, which was stay in shape. I might have done better if I’d stated my goal differently–perhaps “Achieve exercise independence.” Teams need to look at the implicit goals and values behind their retrospective actions to make sure that both explicit and implicit goals are aligned.

Even with a better goal statement, I suspect the outcome wouldn’t have changed unless I addressed Lesson #2.

Lesson #2

I thought the first goal would be easy. Because I thought it was a no-brainer, I didn’t use my brain to plan the change in a way that would propel me to success. When teams think they face an easy change, they may not recognize how hard it is to change even a simple habit. And by treating the change as simple and easy, they make it easy to fail.

Brainful Change

I succeeded in my goal to lose ten pounds by giving myself structures and supports that would help me reach my goal, and I developed a strategy for when I knew it would be hardest to hold to my resolve.

Feedback

I used a point system to track how much I was eating and exercising. Tracking made me much more aware of my eating actions and helped me make choices. I also bought a scale so I could measure my weight and see my progress.

When the team members are deciding what to do in their retrospective, set aside a few minutes to consider how they’ll evaluate success and track progress.

One team chose a goal of increasing their automated unit testing by writing at least one test for each story they worked on. They added a column on their task board to track the unit tests for each story. A team that wanted to improve code quality by pairing created a tracking sheet and made a check mark each time they caught a defect that would have been missed without another pair of eyes.

Structure

I established a “weigh-in day” to help hold myself accountable.

A structure can be anything that creates an opportunity for the team to do what they’ve committed to do. The team who started pairing created and posted a pairing schedule. A team who wanted to improve their design skills did cooperative reading and set up a weekly lunch to share key ideas.

Support

I am lucky to have a husband who will eat pretty much anything I put on his plate and is willing to grill whatever I bring home from the store. (Plus, I suspect he had a vested interest in seeing me lose a few pounds, so he wasn’t going to work against my goal. Just guessing.)

Support can be an “atta boy,” or it can be access to books, training, coaching, and experts. The team who wanted to improve their refactoring purchased books and supported each other by walking through their refactorings with each other.

A Counter Balance

That was fine for when I was at home, but I travel. That’s where the extra pounds came from in the first place.

As soon as the waitress set the plate in front of me, I’d cut the portions down to size: a serving of meat is the size of a deck of cards. A cup of pasta is about the size of a tennis ball. I didn’t have to rely on will power to stop eating; I had a handy heuristic and a specific action to help me stick to my food plan.

When you review retrospective actions, think about what will make it hard to stick to the resolve. Use a Force Field analysis to identify the factors that will propel the change forward and those that will restrain the change. What can the team do to strengthen the drivers, and reduce the retraining factors? (See the hand-drawn chart of a force field analysis below.)

Most changes aren’t no-brainers, even when they sound simple on the surface. Save a little time in your retrospective to identify how the team can use feedback, structure, and support to help them make the change. Consider it insurance for the investment you’ve made in a retrospective.

Too often, manager in organizations act as if changing behavior in an organization is a simple matter of “make it so.” Some changes are like that–but most significant changes are not.

Systems drive behavior. Therefore, if you want to change behavior in an organization–increase accountability or teamwork for example– you need to understand the factors that are driving the current pattern. Telling people to change the way they act (push) or talking about a vision (pull) isn’t sufficient. If you want to people to change their behavior, change the system that drives the behavior.

Let’s look at an example that I see show up quite a bit.

Say the managers in an organization have decided that they want the productivity and morale benefits of cross functional teams. So they put together a cross-functional team–a three developers, a UX/UI person, and a couple of testers.

The managers charter the team to work on the next release of a product. It’s a compelling goal, one that all the members of the team understand and support. It’s an exciting project both from a technology and a market perspective. The managers really want to support teamwork and collaboration, so they send the team to an team building offsite.

When the team comes back, they are enthusiastic. But after a while, the managers notice that the “team” part isn’t working. Their efforts are fragmented, their priorities are in conflict. No one is intentionally hoarding information, but somehow information that everyone on the team needs to know doesn’t spread to all memebers.

It’s pretty much the same pattern as existed before the initiative to form cross-functional teams.

How can this be? This group has a shared goal and interdependent work that requires all of their skills. They are all accountable for the success of the release. So why aren’t they acting like a team?

It might be something about the individuals. But it might be something about the visible and invisible structures in the organization that are holding the old pattern in place.

Containers, Differences and Exchanges: structures that drive patterns of behavior in organizations.

Containers hold the focus of the group. Containers can be

physical–a team room
organizational–a department
psychological or conceptual–a goal, a set of professional concerns

Some containers are obvious, others are not.

Differences are just that, differences among the people within a given container, or between containers. There are an infinite number of difference, but not all of them make a difference–hair color for one example. Differences hold the possibility for constructive complimentary action or for conflict. Some differences are negotiable and mutable (e.g., skills) others are not (e.g., gender).

Exchanges are the flow of value (information, money, energy, social connection) within and between containers. Exchanges might be allocated funds, salaries, policies, formal and informal communications.

Two of the developers report to the same manager. The third reports to a different manager. The testers report to the test manager, and the UI guy reports to the UI manager. These reporting relationships line up with departments within the organization, and they’ve been in place for a years.

Each of these managers has a different perspective. Each manager has been given different objectives by his/her manager. The people on the team know that they need to attend to their manager’s concerns–which don’t line up completely with the project goals.

The developers are on one floor of the building. The testers and are on another floor, but don’t sit close to each other.

The UI guy is working on five other projects.

Here’s a sketch of the containers for this team.

The dotted line circle represents the project container. But that’s not the only container and it’s certainly not the strongest.

The obvious solution is to put the team in a team room. That would probably help a lot. But it’s not the only possibility for action to shift the pattern.

I posed this question to the participants in my workshop at Agile France, and here’s what they came up with:

Container interventions

• Strengthen the shared picture and vision of the product
• Strengthen focus on common goal
• Move the team to a team room or at least to contiguous cubes
• Have all team members report to one manager who has responsibility for the project
• Remove roles, make everyone a team member rather having distinct roles such as developer, UI designer/developer, tester. (Obviously this won’t result in everyone having the same skills, but will reduce the strength of the role container)
• Make the project container stronger

Difference interventions

• Align management objectives
• Cross-train to create generalizing specialists vs. specialists

Exchange interventions

• Provide a facilitator
• Change the rhythm and content of meetings (meetings can also be thought of as a container)
• Have team members report their status to each other
• Hold a retrospective
• Have a social exchange
• Show and explain how the project and each person contributes to the company
• Change the bonus structure

An interesting list—and in my experience, a much longer list than the question “How can we get them to work together as a team” will generate.  And that’s the point.  Looking at Containers, Differences, and Exchanges shows possibilities for action that will shift the pattern.

(The concept of Containers, Differences, and Exchanges comes out of Glenda Eoyang’s work on Human Systems Dynamics.)

A while back, I sat in on a birds-of-a-feather session on organizational change.  The main theme was bemoaning the difficulty changing even mid-sized organizations.

When people talk about how hard it is to bring change there’s a tendency to blame:  people who don’t turn on a dime are labeled resisters, NoNos,  dinosaurs, laggards.

There certainly are people who don’t change as quickly and with as much enthusiasm as the people behind the change would like.

(I heard one agile evangelist  complaining about people who weren’t embracing scrum after a two-day workshop.   “I want them to drink the Kool Aid,” she declared in frustration.  Yikes!  I want people to consider and wrestle with a new idea, not accepted it as someone who has given up free will. I hope she was ignorant of  Jonestown.)

There are many reasons people don’t change as quickly as we’d like.  A few I cited in Seven Lessons for a Top Down Change:

they don’t know how to do what they’re being asked to do.

they don’t feel they have time to learn the new way and still meet existing goals and targets.

they believe the existing way is better.

they don’t think the new way will work.

they believe the new way will cause harm—to customers, the company, the employees, etc.

they don’t like or don’t respect the person requesting the change.

the new suggestion is counter-intuitive given people’s existing models of how the world works.

the new way runs counter to existing reward structures or other organizational systems.

When there’s been a failed change or a change that went badly, people may figure that they can simply wait out the change. I’ve certainly seen re-orgs done and undone within a year.  And not matter how good a change looks, it’s bad for someone, somewhere in the organization.

People have a valid reason not to change–from their own point of view.  Labeling them will not help.

Most change efforts take a deterministic approach to change.  Set the vision, establish a sense of urgency (usually through pep talks)  and then pull and push people towards the desired state.  That may work with a simple change.  But most change isn’t simple.

Entirely apart from the (normal) human responses to change, there are structural and systemic factors  that make change difficult in organizations of any size.

So sitting there in the BOF, I thought about the times that I’ve seen top down and bottom up changes grind to a halt.

Hierarchy acts as a filter. Change from the top can stumble when the desired change doesn’t mesh with realities on the ground. Other top down changes falter when there isn’t sufficient understanding of the gravity of the need for change–what’s self-evident at the top isn’t communicated to the people being asked to change. Some popular writers on change talk about creating a sense of urgency. One SVP attempted to generate some urgency  by declaring he wanted seven scrum team up and running by a certain date because it was his birthday–which generated cynicism.  Urgency doesn’t come from a “vision” or from pep talks. It comes from a clear understanding of the current reality and it’s implications for the organization (and the people in the organization).

Bottom up changes peter out when they run into systems, structures, policies, and procedures that hold the current pattern firmly in place.  For example, grass roots efforts to form teams can fail when HR mandates forced ranking.

From both directions, it’s critical to understand the visible and invisible structures and how they hold current patterns in place.

If you want to change patterns of behavior, you need to know something about the pattern you want to create.  You have to understand how the work works, see the system and change the system.  Pulling and pushing people won’t change the pattern (but it will result in the predictable responses that people have when they feel they are being pulled or pushed).

© 2007-2010 Esther Derby

This article originally appeared in my newsletter, insights.  You can sign up to receive my newsletter using the form on the right.

You’d think that since I’m president of a one-person company, I could change anything in my office in a snap. But a recent incident reminded me that change is always a process.

My dog, Pudge, comes to the office with me every day. Until recently, she spent her day on a blanket by the door where she chewed her on her bone between naps. When she wasn’t chewing or napping, she tugged the blanket around the floor. But this day, I’d stepped on the blanket and slipped one too many times—and frankly, the blanket was looking ratty!

So I decided to replace it.

Lesson 1:  A change usually represents someone’s best idea on how to solve a problem or respond to an external event.

I decided that a cushy new dog bed would solve several problems at once. It would stay in one place, look better, and provide a more comfortable nest for Pudge.

That’s usually the case with a top-down change. Someone is offering the best solution they know at the time to improve the situation. No matter what it looks like from below, people who initiate change hope and intend to improve the situation. But unless managers follow the rest of these lessons, it’s unlikely that the people who are asked to change will appreciate this truth.

Lesson 2: One person’s carefully considered idea is another person’s incomprehensible surprise.

When the new dog bed arrived, Pudge was curious about the box. She was even curious about its contents. But when I replaced her old blanket with the new bed, her curiosity ended. She picked up her bone and headed into the hall for a good chew. Then, one by one, she moved the rest of her toys out into the hall.

The people charged with formulating new strategies spend time thinking through the issues, economics, benefits, and risks. By the time they decide to implement a change, they have a thorough understanding. They’ve worked through questions, risks, and their own objections. And then they forget that other people have not had as much time to mull over the issues and examine the pros, cons, and imperatives.

It is very important for people to understand the thinking behind a change. They need information and time to digest it.

Lesson 3: The people seeking a change may value different things than the people expected to change.

When I bought a new dog bed, I was looking for neatness, containment, and easy washing. Although Pudge can’t tell me, I suspect that she valued the ability to tug the blanket around and actually enjoy its odor (she’s a dog, after all!).

When a mid-western company was purchased by a larger firm based in New York, headquarters assumed that the acquired company would appreciate new opportunities for advancement and travel. They were sure the mid-westerners would find their direct approach a breath of fresh air. But the mid-westerners valued balancing work and family life. The mid-westerners believed that being considerate was part of maintaining long-term working relationships. To them, the New Yorkers’ directness seemed disrespectful and rude.

People who ask others to change may not understand what value they are asking people to give up. And in fact, they may not appreciate or even notice what’s valuable to the people they expect to change.

Lesson 4: Change always involves loss.

I had every intention of providing something wonderful for Pudge when I bought her a new dog bed. But she didn’t see it that way. She lost her familiar blanket.

Even when there is long-term gain, the people affected by change will experience loss. They may lose established routines, patterns, and relationships. They may lose prestige, their sense of competence, or belonging. When you plan a change, think about who is benefiting and who is losing as a result of the change, and then be prepared to empathize with people’s sense of loss.

Lesson 5: Choice or coercion depends on where you sit.

I chose to change my dog’s blanket for a new dog bed. She didn’t have a choice—she wasn’t even consulted! “She’s a dog!” you may say. That’s true. Too often, though, intelligent adults are treated the same way when it comes to organizational changes.

People don’t resist change. Change that’s presented as “Follow, or be fired!” feels like coercion. And most people resist coercion.

Along with providing information, engage the affected people in designing the change.  Engagement increases support. People will still feel a sense of loss, yet they are less likely to feel like victims when they have information and some input in shaping the change. And the people closest to the work are likely to have ideas that will improve the implementation—if you bother to ask them.

Lesson 6: How people respond to a change is a rich source of information.

When people don’t do what we want them to do, change management professionals call it “resistance.” Resistance is something to overcome. If we look at it another way, how people respond to change is a source of information to refine ideas and shape implementation.

When people don’t do as we want or expect, it may be because:

• they don’t know how to do what they’re being asked to do.
• they don’t feel they have time to learn the new way and still meet existing goals and targets.
• they believe the existing way is better.
• they don’t think the new way will work.
• they believe the new way will cause harm—to customers, the company, the employees, etc.
• they don’t like or don’t respect the person requesting the change.
• the new suggestion is counter-intuitive given people’s existing models of how the world works.
• the new way runs counter to existing reward structures or other organizational systems.

Once you learn about the reasons behind “resistance,” use that information to adapt the change, provide needed training, or review potential roadblocks. Acting on the source of the response increases the chances the change will succeed.

Lesson 7: People change to retain something they value.

The second day after I introduced the new bed, Pudge followed me to the office but stopped at the door. I enticed her onto the new bed with a biscuit. She stepped gingerly onto the bed, picked up the biscuit and left. We repeated this routine for three days. Finally, after four days spent alone in the hall, she came into the office—not because she liked the bed, but because she wanted to be close to her human.

That’s true for people, too. Most people don’t change because there’s a good argument for a change, or even when there’s overwhelming data supporting the reasons to change (witness the number of people who still smoke cigarettes). People change to retain something they value. It may be an association with people or the organization. It may be a steady paycheck. Take time to find out what people value and how the change relates to what they value.

So what does my experience with Pudge and her new dog bed teach us about change? Lack of enthusiasm for a change proposal may not mean it’s a bad idea. But it’s a good indication that there’s work left to be done in introducing the idea, understanding what people value, and incorporating their ideas.

Most of my clients want to change something: they want to deliver software faster, reduce the number of defects the software they do deliver, and improve financial results.

Affecting these changes neither simple nor easy. Improving organizational results involves changing the work system on multiple levels. That means seeing the system, understanding that there’s seldom a single cause for the current pattern, and that the most effective lever may be an indirect one. It means discerning the shifts that will nudge the system towards the desired pattern.

Other changes aren’t so complex. Migrating software for example. On the surface, it’s a matter of switching one system off and another on, or reloading software on a desk top. Of course, the technical details are much more complicated; and as technical people, we are accustomed to navigating those waters.

But what about the people who use the software? Some thoughts on that complication here: Software Migration is a People Problem. Treat it That Way.

Esther Schindler recently put forward a scenario about a struggling employee named Frank, and solicited advice from her network.

Briefly, the scenario is this: Frank was a great maintenance programmer, but the company is retiring the system he worked on. Frank has moved to a new project in a new language and he’s not catching on. (Full scenario is here.)

The Other Esther summarized the advice she received in When the Job Changes But the Programmer Doesn’t and When the Job Changes But the Programmer Doesn’t Part II: Saving Frank’s Job.

My full response (excerpted in Esther Schindler’s posts):

It sounds like Frank has been a valuable employee. But now he’s in a position where his skills and preferences aren’t a good match for what the position requires.

So first, I’d think about whether there is a way to make use of his maintenance programmer skills on the new system. Can he fix bugs? Can he contribute domain knowledge in some other way?

It’s not unusual for people who are learning a new skill to follow rules rigidly. They haven’t internalized the new knowledge to the extent that they can see possibilities and use the skill intuitively.

The scenario doesn’t say how Frank has gone about learning the new language. Pair programming can be a great way to learn, and pairing a beginner with an expert can be enlightening for both.

I’d also look at how the work is chunked up. It may be that if Frank broke the work down into more discrete 1-2 day chunks he’d be able to make better progress.

If there’s no way to use Frank’s skills, then Frank’s manager needs to have another forthright conversation with him, explaining his expectation and concerns, and hearing Frank’s point of view, as well. Chances are pretty good that Frank is as distressed as his manager is.

But before the meeting, Frank’s manager needs to decide if he’s willing to give Frank another chance, or give him time to find another job within the company. If not, get the ducks lined up with HR to end Frank’s employment.

If Frank wants to try once more to get up to speed, they need to agree on a plan with specific actions. They need to agree how they’ll evaluate whether Frank is making the kind of progress the job requires. And the manager has to put a time limit on it–weeks not months.

If Frank recognizes that he’s just not in the right job, and he’s an employee that can still make a valuable contribution somewhere in the company, set a time frame for Frank to find a job internally–weeks not months. Start looking for Frank’s replacement. If Frank hasn’t found an internal job by then, end his employment.

If Frank isn’t a good candidate to stay at the company, don’t let the situation drag on forever. The current state is painful for everyone. And while firing Frank will probably be painful, it won’t be as difficult as the alternative.

A couple of things to emphasize:

Allow weeks not months to turn the situation around. That means 2-6 weeks, no more.

Choose based on how big a hit you can take on the project. Look at the trade offs. Some times no body is better than a warm body. If working with Frank is taking significant productive time away from others for little potential return, 0 weeks is the right answer. As Jerry Weinberg asked, “Is this a business or a charity?”

If Frank can be valuable to the company, but not on your project, set a time frame for *Frank* to find a new job. You are not a job placement service, and not your job to find him a new assignment. It’s Frank’s job to find that next assignment. You can offer to introduce him to people or give a reference, but Frank needs to do the work. And set a time limit 2-6 weeks, no more, depending on your project needs. Do not wait until Frank has found a a new assignment to start looking for his replacement.

I attended an Organizational Change BoF last evening at the AYE conference. Among other things, we talked about why it is that some managers fail to act when there are many signs of big problems.

I see three conditions that are prequisites for change (at any level):

People have to recognize the situation. One person at the group told a compnay that was losing billions, but kept cancelling projects that produced revenue, and funded projects that failed. The problem was obvious to anyone who *could* see. But the senior managers had a mental model of operating as a monopoly, and updated neither their mental models nor their corporate accounting systems. So they didn’t see it.

People have to believe it is possible to change the situation in some way. If people don’t believe it’s possible to change, they are paralyzed. THere are some things can’t be changed, that are out of the sphere of influence or control. People often forget that even when they can’t change external circumstances, they can change their response.

People need to have some idea of how to shift the situation. WHen people have no earthly idea how to shift the situation, they become paralyzed. So paralyzed that they don’t seek help in the form of new ideas or expertise. Or they grasp at the first silver bullet that’s offered (which often makes the situation worse). Or they do nothing.

So how do you create the conditions for change in your organization? Stay tuned. I’ll be blogging about that in the next weeks.

I got a call from an acquaintance, Gloria, who is trying to convince her organization to adopt agile methods.

“I’ve given them every logical argument I can think of,” she said. “They just don’t get it. All I get is blank looks. How stupid can they be?”

“They” probably aren’t stupid at all.

But they may have a different frame of reference, or a different mental model.

They may value something that isn’t considered in Gloria’s logical arguments.

They may agree completely with Gloria’s argument, but don’t see how to get to where she wants them to go.

They may be afraid that if they do what Gloria suggests, their managers will be angry.

What Gloria doesn’t get is this: while logic is appealing, it isn’t always the most effective tool for persuasion.

Rather than try to win through logical argumentation, Gloria might try understanding:

what other people value
what other people fear
what obstacles other people face
what problems they want to solve.

Back in February, I wrote a post on helping people change and pointed to George Dinwiddie’s post on Overcoming Resistance. His post has grown up to be an article, and it’s posted on the AYE Conference website.