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.

When managers want to improve financial results, they turn first to trimming costs.  This is the logical first place to look if balance sheets are your primary view into how the organization functions.

Many cost cutting measures do have an immediate effect on the balance sheet.  A layoff reduces labor costs immediately.  Cutting travel, training, and conferences is less dramatic, but also shows immediate effects. There are more targets deep in the budget detail lines:  unplugging the break room coffee machine, rationing pencils, paper, markers.

But the cost of cutting costs rarely shows up on the financial reports.

A small engineering firm axed the company lunch room and eliminated over $200,000 per year in costs. That gave an immediate boost to the bottom line.

One side-effect was visible immediately. Without the lunch room, some people at ate their desks, and some left the building for lunch. That was probably a wash, with the longer lunches canceled out by quick lunches gobbled while catching up on email.

A more insidious side-effect was invisible (at least on the balance sheet) for several months. The lunch room had been a hub of informal, cross-department communication.  People who didn’t meet in the normal course of business ran into each other over lunch.  Someone from environmental remediation might learn about a new potential project from someone working on a run-off project in the mining division.  Someone working on a mine project might learn that one of the landscape architects was looking for more work, and bring him in on a site remediation project.

Middle managers lost the big picture of what was going on in the company—which made it more likely they make decisions that were good for their group, but bad for the company. Specialists lost opportunities to gain the perspective of other disciplines on their projects though informal means.  Formal consultation required a billing number, so they didn’t happen.

That led to poor decisions, and disappointed customers.  It took half a year before the communication gaps started showing up in project cost over-runs. Finally, the company lost a customer.

That captured management attention. The immediate response was to make more cuts—including a layoff.  Fortunately for the company, one of the partners insisted on a systemic analysis to explain what had changed before taking drastic measures.

Focusing on costs almost always increases costs, even if the balance sheet looks better (at least in the short run).

If you want to improve financial results, don’t just look at the balance sheet.  Look at how your company creates value for the customer.

For a start, follow a product from the idea stage all the way to software on a customer’s computer and money in the bank. There are almost always ways to make value creation faster and more effective.

You can start with a simple flow sketch.  As you make the sketch, notice:

How much coordination overhead is self-inflicted?  One organization I know had trouble developing by feature.  The company was organized by component groups. Each group had it’s own set of requests and it’s own schedule—which by some mechanism resembling a miracle—was planned to come together in a working release every six months.  Managers spent weeks negotiating, cajoling, and demanding time from various component groups to get a feature out the door.  Once they gained agreement, it was  full time job to facilitate meetings, track  tasks across multiple groups, and manage dependencies. When decided to try a cross-component team as an experiment, most of the coordination overhead disappeared.

How much rework might be avoided?  Another was developing by feature, but waited until all the functions with in the feature were coded to start testing, usually a period of three to four months.  Then they began the process of discovering misunderstood requirements, infrastructure that didn’t work as anticipated, and errors that started in one part of the feature and were then perpetuated through-out the feature. Most companies can’t afford (and don’t need) a process that eliminates all rework.  But there are methods that can reduce rework and find and fix errors early, before the rest of the software is build on a shoddy foundation.

Where are the delays in the process?  Delays in knowledge work often center on decision making and approvals—involving the wrong people, excessive sign-offs up the chain, processes where the rigor doesn’t match the risk.  (A friend told me about an approval process in this company that cost over $50,000 in management time to okay purchasing a $300 piece of software for one desktop.)

These are just three of the areas for opportunities to enhance value creation. And when you do that, costs will go down. Focusing on how you get products out the door and making that process effective will improve financial results in the long-run more than any one-time cost-cutting measure will.

***

If you are ready to explore value creation in your company, I am here to help. Curious about how we might work together?  Start here.
© 2010 Esther Derby

“….leadership may be defined as:
the ability to enhance the environment
so that everyone is empowered
to contribute creatively
to solving the problem(s).”

Gerald M. Weinberg

I talk to many managers (and some coaches) who bemoan that their teams can’t function without a leader (in this case “leader” usually means someone who set standards, assigns work, and tracks progress, tells people what to do.  That’s a leader? What ever.)

It is true that some teams need a leader. Occasionally, I run into a software teams whose members were all recent college graduates. Those teams do need guidance. With a team whose members lack real work experience, it might well be folly to create a team charter and then set the team loose on a project that is the life blood of the company. Oh, wait. That’s how some really big tech companies started–and sometimes they weren’t even graduates yet…or in college. So it depends.

When the team isn’t a collection of juniors and still relies on someone else to give day to day direction, make decisions, assign work and track progress, I suspect something else is at play.

Now, I assume that most members of work teams are not utterly dependent people. They are adults.  They make important choices–where to live, when to invest. The enter into financial contracts such as taking out a mortgage. They make short and long term decisions about health and investments. They pay the bills on time. Some have marriages, and raise children.

Navigating life is just as challenging as identifying edge cases for testing, designing a data base or writing an algorithm. So you’d think such people could make decisions at work.

What happens when they get to work that makes them incapable of working without supervision?

Teams exist in relationship to the rest of the organization and their managers. The pattern of behavior on the team is in response to the system, environment and how they have been managed. Without intending to, a manager may create a team acts dependent. It’s a dynamic. Here’s how it works.

A manager–let’s call him Ted–tells a team he wants them to take more responsibility and be more empowered.

This is waaaaay different than the Ted the team has come to know. So the team hesitates.

Ted urges the team to step up, then crosses his arms over his chest and waits. The team hesitates some more. Then the tentatively begin a discussion, all the while looking over their shoulders to see how Ted is reacting (at least metaphorically speaking).

Then one of two things usually happens. In one scenarios, the team comes back with a decisions or takes a course of action that Ted thinks is a bad idea. So he countermands the decision. In the other, Ted, impatient with the time the team is taking to make a decision or act, steps in and tells them what to do.

You can guess what happens next. The team takes Ted at his actions, not his words. They know that he didn’t really want them to be more empowered and responsible. He wants to tell them what to do. In any case, once bitten, twice shy.

The next time Ted tells the team to be empowered (there’s a paradox in telling someone else to be empowered, isn’t there?), the team members sit back and wait. Ted can only take it so long before he steps in again.

And then you have this:



Management action reinforces team response. Team action reinforces management response.

It becomes a self-reinforcing pattern.

The good news about dynamics is that they are not immutable; they can be changed.

There are situations that call for one person to lead. Planning meetings, decision meetings, design sessions, customer conversations, and retrospective all benefit from having a leader—where leader is defined as one who provides a process and guides the group to think, learn, and decide together. Some work requires a supporting actor in addition to the one who takes the lead. And some decisions require knowledge that isn’t spread through the team. Then it makes sense to have one leader. But that doesn’t mean it’s a permanent position—far better for the team in the long run if it isn’t.

Teams need leadership and direction. Direction–the problem the team is chartered to solve, comes from management. But leadership comes from within and from all.

Leader-full, not leaderless or leader dominated.

Questions matter.  The questions we ask open one avenue of inquiry, but close others.  If we want to change the way we manage, we need to change our questions.  And so, here are my slides from my talk at Agile 2010:

14 Essential Questions aimed at refocusing management attention on creating work systems that work–creating products the customers want, returns that are acceptable to stakeholders, and providing satisfying work for employees.

Last summer I participated in a seminar.  The format included group discussion, and discuss we did.  But one member of the group, Bernard, didn’t discuss so much as pontificate…at length, and often on topics that were tenuously connected to the subject matter of the class.  And, when Bernard got to a pithy phrase, he repeated it three times:

Trust (pause) is the essence of change. (Meaningful look around the room).

Trust (pause) is the essence of change. (Meaningful look around the room).

Trust (pause) is the essence of change. (Meaningful look around the room).

Most of us in the group made our point in a minute or two.  Bernard went on for five or six.

I found myself feeling annoyed.

I also found myself waiting for the seminar leader to do something…redirect Bernard, bring him back on topic, give him feedback, something.  But the seminar leader just listened to Bernard, and nodded her head.

When we gave 5 minute presentations, Bernard’s presentation lasted 15.

I still found myself feeling annoyed.

I still found myself waiting for the seminar leader to do something…point out the time limit, give Bernard a sign he was over time, ask him to wind it up.  But the seminar leader just listened to Bernard, and nodded her head.

When I looked at my own motives, I realized that at first, I was giving space to Bernard, since I didn’t know him, and wanted to withhold judgement. But by the second meeting of the seminar, I was keeping quiet because I didn’t want to appear biased, since Bernard was from a different culture.

In short, I was participating in a situation where I felt annoyed (by Bernard), let down (by the seminar leaders), and put upon (by myself, for holding back). I was also withholding information from Bernard, and that was getting in the way of my having a constructive relationship with him. I wondered how many other people in the workshop were experiencing something similar.

Now, often our inclinations in such situations is to look at individual behavior, give feedback, and ask individuals to act differently. Sometimes that’s absolutely the right thing to do.  Other times, it’s more helpful to look behavior of the group as a whole.

One day, after Bernard went on a sententious ramble for the upmteenth time, I had a moment of recognition: we have a pattern here—repeated events that have meaning over time—and I am part of it.  I was colluding with the pattern, helping to hold it in place.

This time, when Bernard started his presentation by declaring he was going to play some music for us and announced “This is your time, I want you to get up and move to music,”  I decided not to participate in the pattern or wait for someone else to change it.

I took Bernard at his word (at least the first part of his sentence).  Rather than swaying to Bernard’s music for 10 minutes (as the rest of the group did), I checked my email.  I responded to a couple of items that needed quick attention.

When Bernard finished (15 minutes beyond the stated timebox) the entire group took a break.  During the course of the break half the group members talked to me about my action.  I was not the only one who was irritated by the way Bernard was interacting with the group—nor was I the only one colluding with the pattern. Bernard was taking up a lot of air time because we let him take up a lot of air time.  We had a choice. We could continue in the pattern, or we could shift it.

And we did.  When Bernard started down a topic that was unrelated, someone would gently remind him of the topic at hand. When he got close to the end of a presentation timebox, some one gave him a signal that he had two minutes left.  The first time it happened, Bernard looked shocked—a shift in the pattern can be disconcerting, especially when the previous pattern worked (at least for Bernard).

And we formed a different pattern. We stopped waiting for our “leaders” to solve all issues with the way our group handled disucssions. One of the people who had a closer relationship with him, spoke to him directly about how Bernard’s tendency to go on affected him personally. And we all started being more honest with each other.

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