Systems drive behavior. Therefore, if you want to change behavior in an organization you need to understand the factors that influence the current pattern.
The managers in an organization have decided that they want the productivity and morale benefits of cross functional teams. They put together a cross-functional team–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. The technology is new and exciting. The market possibilities are, too. The managers really want to support teamwork and collaboration. So, they send the team to a team building offsite.
The team returns, full of enthusiasm. However, after a while, the managers notice that the “team” part isn’t working. Their efforts seem disjointed. It appears they’re working different priorities. While no one intentionally hoards information, somehow information that everyone needs to know doesn’t reach all members.
The managers recognize the pattern. It is the same one that prompted the move to cross-functional teams.
How can this be? The managers articulated a clear goal. The goal requires interdependent work. Furthermore, they communicated clearly that the team succeeds or fails together.
Why aren’t they acting like a team?
One could say the individuals aren’t team players. People are easy to see, and easy to blame. But I think that’s not the likely reason. Something about the structures in the organization caused the old pattern to re-emerge.
Containers, Differences, and Exchanges (CDE)
In every system these three factors (along with many others) influence patterns. By patterns, I mean events that have significance and occur over time and across the system.
Containers hold the focus of the group. They 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 within a given container, or between containers. Not all differences make a difference. Hair color probably doesn’t, but age might. Differences hold the possibility for complimentary action and for conflict.
Some differences are changeable, such as skills. However, others, like national origin or mother tongue are not.
Exchanges represent the flow of value within and between containers. Value might consist of information, money, energy, social connection. Allocated funds, salaries, policies, formal and informal communications are examples of exchanges.
The Current Pattern
Now, let’s look at the situation using CDE.
Two of the developers report to the same manager. However the third developer reports to a different manager. The testers report to the same test manager. Both the development manager and and test manager are in the engineering department. The UX designer has a different manager in the product organization.
Each of these managers has a different perspective. Their goals differ, and reflect the priorities of their managers. The people on the project know that they need to attend to their own manager’s concerns. Unfortunately, those don’t line up with the project goals.
The developers are on one floor of the building. While the testers are on same floor, they don’t sit near one another. Plus, they are two flights down from the developers. The UX designer sits in another building. Plus, he’s’ on four other projects.
Visualizing System Influences
Here’s a sketch of the containers for this team.
Solid lines represent strong containers. They represent professional identities, departments, and reporting relationships. These also represent differences. When containers mirror differences, they tend to amplify the difference.
The dotted line circle represents the project container. Arguably, that’s the weakest of them all. More factors pull them apart than hold them together.
Possible Ways to Influence the Pattern
The conventional solution might be co-location. That would probably help. However, moving everyone is not the only way to influence the pattern.
I a group of workshop participants to identify other ways to shift the pattern, using CDE. Here’s what they came up with:
- 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
- Align management objectives
- Cross-train to create generalizing specialists vs. specialists
- 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” might generate. And that’s the point. Looking at Containers, Differences, and Exchanges shows possibilities for action that will influence the pattern.
Glenda Eoyang identified Containers, Differences, and Exchanges in her work on Human Systems Dynamics.
Updated October 2020.
Thank you Esther. Food for thought. Read this from my iPhone. Will read again soon and reflect more upon it. /T
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.
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.
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. 🙂
We just posted a report of the session in French here : http://blog.soat.fr/2010/06/agile-conference-atelier-desther-derby/
If you’d like to practice more 😉
excellent… we just had some major changes in our dept… I think this will help me focus my team a little
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.