When to stand back, when to step in

Part of my definition of a successful team is that the members of the team increase their knowledge and capacity as a result of their work on the team. That means that giving the team the opportunity to learn is part of the job.

One of challenges I see when managers first start working with agile teams is knowing when to step back, and when to step in. Swinging too far in either direction hampers team learning.

Helicopter Managers step in too soon. They swoop in at the first whiff of a problem to "rescue" the team. They deprive the team of the chance to think, solve problems, and decide together. These managers may believe they are doing the team a favor; what they really do is hamper the team's development.

Absentee Managers throw up their hands and say "you figure it out," no matter what the issue, or whether the team has the skill and authority to solve the problem. These mangers let the team flail and churn, wasting time and building frustration. People do learn from mistakes; but when people feel frustrated, hopeless or abandoned by their manager, increased capability is not the likely learning outcome.

Self-organizing teams still need managers. But those manager need to know when to step in, and when to stand back.

Here are three guidelines to help managers gauge their actions with self-organizing teams.

#1. If the team has the skills to solve the problem--or they are on the verge of having the skills--give them space to solve the problem. If they're stuck or don't see how to use the skills they have, ask questions to help them get unstuck. They will learn much more from wrestling with the problem than having the manager fix it. (Assuming it's not a management problem. Then it's managements job to fix it.)

#2. When time is not of the essence give the team time to work the issue. If it takes a day or two to solve the problem, will it bring the company to it's knees? (If the answer is yes, you've got bigger problems than working with a self-organizing teams.) Keep in mind that many companies live in permanent fire-fighting mode and believe that everything is urgent. Or the manager believe that people won't actually apply sufficient effort unless they believe the issue is urgent. Again, that's a bigger problem. OTOH, if there's information that will help the team solve the problem give the information. Withholding the information is just plain wrong. Likewise, if there's a very simple solution that the team is overlooking, ask questions to help them discover it.

#3. If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time. If the solution space isn't bounded, then there's something amiss with the way the problem or decision authority has been delegated. Bound the issue so that the team is involved and there's appropriate fiscal and management oversight.

There's always a trade off between expediency and a learning opportunity. Self-organizing teams can outperform manager-let teams....but only if the managers are willing to navigate the balance.

Shifting from a manager-led team to a self-organizing team is a little tricky. It calls on a different set of skills, and brings up questions about value and identify for many managers.

But there's still plenty of work for managers to do. It just doesn't involve task management and having all the answers.

system blindness

One of the big problems I see in organizations is that managers who want to improve productivity pull the wrong levers.

For example, one company I know of decided to improve performance by ranking everyone in the company from 1...n, and firing the bottom 10%. Not surprisingly (to me at least), performance didn't get better. But the managers were surprised (when they noticed at all).

Individual performance is important, but it's often not the primary lever to improve organizational performance--it's the work system that needs improvement.

In the company that tried ranking to improve performance, there was no clear product direction, priorities shifted weekly, and teams where broken and reformed every few months. Improving any of those factors would have had a much bigger over all improvement effect than forced ranking and culling.

We like to believe that people succeed or fail by their own efforts. I don't discount individual effort....but focusing only on individual effort blinds us to system effects.

Self-organizing Teams Interview

Bas de Baar and I had a little video chat about self-organizing teams a couple of weeks ago. Video is here. (Thanks to Andres and George for pointing out the empty link.)

A Poor Performer?

Mark Levison has an interesting post in response to a Scrum Development discussion about "bad apples" on a team.

Before applying the label, look for reasons the person might not be performing. There are lots of reasons for a temporary dip in performance. Or, it might be a problem with the tools available, or the environment. It's very common to attribute problems with the system to the individuals (and vice versa).

Our own prejudices can get in the way. My friend Jerry tells a story about when he was a grader for a college course. His job was to read essays and grade them based on criteria. When he turned the grades over to the professor, the professor challenged one of the grades, an A. "You can't give this person and A," he said, "he's a C student."

Mark offers a quote from Linda Rising:

"In many cases, a supervisor “determines” the ability of a worker in about three weeks, labelling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice."

Mark advises:

So before we rush off to action on poor performers:

Stop, let go of preconceptions
Re-examine the person's role on the team
Listen/Watch - don't measure
Only if there is a problem - then solve it.

I agree.

Also see:

George Dinwiddie's Working Hard or Hardly Working, and my response.

and...
When is it time to move someone off the team?

A Conversation with Glen Alleman

'twas the night before Christmas, and all through the house, not a creature was stirring, not even a mouse...

But Glen Alleman and I were chatting via his blog about the difference between self-organizing and self-directed teams, and how failing to recognize the difference gets people in trouble from time to time.

A (slightly) edited form of the conversation:

Esther: I'd agree that self-organizing teams are not the same as self-directed teams. I specifically reference self-organizing teams, not self-directed teams. Self-organizing teams exist within an organization context and serve the needs of that organization.

I agree there is still a strong role for management in organizations that have self-organizing teams.

Glen: My experience has been whenever the term "self organizing team" is used it is taken to be "self directed." In the absence of a specific statement about the differences in the first sentence of any article the listener jumps to the end with "we're going to run our team in the absence of management." The next step is usually the cancellation of the project ;>)

Esther: As often as I see teams reject guidance from management "because we are self-organizing," I see *managers* abdicate any responsibility to the team or for the team. Neither stance is very productive.

But it does take both managers and team members time to figure out new roles and how to work in a new relationship. That's part of the reason I wrote the article.

Glen: It does take both side of the "team" to understand their individual and combined roles.

I've moved back into defense system for many reasons, but one is the continuous questioning of "how can this benefit the program as a whole - the entire business operation?" Management in this environment are the leaders of the subject matter experts, rather than the "supervisors" of the labor. We are working managers, rather than observers.

The article provides a wonderful starting point for the conversation about how each role contributes to the successful completion of the project.

###

My entire article (referenced earlier in this blog) seems not to be online right now :-(

What's a Manager to Do?

When the team self-organizes, the manager needs to step back, but not too far back; she needs to step in, but not to quickly.

My article on the manager's role in self-organizing teams is on the cover of Better Software Magazine and available on-line here. (link updated 2/4/09).

Magic Chemistry of Teams

George Dinwiddie has posted his notes from one of my AYE 2008 sessions, Magic Chemistry of Teams.

During the session, I asked people to draw a time line that represented their experiences working on teams, then, working in small groups, identify the factors that were present on high-point teams and low point teams.

Here's a partial list of factors present on low-point teams (posted on George's site):

no vision
bad results around us
bad fit of skills & interests
alone
angry boss/poisonous environment
no common location
lack of appropriate tools & equipment
specialization
One Jerk/personal conflict
lack of respect amongst team members
absent leader
lack of face-to-face contact
lack of clear priorities
judgemental leader
loss of team members
blame/shame
team too big

Notice how many items on this list relate to how the team is established: vision, location, skills fit, priorities, tools and equipment, team size. These are all within management's responsibility.

If there is a clear vision, clear priorities, necessary physical environment, the right number of people with the right skills, then it's more likely that the items on the "high point" list will emerge:

common goals
clear goal/vision
clear role/expectations
new/novel/learning
presence of great skill
self-organizing
ritual
team members value each other
good humor
ate together
camaraderie
appreciation
recognition
trust
passion
friendship
flow

Too often, managers throw a group of people together and declare it a team. Calling a group a team doesn't make it so. It takes work to establish an environment where team work will emerge.

(It takes collaboration skills on the part of team members, too, as in Secrets of Agile Teamwork, coming up in February.)

What trust means for teams

It’s a truism that trust is the foundation of teamwork.

But trust is a big word. What do we really mean when we talk about trust?

First, trust exists within a context. The sort of trust that you need for a productive working relationship is different from the trust you need for a healthy marriage. And it’s certainly different from the trust you need on a ropes course (which is why that sort of team building activity seldom has much effect).

What you need for productive working relationships is trust that says:

I believe you are competent to do the work

I believe that if you have an issue with me, you’ll bring it up directly

with me, not talk behind my back.

I believe will follow through on commitments—or let me know when you need

to renegotiate.

I believe you have good intentions towards me and the team.

And there’s a prerequisite for trust: a person needs to have a capacity for trust.

When is it time to move someone off a team?

When I talk to teams about self-organizing, people worry about what to do when some one on the team isn't working out.

If we're a team, they posit, we have to work things out so we can work together. Not necessarily so.

Teams need to manage team membership so that they can achieve their goals. There are times when teams can work things out to work together. And there are times when someone needs to go.

I see four common reasons to move to move someone off a team.

When a team member doesn't have the skills needed to do the work and can't (or won't) learn them in the timeframe needed by the team and the business. This can happen because of a hiring mistake, when the company moves to a new technology, or when the focus shifts from one type of work to another (e.g., from manual functional through the GUI testing to automated testing through APIs).

This is really hard when it's someone who has contributed and now can't make the learning curve. If there's no other way for the person to contribute, it's time to move him off the team. In the long run, though, allowing the situation to continue doesn't do anyone favors. The team may start to resent the non-contributing team member. The non-contributing team member doesn't have the satisfaction of pride in work and making a contribution. Everyone suffers.

When someone can't or won't work collaboratively. For example, when a person focuses on completing his tasks at the expense of completing the team's iteration goal, or the rest of the team agrees to share code-ownership and he refuses to relinquish control over "his" code. Or when an individual doesn't communicate with other people on the team.

On a team with interdependent goals, having a member who refuses to collaborate (for what ever reason) makes it harder for everyone to do their work. It also creates a dynamic where team members focus time and energy on the behavior of one team member rather than on building working software. It's futile to try to convince someone to work collaboratively when he doesn't value collaboration.

When the person challenges efforts to move forward that aren't perfectly aligned with his ideas. Sometimes an individual sees risks in an option and has a hard time talking about it in a helpful way. Usually this comes as "that will never work here," or "we tried that and it didn't work". This is irritating; AND there's often useful information behind the objection--when you tease it out. (And you can coach the person to modify their style.)

On the other hand, some people challenge efforts to move on a philosophical basis--they call into question whatever the team proposes on the basis of an abstract notion of how-things-should-be. It's really easy to get hooked on the content and get sucked into discussions about why some action is or isn't pure and correct.

There is a place for "devils advocating" and vetting actions against fundamental values. That's an important function on any team and I'm not talking about eliminating it. However, when one member has a pattern of challenging efforts to move forward, not letting go, and killing new ideas with criticism, its a problem. Especially when the challenge shifts to meet each new proposed avenue of progress that doesn't meet the purity test.

When someone has a fundamentally different vision of where the team should go. A few years ago, I was traveling from Amsterdam to Copenhagen by rail. My route required that I change trains twice. As I settled in to my seat after the first train change, a nice German woman asked me where I was going. "Copenhagen," I replied. "Oh, no, my dear," she said, "you are going to Berlin." I guess I could have argued, but instead I got off at the next station, back tracked, and got myself onto the train that was going to where I wanted to go.

It's like that sometimes with teams. Most of the team wants to go in one direction, and one individual wants to go in a dramatically different direction. And he argues for that direction, well after the majority of the team has expressed their commitment to go another way. The team spends lots of time trying to convince the one person, and that person spends a lot of time trying to convince the team. At a certain point, it's time to say, "This is where we are going. We want you to come with us. If it doesn't fit for you, we understand. And you'll need to go your own way." Early in the life of a self-organizing team, the coach may have this conversation. Some teams reach the point where they have the conversation amongst themselves.

There's a risk that the individual has the right of it, and the team is headed in the wrong direction. But if the team makes some movement, they are likely to discover that, and then they can make corrections. As long as the argument continues, no one is moving at all.

Excluding some one from a team is difficult. Most of us want to feel included and part of the group. That's a potent trigger for most of us. Some people feel overwhelming anxiety over excluding someone from the team. For others the need to belong is equally overwhelming. Helping someone move off a team is seldom easy. And when it's done--and handled with respect and caring for the person who is leaving the team--it's doesn't have to be a traumatic event for anyone.