Top DZone Article of 2011 - 10 Mistakes That Software Team Leads Make
Join the DZone community and get the full member experience.Join For Free
- roy osherove
“ten mistakes” (as i shall now call it because i’m too lazy to keep typing the whole title), was a talk by roy osherove which i went to at skills matter. he basically takes us through ten common mistakes he sees team leaders make, and offers some solutions to them. he also looks like adam sandler, i kid you not.
here’s roy delivering a piece to camera…
roy started us off by talking about a number of questions that team leaders might have. these included such things as:
- how do i convince my team to do x
- what do i do with the bad apple in my team?
- what am i supposed to do as a team lead?
- why can’t we get away from fighting fires?
- will i lose friends?
he said that these were all questions that haunted him for years, and in the rest of the talk he goes on to explain how to answer them. he is also in the process of writing a book called “notes to a software team leader” which also covers these points.
so, we then moved on to the first of the ten mistakes…
#1 not recognising team maturity
this was a good place to start because much of the talk referred back to the “maturity level” of the team. roy says that there are 3 levels of maturity when it comes to describing agile teams. these are:
a chaos team is one where people are always too busy. maybe they’re always firefighting or they’re just being asked to too much in too little time, eithe r way, the result is the same – chaos. nobody has any time to get organised and nobody has any time to learn anything new because they’re just too busy for that. this is obviously not a great maturity level to be at if you ask me, because eventually people will suffer burn out or get frustrated at the lack of opportunities to learn, and eventually the good guys will leave. however, roy says that the chaos level is actually exceedingly common, and i can easily believe him. the trick is to act in an appropriate way if you’re the leader of a chaos team. a chaos team leader needs to be assertive and strong in their actions.
when the ship is sinking, you need a leader to give orders, not call a meeting
a chaos team leader will often need to take a stand and maybe tell management that the team cannot do everything that they’re being asked to do. it’s a tough role, it requires you to make tough decisions with conviction.
management done right is a really tough job
so why, as a team leader, do you have to make all of these tough decisions yourself, instead of discussing them with your team? well the simple answer is that there just isn’t enough time for meetings. by making these executive decisions yourself, you’re giving your team some breathing space, or simply just the space they need to get their work done. sure, you might make a few wrong decisions, life’s tough, but it’s for the greater good because you’re giving your team the space they need to grow into the next level, a learning team.
this level of maturity is one in which the team has a greater degree of self organisation, but the team members still need to be coached. a team leader will need to grow his/her team by constantly challenging and questioning them, maybe even setting them homework! the goal with these teams is to improve week-on-week, and to get the team members to start solving their own problems.
so what are you going to do about it?
as a team leader of a learning team you need to start to get your team members to solve their own problems in order to grow into a self-leading team. so if someone comes to you with a problem, encourage them to think of ways to fix their issue, and empower them to do so by responding with “so what are you going to do about it?”.
the third level of maturity is the self-leading team. this is where we all want to be! in this team, the leader is more like a mentor – he doesn’t tell people what to do or make executive decisions on behalf of the team as he/she would in a chaos team. even in a self leading team, the team leader should still spend in excess of 50% of his time with his team.
so, the first mistake in our list is to not recognise what maturity level your team is at, and therefore not know how to lead your team in the right way. if you run your team as if they were self-leading, but in reality they’re chaos, then before long you’ll be heading up a certain creek without a paddle.
#2 fear of delegation
if you’re used to taking things on and doing them yourself, then it can be quite hard to feel comfortable delegating work to people, especially if you have trouble relying on others to get the work done.
if everyone feels comfortable in what they’re doing, then you’re doing something wrong
when you delegate work, you’ll need to get used to asking other people to take responsibility for something you’d otherwise do yourself. this responsibility can take some people out of their comfort zone, and this is a good thing. it’s important to challenge your team and get them out of their comfort zone as it’ll help them grow.
#3 fear of engagement
this generally means not communicating effectively, but roy breaks this down even further:
“the bus factor” – what’s that? well, the bus factor is the number of people needed to get hit by a bus for the project to grind to a standstill. it’s all about individuals holding lots of information. i’ve seen this in a number of places, on good projects as well as bad, so i think it’s fairly natural, but the point that roy makes is that you mustn’t placate these individuals just because they hold a lot of crucial knowledge. a person with a bus factor of 1 (meaning they could bring the project to a halt if they got hit by a bus) should be treated just the same as anyone else. i love the idea of people having a bus factor, just because it reminds me of the kevin bacon number .
#5 being irrelevant
i think this is about being in too many meetings and dealing with too many emails etc and so on – basically not being there for the team, losing contact with the real work, and generally being irrelevant. nothing to do with kevin bacon.
#6 being super-reasonable
not sure i really agree with the terminology here but roy says that it’s super-reasonable to assume that everyone understands what your talking about when in reality you might not be getting your point across. i think the point to make here is that when you’re dealing with groups of people, as in an agile team, it’s wrong to assume they all have the same level of knowledge and understanding as yourself, and that you should communicate with them in the best way suitable, which tends to be by not making too many assumptions.
if you make your mind up that someone’s rubbish, then you will consciously and subconsciously use this as an excuse to not engage that individual. there will always be some people who are rubbish, but what you need to do is work on their weaknesses and bring them up to the level of the team, rather than to avoid engaging them, as this just means you’ll constantly be carrying a dead weight.
#8 ignoring behaviour forces
you must understand the forces that act on a person in order to understand how they behave. there are 3 main types of forces that act on a person:
all of these can affect a teams ability to be successful, and you need to work out exactly what these forces are, and determine whether they are affecting your teams ability. an example of an environmental force is not having enough hardware to do what you need to do – for instance, if you don’t have budget for a continuous integration server then it’s going to be almost impossible to be agile.
#9 fear of assertiveness
apparently this is common in the uk and in norway, but not in denmark. bet you didn’t know that. well it’s true, allegedly. anyway, assertiveness is all about standing your ground and not living with things that you feel aren’t acceptable. if your team is in chaos mode, then you need to be especially assertive. a fear of being assertive can be disastrous in a chaos team.
#10 spreading non-commitment
this is about using vague language. roy says that you should always commit to deadlines, and when speaking to your team, make sure they tell you when they will do something by. apparently, just by making the commitment in the words they use, they will be more motivated to deliver on that commitment. roy suggests that when you have a meeting, end it by asking people what they’re actions are, and make sure they answer in the form “i will do x by y”. however, people should only commit to doing things that are under their control, there’s no point committing to doing something that you have to get someone else to do. also, as soon as you know that you’re unable to deliver on time, let the team know and they might be able to help you out and maybe then you will be able to deliver on time.
questions and answers
the q&a went on for an age. i’ll summarise in bullet form, because bullet points are great!
- you need to recognise when to change your leadership style – you need to stop being a chaos team leader if the team moves on the being a learning team
- there’s no such thing as a chaotic learning team. the 2 cannot co-exist, however, teams can switch from one form to another.
- overseas teams don’t work as well as having everyone in-house. if you’re in this situation, you need to “change your reality”.
- agile teams should be 2 pizza teams – i.e. only as large as can be fed by 2 pizzas.
- good teams are grown, not hired
- scrum sometimes doesn’t fit teams in chaos mode
- there’s no difference between a team leader and a manager if they’re the same person, which they can be.
- protect your team from project managers if your in the chaos mode
a number of books were mentioned. here they are!
managing teams congruently – gerald m weinberg
behind closed doors – johanna rothman
influencer (the power to change anything) – patterson et al
succeeding with agile – mike cohn
Published at DZone with permission of James Betteley, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.