Stable Roles ★

No, not THAT kind of stable!

In our organization studies, we ask teams to simulate their typical development experience. During one such exercise, the team described a quality crisis, and how they formed a task force to handle the problem. I was struck that the team seemed to thrive on crisis; crisis management was valued and rewarded. When I mentioned this during the debriefing, the architect said, "Yes, we run on crises like a car runs on gasoline."

... a team has been formed, and the ProducerRoles are in place. During the course of development, disruptions and distractions are common. The team's response to them can have long-term impact on the health of the organization.

✥ ✥ ✥

If a team overreacts to disruptions, the team can become perpetually dysfunctional.

A well-functioning team is like a spring, stretched over some distance. A disruption is like a wave induced in the spring; it travels along the spring for a while, keeping things from working as they did before. The right response damps the wave and life returns to normal. But the wrong response tends to amplify the wave and keep it going. In organizations, the danger is twofold: first, that the disruption interrupts the team more than it should, and second that the team members begin to see the disruption response as the normal way of life.

Disruptions to teams come in many flavors. The most obvious ones are crises such as emergency bug fixes. But team growth, changes in requirements, reorganizations are also disruptions.

Each disruption requires action which takes attention away from the task at hand. So the challenge is to take the appropriate action while minimizing the attention it draws away from the main job. An important aspect of this challenge is rewards: dealing with disruptions, particularly crises, deserves rewards, but one must be careful not to value fire fighting over fire prevention. People have been known to commit software development arson in order to become software fire fighting heroes.

Therefore,

Whenever possible, keep people in roles for at least the duration of the project release. Avoid elevating transient tasks dealing with disruptions to the status of roles.

Obviously, in order for this to work, the roles themselves must be around for the duration of the project.

The key is that as a disruption comes up, don't create a new role to handle it. Handling disruptions, particularly crises, has a certain status to it. If you allow a role to emerge, then the role institutionalizes the behavior, which tends to encourage the disruptions to happen. So instead, focus on nurturing the ProducerRoles. This can be done carefully in the rewards (see CompensateSuccess.)

Beyond typical crises, this pattern can be used as the team composition changes. Such disruptions may be less dramatic, but often are more devastating. Even team growth can cause serious disruption. So as the team changes, keep the remaining people in the same roles as much as possible. Instead, try to keep the role changes to the natural breaks in the project, such as just after the project ships.

✥ ✥ ✥

The impact of this action is many-fold. If you keep people in the same roles, the learning curve is obviously flattened. It helps maintain DomainExpertiseInRoles. If people's roles don't change when they must deal with a crisis, they still retain their primary focus. Furthermore, the organization keeps its values focused on the long-term solutions, and not on the short-term disruptions.

This may seem like simple common sense, and it is. But the trouble with common sense is that it is, well, so uncommon.