The Elastic Leadership Book



        RSS Feed

Latest Entries


Leadership and the mature team

The following is a guest post by Mike Burrows.

Until last year a developer, project leader and development manager in investment banking, Mike is now an IT Director in the energy risk management industry, still leading projects, still writing code.  His blog ( covers open source development and his recent Kanban implementation.

Roy's post "The 3 maturity stages of a software team and how scrum fails to identify them" [1] rings true to much of my experience as a team member, project leader and development manager, but still it touches a red button of mine!  I'm grateful to Roy for his very gracious offer to let me respond to it.

My red button?  I worry about the Agile community's recent focus on self-management.  Don't get me wrong: self-management is a good thing, but in its current popular usage it has two problems:

  1. It fails to capture satisfactorily the much more powerful concept (borrowed from the study of systems) of self-organization
  2. There seems to be a move in the community to minimize the role of leadership

Self-organization is at the heart of agile methods, indeed it is the 11th of the 12 principles [2] behind the Agile Manifesto.  Definitions vary, but in this context it describes the ability of a system (here the project team) to create for itself ways to increase its own effectiveness. 

Looking at the team from the outside, we see "emergence" - new behaviors arising without external intervention.  In the Scrum context this might happen as a result of team retrospectives (the 12th principle) or simply through the individual contributions of team members.  Either way it's important to recognize that some of these new behaviors (i.e innovations) may be highly non-standard.

Leadership (whether from within or without) takes the team to places it would otherwise never have reached, perhaps never even have considered.  This can be in terms of the team's internal structures or its external goals, but in the absence of leadership it is a rare thing for a team to take itself out of its comfort zone, to redefine its approach to the outside world, perhaps even to completely reinvent itself.

Here's the paradox: good leadership encourages emergence, but the leader must also be ready to take the team out of the ecological niche it has carved out for itself, however effectively.  Yes, self-management is needed at every level (or the leader has time only for management), but we need also the humility to recognize its limits.  Now there is true maturity!


Mike Burrows

« Video – Code Leaders and Beautiful Teams | Main | The 3 maturity stages of a software team and how scrum fails to identify them »

Reader Comments (2)

If you're interested, I recently created a presentation around this topic:

The Dolt's Guide to Self-Organization

May 19, 2010 | Unregistered CommenterJurgen Appelo

Hi Mike,

Leadership is one of those areas the software industry has had a lot of trouble grappling with. I agree Agile hasn't helped much. For me the underlying route cause is our historical lack of meritocracy within software organisations. The typical software manager, became so because he was not that good at development, was looking for a pay rise, and everyone else wanted to see the back of him away from the code :) The phrase "promoted to your level of incompetence" rings a bell.

Self organisation opens the door to leaders that gain their position through merit. Leaders are people other people choose to follow. If the leader is imposed (like in most scenarios), then what they become is a person with "higher authority", someone who tells you what to do, and someone you are paid to listen to, not someone you choose to follow.

Not sure how to fix this one. Lean offers a great deal of insight into what a good leader should look like. Interestingly, in manufacturing, the leaders are practitioners too (production engineers etc). I had the same experience in Electronic Engineering.

Software is almost unique in Knowledge work, with leaders that generally do not practice. Why should I have any respect for someone who wrote Cobal 10 years ago and hasn't written a stitch since? What do they know?

I agree with you, that self management opens the door for leaders to have the time to be practitioners also. I don't like the idea of full time technical Managers (having been one myself). IMHO Managers should be hands-on practitioners with skin in the game. It is only then they stand a chance of gaining the respect needed to be true leaders.


July 1, 2010 | Unregistered CommenterPaul Beckford

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>