· leadership

Leadership and software teams: Some thoughts

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.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket