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