In response to a tweet on the benefits of stable teams, someone asked whether I’m against changing teams (aka re-teaming) in response to business needs. I am not. 

I’m against churn. 

There are plenty of good reasons to re-form teams to meet organizational needs. And there are good reasons to attend to creating conditions that support success when you do so.

Don’t Play Johnny Appleseed

The Johnny Appleseed* of legend traveled through Pennsylvania, Ontario, Ohio, Indiana, and Illinois, randomly sowing apple seeds. Trees sprung up where ever he went.

I’ve seen many managers/executives break up great teams and try to “seed” the goodness by sprinkling those team members across the organization. They seem to think that the team was the results of extraordinary individuals. Therefore, forming a team around a great individual who was part of a stellar team will result in another great team.

There is a non-zero chance that this will succeed. But it is just that: a tiny chance. Don’t count on it. More likely, you’ve broken up a great team in favor of a few mediocre ones.

Be Intentional

Obviously, there are good reasons to re-form teams. The key is to do it with conscious intent and conscious attention to team composition, formation, and learning.

In many organizations, teams are formed and re-formed around what ever work is in the pipeline. I’ve seen teams reformed monthly.

One way to avoid churn is looking at the work in the pipeline. Look for patterns in which parts of the system are involved. At one client there were very clear delineations. Certain features touched A, B, C, D. Others touched A, C, F, H, and a third group involved E, G, H. They chose to organize teams around the first two feature profiles, because their were few features in the third profile.

An equally valid approach would be to have an explicit team rotation that exposed everyone to all parts of the system. Over time, this enables fluid re-teaming with a larger group of people. I’ve heard of this working with groups of up to 50. 

The Nightmare

One of the worst situations I’ve heard about came up in a workshop I lead.  People shuffled on and off the “team” every couple of weeks. The only things stable about that team was the box on the org chart and a beleaguered ScrumMaster. 

Management was coming down hard on the ScrumMaster because productivity was in the ditch. How could it not be? My short term advice to the ScrumMaster was to slice stories as thin as possible and always do pair or ensemble programming.

Every Change Means a New Team

Changing membership—even by one person—means you have a different team

While skills on a resume may seem equivalent, that only accounts for a sliver of the skills that contribute to team collaboration. All the individual’s implicit knowledge leaves with them. The new person’s “white space skill” won’t be the same as those of the departing person. The team won’t have the same knowledge base and won’t function in exactly the same way.

Moving several team members leave at the same time damages the pool of implicit knowledge even more.

Re-forming teams to “shake things up” will indeed shake things up. Things like working relationships, pools of implicit knowledge, subtle understandings of how to work together. Shake ups also mess with productivity levels. Some teams recover. Some teams never do.

Consider the Learning Challenge

It takes time to develop a reasonable grasp of the code base.  

It is a lot of work to develop a complex system incrementally. But, if you are there at the start, your mental model grows of the system grows as the system does. The cognitive task is inventing.

However, trying to develop a mental model of an existing complex system is  much more difficult. This is an analysis task, and is monumentally different. 

This is often overlooked when re-teaming. 

A new person joining a team, at best, has a partial mental model of the system. They may understand it at the architectural level, but that isn’t sufficient to be fully effective. 

It is even harder when the system is constantly evolving, as the new person tries to understand it. 

Without conscious attention to learning, the timeline for a new person getting up to speed stretches out. When this happens, people start to question the new person’s competence. Confirmation bias kicks in, and people see reasons to confirm their assessment.

Sometimes people don’t work out—but it is far more likely that the process of supporting someone to become effective is the part that is defective.

Programmers are Not Plug-and-Play

The challenge of learning a new and complex domain doesn’t exist in every field. For example, for technicians in hospital settings the domains are stable. Each knows the procedures and equipment of particular specialty. The system they work on—the human body—is a constant. Their challenge in re-teaming is more about coordination and working effectively across their disciplines.

In software, people may have some level of specialization. They also have to learn how to work effectively across disciplines. But the system is alway different to a greater or lesser degree.  Stable teams give the time and space for people to learn how to work together and develop a deep understanding of the unique domain.

And that’s why we have to approach re-teaming with care and consideration.

---

* The real Johnny Appleseed was a nurseryman, who sited his apple tree plantings carefully. He returned at intervals to check on them and nurture them. He also used his orchards to establish land claims.