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

I received an email advertising  a workshop for managers, titled “Overcoming a Culture of Entitlement,”  last week.

Here’s the hook:

“When employees feel “entitled,” they resist change, they drag their feet, they’re not accountable, and leaders are constantly frustrated.”

Who are these leaders that are constantly frustrated?  Might they be the same ones who had a part in creating the entitlement culture they want to overcome?

To understand how people come to feel entitled, let’s look at the definition (from Merriam-Webster online):

en·ti·tle·ment Pronunciation: \-ˈtī-t^əl-mənt\ Function: noun

1 a : the state or condition of being entitled : right b : a right to benefits specified especially by law or contract

Employment agreements usually specify such things as vacation days, sick days, salary.  People are entitled to those by explicit contract.

I recently met a woman who was having trouble performing her job. Her desk and desktop computer were right by the window. At certain times of day, there was so much glare on her computer screen that she couldn’t do her job.  Further,  she suffered from light induced migraines.  Between the glare and a debilitating head ache, she struggling to do her job.

Under company policy, she was entitled to an ergonomic consultation to assess her office set up.  If she had a medical statement about her migraines, she would also be entitled by law to reasonable accommodation in the workplace.  That might include drawing the blinds or moving her to a different workstation.

(Her manager denied her request to close the blinds—and implied that she was selfish to want to draw the blinds when no one else was bothered by the sunlight.  The manager warned the other employees, “don’t you dare close those blinds.” Absolutely astonishing!)

But there are other types of contracts.

If company has given out a Christmas turkey for 25 years, people come to expect that this year at Christmas, they will receive a turkey.

If people observe that programmers are promoted from junior developer to senior developer on the 2nd anniversary of employment–like clockwork–they’ll come to expect it.

People come to expect certain patterns of behavior because they’ve experienced them over time.  Reliable, repeated behavior creates an implicit social contract.  When one party to the contract withdraws without notice or explanation, the other party wonders what happened, and may feel disappointed, angry, or mistreated.

2 : a government program providing benefits to members of a specified group; also : funds supporting or distributed by such a program

If an employee looses his job through no fault of his own—due to layoffs, or a position being eliminated—he is eligible for unemployment insurance. Most people who lose their jobs (even if they have been fired) believe they are not at fault, and are therefore entitled to unemployment insurance.

3 : belief that one is deserving of or entitled to certain privileges

Sometimes people generalize a social contract in one context to apply in others.  This happens most often when people experience a pattern of behavior from the time they are small children.

Kids who receive every toy, candy, item of clothing, pool party, trip to the amusement park and all else they ask for tend to develop a belief that they are entitled to everything they desire. Children who are protected from the consequences of their behavior come to believe that they can do what ever they want with impunity.

Personally, I’d try to find out about this mindset in the interview process.  It come under the heading of “maturity.”

A culture of entitlement is about patterns of interaction between managers and employees over time.

Few people get to feel entitled all on their own.

I suspect that the “frustrated leaders” mentioned in the email are dealing with the first type of entitlement, the sort that comes about when there is an implicit contract.  But they are responding to the situations as if it were the 3rd type of entitlement—employees believe they deserve privileges.

When there is a “culture of entitlement” it is that way because it got that way.  And it got that way because of the interactions between employees and managers as managers carry out (stated and unstated) company policies.

These “frustrated leaders” can change the dynamic–because they are part of the pattern.

They can do that in way that ignores their contribution to the situation and blames employees—forcing, cajoling, threatening, and manipulating them—as advised in the email.

The alternative is to own up to the part manager’s actions played, treat employees like adults, talk frankly about the situation, and renegotiate the social contract.

Between Kent Beck’s post on Capital Efficient UI Design and attending a UI conference this week, I’m prompted to write down a few thoughts on incorporating UI design into development iterations.

Establish critical design standards at the beginning and work out the details as the software grows.  Look and feel, when to use drop down menus, when to us pop-ups can be decided early.  But it’s not necessary (or desirable) to have a wireframe for screens that won’t be worked on for months.  Too much can change.

Use design critiques to increase the entire team’s understanding of UI design principles.  Design critique asks these questions:  What was the intent of the design choice?  How well does the design choice meet that intent? Is the intent appropriate for the situation?

The goal isn’t to make everyone into an expert UI designer.  But when everyone understands basic principles, communication about UI design will be smoother and more effective.  And the devs (or PO) will be less likely to go off and do something–with the best of intentions, but not enough understanding–that makes the system harder for the people who will interact with it.

Engage in micro iterations on screen design. Work in rapid feedback cycles. Change only one thing at a time, so that the effect of a change is clear.  Looking at the actual design rendered first in simple sketches and then on a computer screen (and there are tools to do this now)  reduces miscommunication and misinterpretation.

Design global navigation last.  Before designing global navigation, design screens with only local navigation–how people do the work of that screen.  Then, as parts of the system are ready to release, create an application map that shows hub and spoke relationships, selection screens, modal screens and links and build just enough global navigation for the current feature set.

Iteration demos to confirm acceptance criteria are necessary, but not sufficient.  End of iteration demos confirm that a small slice of functionality works as anticipated.  But it doesn’t tell you how much about the experience of someone using the system to do work. Watch people using  the software to understand their environment, work, and experience of the software. UX experts recommend that each team member spend 2 hours every six weeks watching people use the software the team members write.

These aren’t the only was to help UI design fit into an iterative development cycle.  But they are a start, and we need to start somewhere to bring user experience into agile.

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.