By

December 17, 2015

Growing Self-organizing Software Teams

, author of ‘Notes to a Software Team Leader’, discusses how you grow self-organizing software teams. He covers how to develop team members, different phases of leadership, and some common mistakes made by new tech leads.

Read more interviews with some of the world’s best developers on * or follow us on or follow us on .*

Often developers can be reluctant to put themselves forward for leadership roles, but Osherove says that whilst it can be scary, “it’s not something that should block you”. In fact, if you want things to change, then you should actively seek it out. “Remember all those things that you’ve always wanted your manager or leader to do? You can actually get to do them… It’s a great chance to change the environment, and not just bitch about it,” says Osherove

In his book, Osherove explains that “a team leader grows the people on their team,” and he thinks that this should be the key thing driving your behavior as a lead. “It’s almost required,” says Osherove. “If you don’t do it, you’re basically stopping in the same place and you’re not actually changing anything”. Furthermore, “if you want the team to do unit testing or test-driven development, but the team itself thinks it’s not such a great idea, how do you actually get them to do it without growing them in the right direction?”.

“Another thing that happens is that a lot of teams are actually not in a position where they can actually make good decisions,” says Osherove. So “as a leader, you are the bottleneck. They come to you with every little decision”, but “what we want is for a team to grow their skills so they can handle the current reality that they’re in”.

Osherove says you should ask yourself “are you the bus factor? In other words, if you get hit by a bus tomorrow, could the team continue to function without you? If the answer is no, then you don’t really have a team. What you have is a bunch of people to help you”.

To gauge whether you’re moving in the right direction with this, each week ask yourself whether “the team need me more or less than last week? If they need me less, if I make myself less needed, if I remove myself from the equation, not just by disappearing but by enabling the team to do the things that I know how to do, then I’ve basically made them better”.

In Osherove’s view, there are three main phases of leadership. There’s “survival mode, where you don’t have time to learn, you don’t have time except only to react; learning mode, where you’re supposed to do things and fail and learn and do things slower; and self-organization, where the team can handle their situation without requiring the leader”.

Osherove explains that “you know you’re in survival mode if you don’t have any time to do the things that you would like to do, and you keep reacting instead of planning. Even if you have time to send people on a two-day course, it doesn’t mean that you have time to implement what they learn. If you don’t have time to do slow practice, you’re in survival mode.”

Of course, life is rarely as simple as being in a specific binary state. But Osherove explains that “it could be that a part of the team is in survival mode and a part of the team is self-organizing. If you have a large enough team, you might start to get cliques where some people are doing okay, whilst some people are definitely buried deep”. But “the way I see it is that it always hunkers down to the lowest common denominator. That means that if a part of the team is in survival mode, your team is in survival mode”.

“I think one of the most common mistakes,” says Osherove, “is that they tell people what they want to hear instead of telling them what the reality is, because they’re really scared and they want to make a good impression”. But, “we get paid to do good work and to say if there’s a problem,” although it really “takes a while to learn that.”

Another common mistake that Osherove highlights is not considering the mode their team is in, and the appropriate phase of leadership to apply. For example, “in learning mode, you definitely want to be a coach. You want to teach people. You want to give them time to do it. In survival mode, you usually want to be command-control. You don’t want to start coaching. You don’t have time to coach. You have to get people out of survival mode and into learning mode. If you mix those things up, you have a problem. Suddenly, you’re not really helping the situation. Similarly, if you have a self-organizing team that already knows how to work, already knows how to do something, and you treat them as if they’re in survival mode with micromanagement and command-and-control, you’re going to lose your team very, very quickly.”

The particularly difficult part though, says Osherove, is that “the mode can change from day to day. You have a new project, and suddenly you are back in survival mode.”

Read more interviews with some of the world’s best developers on * or follow us on or follow us on .*