Sometimes, wanting to give a team space to take more responsibility, managers step back. Sometimes too far back. However, a too hands-off approach can be just as bad as micromanaging. Both inhibit learning and effectiveness.

A Struggling Team

I recently worked with a team that was struggling. One of the team members, Tad, wasn’t abiding by the team’s working agreements. When the team formed, members–including Tad–agreed that each day they’d have a fifteen-minute meeting to report on progress and synch for the day. They’d agreed that they’d chunk their work into tasks that were a day or two long, knowing that would help them stay on track and make progress visible.

But all was not well. When the other team members picked a story off the task wall, they’d break it down into tasks and post them back on the wall. When Tad picked a story, the card disappeared from the wall. At the stand up meeting, his reports were vague. “I’m coding,” he’d say.

a too hands-off manager

After a couple of rounds of such murky reports, two team members, Sally and Will, sat down with Tad.

“What’s up?” Will asked. “Do you need some help?”

“No,” Tad replied. “I’m working on it.”

“But we don’t know what progress you’re making,” Sally said.

“I’m working on it,” Tad replied, staring at the notebook in his lap.

“Tad,” Will implored. “You agreed to report tangible progress every day. We all did.”

Tad closed his notebook. “I’m working on it. Now leave me alone so I can keep working on it.”

The Coach Tries

The team’s agile coach tried, too. After a vague report in the next stand-up, the coach probed for more information.

“What exactly are you working on, Tad?” he asked.

“The reset feature,” Tad replied “I’ll be done when I’m done,” Tad said. “I’m working on it.”

“That’s not good enough,” the coach responded. “When you don’t report demonstrable progress, it hurts the team. We don’t know if we’re on track or not. We can’t give our customer an accurate read on meeting our iteration goal.”

“I’m working on it,” Tad reiterated.

The coach tried telling Tad he couldn’t take any more tasks until he finished those he was working on. Tad pulled cards anyway He worked at odd times, checking out code, and keeping a local copy on his machine.

The Manager Takes the Hands-Off Approach

After weeks of Tad’s strange behavior, the coach approached the development manager. “We’ve tried everything we can think of,” the coach said. “We need you to step in and help us work with Tad.”

“You are self-organizing,” the manager demurred. “You need to figure out how to deal with team members.”

And that was that. His hands-off approach amounted to abdication.

The team tried everything it could think of to induce Tad to report on his work, finish his work, and see his contribution—or lack thereof—to the team’s goals. And as their manager continued with his hands off attitude, team members’ morale plummeted. They felt like their manager had abandoned them. He had.

Fortunately for this team, the hands-off manager left the organization. The new manager recognized the team was struggling and handled the issue with Tad. Tad, in spite of his initial acceptance of team agreements, really didn’t want to be part of a team. He wanted to work on his own. Fortunately for Tad, there was other individual work he could do. The new manager coached him off the team.

Not Too Hand-Off, Not Too Hands-On

Managers of self-organizing teams need to discern when it’s time to step in and when to step back, allowing the team to solve the problem on its own.

How do you, as a manager, know when a light touch is called for and when action is needed?

Ask yourself:

Does the team have the…

  • knowledge to solve this problem?
  • experience to solve this problem?
  • will to solve this problem?
  • the courage to solve this problem?

If so, give the team some time to work out the issue. If you sense team members are stuck, coach them with open-ended questions to recognize the resources they already have to address the issue.

  • Is this a new area of responsibility for the team?

If the team is taking on a new responsibility—one that’s been yours in the past—offer a process to help the team make the decision or solve the problem. Be careful about stepping in. Looking like you are trying to take the decision back or nudge them in a particular direction will set back the team’s development.

  • What are the consequences of failure?

Everyone learns from trying things and making mistakes, reflecting on them and adjusting. Swooping in to fix things deprives a team of that opportunity. Consider the consequences of letting the team learn from its mistakes. Most projects can survive a missed iteration goal. Most projects can survive going a short way down the wrong technical path. But they can’t survive a team that doesn’t learn.


This article originally appeared as a sidebar to an article in Better Software magazine.

Pin It on Pinterest

Share This