Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 534 posts at DZone. You can read more from them at their website. View Full User Profile

Leadership and Software Teams: Some Thoughts

  • submit to reddit

Roy Osherove wrote a post about a month ago describing the different maturity levels of software teams and the strategies that he uses when leading each of these which I found quite interesting.

He describes the following states of maturity for a team:

  • Chaotic Stage – the state where a team does not possess the skills, motives or ambition to become a mature self managing team.
  • Mid-Life stage – where a team possesses some skills for self management and decision making , and can make some of its own decisions without needing a team lead.
  • Mature stage – where a team is practically fully self managing and a team leader is mostly a coach rather than a decision maker.

Later on in the article he goes on to describe the best approach as a leader of each of these types of team:

  • The chaotic stage needs a strong, dictator like leadership
  • The Mid-Life stage needs a coach-dictator
  • The Mature stage needs a coach

My experience over the last few years is that a lot of tech leads seem to start off with the assumption that their team is a chaotic one and that they need to make every decision if a project is going to be successful.

Perhaps this is a good place to start but I think it's important to keep checking/iterating your approach to see whether it's still appropriate. Teams tend to improve as time goes on to the point where you don't need to decide as much for the team as you originally did.

The dictator approach seems to work more effectively in smaller teams in non political environments where it is possible for the tech lead to be around frequently and have the time available to make the majority of decisions.

When we don't have that i.e. it's a bigger team or political situation then it doesn't seem to scale since that person becomes the bottleneck as they don't have the time available to get involved in every decision that gets made.

Even if it does work the team leader can end up discouraging people from taking responsibility by always taking it themselves instead of coaching people so that they become more effective at decision making.

Ironically this isn't what they were trying to achieve but not allowing people to be responsible for decisions means that they'll be less likely to take responsibility in the future i.e. it's a self fulfilling prophecy.

I appreciate that there is a fine balance to strike between allowing people to self manage and potentially make mistakes and wanting to keep things progressing by making a decision which you intuitively know is right but somehow we need to find it!

An interesting quote from a post by Leanne Chase about leadership sums up my current opinion on where we should aim to drive software teams towards:

Finally, I heard the ESPN announcer say at one point last night after a Kobe Bryant 3-pointer that Kobe was essentially telling the team – no worries, get on my back, I’ll carry you. That sort of mentality must be exhausting in basketball, at work and in life. I don’t know about you but I would much rather have a team mentality.

I've never yet had to lead a software team so all the above is from observation of how others have carried out this role. It's interesting picking up ideas from each of them and hopefully I'll be able to make use of these if I'm in that role in the future.


Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Michael Eric replied on Wed, 2012/09/26 - 3:38pm

Thanks for another great post. I totally concur on the point that one of the most important things a team lead or even an experienced developer must learn is to let go. Persons eventually mature by a mixture of commiting errors and learning from others. But, they must be given and accept growing responsibility.

linux archive 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.