A Tale of a Too-Hands-Off Manager
I recently worked with a team that was struggling. One of the team members, Tad, wasn’t playing by the rules the team had established. When the team formed, members agreed that each day they’d have a fifteen-minute stand-up meeting to report on progress. The team members 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.
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 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.
“When will you finish it?” the coach asked.
“I’ll be done when I’m done,” Tad replied. “I’m working on it.”
“That’s not good enough,” the coach said, laying down the law. “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 replied.
The coach tried benching Tad, telling him he couldn’t take any more tasks. Tad took them anyway, working at odd times, checking out code, and keeping a local copy on his machine.
After weeks of Tad’s odd 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 get Tad on track.”
“You are self-organizing,” the manager demurred. “You need to figure out how to deal with team members.”
And that was that.
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 iteration goals. And as their manager continued with his “hands off” attitude, team members’ morale plummeted. It 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 performance issue.
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 know when a light touch is called for and when action is needed? Ask:
- Does the team have the knowledge to solve this problem?
- Does the team have the experience to solve this problem?
- Does the team have the will to solve this problem?
- Does the team have 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 wary of stepping in. If it looks like you are trying to take the decision back or influence the team, your credibility is lost.
- What are the consequences of failure?
It’s been said we learn more from failure than from success. So do you really want to deprive the team of a learning 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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)