Tag Archives: systems

Some pundits proclaim that leadership rests on charisma, the ability to create a vision, or “presence.” Teams do need a vision and a compelling goal. But do teams need one charismatic leader? No.Teams need leaders of a different sort. Teams need leaders who don’t need to be out in front, who are able to work quietly, creating an environment where everyone on the team is empowered. Such leaders–empowering leaders—may not get the glory. They do help teams get work done, invite creativity, and build capacity. How do they work? Not by rousing speeches, through followers or by exuding some magical stuff. Empowering leaders create an environment where everyone is empowered. The act on observation, not gut feel or random action.

As Yogi Berra pointed out, you can observe a lot just by watching. But what should you watch? How do you make meaning of what you see?

We are bombarded with sensory input, and our brains are built to find patterns. They are also build to filter out data. Empowering leaders can’t rely on innate observation abilities. They need to hone their awareness to make their interpretations reliable guides for action. Empowering leaders hone awareness in three areas:

Self-awareness. They know their own strengths, patterns, blind spots.

Team Awareness. They understand group dynamics and understand that teams are goal oriented social units.

System Awareness. They grasp that the team exists within a larger system, which includes the organization as a whole, other teams, customers, work flows, and policies.

The average person knows quite a bit about him or herself. He knows what he likes, and what he doesn’t like. He probably knows whether he likes to decide quickly, shoot from the hip, or examine all the options before choosing. He probably knows whether he is mad, sad or glad at any given moment. He probably thinks he knows what he’s good at.

Average self-knowledge isn’t good enough for leaders. Empowering leaders observe their own thoughts and feelings, so they can manage their emotional responses. They separate the data from the interpretations they make of data. They understand their thought patterns, and how they respond to stress. They understand how that not everyone sees the world the same way (and that’s a good thing).

Empowering leaders learn to observe the team and discern patterns of behavior on the group level that effect that ability of the group to get work done. They notice who offers ideas, who challenges ideas. They notice when one person consistently interrupts another team member. Leaders hone their ability to notice the roles people take in group discussions, and pick up on non-verbal cues. This is the information that allows them to determine what is happening, and what (if anything) is needed to adjust the environment so everyone is empowered and able to work. Empowering leaders notice how the physical arrangements affect work, how information is flowing (or not), and when the constraints on the team are too few or too many.

Finally, empowering leaders pay attention to the context, the world the team works in. How does work flow into the team? What are the relationships with other parts of the organization? Are their policies and procedure that are hindering the team? An empowering leader on a team may not be able to eliminate such factors himself. But he knows how modify the team environment to lessen harm, and to influence out side the team to achieve change.

Awareness gives leaders the ability to make sense of the data. Then, they can choose from a variety of responses that will influence the environment to empower all members of the team to contribute.

An effective hierarchy provides enough central control for coordinated action in achieving the aim of the organization. At the same time, the hierarchy must provides enough autonomy for subsystems to function, self-organize, flourish.

Yes. But how to do that? Let me walk you through a scenario that describes the challenge.

I’ve seen a number of organizations decentralize control and decision making, only to pull it back to the home office. If you watch long enough, many of these companies after experiencing centralized control for a while, go back to decentralized control–like a pendulum swinging back and forth.

Here’s how it goes.

As a result of centralized control, decisions are slow. Slow decisions and top down plans that require an act of god to change lead to poor financial performance, and customer dissatisfaction. Because people are effectively denied discretion, creativity plummets. Rigid plans and targets don’t allow people to take advantage of new opportunities.

When the financial results start to trend down, senior management notices. They want faster decisions, and front-line people who are responsive to customers. They want creativity, innovation. They want to seize emergent opportunities and respond nimbly to change. They want better financial results. Who wouldn’t want all those things. So they decentralize.

After the initial flush of enthusiasm, they start noticing problems. Visibility decreases. Decision making and spending feel out of control. Some subunits make inappropriate decisions. Subunits optimize at their level, forgetting the overall goal of the organization. Some subunit managers go rogue, and strike out in directions that make no sense for the overall company strategy. Financial results dip.

And the managers want a return to clear lines of communication and authority. They want visibility, coordinated action. They want predictability, consistency. They want CONTROL. So the pull decision making, planning, budgeting back to the center.

While the supposed solution seems to be swinging between two poles, the organization and the people in it experiencing an oscillating effect.

In truth, the company doesn’t want either end of the pole. They want the upside of both centralized control and decentralized control. They want enough control to effectively coordinate actions of the various parts of the system to achieve the goal of the organization, And they want enough autonomy so that all parts of the system can flourish, self-organize and respond to opportunities and change.

Why do systems oscillate? Delayed feedback and an over-vigorous correction. This happens on the organizational level, but it can also happen on a smaller scale anywhere in the system where feedback is slow and well-intentioned people over-correct when they do get feedback on system performance.

In order to achieve the upsides, organizations need to manage the downsides. And that requires faster and more robust feedback loops. Those feedback loops will provide information about system behavior sooner, and allow smaller more nuanced adjustments.

Not so very long ago, I made my living writing code. My colleagues and I did our best to understand what our customers needed, and to write code that was easy for other programmers to understand, solid, defect free. When our managers asked us how long it would take to create a new feature or modify and existing program, we studied the problem, considered how much code we’d need to write or change, how we’d integrate the new functions with existing functions, and what sort of testing would allow us to feel confident our work was complete and correct.

Our managers were often not satisfied with our estimates. They wished we could deliver working software more quickly. They suggested we were exaggerating how complicated the work was. They hinted we were padding our estimates, and spoke sternly of work expanding to fill the available time. Then they revised the estimates to fit their desires and handed down a due date.

Strangely enough, the work usually took longer than the managers wished it would. Our managers contemplated the gap between wished-for and actual delivery and pronounced us not sufficiently productive.

And so the quest to improve our productivity began. First it was CASE tools. They were supposed to improve productivity by an order of magnitude (they did not). Then came Rapid Application Development (apparently the managers stopped reading after “Rapid”). The next improvement, Object Oriented programming, was supposed to save the day (it did change the way we think about programming). When I left that company, the productivity pill was a development methodology that took up an entire 4-foot bookshelf.

And the quest to improve productivity in software organizations marches on. More and more often, the quest includes some flavor of Agile Methods, and a promise of hyper-productivity, quick delivery, and change for free.

Agile methods can help achieve business results, get software out the door faster, adjust to new priorities, and dramatically reduce the number of errors that reach the customer.

Agile encourages close collaboration with a product owner or customer (whether that’s an internal customer proxy, product owner or an end-user of the software). This helps teams understand the customer and his context, so they can make better decisions about feature design. Short iterations and frequent demonstrations of working features keeps development close to customer needs and wants.

Agile methods encourage planning based on demonstrated capacity, using agile methods can help prevent cost overruns and help managers make decisions to continue funding feature development–or not. Iteration planning and tracking story points helps teams and management understand capacity. Without this information, plans are merely wishes. Armed with such information, managers have the opportunity to review progress and viability at the end of every iteration.

Working in short iterations to produce working software can allow a company to realize revenue early; when teams finish small chunks of features each iteration, it’s no longer necessary to wait until all the features are completed to test and deploy. Every feature slice is tested and ready for customer acceptance at the end of the iteration. When the slices add up to a marketable set, managers can choose to release.

Agile engineering practices such as automated unit and customer tests, pair programming, and frequent integration find errors early which reduces the number of defects released to the customer. That results in lower support costs, find and fix costs and bad press generated by buggy products. Practices such as simple design, Test Driven Development and refactoring keep the design flexible and clean, avoiding design degradation and escalating costs for future changes.

Many teams who use agile methods are building strong cross-functional teams and report that their satisfaction with work-life and work/life balance is higher. Working at a sustainable pace and re-establishing pride in work bring intrinsic motivation. That makes it easier to attract and retain employees.

But when agile methods—extreme programming, scrum, kanban or some combination there of—are imposed as a way to “fix” perceived programmer productivity problems, the effort almost always fails. Sheep-dip training programs, “going agile” by decree and cherry-picking the agile practices that don’t seem difficult won’t achieve great results.

No method, or set of methods can improve results unless managers also change the way they do their work.

Managers need to get organizational systems working. Managers must do the hard work of understanding the market, their customers, and make difficult choices about what work to do and what work not to do. Managers need to study how teams and organizations really function and then create systems and environments that don’t hinder people from doing work.

Writing software is hard. Agile methods can help. But they are not a silver bullet. And no method can improve productivity unless management also changes.

There’s a buzz about systems thinking in the software world these days. Systems thinking isn’t new. Jerry Weinberg’s An Introduction to General Systems Thinking was first published in 1975. Senge’s Fifth Discipline came out in the 90s.

Still, we haven’t turned the corner on this thinking revolution. That may be because the pragmatic benefits of the systems thinking approach aren’t always clear, and some people find system diagrams inaccessible. Further, it’s not always easy to see what’s a system problem and what’s not.

You probably have a system problem if:

You have tried repeatedly to solve a problem and it keeps coming back

You replace people and the overall behavior doesn’t change

Multiple factors interact to produce the result.

When you suspect a system problem, gather data that will help you understand the how the system performs, and how various factors interact. The following steps outline one way to “see” your system.

1) Expand the time horizon. Look back to the point where the problem may have started. If you have historical data, look back at least two years. Notice any events that might have precipitated the problem (but don’t jump to conclusions).

2) Brainstorm factors that might be related to the problem. Choose factors that are potentially measurable. Name those variables using neutral or positive language to avoid confusing double negatives.

3) Sketch a graph of the variables to see how they move in relationship to each other. Notice whether they move in parallel, in opposite directions, or seem unrelated.

4) Formulate a hypothesis based on the graph. See if you can test it in a small way.

Here’s how one group of managers used this process to understand and improve their system.

During the year-end financial review the executives at FinCo were displeased that most of the IT projects were at least 100 per cent over budget. Wanting to educe budget over-runs, the executives established a bonus target tied to meeting +/- 5 per cent of the original project budget. They reasoned that project managers weren’t trying hard enough to meet budget targets, since there was no real consequence (to the project managers ) for not meeting targets. The incentive, they reasoned would provide the will project managers needed, and focus their attention that important number.

At the first quarterly review, most of the projects appeared to be on track to meet the target. But as the year went on, it was clear that many projects were still blasting through budgets at an alarming rate. Since the incentive was clear, it must mean that the current crop of project managers didn’t have the skill to deliver to budget, they reasoned. This time the executives replaced the project managers.

But there was no cheer at year end. Once again, every single project was over budget. Faced with another year of disappointing results, the executives decided to try another approach. The fact that the results didn’t change after they changed the people made them think that perhaps their project managers weren’t entirely at fault.

First, they expanded their time horizon and looked as far back as they had project data. They were shocked to see that out of dozens of projects, only one had spent less than 100% of it’s original budget–and it wasn’t a project managed by one of their replacement project managers, the ones they had hoped would work miracles.

Many projects spent 200-500 per cent more than their original budget. Could it really be that, over six years only one project manager had the will and skill to meet the budget? Based their previous interventions, they could see that changing incentives and changing people didn’t change the result. (Though changing the incentive did bring a change in behavior: project managers managed to game the numbers, at least early in the project.)

The executives brainstormed a list of potentially measurable factors of that might be related to the problem: size of project, lack of involvement of business stakeholder, number of scope changes, team size, length of project, number of new technologies, staff turnover, full-time vs. part-time team assignment.

To make it easier to see relationships among variables, they used neutral or positive words to avoid confusing double negatives. For example, stakeholder involvement, rather than lack stakeholder involvement.

They decided to look at three factors: stakeholder involvement, measured by the number of meetings between the stakeholder and the project team; original project size measured in effort months; and number of new or unfamiliar technologies used on the project. They didn’t worry about having precise measurements–they were going for a rough picture that would help them form a testable hypothesis.

Here’s what they saw:

Based on this initial sketch, they did more research and more graphing, looking for useful information about how their projects worked, and which levers were likely to reduce budget over-runs.

When the next project prioritization came up, the executives formulated an experiment. They chose two of the biggest projects. They set a guideline that these projects use rolling budget and deliver some piece of useful working software within three months. They directed the project sponsors and project managers of those projects to work together to identify smaller chunks of work that the projects could teams could build in short time-boxes, leading up to the three-month delivery. They also gained commitment from project sponsors to participate in project meetings.

At the end of three months, both projects had delivered useful software. Neither hit their budget numbers exactly– as one would expect. However, both stakeholders agreed that the new arrangement helped build confidence and trust. All agreed they had a better basis to predict costs for the next timebox than had been possible at the outset of the project.

Based on these results, (and despite some grumbling about re-work and wasted work in progress) the executives revised their project portfolio. They structured projects to complete useful working software within three months–at which point they could re-evaluate based on data and the current environment. Rather than plan and budget a year ahead, they committed to adaptive planning and incremental funding.

Initially, the executives in this story believed in their budget numbers more than they believed in their project managers. It is common for people to put faith in predictive numbers such as budgets and estimates. That faith led the executives down the wrong path–they tried to fix the problem by fixing their project managers. It wasn’t until they looked beyond the budget numbers that they began to see their project system and understand how to improve it.

Of course budget reports can be useful; while they can alert you to a problem, they don’t give you the information you need to really improve the situation. To do that, look beyond budget reports. If you want to steer your system, you have to see it first. Using the steps described in this article can help you understand problems in your organization–whether the problem relates to projects, technical debt, or staff turnover–and see the dynamics of your system. Armed with that understanding, you’ll better equipped to find a fix that fits.

You can sign up to receive my newsletter via email using the box on the right of the screen.

0. Most people in management roles want to do a good job, but may not know what to do or how to do it.

1. People in management roles are dealing with incomplete and ambiguous knowledge. It’s a fantasy that they have all the information and know what to do (which may be held by both managers themselves and people who wonder why their managers do clueless things).

2. Most people in management roles receive little or no training on how to be good managers. Many people are promoted into management roles because they excel at technical work. This is not an easy transition.

3. Many people in management roles are working out of a mental model of management that limits their effectiveness. (See Don Gray’s Managing in Mayberry for two common mental models and one that’s less common.)

4. Many of the role models new managers have aren’t helpful. If people have never experienced good management, you can’t fault them for a lack of imagination.

5. Much of the management training out there is crap.

6. People in management roles are expected to achieve results over which they have no direct control. They must work thru other people and create work environments and work systems that support other people to do excellent work. Most managers have no training in how to do this.

7. Most people in management roles face demands from their managers and from the people who report to them. The are pulled from above and below. These demands are not always aligned and may be mutually exclusive.

8. Middle managers receive little peer support. Most managers face isolation and competition from other middle managers who are trying to meet locally optimized goals, obtain scarce resources and look good to the next level up. This is even more salient for new managers. Power difference (not matter how slight) changes the relationship with former peers.

9. People in management roles need to see the system and work on system, but receive little to no training in system seeing/thinking/acting. Relentless pressure tends to hold their focus on short term events and results, making it difficult to see patterns and connect the dots of seemingly unconnected events.

10. People in management roles need to work on the work system; they are also in the system, and their behavior is shaped by the system they work in. Both top managers and middle managers fall into predictable patterns of behavior.

One of the biggest mistakes people make is attributing system problems to individuals (and individual problems to the system). If you try to solve the problem on the wrong level, you are doomed to fail.

Here’s a simple yet classic example of trying to solve a systemic problem on the individual level.

Bob Sutton recently posted a piece on Team Guidelines. (I have some other reactions to the post, which I’ll cover some other time.) The list starts with Show Respect, which includes “Show up to meetings on time.” One can deduce from this that people aren’t showing up on time for meetings–hence an exhortation to individuals to be respectful and arrive on time.

People showing up late for meetings is a common problem; I see it in almost every organization I visit.

When you look at the problem on the individual level, and as disconnect events, it limits the range of solution options. Thus the ground rules, feedback directed at individuals and the non-solving of the problem.

Showing up late for meetings is an individual matter of respect.

But if you want to understand the problem, look at the shape of the problem across the system:

A wider view of the "late to meetings" problem.

A wider view shows interconnections, complexity, and effects beyond a single meeting. From this view, the “showing up late” problem has much more serious effects than annoying and inconveniencing other meeting participants.

Taking a wider view shows that “showing up late for meetings” isn’t a trivial matter. Maybe if more companies took the broader view, they’d actually try to fix the problem, rather than telling people to “show respect.” For the most part, this behavior has little to do with intentional or unintentional disrespect (an exception described here, again, thanks to Bob Sutton). We’ll look at that another time.

I’ve seen lots of managers struggle to help teams. Often, they are driven by deadlines and goals set by their managers. They do what they think will help, acting out of their current view of how things work.

Sometimes they look for new ideas on how to manage. One of the ideas that’s been popular in the circles I travel is Lean. Lean suggests three things a manager should do.

1. Reduce overburden.

In manufacturing, overburdened machines break down. In knowledge work, overburdened people make mistakes, fall ill, or burn out. So help the team hold to a sustainable pace by managing the amount of work flowing into the team.

2. Eliminate unevenness in the work load.

The aim here is to create a steady flow. One way to do this is by using team velocity to allocate work (velocity is a measure of the completed work a team can finish within a specific time period). Create an even pace by allocating work in timeboxes based on measured ability to complete work. Over time, as the team matures, velocity may naturally increase. Even flow of work means predictable delivery.

3. Eliminate waste.

Anything that does not directly add value to a product is considered waste. Extra processes, task switching, and partially completed work are examples of waste.

These three things—reducing overburden, eliminating unevenness, and eliminating waste—work synergistically to increase the capacity of the system.

I don’t have a problem with focusing on these three areas. Many managers push too much work onto developers or demand overtime without understanding how that actually reduces the work completed (or completed to some quality standard). Many managers don’t understand how pushing to much work actually makes the work take longer–and paying attention to how work flows through the system is more important than looking at the speed of individual task completion. Many manager don’t understand the dynamics of work in process, the cost of multi-tasking or context-switching.

These things aren’t much taught in CS classes and barely touched on in many business schools. So it’s not surprising that they many managers don’t know about them. (I do wish people–managers and developers– would continue to study their chosen professions after they leave school, though. By that I mean study, not skimming a few articles. Though if they’re my articles, keep reading.)

And any tool (or piece of advice) can and will be misapplied. This is especially true when a tool is plucked from one context and applied in another and when the use of the tool is divorced from the thinking and philosophy behind the tool. (John Seddon has some comments on Lean and Tool Heads.)

Sadly, to many managers start at the bottom of the stack, and never get past #3. And they start on #3 without a deep understanding of how the work works.

That’s where managers get into trouble. When managers focus on eliminating waste without attending to reducing overburden and eliminating unevenness–or understanding how the work works, they do enormous damage.

I hear about managers who approach this out of a cost-control mindset–and start looking for ways eliminate wasted money by making sure they are getting the most out of every employee.

On paper, , “efficient utilization of resources,” seems a like a Good Thing (assuming that you are not disturbed by referring to people as “resources”). After all, if you are paying someone for 40 hours a week, its waste if they aren’t on task for each of those 40 hours, right? That’s the thinking.

One manager devised this workflow in the name of efficiency, eliminating waste:

This manager devised an "efficient" workflow.

It did look quite neat and efficient on paper.

But the team wasn’t performing as he hoped and he wanted to “fix” the team. He was upset that they weren’t achieving the improvements inherent in his work design.

It turned out that the product had dozens of code modules, and each developer specialized in a handful, but knew next do nothing about the others. Under the managers design, as soon as a developer finished one piece of work, he should take the next item in the prioritized queue.

If he knew about that code module, the process worked okay. But chances were pretty high that he’d pull a module he didn’t know anything about. Plus, they got calls from the support desk, from the product owner team, and the production support team, all of which were considered as priority interrupts (by everyone, including the manager–which he some how forgot when he designed the work flow).

It looked more like this. The arrows show communication flows related to an unfamiliar code module. This picture only shows work for one person…it would be really messy if it showed more. (I also found it quite interesting that testing was a sort of mysterious cloud in this organization.)

There were a bunch of ways to improve effectiveness at this company. But the fantasy workflow wasn’t one of them.

Rather than start with a slogan (“eliminate waste”), start by understanding how the work works. And that means understanding structures, behavior over time, communication flows. That’s management work. When managers take action without understanding the work or the theory, the result is seldom pretty.

I’ve been writing about seeing systems, and got to thinking about a company I did some work for a few years ago–because they were a great example of how focusing on events leads to blame and prevents people from seeing patterns.

Here’s the story. The customer service organization in this company had serious problems with availability of a whole slew of systems that their reps relied on.

It was such a problem that they created a new role and a new department to deal with the issue. The “availability analysts” were charged with collecting data, analyzing the data and supporting a solution to the problem(s).

And collect data they did. They had data on system performance, run times, crashes, errors, and abnormal conditions; server up time, server down time, software outages (by application and system component); problem escalations, helpdesk calls, and trouble tickets.

When they weren’t collecting data, they were busy creating “the deck” for the (dreaded) management meeting. The deck was pages and pages thick. Page one listed the lost productivity figures for the month, in “productive FTE minutes” lost. Page two listed the number of incidents.

Source Contributions to Total Outage Minutes for the Month

But page five was the big event: a pie chart that showed all the sources of lost productive FTE minutes for the month. The availability analyst walked the group pointing out that 25% of the outage minutes were due to network problems, 20% due to Mainframe outages, and so forth.

At the end of the pie chart report, the highest ranking manager would demand, “What are you going to do about this?” Everyone else at the table tried to look small. After some squirming, one of the lower ranking people would put forth an idea. “I’ll expect a progress report next month,” the top manager would say, sounding stern. And that was the end of the meeting.

Then, the availability analysts scrambled out to start chasing the problem of the month.

And it all started again the next month when the new pie chart was published.

Events, Patterns, Structure

Both analysts and managers were firmly focused on a snap shot of events, and missed the patterns. The way they were presenting information helped hide the patterns and keep the focus on the latest hot issue.

I worked to help them see the patterns, which lead to understanding structure and dynamics–and taking meaningful action.

Now, they did need to respond to events–bring the network back up, or swap out a server for example. They needed to adapt to some of the patterns. For example, figuring out how to deal with certain types of outages more effectively until deeper changes took hold.

But as long as they only focused on short-term events–the monthly outage minutes–there was little chance of improving the overall situation. They were system blind.

Contextual knowledge is concentrated at the top of the organization.We’ve long lived with the assumption that the people at the top of the organizations are the ones who understand the business. They understand the market, the product, the customers. They hold the financial information about how the company makes money and the current financial status. Since they hold this info, they also know what the company should do—on a strategic and tactical level.

One assumption behind this model is that the brains are at the top of the organization and the brawn is at the bottom. Knowledge flows down, but mostly on a “need to know” basis. So it filters down as a trickle, not a torrent.

At the same time, the hierarchy acts a filter from the bottom up.

Day-to-day knowledge about how things really work, who to talk to when you want to get something done, how to work the (doesn’t work as defined) process, work arounds, greasing the skids, what the status really is and other useful stuff is concentrated at the bottom of the organization.Implementation knowledge--how things really work and how to get things done--is concentrated a the bottom of the organization.

The higher in the organization, the more the day-to-day reality of business is abstracted to numbers. And because the people at lower levels in the hierarchy don’t want to displease people at higher levels, they tend to minimize bad news—so the picture becomes rosier with each level it ascends.

One can argue that this model of knowledge concentration has worked. There are many companies that started this way, and they are still around. But I think the days when it served us well are over. It doesn’t meet the needs of the our times or our industry.

For one thing, we aren’t pouring ingots. We do knowledge work. We need to know about the context, customers, and cash flow in order to make the right products.

We live in a time of fast change. The competitive environment and customer preferences can change on a dime.

This bifurcated concentration of knowledge does not serve us. It makes companies slow as requests for approval work their way up the chain. Worse, it makes companies stupid. Think about it. How many times has a decision from top management looked silly, misguided, or malicious given the realities of implementation? How many times has management countermanded a decision made close to the work because the people who made the decision were missing some piece of information about market context, customer needs, or how cash comes in the company door?If we want our companies to be smarter and faster, we need to increase the overlap of contextual and implementation knowledge.
If we want our companies to succeed, we need to make the over-lap between contextual knowledge and implementation knowledge bigger.

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