A Tale of a Too-Hands-Off Manager

October 21st, 2010
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.

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

20 Comments

  1. Sami says:

    I had similar experience with one of teams I was coaching in the beginning of an Agile transformation. The manager was a good manager (knew technology, was driving Agile practices), but he did not have any idea of self-organization. I think he was afraid for his power and could not make difference between independence and ignorance. “Don’t come to me anymore, you are supposed to be self-org”.

    In that case the situation improved when we agreed with the manager about boundaries and explained he has a key role in helping the team. The manager realized he has a role and that he still was listened & respected by the team. His initial response (I learned later) was that he was against the idea and showed his opinion through ignorant comments.

    I think many managers are afraid of self-organization. They fear for their job, and loss of their position & respect. There are bad managers, of course, but some really good leaders also fail when they encounter self-organization. It requires working with fear and insecurity.

  2. Esther says:

    Hi, Sami –

    I think you have the gist of it.

    Managers do fear for their jobs–as people do when there’s a change and they don’t see how they fit in. Some early agile proponents exacerbated this fear, by advocating firing all manager and calling managers stupid.

    I actually see a much more strategic role for managers in studying and steering the system, establishing the conditions for teams to succeed, and creating capacity in the organization.

    One of the actions I take is to help managers and teams identify decision boundaries. That helps both (manager and team) know what the field of play is, when they can act on their own, and when they need to include the other. Making it explicit helps build trust and makes it more likely that people will learn from decisions that don’t go as planed.

    Thanks for stopping by and commenting.

  3. cuan says:

    Hi Esther,

    Great post, and very relevant to what I am experiencing currently.

    I am working with a team on its agile adoption, which is more of a political thing rather then team really wanting it.

    The team is over worked, far to many things going through them, and the manager is focusing on what he feels is going to cause him the most pain if he does not work on it..ie another project rather then the adoption of agile within the team.

    In the role of the coach, for certain aspects, I have inherited a leader role with no authority or support, the manager is happy to have someone do “it”.

    Your 4 questions are a great way to gauge when the team needs to be coached as opposed to managed, if the answer is no to a few of these questions, it feel like its time to take a more directive position then a coaching one, would you agree ?

    Cheers
    Cuan

    • Esther says:

      Hi, Cuan–

      Intervening with a team is a delicate matter, especially when the team and manager are new to the idea of the team taking responsibility for organizing and tracking their own work and taking on more decision making.

      Kati Vilkki shared this model for intervening with a self-organizing team.

      Supportive about process.
      Supportive about content.
      Directive about process.
      Directive about content.

      Start small and gentle, move up the scale if you need to.

  4. David Bock says:

    Great post. Another question to ask is:

    Does the team have the power/authority to solve this problem?

    A self-organizing team can solve a lot of issues – but when the solution requires power the team doesn’t have (in this case, reassignment of an employee), the responsibility of action falls to those with the authority.

    The ‘peer pressure’ from a team can provide a lot of good carrot/stick-style motivation… With Ted, that didn’t seem to work. Sometimes a problem is solved with a carrot or stick not within the teams responsibility to carry; that is the best kind of support the larger organization can provide.

  5. Prabhu says:

    Very good post.

    I am a manager for a team that is following Agile methodologies for development.

    I have seen that in some cases some teams or few individuals try to hide behind the so called “Self managing teams” and “Agile” practises.

    The word “We are Agile” seems to indicate a wrong connotation in case of a few who want to use it to their advantage of being laid back. They play around it saying “you can’t question me as I know I am managing myself”.
    Ther

    In such cases, “Agile” is only for matured and experienced individuals who value collaboration and know the real meaning of “Trust”.

    I accept the fact that sometimes the manager has to come forward and solve some of the issues. In my case, I tried to do some changes to the team by moving the laid back individual out of the team. The new individual completed the tasks in half the time and I hope the laid back individual learnt some lesson out it!

    • Esther says:

      Hi, Prabhu –

      I have seen teams that reject all direction, claiming “we are an agile team.” That ignores that fact that the team exists within the context of the organization, and has a charter to solve some problem.

      Agile teams have the freedom to organize and manage their work. But they also have the responsibility–and one of those responsibilities is making progress visible to management.

      (Freedom and Responsibility is one of the balancing acts that Rashina Hoda writes about in her PhD thesis.)

      And I’m curious why one individual was singled out for individual task completion.

      I wouldn’t expect a manager to be tracking individual task performance on a team, but rather looking at the capacity and health of the team as a whole.

      I’ve seen teams where one individual might not be as quick on tasks, but brought some other quality or skill that was essential for the team to function well. For example, synthesizing information, helping the team vet their ideas against fundamental principles, keeping the team on track and working to high standards are important team leadership functions that don’t show up in “timely completion of individual tasks.”

  6. Heidi says:

    Hi Esther, can you please give an example of decision boundaries to use with a team?

    • Esther says:

      It’s different for every team and every manager, and depends on the capabilities of the team.

      Some examples I’ve seen:

      The team has discretionary training budget of X dollars. They can spend it on what ever training the feel is most appropriate.

      The team has discretion over testing tools up to X dollars and that live on individual computers. If they impact the network, then they need to get approval.

      The team can make technical decisions, excepting those that affect other products.

      The team recommends which candidates to hire, manager has final say.

  7. Rashina Hoda says:

    Hi Esther,

    A very interesting post and an important point you’ve raised here. Self-organizing Agile teams (SOAT) and the role of the manager in such teams, are two concepts in Agile that demand good definitions and description. I’ve been exploring this topic as a part of my industry-based PhD research for past 4 years.

    The ability to balance between freedom (provided by senior management) and responsibility, is one of the balancing acts that define the practices of a SOAT. This balancing act is achieved through the practices of collective decision making (collective estimation, planning, and goal setting) and self-assignment which enable the team to exercise their freedom. The practices which help teams display responsibility, in return are: the use of status reporting (through daily standups) and information radiators (story board, burndown charts etc). [Other balancing acts are discussed here: http://www.elvis.ac.nz/Main/RashinaHoda ]

    The role of manager in this balancing act is to provide an informal boundary. In the example above, Tad is an example of a ‘cultural misfit’ threatening the team’s self-organizing ability. An able manager (or Agile Coach) can take up the role of a Terminator, that attempts to convince Tad to follow the team norms, and failing which, may need to seek senior management support in removing him from this team.

    • Esther says:

      Hi, Rashina –

      Transitioning from manager-led teams to self-organizing teams can be rocky, because people don’t have a model to follow. Some times the team rejects direction, some times the manager steps too far back. So it is an ongoing balancing act, not an end point. As the team gains capability, there’s another round of negotiation and rebalancing.

      Thanks for stopping by, commenting, and posting a link to your research. I find your work really interesting, hope that others will, too.

      Readers, go check out Rachina’s research!

  8. Max says:

    Hi Esther,

    Thanks for the interesting and useful article. I think it must be read and taken into account by every manager who works in organization practicing Agile. Often those managers tend to micromanagement, which bring problems to teams in their path to self-organization.

    In the article you described situation when one of the team members broke one of Scrum’s prescribing rules – daily standups. But what if someone in SOAT (self-organizing agile team) breaks violate discipline, for example being late for scrum stand-ups or start of the workday when duty chart is fixed in a company, or he/she doesn’t work out the required amount of hours per week. In this case, should manager step in and take actions to punish the breaker, or wait until the team raise this question and ask the manager for assistance. Or if the team is Ok with this, manager should not worry and react at all?
    It would be interesting to hear your opinion on this matter.
    Thanks.

    • Esther says:

      Hi, Max –

      If a team member is late to stand ups, I’d first wonder why that is. Perhaps he has another meeting right before, or he has to drop the kids off at day care. In that case, the team can work out a time that works for everyone.

      If he’s immersed in code and forgets, maybe another team member will remind him.

      Working it out with someone who is late for standups is a good starter problem for teams who are new to taking responsibility for their own work. Working out a small issue will help them build their skills to handle more significant conflicts.

      Nothing says command and control like fixed “butts in seat” hours or punching the clock. Why not let the team agree on core hours to be on site? There may be some constraints the manager sets based on the organizational context, but the focus needs to be on work results. When the team handles stuff like this, the manager can focus on how he can improve the system.

      If it appears the team has a problem they aren’t handling, the manager can offer help. Or he can help when asked.

      • Max says:

        Esther, thanks for your answer!
        So, if the team is Ok when one of them is late periodically and if it doesn’t affect the team’s works results and productivity, there should be no reasons for the manager to punish that guy just because of there is strict discipline in company, right?

        Do you think it makes sense to turn a blind eye to discipline violations of a super-productive worker?

        • Esther says:

          Hi, Max –

          It would help me if you explained what you mean when you say “strict discipline.”

          I don’t have a positive reaction to the idea of “punishing” employees.

          Managers communicate values that guide behavior. They reinforce those by modeling them in their own behavior. They offer feedback, coach, and explain the impact of behavior. When there’s behavior that interferes with work results and work relationships and it doesn’t change after feedback and coaching, they talk about consequences. Some times the consequence is ending the persons employment with that company.

          As for super-productive employees–many of them turn out not to be. I see this show up in two main ways. Either they write code that’s so complex that other intelligent people who must work with the code can’t understand it. That makes everyone else LESS productive. In the other main case, they only *believe* they are highly productive because they are finishing tasks quickly. They do that by taking short cuts, writing crap code, and making more work for everyone down stream.

          I think it makes sense to treat employees consistently, and not be harsher or more lenient because of perceptions of “individual productivity” (which is extremely difficult to discern in interdependent work).

  9. Max says:

    Hi Esther!

    Thanks for the profound answer. Under strict discipline I meant fixed working schedule, fixed hours and duration for lunch, fixed number of hours to be worked out per week.

    When is it better for manager to initiate feedback and coaching sessions with an employee breaking the discipline: only after the team complained about this member to the manager or at any moments he wants?

    • Esther says:

      Hi, Max –

      That’s an interesting situation. Is there a business reason for all these rules about when an adult must be sitting at his desk?

      The rules you describe are command and control to the core. They assume that adults can’t be trusted to manage their own time and work, and that without strict discipline, employees will slack off.

      Rules like these set up an dynamic where employees–recognizing that they are not trusted–take less responsibility and initiative. The manager then exerts more pressure and control in an effort to get people to “work hard” and “be accountable.” In my experience, it ends up in resentment and even sabotage. It’s dehumanizing and soul-breaking.

      Rather than focus on small infractions by the employee, I’d work on changing the rules and the thinking that leads to such rules.

      In some cases, a manger can create a bubble around the team and protect them ridiculous rules and micromanagement. They can negotiate negotiate new boundaries with the team–for example, core working hours, coverage for incoming requests, and working out their own work schedules.

      Generally, if one team member comes to me to complain about another team member, I ask him “Have you talked to him about it?” I wrote a post on that topic here: http://www.estherderby.com/2010/10/no-more-middleman-avoid-triangulated-feedback.html

  10. Max says:

    Hi Esther!

    Thanks for your answer.
    “Is there a business reason for all these rules about when an adult must be sitting at his desk?”
    They are just fixed in the employment agreement in our company.

    So, you think such rules (the so-called strict discipline) are rediculous and it’s better for manager to negotiate core hours when all the members should be on site and the rest time the team should control on their own and the manager sholdn’t get in their way, right?

    • Esther says:

      I think…..

      *policies and rules in organizations usually reflect the something of the beliefs about people that are prevalent in the organization.

      *sometimes, managers (and humans in general) don’t think through the message that policies send, because they reflect conditions they’ve grown up with and they’ve never examined the underlying assumptions.

      *if you want high performing teams, it helps to have policies that reflect a belief that people are capable of creativity, adaptability, and responsibility.

      *sometimes well-intentioned managers do things that get in the way of teams producing great (or good, or any) results.

      Cheers!

Leave a Reply

Contact Me

Phone me: +1 612.239.1214

Email me: esther@estherderby.com

Register for My October 22 Q&A

How to Offer Feedback Eventbrite - Q&A Teleconference: How to Offer Feedback

Search this site

Sign up for my newsletter

Sign up for my newsletter. I will send you updates about my public workshops, information about human and organizational dynamics, and articles that I think you will find useful.

Follow My Updates on LinkedIn