Jeffrey Palermo 8:28 am on November 11, 2008  

The Myth of Self-Organizing Teams

A hot topic in the agile world is “self-organization”.  The reaction against tight command and control management structures has swayed the pendulum all the way over to chaos. 

First, I understand that every team is different, and my views are tainted by my personal experiences, which include heavy work in Austin, TX and with various companies sprinkled across the U.S.  I have seen (and made) arguments stating that self-organizing teams are much more productive and effective than tightly-controlled team.  I now believe that a balance is critical (surprise, surprise).

To understand my perspective, you should know that I have been in software management for just over two years, and before that I came up through the ranks as a software developer.  My views on self-organization have changed with my role, but in either position, they have not been extreme.

When I was an individual contributor, I was hardily in the self-organization crowd, mainly because I preferred not to be directed.  What I found was that I and so many of my very intelligent co-workers at several companies felt that we as the team knew the best way to proceed, and I somewhat resented management handing down decisions that seemed misinformed for the situation.  The fact was that many of management’s decisions were misinformed.  There was no alternative since management swooped in for a weekly status meeting and then was gone again.  The lack of consistent, involved management on a day-to-day basis severely colored my opinion of managers (at least in I/T).  With this lack of engaged management, across several organizations, the team has no choice but to self-organize or remain in constant chaos.  The self-organizing did happen to a certain extent, but only after much chaos and posturing to determine which team member would surface as the “lead” since management had failed to identify such person.  Since most of the time the team was made up of peers, making decisions was slower than necessary because no individual had the authority to make the decision so that we could move on.  Consensus and needless discussion ruled.  Over time each team member learned to carefully select the battles in which to engage so that these discussions could be limited, but the time wasted was significant.  If any of my former co-workers or managers are reading this, you were the good group (the ones described above would not be reading this blog).

The above represents some of my experience as a software developer, and because of this experience, and reaction against managers who were not properly leading the team, I have been in favor of what the industry calls “self-organizing teams”.  Some other writings on the topic (for and against) are below:

It is very important to emphasize that my experience managing and growing software teams has changed my thinking regarding self-organization.  My current situation as Chief Technology Officer of Headspring Systems finds me managing a company with 10 software developers, not including me or our Chief Architect, Kevin Hurwitz.  In our line of work, consulting projects, we cannot afford the time it takes for a project team to go through Forming, Storming, Norming, just to get to Performing.  While that has to happen, ultimately, we had to find a way to streamline the forming and storming phases.  This is where management comes in.

My approach to management has some roots in what not to do.  From some of my past experiences, I know that I will be more successful if I’m engaged closely with my teams in not only supporting them but also in directing their activities.  If we think about a continuum, dictatorship is as the opposite end of pure consensus.  If management has a tight command and control approach, the organization just will not scale and cannot grow.  A single manager can only control so much.  A manager must know how to delegate if the organization is to grow.

As with anything in life, self-organization is a balance.  My guys employ self-organization with certain things, but there are other things that are directed.  Point:  Self-Organization does not require Self-Directing.  A team that is self-directing will likely not accomplish anything significant.  A software team within a company cannot make every decision.  It can only make certain ones.  For instance, what market segment to compete in is a decision that has likely already been made; however, what unit testing framework to use might be up to them.  This is where the balance between direction and delegation comes in.

We have certain things that are mandatory for Headspring projects.  These things are considered competitive advantages, and no project team has the ability to deviate.  This may seem like command and control, and it is to some level.  This is the balance I am talking about.  Some of the things that are “dictated” to the team are (most other decisions are delegated to the team):

  • An automated, continuous build
  • Very high (near 100%) unit test coverage
  • O/R Mapper for data access
  • IoC container required
  • Onion Architecture as architectural approach
  • Extreme Programming practices
  • Some coding standards
  • Sitting together

The above are just some of the things that are “handed down from above with an iron fist”, and one could argue that a team should have the authority to decide their own process framework or whether or not to do unit testing, but that is a business decision.  If I were running a Research and Development group, I would certainly have different levels of delegation, but the above are considered core to our practice and key to project effectiveness.  If I’m wrong, then it is clearly my fault, but that is one reason why management is hard:  anything that is wrong with the organization is the manager’s fault, either by having the wrong people in place or sending them in the wrong direction.

The Self-Organizing Team is a myth because it communicates an absolute.  What is more real is an appropriate level of direction coupled with suitable delegation and trust.  In order to make our project teams effective, I must provide guidance and a behavioral framework for the team to operate in.  Within these somewhat strict guidelines, all other decisions are delegated, and I trust them to make the right choices.  This balance between directing and delegating has proved to be the appropriate balance between self-organization and dictated-organization.  The team members are very happy as well because they are pushed in the direction of success.

General management support is always key.  This approach to organizing would not work at all if I was disconnected and uninvolved with the teams.  I must stay on top of progress and current blocking issues in order to keep the team as effective as possible.  By staying engaged, I also can see problems coming from a distance, and I can take action to solve the problem before it becomes a blocking issue for the team.  Software tools are an easy example that hangs up so many organizations.  Any software tool for software development has an ROI story, and many sub-$1000 tools are available.  Compared to developer time, these tools are dirt-cheap.  Just yesterday, I purchased new licenses of Redgate SQL Compare for the team because they were incorporating it into the process for database migrations.  I’ve seen several managers try to negotiate away a small tool cost just because the procurement process for the company is difficult or it is politically unpopular to ask for special allocations.  This one small example is a symptom of the type of management that exists.  Supportive or tourist (comes to visit once in a while) management.

Conclusion

In order for a team to exist, it must have a mission, a purpose in life.  This mission must be directed, and is probably what caused the team to form in the first place.  Management must find the appropriate balance between directing and delegating.  Because of my background in software development I am able to competently direct my teams in the right direction while at the same time delegating tactical decisions that are contextual.  Furthermore the Principal in charge of a single project team decides what further decision to make singly and which to delegate to the individual developers.  The experiences in my career have shaped my views on self-organization, and I have found that neither self-organization nor command-control are appropriate for an effective software team.  A team might perform in spite of either, but a carefully balanced direction/delegation ratio will increase effectiveness exponentially.