Hello. I quit my job as a CTO and I thought I would get a little bit out of my comfort zone and become a Ruby intern for a while, just always interested to do some Ruby and web development, so I am actually between jobs right now. And hopefully I am just about to close with a company where I will intern as a Ruby guy and basically start from scratch just to see what happens.
So what drew me to the team leader’s space? I’ve always been drawn to it especially since to become a team leader, that was a few years ago. My first experience as a team leader was pure fear and lack of trust in myself. That is I thought I knew what I wanted to do but I had no one to guide me, I had nothing to guide me in specific directions, so I pretty much had to find out, just like every other team leader in software does today. And that hurts and today I think a lot of the Agile stuff that is going on talks about where we want teams to be, but no one talks about a team leader who actually has to make that happen. Personally I feel that is one of the reasons a lot of the Agile related adoptions fail, because team leaders are basically programmers with no kind of training on how to actually to get people to do something, to get rallied up behind something or to actually sometimes even confront people who may hurt the team.
I don’t think it’s a bad thing. I think it’s actually a good thing that programmers have to or are forced to get out of their comfort zone and become team leaders. The only problem is that no one gives them any guidance on what to do once they are out of there. So without guidance it’s a bad thing, but programmers becoming team leaders is a good thing because I think a technical team leader has more tools in their belt to handle problems and to discover issues than a team leader who is not technical and they have to rely on the technical leader who doesn’t have necessarily a management role. I actually like it. I think that pushing people to things they are not comfortable with may sound like negative thing, but I think it’s a good thing.
4. So it’s rather a challenge?
It challenges people and it grows them, it makes them experience things they would’ve never experienced if they had to choose and I think that is good for the programming community because programmers need to experience as many different things as possible, otherwise they will stay in their little bubble, just like I used to, and not experience anything if they can help it. And I like the fact they sometimes can’t not help it, they just have to go out of there and just actually do something. But that is one of the reasons you see a lot of the failures today, because people actually try to do something, but there isn’t a hell of a lot of guidance for software team leaders.
What’s interesting is that there is a lot of guidance on the management stuff and leadership, but no one has ever connected it to software in terms of management. The only recent book I can think that actually tries to do that is: "Management 3.0" by Jurgen Appello and I would call it the "X Unit Test Patterns" book of management. That definitely looks like hopefully one of the first in many that will come out to that because it’s definitely missing.
First of all, I would remove the word "Agile" from that. I think that a software team leader is a software team leader and team leader coaching is not the same as Agile coaching. Agile coaching is more about the process or so it looks. Definitely today Agile coaching is about processes so they teach people what the process should be, but they don’t teach them how to apply it to people’s skills. So team leadership can be taught regardless of the process your organization has and I think it’s important to separate that.
You can learn team leadership regardless of any agility or perceived agility or like thereof in the organization. So if you are a military project doing a 5 year releasing waterfall and CMMI level 17 or if you are a small startup of 3 people doing 17 releases a day. Team leadership is the same thing in both of them. So definitely it’s important. Without it there would be lack of guidance and team leadership happens whether you want it or not, the question is at what level is the leadership happening and how good it is. So if there is no team leader for the team or the team doesn’t do anything someone else will take command, it might be the project manager, it might be the CEO, but they have different interests although we should all have the same, but they have different interests that don’t necessarily apply to the good of the team.
A software team leader should have as one of the first things in them the wanting to have the members of the team be better, each and every week or month than they were the week or the month before. And that is a long side the business needs and obviously I think if that happens the business will actually benefit from that.
Anything whether it’s people’s things or technical issues or both. As a team player you are better than you were before and personally you are better in terms of work. I don’t claim that it’s a good thing to think that you can even change someone personally, but we are talking about growing someone in terms of their profession, in terms of their craft. So if the craft is to work with people and to write code along side of those people then it has to include both of these skills.
One of the things that I noticed is a team might have what I call the three phases of a team maturity. Teams might start out as very chaotic. Sometimes they end up as very chaotic as well. So chaos is the first, the most bottom level. That is the level where the team doesn’t even have enough time to sit down and learn something or experience something new. So they are either busy putting out fires or in-fighting or just not even knowing what to do. It might be at the level where even technically they are not even using source control, or they are making really bad decisions, or the quality is really bad, but chaos is anywhere where drastic steps need to be taken immediately so that the team can start learning something new. And what's interesting is that each phase actually requires a different leadership type.
So what you would do for a chaotic team as a team leader is different from what you would do for a team that already is self organizing. So a team leader that is inside a chaotic team, the first thing they would need to do is to actually cut off all the interruptions as much as possible so that a team can stop just putting out fires and create some time for the team and of course to not commit any new things until they can bring the team to some kind of a safe place. So usually teams in chaos are way overcommitted or they might have a lot of interrupts, so a team leader might need to even become the shield for the team, become the only interrupt the team from management or they might need to remove any commitments that the team already has.
Knowing that there is no way on Earth that they would make that anyway. So it’s about getting some kind of relief for the team, finishing what work there is right now and getting to some kind of state where there is some time to sit down and actually learn some new skills. But that is not the state where you start doing Unit Testing or TDD, that is not the state where you say: "Ok, let’s change everything and do Scrum". That would be one stage after. The first stage is chaotic; when the team has time to learn, that is called the team learning stage.
That is where you actually try to get the team as much as possible to the self organizing stage. And to do that you would actually have to start growing people and get some commitment from them, to challenge people to fix their own problems, to actually get the team into a state where they are skilled enough, that when you actually leave them in a room alone they will know what to do. But until you get them to that stage you absolutely cannot start and say: "You are self managing, go and be happy" because that will also fail because you are not challenging them enough to have the right skills. So there is chaos, then there is learning stage and the 3rd stage is self organization.
That is the stage of a lot of the Agile folks are talking about when they say how to lead yourself organizing team, how to be a Scrum master and how to lead teams in terms of soft skills. Not a lot of teams are in that stage. In that stage the team leader’s job is to be much more of a coach and much less of a shield. By the way the shield also goes away on the second stage because you want the team to start learning to work with other people outside the team. But this is where the team leader becomes more of a coach, more of a mentor and they might change constraints outside of the team, but they wouldn’t need to tell people what to do, because the whole point is that the team is self organizing so it wouldn’t even need a Scrum master, it would just need a mentor, but nothing more.
We usually introduce practices just at the first two stages; the first stage would be in chaos you would need to get the team into some kind of predictable state of being, so what work you have, you have more communication, so basic things like daily stand-ups, like one-o-one with the team; getting maybe a simple backlog together on a white board; very simple things that don’t really change a lot.
There is always the risk, but removing commitment that are already preventing the team from doing anything else, preventing interrupts from other people. Creating that shield and getting some basic practices in place such as build automation. Build automation doesn’t require and skill from the team after you build it, it just requires kind of a heart beat from the team. After that Unit testing would not be part of those. On the learning stage you might start teaching unit testing, getting people into that, but at the 3rd stage it’s more about letting the team decide what they want to learn, but especially mentoring them about recognizing when they have a problem and what they are going to do about it.
I would say that accountability is more to work with the costumer, I am talking about more about the team level, commitment is accountability on the team maybe. What happens in a lot of teams is people just break their promises a lot. So they would say they would want to do one thing, they don’t do it. Or they are no going to accomplish something, but they don’t tell anyone about it. Commitment is about getting people to do three things: to say something, to mean what they say and to actually do it. So a lot of people go maybe on the first stage, a lot of people may go also on the 2nd stage and they actually mean what they say, but they don’t actually do it. And a lot of people also try to do it but they fail and they don’t tell anyone they are not going to do it.
Commitment is a way for a team leader to make a team not break their promises. Because you are a team leader and you have authority and that helps. That is why I think that a team leader that doesn’t have authority will have a harder time getting team members to do something. When they don’t know that person or they don’t trust them or is in a chaotic stage, but when he is teaching new people new things he can get them to commit to someone with a bit more authority than they have and that gives them a sense of urgency. So commitment also comes from a different language. So there is whole language of commitment; if you’ve ever heard people say: "I will try to get it by ..." or "we really need to do this".
A lot of people will just say, what they really mean is we need to do this but I am not going to. If I say: "I need to lose weight" does that mean that I am going to lose weight? No it means I am not going to do it, it just means that I need to, but that is me getting rid of that need. So changing that language in which the team talks is a key. So you look for those words: "I wish", "if only", stuff like that and you change it, you ask the person to say something else. For example someone comes to you and says: "My machine is too slow." So you can ask: "And what are you going to do about that?" Actually turn around, delegate the responsibility to that person, which kind of sounds the opposite of what a team leader might need to do, but that is how you start growing people, you ask them to take responsibility for what they want, if they really want it they will have to do something about it.
They cannot expect you to solve all their problems. That used to be the model where the team leader solved the team’s problems and the team is just a bunch of code monkeys, but that doesn’t help anyone, except creates a bottleneck from the team leader. The team leader is away for a couple of days and suddenly no one gets anything done because everyone is waiting for him to make decisions and so on. So we want the team to be self organizing. To make that happen we need to teach them they can actually fix their own problems. To make that happen we will expect commitment whenever there is a problem that needs to be solved, and we won’t solve the problems for them unless there is absolutely no other way. So for example you might ask someone to fix their own problem and ask them to say "I will", not "I am going to try; I will give it a shot". Ask them to say "I will ..., by when?" and they might even say "I will do it by the end of this week".
That is a real commitment that is something you cannot escape from. The only other rule is that if you can’t get it done as soon as you realize that, you notify the person you are committed to or all the team that you will not be able to. That gives the whole team the chance to do something about it.
They can trust me as the team lead to support them even if they fail as long as they did what they were committed to. So for example sometimes people cannot commit to something they have not control of. Imagine five bugs in the system. I can’t ask someone to say I want you to commit to fixing all those bugs in the next five days, because you don’t know how long it will take. So what do you do in that situation? You ask them to commit for the actions that might lead to that solution. So I can’t commit to fixing it, but I can commit to working on it at least six hours a day for the next five days. That I have full control of and that is something you can actually measure, so that is trust.
If you have people committing to something they don’t have control over it doesn’t mean anything. So you also have to look for that. They have trust in me, I have trust in them and of course if someone breaks the commitment you can tell them that you expected him not to break the commitment and in this team we don’t break our commitments, we tell someone before we break them.
It’s very important obviously, but depending on the stage, the team might be more or less engaged with the outside. So in chaotic stage the whole point is to actually insulate them from the outside, so that the only context is the team and the requirement coming in that might be through the team leader. But in the next stages, the context gets bigger and the team has to realize they work in a company with a lot of stakeholders and I would want to teach every one of them how to deal with the different stakeholders, so that they get out of the comfort zone and they know what to do if the CEO comes in and says: "Can you make that button red?" What should a team member do at that point? If I continue to shield the CEO and tell him: "Don’t enter the room, everything you want just go through me" no one will ever know how to deal with the CEO who does that.
But if you teach someone to do, or if you ask them or actually give them homework, say: "The next time the CEO comes to you I want you to create a backlog item and tell the CEO 'I’ve put it in the backlog'". It might be scary for someone to do but that is part of getting it into the comfort zone. So that is how you can use commitment to get people outside of their context for example.
I don’t want to change people’s behavior; I want to influence their behavior. There is a very good book called "Influencer" and it talks about 6 points of influence for every behavior you see. One good sentence that I remember from that book is that every behavior you see someone do - if you see your CEO not willing to accept iterations, if you see a team member that is hording information instead of sharing it, if you see someone picking their nose in the team - the whole world is designed to make that behavior happen. Everything around that person is perfectly designed for that behavior to happen. So you need to start figuring out what it is that you might get to change so the behavior changes. And there are 6 factors, basically in 3 layers. The first layer is personal, does the person have a personal motivation to do that behavior or the new behavior you want.
Let’s say you want someone to start doing test driven development. Does that person personally want to do test driven development? For example you can give the motivation to say that if you do TDD you become a better programmer. So that is good. The second phase in that layer is: "I want to, but can I do it?" Do I have the ability to do test driven development correctly, or maybe that person needs a course. So there is always a motivation aspect and the ability aspect, so personal motivation and ability, even if you solve these two, the person knows how to do TDD and that person wants to do it. They still might not do it because then there is the social level and socially is there a motivation for that person to do test driven development or does everyone else on his team not do test driven development? So he’d be the only guy doing TDD. That usually doesn’t work, so that person might stop.
Second of all does the society allow that person to do it? Or whenever he writes tests someone comes up to him and says: "Why do you even do that for? So is he able to function in a society where people write test driven development? Ok, let’s say he has a social motivation, the whole team wants to do TDD and the whole will never nag him, will just help him do it actually, cheer him up.
Ok, you solve these four, you have two more, because that still might be not good enough, because what happens if you do not know you have the layer of the environment. Does the environment give you a reward or a punishment based on your action? Maybe your only reward is based on the amount of lines that you wrote in code, so you are much better off just writing a lot of lines of code and not unit test because you are going to get more money, so it doesn’t really matter how much test driven development you want to be in the team and all that stuff. Or maybe you are actually punished for tests because you are counting lines of code instead of amounts of tests.
The second thing that might be is the environment ability. Maybe there is not budget for an automated build server, so even if everything else was true people would still not do TDD because physically they are not able to automate all that hard work. They might start but then it would die. So those are the 6 points which are really important: social motivation and ability, personal motivation and ability and environment motivation and ability. Imagine pair programming: if everything was perfect but the table was actually, a desk that is in the corner, or you have those round desks where there is one person sitting, you cannot pair program on such a table. So someone always has to stand behind you. So that is environment actually stopping you. You have to solve all of the points in those to get a behavior to change and a lot of times people don’t understand that.
When you work with someone you want to change the behavior that affects the team you have to back off for a second and actually analyze right now those 6 factors and see if there is anything in those 6 that might match that behavior. And then you have to go through and go fix each and every one of them and then you will see the behavior magically changes.
For me one of the scariest moments of the team leader was when I actually realized I am actually going to have to confront a team member being really unproductive and that was really scary for me because that person was a friend of mine and I didn’t want to hurt their feelings and I didn’t want to be the bad guy. I didn’t want that person to leave their job because it means well they were really annoyed. So I wasn’t sure what to do and my mentor at the time actually asked me what I was going to do about it and I said: "Maybe I am going to have to sit down with that person, but I don’t know what I am going to say." And he said "Tell him what you told me, but be nice about it". So I sat down with the person, we had a good talk about their productivity and I actually asked him: "If I told you could type 4 times faster what do you think of that?" and he said: "That is awesome" and we went out of that conversation we began a real learning relationship and even more respect.
So that completely changed my mind about the whole idea actually confronting problems and it definitely changed the way I look at approaching people. Before that I would never have done that and I think a lot of team leaders today are afraid to actually sit down with the people on their team who either have a problem or are causing a problem for the team, because they are afraid of hurting people’s feelings and they are afraid of actually being hurt themselves because that person is their friend. And what we need to realize is that there is a good way to say almost everything as long as you explain to that person what’s in it for them. That is all you really need to do. You don’t have to explain how it’s a problem for everyone else, you just have to explain how it’s good for them and how you can actually help them and teach them to do that.
I’d like to say that yes there is a good way to do it, but part of me actually says that there is no problem because it’s kind of like natural selection. People get randomly chosen, some of them are good some are bad. The ones that are bad have to become good or they don’t, or the ones that are good will do amazingly well. If we were to try to select people you could select people with leadership qualities, but then the whole thing of getting out of the comfort zone might be a bit of a problem, because it is already their comfort zone. You could teach them a lot of stuff they don’t already know, but I am more interested into getting that shy person to be the team leader.
I know it happens randomly or by chance most of the time, so I would actually not interfere with that. Usually an organization would choose, remember it’s a behavior, so all the environment is everything around the team is organized so that that specific person will be chosen. So it doesn’t really matter if there is a good way to choose it because the circumstances and the reasons and the personal motivation of the person who chooses they are so complex, and the 6 reasons are so much there that even if there was a good reason to choose, a lot of it is personal and a lot of it is environmental and a lot of it is social. So I would say keep it at that. So the answer is no.
First of all you should know you are not alone. There are a lot of people feeling alone just like you and second of all there are blogs and various societies out there that can help. For example my blog, 5whys.com, has a link to a mailing list where you can actually share some questions with a bunch of other team leads. Also I am organizing a conference that will happen in London, December 2011 that will be specifically for tech leaders, for team leaders in software, where we are actually creating our own society, where we can learn from each other. The closest thing to it right now is the AYE Conference (Amplify Your Effectiveness), but it’s more about personal things. That conference will be about skills for team leaders.
Yes I think you should look for a mentor and a lot of organizations have them if you are lucky, sometimes you are not lucky and you are not going to find that person. And that is OK too, so you just going to have to be there a bit alone and that is part of getting out of the conference zone. Feeling alone as a team leader I think is sadly quite common. I know that I’ve definitely felt that for quite a bit, so getting a mentor definitely helps. Getting into a mailing list helps more than it doesn't. And I don’t have a good solution for that yet. I'm working on it.
First of all if people want to share their experiences I am actually writing a book right now called: "Notes to a software team leader". The whole point of this book is what would you say to your new software team leader just coming into play and half of the book is going to be dedicated to submissions from other people. So if you are a team leader or a project manager or a team member, there is something you always wanted to say to your team leader or you’ve already been down that road - there is one thing you would love to say to a new team leader just coming in. Please go to 5whys.com/note and submit something between 500 and 1000 words and it just might get published. I would love to hear what people have to say.
Other resources, as I said, there is the "Management 3.0" book by Jurgen Appelo and there is the mailing list and there isn’t a whole lot more, that is the big problem. There is the 5whys.com blog which is awesome. There are a few links to other blogs on my blog which I don’t remember right now so you can definitely look there.
18. This interview was very revealing and I want to thank you for that.
Thank you. One last thing, if you are interested in courses and stuff like that, you can find them at osherove.com and some running courses about team leadership in April and in July in Oslo and London. It’s a two-day course for new team leaders, especially for new people coming in. So I’d love to see people there, I’d love to grow this field and create a real community of practice for this.