Shifting the Pattern: A Systems Approach to Change

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.

Containers sketch

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

10 thoughts on “Shifting the Pattern: A Systems Approach to Change

  1. Thank you Esther. Food for thought. Read this from my iPhone. Will read again soon and reflect more upon it. /T

  2. This is excellent. It is so good to see an article that is clearly based on some particular experiences.

    Also, for me, this works much better than a dressed up story with made-up names.

  3. Thanks again for the session ! I was really surprised to see that I used the concepts of containers the next day already in another session.

    1. It was my pleasure! I’m glad were able to apply it.

      On another subject, I’ve installed Rosetta Stone on my mac and I’m practicing French. 🙂

  4. Great post Esther. I often see that organizations that struggle with Agile (or being successful in any regard) think sticking people together into cross-functional teams is enough.

    When the results aren’t what they expect the conflicting agendas of functional departments gets in the way and the team is blamed for not working hard enough.

    I’m a fan of the statement “people are doing the best they can with what they have” A programmer doesn’t come to work with the intent of writing the worst possible code they can think of, they do the best they can based on the parameters of the system.

Comments are closed.