Managing Self-Managing Teams

Managing self-managing teams sounds like an oxymoron. I assert that it isn’t. Hear me out.

Central to my position is an understanding of management (managing), self-managing, and the manager role.

Management refers to the collection of activities required for the healthy functioning of an enterprise. These activities include planning, organizing, measuring, budgeting, coordination, etc. We can lump these activities under the umbrella of “managing.”

Researchers (as far back as the 1970s) have described self-managing teams as groups of individuals who can self-regulate on whole tasks. Dr. Richard Hackman developed a typology that includes self-managing teams. Other team types include manager-lead teams, self-designing teams, and self-governing teams. Hackman’s typology below describes teams based on their management responsibilities.

Last but not least, a manager is anyone assigned managerial responsibilities (and not just people with “manager” in their job title). This means that a Vice-President in a software development firm is a manager because they have management responsibilities. I will not wade into the nonsense I consider the manager-leader distinction. That will have to wait for another day.

Bringing this home to product development, a self-managing team has responsibility for executing the team task and monitoring and managing work process and progress. “Executing the team task” requires little explanation and is pretty straightforward to understand—the team has full responsibility for completing the task required to achieve desired outcomes.

Self-managing teams also have responsibility for managing how they get their work done and monitoring their progress on their work. Of course, the team must have the competencies to do this well. It’s not enough to declare a team self-managing and expects that they can now magically “monitor and manage work process and progress” effectively. Self-managing is not without its challenges, and anyone who suggests its a panacea is not being truthful.

(While I have you, let me share that I prefer self-managing over self-managed because it speaks to the ongoing nature of the management activities the team is responsible for.)

Hackman’s model makes it clear that “other-managing” will focus on other aspects of management, i.e., “setting overall direction“ and “designing the team and its organizational context.” A self-managing team is not focused on these aspects of management. These aspects can be the responsibility of a manager. It will be the responsibility of some individual(s) outside the self-managing team.

The effective manager of a “self-managing” team will continually ensure the self-managing teams have the resources needed to succeed. The manager will address external friction impeding team progress. The manager’s role is to provide external managerial support so the team can self-manage. And this is managing—managing a self-managing team.

Now it’s easy to try and establish a clear separation between the focus on the manager and the focus of the self-managing team based on typology. Doing this would be a mistake. While the responsibilities are distinct and can be analyzed separately (to a degree), the responsibilities interact and influence each other.

For example, when direction or organizational context changes (and it will), the self-managing team needs to know to adapt their processes appropriately. Conversely, the self-managing team needs to make its progress transparent so the manager can use this information in direction-setting and organizational context conversations. 

These interactions don’t change the locus of responsibility. Rather the interactions remind us that everything is connected and the importance of healthy feedback loops.

I firmly believe that many product development contexts would benefit from (at least) self-managing teams. We know that the more autonomy people have over their work, i.e., what they do, and how they do it, the more meaning and fulfillment they derive from work. The more committed we are, the more we positively contribute to our organizations.

Self-managing teams are rare in product development organizations despite many senior leaders claiming them. I believe a key reason for this is that many senior leaders in organizations do not understand how to foster self-managing teams. They often give mixed messages. On one hand, they tell teams they want them to be self-managing, and on another, they tell managers they are accountable for “monitoring and managing work process and progress.” Well, what do you think happens? 

Many managers feel a strong desire to control. It’s a natural expression for many of us. Additionally, our organizational socialization leads us to believe the only way to control is to take over the responsibilities of self-managing teams. Without proper training in other management areas, while enabling self-managing teams, managers focus on what comes naturally. So manager-led teams continue to dominate the landscape.

Organizations need managing. While self-managing teams manage critical aspects of their work, they will also need management support if they are going to achieve organizational goals. Managing self-managing teams is not an oxymoron.

Thoughts on “Managing” Software Development

I’ve written in the past on management and managers and you can find some of those thoughts here however I want to share some additional thoughts.  These thoughts are basically my answer to the question of: what does a Software Delivery/Development/Engineering manager do?

(Even if you’re one of those who believe managers are not needed in knowledge work, I’ll crave your indulgence to read on).

(I do believe that Software Development/Engineering Manager are better role names than Software Delivery Manager but I digress).

It is dangerous to define the job duties of a role without taking into consideration the guiding philosophies of an organization.  For example, let’s just look at the concept of the manager. The definition of management (and hence managers) in an organization that adopts the principles of Frederick Taylor will be markedly different from that of an organization that adopts the principles of Edward Deming.  In other words, roles are not defined in the abstract.  The organizational philosophy ultimately defines the role.

I belong to the school of Deming when it comes to management, and as a result, my definition and description of a software delivery manager is going to be based on Deming’s view on management and managers.  I posit that real Agile and/or Lean organizations take a similar stance.

A software delivery manager is a “manager of software delivery” and if we decompose the role into its component parts we have manager and software delivery.

Douglas McGregor basically describes the Taylorist manager as person who works with the assumption that:

…workers have an inherent dislike of work and hence needs to be directed, controlled and threatened with punishment in order get them to work hard to achieve company objectives  

The Taylorist manager is all about control and external direction ergo this manager focuses on defining how the work should be done by the individuals on the team and then measuring individuals to ensure they are meeting pre-determined targets the manager defined.  This manager leaves little room for individuals and teams to self-direct as these managers need to do all the planning and provide all direction.

So how does Deming describe as the role of the manager?  According to Deming (excuse the gender-specific tone), a manager:

  1. Understands how the work of the group fits with the aims of the company. He teaches his people to understand how the work of the group supports these aims.
  2. Works with preceding stages and following stages
  3. Tries to create joy in work for everybody
  4. Is a coach and counsel, not a judge
  5. Uses figures to help understand his people
  6. Works to improve the system that he and his people work in
  7. Creates trusts
  8. Does not expect perfection
  9. Listens and learns
  10. Enables workers to do their jobs

Deming is not alone in his thinking.  Other management thought leaders such as McGregor, Drucker, Ackoff, and Senge all share the same thoughts.

If I were to summarize, I would say that the role of the Agile (and some would say modern) manager is to:

Create an environment where people and teams can do their best work for themselves and the organization in a manner that is both rewarding and fulfilling

The modern manager realizes that s/he is dependent on their team to be successful.  The team is also dependent on the manager.  In a nutshell, the team and the manager are interdependent.  The manager and the team share in the responsibility of developing and delivering software.

(If you work for an organization that says they are Agile and but exhibit Tayloristic management tactics, I hope for your sake that the organization is in the early stages of Agile cultural adaption.  If they aren’t, you’ve been warned).

So we’ve defined manager but how about software delivery? Software delivery is simply the aim of the system that the manager and their team(s) belong to. This system has the goal of delivering software that addresses the needs of stakeholders.

What then are the duties of the software delivery manager?  Here are a few that immediately come to mind:

  • Provide clarity to team members and teams on organizational objectives and what achieving them entails
  • Define operating constraints and boundaries for teams in which they operate
  • Provide teams with the appropriate authority, resources, information and accountability
  • Provide career guidance and coaching to individual team members and teams
  • Staff teams appropriately within budgetary constraints.  Manage their budget responsibility
  • Partner and network with other managers in the organization in addressing organizational impediments
  • Provide feedback to the teams on the software that is being developed.  Engage in product “inspect and adapt” sessions.

What else would you add to this list?

While we’re talking about software delivery teams, I need to remind us that in Lean and Agile organizations, the work is done by cross-functional teams.  The implication of this is that software delivery teams will often be composed of individuals from more than one functional group in the organization.  A software engineering delivery manager will often need to team up with managers from other functional groups in the organization e.g. infrastructure manager and together they will provide the team the support it needs.

It’s also important to remember that Agile teams (regardless of the framework of choice), as a part of being cross-functional, have a role on the team responsible for championing the product (or something similar to a product).  This role, often referred to as the Product Owner, and not the software delivery manager, decides what the team should focus on.

So there you have it.  These are my thoughts on the Software Delivery/Development/Engineer Manager.  I anticipate that some readers will disagree with me.  Please share your thoughts in the comments.  But as you disagree with me, take a moment to explore why it is that you disagree with me.  In fact, I would implore that you examine the underlying philosophy and mental models that inform your definition. Where do they come from?  Do you know?  Are they based upon Taylor’s Principles of Scientific Management, Deming’s principles or something else?  

Our actions reveal our beliefs.

Decentralize City

Is your organization highly centralized or highly decentralized?

Lean organizations are characterized by pushing decision-making to the “lowest” possible level. In the using the word “lowest”, I am just reflecting the hierarchy that exists in most organizations. What we’re really talking about here is ensuring that decision-making occurs where the work is actually happening. In order to enable this, the information also needs to be shared with the team(s) actually doing the work.

This is at odds with traditional work structures where people at the top were paid handsomely to have all the information and the peons were given such dumbed down tasks, that they didn’t have to do much thinking.  Take a few minutes to study the history of industrialization.  You may be surprised at what you uncover.  Unfortunately, this “thinking” still influences the control structures of the average organization.

Even though in knowledge work, the “associate” is often a highly trained and educated individual (see Drucker), most organizations still create structures where all the important information is held at the top.  You know, with Director X, VP Y or C-level exec Z. Nothing meaningful gets done without a decision being made by someone with a big title.  Supposedly, those at the top are more informed and have more experience. Supposedly.  The Taylorist mindset lives on; cloak and dagger style.

You can choose whether you want to work in organization like these.  I made up my mind a few years ago that I wouldn’t except I was helping to the change that situation.  You know why?  I can’t stand to see so much human potential wasted.

Additionally, the delays introduced as a result of waiting for people at the top to make decisions impacts us economically (well except we’re a monopoly).  Innovation is stifled, creativity pretty much killed.  But someone still ends up with a fat bonus.

As a leader, how much decision making is centralized in you? How much decision-making is decentralized on your team? How much information is given to individuals and teams that enables them to actually make decisions?  How many centralized boards and bodies does your organization have?

The greater the centralization the lesser the ability for the organization to scale and the more human potential is being wasted. The waste of human potential is such a sorry thing.