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:

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-governed.