How Much Self-management Is Right for a Team?

The  answer is (of course):  “It depends.”

But first, a puzzle:

There are lots of teams in small companies and start-ups who are self-managing and self-directing.  They manage themselves, they set product direction, and set company priorities.  As organizations get bigger, they hire managers.  Managers take those responsibilities, and teams become disempowered.  When I visit big, established companies, there’s almost always an assumption that teams need close supervision.

Are the people in start-up teams and big-established company teams essentially different?

Some argue that people who are attracted to start ups are “entrepreneurial” an therefor fundamentally different from people who go to work in larger, established companies.  I’m ready to accept that people have different preferences for risk and stability. But, as far as I can tell, most people employed in software companies are adults.  Adults enter into contracts, choose mates, raise children, and make all sorts of important decisions.  Why do we expect that those very same adults need close supervision when they come to work?

Much of the work in growing self-managing teams is changing assumptions, shifting the dynamic between managers and employees, and undoing years of disempowerment. What doesn’t work (usually) is to declare that teams are empowered and self-managed.  That leads to a freak-out on both sides.

Going to Extremes

Sometimes I see teams that reject all direction and go their own way, declaring, “We are self-organizing.”

They are missing an important fact. When someone is paid by a company to be part of a team, that team exists within the organizational context. The team has a customer—someone who desires and will pay for its output (or not, in which case the team should cease to exist). If a team doesn’t have a customer who eagerly awaits its product, that’s a management problem.

On the other hand, some managers hear the word “self-organizing” and believe the team is on its own—that the manager can go into semi-retirement. But that’s not the case, either. In fact, it’s a risky oversimplification.

Shift the Dynamic

Teams and their managers are in a relationship, and every relationship has dynamics–patterns of action that are reinforcing.

One of the dynamics that shows up when managers decide to “empower” teams looks like this:

Looking Up, Looking Down
The Looking Up/Looking Down Dynamic

The manager declares the team is empowered.  And he waits for the team to start acting that way and “take some responsibility.”  In the meanwhile, the team is wondering wether the manager really means it this time.  They may be hesitating because they aren’t sure what these new responsibilities are, or how to do them.

After waiting what feels like a long time, the manager steps in. He either pushes the team, or takes action himself.  (The worst ones berate the team for not taking responsibility, just for good[?] measure.)

This confirms what the team feared, that the manager didn’t really mean it when he delegated responsibility to them.

And then the cycle starts again, and each spin through the circle chips away at trust.

Find a Balance

In reality, it’s a delicate balance, and the “right” level of self-management depends on the manager, the team, and the context. As a practical matter, managers who want the benefit of the team effect do need to navigate the balance and move towards self-management–stripping away the layers of disempowerment, growing skills and capabilities in the teams, and building trust on both sides of the manager/team relationship.  That’s a different path for every team and manager.

So,  here are some of the “depends on” factors that I think about….

Teams can take on management work in these areas:

  • Managing their own work and monitoring their own progress
  • Managing team membership
  • Setting direction within the organization

Managing Work and Monitoring Progress

For agile teams, this includes creating the iteration plan, breaking down the tasks and activities, keeping track of progress.  These teams aren’t relieved of the responsibility to report their status to management. They use burndown charts, burn-up charts, and task walls, or kanban boards to make progress and problems visible.

Task management is usually the starting point. For some teams, this is as much self-management as they take on. This may make sense for teams who are together for a very short time.  But then I’d ask the question, why is the company forming and dissipating teams this way?  It takes time for teams to learn to work together, and if they are broken up before they learn that, the organization doesn’t get the benefit of the team effect.

What about bringing the work to the existing teams, rather than forming a new team every time there’s a new project?  There still might be some adjustments to team membership, but there would still be less churn that I see in most organizations.

Managers can help teams take responsibility for managing their own work by refraining from continually asking about progress and from piling on more tasks.

If team members aren’t yet able to plan and monitor their own work, coach them to identify the steps and break tasks down into one- to two-day chunks of work, and then get out of the way.  Don’t step in and take over planning. Coach and show rather than do.

Managing Team Membership

Some  teams manage their own membership throughout the life of the team. In some companies, management announces the projects, and the developers (the programmers. testers, UI developers) with the relevant skills and understanding of the project form their own teams.

It’s more common, though, for managers to assign people to teams, at least initially (although calling a group of people a team doesn’t actually make them a team). I recommend that managers use a collaborative hiring process for self-organizing teams once they’ve formed. Sticking people onto a team without consulting existing team members is a recipe for ungelling the team. At the core, it’s a power play.

Some teams coach members off the team, too; though they seldom have the authority to handle the contractual aspects of terminating employment.

A colleague told me of how they helped  a lone-wolf leave their team. One of the engineers had committed to follow Extreme Programming engineering practices but later violated his agreements with the team. When two team members confronted him, he informed them they’d be lost without him and threatened to find another job. His teammates offered to help him buff up his résumé, and he was gone within a week—no manager involved.

That’s far from a typical case, and don’t count on this happening early in the life of a team, or early in the journey to self-management.

If an employee who is unable or unwilling to work within the team doesn’t leave of his own accord, then the manger needs to step in and deal with the situation from an HR perspective. (See Tale of a Too-Hands-Off Manager.)

Before team members can help someone off their team, they need  have the skills to  offer and receive peer-to-peer feedback and deal with behavior that disrupts work and relationships.

Many teams reach the point where they can handle a range of disagreements, missed expectations, and frictions. Fewer reach the point of helping someone leave–at least in a healthy and respectful way.  Mobbing, shunning, and piling-on don’t count for healthy or respectful.

When there’s a problem that’s getting in the way of the work and working relationships, and the team doesn’t have the skills to handle it, it’s time for management action.

Setting Direction within the Organization

Teams make commitments, but they don’t set product priorities in many companies, especially big ones. The vision and definition of the product comes from the customer or product owner (but, take a look at Know Thy Customer). As a team matures, team members may move towards partnership in co-creating the product.  This depends on trust and a collaborative relationship with the customer. This is a relationship that requires high domain knowledge, technical knowledge, and a high level of trust.

Remember, there are plenty of teams, especially in start-ups, where they DO set product direction and priorities.

Every Team is Different

The “right” level of self-management depends on the context. Consider how long the team will stay together. It takes time for a team to learn self-management skills. If the team will only be together for a few months–ask why the organization is creating churn–and realize that it probably doesn’t make sense to train team members to manage team membership or involve them in setting direction within the organization. On the other hand, if team members will have a long life together, it’s likely they’ll be adding team members, so teach them to participate in collaborative hiring.  Build towards partnership with the product owner group.

A Mile Too Far

It’s possible to push too much management work onto teams. I talked to a manager in an organization that had expended millions of dollars to train teams to self-organize and self-manage. The division then eliminated all but a few management positions.

But the division wasn’t seeing greater creativity and engagement, as it had hoped. Instead, highly trained technical people were leaving the organization in droves. Alarmed, the remaining managers started exit interviews. They learned that people were leaving for other companies that had traditional, manager-led teams—not because they loved being told what to do, but because they wanted to focus on the technical work that they loved.

In the rush to embrace self-organizing and self-managing teams, top management had loaded too many management tasks onto the teams. Team members were spending less than 50 percent of their time on actual technical work.

(One does wonder if this company collected any data on results. But I don’t know that part of the story.)

A Clarification

The term “self-organizing team” is applied rather loosely in the agile community.  I sometimes use that short hand myself.  In systems terms, every group is self-organizing within their  boundaries and constraints.  So calling a team self-organizing is redundant and probably not technically correct.

What gets managers and teams cross-wise is confusing the term self-organizing team with self-managing or self-directed team.  All teams are self-organizing, but not all teams are self-managing. And not all self-managing teams are self-directed, or self-goverened.

5 Replies to “How Much Self-management Is Right for a Team?”

  1. Great article Esther. I will use some of the tips from your article when working with teams, especially the one about the waiting game when team is not clear whether it is real this time. I think articulating it well and reflecting on self direction as a topic in retrospective would help a lot.

    I would be great if to have some clarification on self managing vrs self organizing. For me self organizing means = ” people doing the work knows best to solve the problem and don’t need to be told” . I don’t believe in that context self organizing is happening in all teams , not even in those teams who are doing Agile instead of Being Aile. For me self managing means team manages the what – what work needs to be done , who they get to work with and where they work with , for me it is the next level of autonomy at work and in many case team setting the direction of the project , would that work in all context, especially in teams that are part of all overall Vision that is executed by multiple teams.

    Appreciate you sharing your thoughts with the universe.

  2. Thank you for sharing your thoughts. Very useful article. I like your note about adults. Really most of IT companies think that each step of the development process must be under control. But we are adults and many problems may be solved by us without control from management side. This of course requires changing of mind and taking responsibility. I would like to add that not every team may become self-organized and self-managed because there are developers who likes only coding and nothing else. They don’t want to take part in any decision making processes or take additional responsibility. But they are still good developers and they perform their job well. Agile approaches change requirements to team members and force teams to become more responsible for project decision. I hope that situation will continue to change in positive direction.

  3. Hi Esther, thank you for the insightful article. Your thoughts match closely my own experience in small and large organizations.

    I think one of the factors, that does hinder people to be self-directing, even when upper management “empowers” a team, is the lack of complete information. This also has to do with the notion of not seeing team members as adults. I just witnessed in one large company, how upper management, in favour of introducing an agile method, sends its teams the minutes of management meetings to inform them, but misses on informing them about their motives and goals. The information without context is plain useless at best and counter-productive at its worst, because nobody can take any action or decision on it.

    Ricardo Semler describes interesting tactics, how they fostered self-direction of their staff at Semco. I am sure you are aware of the story.

  4. Hi Esther, I enjoyed this read on the dynamics of self-organization

    I think there are an additional couple of things at work here:

    Firstly, that small startups have not yet brought in the big
    guns/hired management that don’t know differently than command and control (it’s at this point when you begin to see the original employees begin to migrate south – usually to another start up) and begin to put in management. These teams _tend_ to do a great job of self-organization,self-management and self-governing in my experience.

    Secondly – once the hierarchical/command & control structure is in place, it often times needs a manager in place between it and the teams to provide an umbrella for the team to guard against the dysfunctions, poor communication and competing agendas of the ‘leadership’ up the food chain. (Which may be helpful.)

Comments are closed.