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:

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

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:

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.