#110 - Elastic Leadership: Growing Self-Organizing Teams - Roy Osherove

[00:02:15] Episode Introduction

Henry Suryawirawan: Hello again, to all of you my friends. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. And this is the episode number 110. If this is your first time listening to Tech Lead Journal, subscribe and follow the show on your podcast app and on LinkedIn, Twitter, and Instagram. And if you’d like to support my journey creating this podcast, please subscribe as a patron at techleadjournal.dev/patron.

My guest for today’s episode is Roy Osherove. Roy is the author of “Elastic Leadership” and “The Art of Unit Testing”. In this episode, we discussed his leadership insights from the “Elastic Leadership” book. Roy first shared how he came up with the concept taken from his learning experience and described what elastic leadership is. He explained the different leadership styles based on the three team phases, which are the survivor mode, learning mode, and self-organizing mode, and advised how leaders can adapt and transition their leadership style from one phase to the other in order to lead more effectively. Roy also shared about the Team Leader manifesto and the Line Manager manifesto to provide some guidance on how leaders can grow their teams towards self-organization and self-sufficiency.

I enjoyed my conversation with Roy, and “Elastic Leadership” is one of my favorite books learning about how we can adapt our leadership styles more fluidly based on the team’s phase. If you also find this episode useful, please help share it with your friends and colleagues who can also benefit from listening to this episode. I really appreciate your support in sharing and spreading this podcast and the knowledge to more people. And before we continue to do conversation, let’s hear some words from our sponsors.

[00:05:54] Introduction

Henry Suryawirawan: Hello. Welcome back to another new episode of the Tech Lead Journal podcast. Today, we have a guest named Roy Osherove. He’s actually an author of a few books that I have read. Books such as “The Art of Unit Testing”, “Elastic Leadership”, and he’s also coming up with a new edition of “The Art of Unit Testing” and also “Pipeline-Driven Organization” which is still in progress. Roy is someone who I have been trying to arrange this interview, so I’m really glad to have this opportunity today to actually talk to him.

So Roy, when I read your book, “Elastic Leadership”, I think it was one of the insightful books that I read, especially teaching about leadership stuffs. So hopefully we can discuss a lot about that book today. And yeah, looking forward for this conversation.

Roy Osherove: Wonderful. I’m really happy to be here and looking forward to a stimulating conversation. By the way, I really hope this is going to be like a two-sided thing, not just me talking, but having a real conversation.

[00:06:45] Career Journey

Henry Suryawirawan: Sure. Happy to have that. But first of all, I always like to start my conversation by asking the guests to share more about their career. So any kind of highlights or turning points that you think worth to share with the audience here.

Roy Osherove: Well, I’ve been in the software business over 20 years, so there have been a lot of turning points. I started as a software developer, and I went through a lot of different roles from team lead, architect, CTO, director. These last past few years working as a consultant, also working as an entrepreneur these days as well, and also working in different countries. I was born and raised in Israel. But we lived in Scandinavia for a few years, and then we lived in the US for a few years in both the east and west, both in New Jersey and then California, and then coming back to Israel. And I also have three kids, which also is many turning points there.

So if I try to talk about a little bit of career journey, I could say that there are a few big turning points. For a few years, I was working as a software developer, and at some point, I really got interested in Kent Beck’s book, “Test-Driven Development by Example”. I learned it and I practiced it and I tried to experiment with it with my team. That was the beginning of a turning point. But the real turning point came in when I started organizing an open kind of a two to three-hour workshops, hackathons for the community, kind of like a meetup. But before meetups existed, before meetup.com existed, and that was about test-driven development. I got quite a bit of people jumping into that stuff. That really got me thinking that I could make this like a full time thing. So I went to my boss, and I said, “Hey, listen. I think I can organize training and actually asked for money for these things.” And my boss came with horrible terms. So I said, okay, no thank you. And I decided that I’m going to become a consultant and I’m going to start doing this training and consulting about this stuff full time.

I found my first customer by speaking at a meetup. Then, it was called the user group. And I helped be part of like a .NET meetup then, and later I created the Agile Israel user group. And I found my first customers in those meetups, in those user groups. Once I had the first customer, which was a big customer for me alone, I started down that path. So I had two clean years of just working with one or two customers, learning a lot, making a lot of mistakes as a consultant. So I’ve been on and off as a consultant for the past 20 years as well. And I find that I’ve been working two or three years as a hired person and then two or three years as a consultant, etc. So I’ll dive into something, I’ll learn a lot of stuff, I’ll go out, and I’ll start spreading across multiple organizations and come back in.

So the turning point was realizing I can do this training stuff and enjoying it. The other turning point was when I was first looking at the first check I ever got from the customer. Realizing that I’m making much more money doing the consulting and the value that I bring is higher because customers are willing to pay much more per hour for my services. And so, that was a huge turning point because I decided I’m not going to do just hired from that point on. I’m going to do whatever works best for me, which is a hybrid approach. And ever since then, it’s been training and then writing books about that training and then speaking at conferences about those books, and then consulting about those books. And then moving onto the next thing, learning that stuff, practicing it, writing about it in blogs, writing about it in books, doing consulting about it, blah, blah. So it’s like this cycle that I seem to be going through, which I’m still going through right now. If you ask me, I’m always in the middle of like two or three cycles with two or three pieces of parallel skills that I’m either learning or teaching. And so, there’s always something to fall back on, as a consultant.

If I had stayed with test driven development and unit testing, at some point, it would run out, basically. I mean, there’s always work in that, but you have to be able to reinvent yourself and learn these things and grow, and then you bring more value. So these days, I’m definitely, I have a lot of different facets that I can talk about and consult about. And all these things are related to things that I really, really care about. So to me, they’re like a Marvel MCU. Each facet is a specific skill that I wish developers had, and then I learned that, and then I bring that and then I work in it etc, etc.

Henry Suryawirawan: Thanks so much for sharing your journey. I think it’s really admirable, right? The way you kind of like change facets, like from being as an employee to be a consultant and you switch mode between employee and consulting, and then you find the passion of doing training and consulting, writing books, and things like that. And you mention about also expanding yourself beyond just TDD or unit testing. You also wrote books about leadership, pipeline-driven, and all those stuffs.

[00:11:31] Writing “Elastic Leadership”

Henry Suryawirawan: So today, we are not going to cover about test-driven development, unfortunately. But I would like to discuss a lot more about the “Elastic Leadership” book, and maybe when we have time we will discuss about pipeline-driven organization. So when I read your book, as I mentioned in the beginning, it was really insightful, especially if you’re working in uh, maybe non-performing teams, or in a startup where everything is like chaos. Tell us more why you started writing this book in the first place. What kind of problems do you see maybe in the technical world or maybe engineers for them to read this book?

Roy Osherove: The book Elastic Leadership is based on a blog post on a blog that I started writing when I started becoming a team lead. As I was growing as a team lead, I would document my own realizations about things. And then slowly over time, a few years, it grew and grew, and I decided I’m going to turn it into a book. I wasn’t sure what the book name would be, and I asked Kevlin Henney who’s a good friend of mine and a speaker and author. I was thinking about calling the book “97 Things Every Team Leader Should Know”. But eventually, I called it Elastic Leadership because I wanted to come up with a term that describes this kind of framework that I’m coming up with.

So, Elastic Leadership is based of all the mistakes that I’ve ever made as a team leader. I believe that the best way to learn something is through making mistakes. So I can tell you I’ve learned quite a lot. I think that people should realize everybody in this industry doesn’t really know what they’re doing. They might have more experience. Doesn’t mean that they know what they are doing. They might have had some success, some failure. There are some things that they know have worked or have not, but does not mean that they know what to do next. And so, as a journey, as a team lead, there’s been a lot of that stuff. Trying to come up with different ideas.

I’ll give you the simple example. In my first team, I was very much a command-and-control leader. So I believed in protecting my team and having that bubble where people are not allowed to contact the team. And I believe that was doing the absolute right thing, because the team was kind of in a chaotic state and all that stuff. And I believe that if you’re not going to control what the team is, who the team talks to, then everyone will control the team instead of you. That seemed to have worked for a while. And then I spoke about it at a conference, and I spoke about how you should be able to quickly take charge of a team and stuff like that. At the end of the talk, this Scrum Master, I think, approached me at the end. He said, “This is the opposite of everything I ever teach people, which is self-organizing teams and they should learn to make mistakes on their own and all that stuff. Well, don’t you believe in that stuff?” And I said, “Well, actually I do. I think that’s really good idea.” And he said, “Well, how can you believe that? And also believe in what you just thought, which is you have to take control and be a bit more command-and-control?” And I really thought about, I didn’t have a really good answer. I thought about how can those two situations exist in the same time in the world?

That was a big realization for me, is that they don’t. The same team can have different contexts. In one context, the team might be in what we would call survival mode, in which they don’t have time to learn. They’re too busy fighting fires. They don’t have time to make mistakes. In that situation, command-and-control might be a really good idea to get out of there. But if your team has time and they are learning and they want to learn, they want to practice. God forbid that you should be a command and control leader because they’re not going to learn anything. So that’s why I called it elastic leadership is because there are actually three different types of leadership styles. We change them based on where the team is at. So one week, the team might be in survival mode. The next week the team might be in learning mode, and the week after the team might be in self organizing mode, and then they might go back to survival mode.

We measure that by how much the team is able to cope with their current scenarios, with the current context. For example, if I have a team of developers that have been building websites, hundred websites in the past year, and I’m asking them to build the next one, just another website. It’s very likely that they’re going to be much more of a self-organizing team. They know what to do. They know how to solve these issues. They just need the goal, really. But if I ask that same team to connect my glass of water to my laptop, and they don’t have the skills to do it. And I immediately said, “Okay, we have a deadline and we need this by that, or at least we need something.” The team would immediately be in what we call survival mode, because they’re probably over committed. They don’t even know how long things take. They don’t have time to learn, and they might not even be able to discuss with me how to change the situation. In that situation, a command-and-control leadership might work. But in the other situation, a self-organizing team, it’s really best to leave the team mostly alone. Not tell them how to do their job, but just tell them what you need done. They’ll figure it out.

And in the middle between those two extremes, there is the learning mode. That’s the team that has time to learn, is actively engaging in learning. Well, the example that I use is imagine that you have a kid and you’re teaching your kid how to tie their shoes for the first time. How long and how many times would they need to practice before they tie their shoes as fast as you? The answer is not going to be five minutes, probably not even five days. It’s going to be a long while, a few good weeks, maybe even months. We slowly practiced, and it’s very frustrating. This is what learning really feels like. But in many situations, we go to a company and we say okay, those people don’t know how to work in TDD, so let’s just give them an extra 20% of time. But truly, what we should be looking at is five or 10 times more time to actually do and make mistakes and learn things the hard way, or at least a month or two. So, learning mode is actually very difficult to be in because learning mode requires that you re-estimate some of the stuff that you’re working on so that you can redo it, but this time with learning built in. So with the mistakes.

But if you’re in survival mode, you have to realize you’re in survival mode. And then the only way to get out of survival mode is to make time to learn. The only way to make time to learn is you have to look at the current commitments and then remove whatever you can and finish whatever you cannot move. And within a month, you move into learning mode and re-estimate things. So this type of framework. These are things that I wish I knew or someone ever told me as a team lead because I didn’t even think about those things. Those are the things that nobody really talks about. It’s the glue between people. It is not Scrum. It is not agile. It is not all those things. These are specifically methods for handling reality. And so, a way to grow self-organizing teams. That’s the way I think about it.

[00:17:57] Team Leader Manifesto

Henry Suryawirawan: So it’s very interesting when I also read about these three phases of the team, right? Because as you mentioned, a team has a different context, and one day they could be in survival mode. The next day, they could be in learning mode. The next day could be self-organizing. But then they can change to another mode. And as a team lead, sometimes we are not trained to understand about this context. And in the first place you mentioned that you wish you know all of these things, right? Because many times as a team lead, especially the new ones who just got promoted from being a good IC, they just got promoted as a team leader. They don’t understand this kind of nuances.

In your book, you actually have this really interesting manifesto, a Team Leader Manifesto. Can you tell us more about this manifesto? And what should be the responsibility of a team lead from your view?

Roy Osherove: So the manifesto is, basically, it’s a compass. My realization for myself is that as a team, I have no idea if I’m doing the right thing. I need a moral compass. Something that when I’m dealing with a dilemma, it allows me to decide which choice to make. If someone comes to me and says that they want me to help them with a problem, should I let them solve the problem alone? Should I solve it for them? Should I do something else instead? So, the elastic leadership model is a moral compass, and the manifesto is basically a way to explain it.

The idea of the manifesto is to say, here is one worldview, and that worldview is that as a team leader, my job, or the way I measure myself, is that I make myself unneeded. So every day or every week, I look and I try to even measure how much do people need me to solve their problems? Or can they start solving their problems without me? If they can solve more problems without me this week than they did last week, then I’m doing a better job. So that’s one way to measure, is that slowly over time, you are needed less and less, which is completely crazy, because a lot of people want to be needed. I mean, that’s kind of your job. Won’t you get fired if you’re not needed? And the answer is, you will actually become more successful and more valuable to your company if you are no longer a bottleneck for the people that are working with you and under you. Which means that every time you are the only person that is able to make a decision, or that needs to be consulted with, or that has the experience to give an opinion on what to do something, and people will not move forward without you, you are essentially a bottleneck.

Another way to say it is that you are a bus factor. A lot of people have already heard this, but let me just define it. A bus factor is the number of people that have to get hit by a bus for the team to stop working. A bus factor of one means you have this person in the team that if that person doesn’t come into work tomorrow, the team is screwed. They don’t know how to do that specific person’s job. So a person that knows how the build works or the manager or the leader that is able to sign or make a specific decision, or an architect that has to sign off on something, etc, etc, etc. So as a team lead, I want to remove myself as a bottleneck over time, more and more.

We also believe a few different qualities. We believe that it’s just as important to understand how people work instead of just machines. So we need to understand how people work. We need to understand psychology a little bit. Because part of our job is working with people. I think that’s more important, because computers do exactly what you tell them. In fact, if you could get rid of people in the software business, everything would be much easier. We can’t, unfortunately. So you have to understand people better.

Another thing is that we adopt a leadership style that keeps changing instead of a one style, one size fits all. Which means that we look at the current phases of the team, and we see where the team is, and we change our leadership style based on it.

And lastly, is we believe that people need to grow under our care. Which means that one way to remove yourself as a bottleneck is to grow the people that are working with you. So they learn new things. So they learn how to think like you think. They don’t need you, and that’s a very powerful feeling. So growing people and challenging them to get out of their comfort zone would be one of those things. That’s a very difficult thing for a lot of leaders to do because sometimes people don’t like getting out of their comfort zone. But if you’re trying to get your team into learning mode, the whole point of learning mode is that you feel uncomfortable. The whole point is that you’re trying to learn things that you’ve never done before, which feels really, really sometimes frustrating or annoying.

So all these things together, they form this moral compass. Every day, am I a bottleneck more or less? Am I challenging people? Do I pay attention to human interactions and understanding how they happen? Am I changing my leadership style? All those things together. That’s the manifesto, really.

Henry Suryawirawan: So when I read this manifesto, definitely it strikes me, because as a team lead, sometimes we tend to focus more on like projects, tasks, and also hitting the deadlines, making sure the code quality works, and things like that. Sometimes we tend to forget the people aspect, or, for example, changing our leadership style as well, which I think is really crucial, coming back to the three team phases. And also, you mentioned that the job of a team is to grow the people and to be able to remove themselves from the bus factor or the bottleneck equation, right? So I think this is also a very critical thing because yeah, as you mentioned, a lot of team leads probably think by being there as a leader, they are like the crucial person inside the team, maybe to make decisions, or maybe to advise people, and things like that. But actually, a true team lead that is successful is someone who can remove themselves out of the equation more and more. So thanks for sharing about this.

[00:23:23] There Are No Experts

Henry Suryawirawan: I also like this one phrase that I read in your book. Let me read it. “There are no experts. There is only us.” I think many times in any kind of a team, we all aspire to have someone who can come and save us, maybe consultant, maybe from books, or whoever thought leaders. Tell us more about this phrase, because when I read it, it is really interesting. There are no experts. There’s only us.

Roy Osherove: Yeah. My friend Jeremy D. Miller uttered it in one of the conferences, the All .Net Conference, I think. I really like that sentence. It goes to what I said at the beginning, is that nobody really knows what they’re doing. “There are no experts. There’s only us”, is kind of a lonely feeling. Because it means that at some point, you’re going to have to make your own decisions. There will never be the person that knows exactly the answer. Those that tell you that they know exactly the answer, they’re probably missing something, because it’s like that effect, I don’t remember the name of it, is that the more that you think you know, the more you realize how much you don’t really know.

Managers in different capacities with different experiences and leaders are still winging it. They’re still trying things. At some point, you cannot just wait for someone to tell you what is the right thing to do, especially if you’re a leader. That day will come, and hopefully it’ll come soon, is that you will have to make a decision and you will have zero idea what’s going to happen. So you can try to delay the decision. You can try to learn more about it. You’ll try to make it an educated guess. But at some point, you’re going to have to jump feet first into that pool and actually try things, and realize that there are no experts. You’ll be in a room with other leaders and other managers, and you’ll talk to them about those things that you’re experiencing, what you’re learning, etc. And at some point, you’ll realize that they know just as much as you or they don’t know just as much as you, and they’re all winging it. The higher up you go, the more surprised you will become just at how much people are really open to different ways of thinking.

If you realize this, then that gives a very strong indication that if you come up with some way to try to change the situation, you might be surprised how much more people are willing to listen to you. Because we usually assume that, oh, the people are leaders, they already know so much. Why would they even listen to me? They are waiting, and they can’t wait for people to come up with more ideas, so they can try them. Some people are afraid to try ideas and that’s a different problem. But no one really knows. No one really has all the ideas. Some people have tried some of them. Some people might tell you, oh, I tried this idea, but don’t think for a second that 50% of the time, if you’re talking about someone, the other person might have less experience than you. Even if they are at a higher role than you, they might even have less experience than you about that specific thing or problem or situation, etc. So, if you feel like you have no idea what you’re about to do, join the club. Welcome. Everyone who writes books like me and does consulting and speaks at conferences. They don’t know more than you. They’re just like talking about what they’ve learned on their own the hard way, and they just seem like they know what they’re talking about.

So this elastic leadership stuff, it is a thing that seems to have worked for me. And I completely made it up. It is a framework that I decided to call elastic leadership. Who the hell am I to create this thing? Who gave me permission to write this thing? No. Nobody. You can go ahead and create your own framework. Talk about it. The thing that really brings value to me is not that I created a framework. What brings value is that I talk about it and I explain it, and then I realize how much I was wrong, and then people talk to me and I learn something. So if you want the right answer, give a wrong answer.

One of the best ways to learn is to put what you think your knowledge is out there and then see what the world throws back at you. To me, that’s always been my motto. Hey, I tried learning test-driven development. Let’s see. Let’s write a blog about it. Let’s speak at the conference. And then suddenly, you get sometimes slaps in the face like, oh, that does make any sense. Like that guy who spoke to me about how can you talk about command-and-control, but we also want to do this. And that was after I did the talk. It’s not before, but I already did the talk. And then after the talk I realized, yeah, I completely missed this entire part. So when you see someone speak on a stage, don’t assume that they’re speaking because they’ve figured it out. They’re speaking and they’re in the process of figuring it out. And if you talk to them, maybe in three months, their talk might be different.

If they never change their talk, they’re not learning anything new, and I would trust them less. For real, you want to look for people that keep changing their mind, because it means they’re learning something. Like the first version of Art of Unit testing is completely different from the third version. Completely. Like I removed some chapters. There are some things that I don’t like anymore. Some things that I changed in the second edition, and they’re not like small stuff. Anyway, some things stayed, which is good, but some things did not.

Henry Suryawirawan: So I think that’s a very apt advice for a lot of team leaders, because sometimes when they’re new in the job, sometimes they are like indecisive. “What should I do in this kind of situations?” And they wish somebody could tell them exactly what to do. I believe this is not an advice for people not to ask for help if they need help, but it’s more about, yeah, sometimes you just need to believe in yourself. Maybe you do research, gather opinions from few other people, right? But at the end of the day, there’s only us. There will be no experts, so to speak, to come and help and solve the problems for you, right?

Roy Osherove: I would even say, you don’t even have to believe in yourself. I would say, the only thing you should believe is that you will make mistakes, and you have to get those mistakes out of the way as soon as possible. The only way to get that out of the way is to actually go ahead and do them. You don’t know what they are. So the more decision you start making, especially if they’re a bit scary, the better you will become, the more experienced you will become, and you will learn.

Let’s say, for example, you have to do a serious one-on-one conversation with a person in your team. It’s really scary and there’s a million ways to go about it. You don’t have to research the million ways to go about it. You take a day. You maybe do a bit of research, and then you just do it. You do it not because you think you’ll do okay. You do it because you have no idea what’s going to happen, and you have to find out what’s at the end of the talk. What will you find at the end of that conversation? And you might find, hey, that was easier than I thought. Or I thought it would go this way, and it completely went different way. Or I thought that I will not be able to say something, and I did say something. I thought the person will say X and then they said Y. Or what I thought would happen did happen. Whatever it is, you have learned from that. So the next one-on-one will be better from your point of view. That’s the important part.

So don’t think that you will get everything right. In fact, you will get most things wrong. And then slowly, over time, you will get a few things less wrong, because you’ve already made the mistake. It’s like touching hot fire the second time. You probably won’t touch it, right? But you had to touch it the first time. So just get it out, it’s the first dent in the car, but there’s a hundred of them.

Henry Suryawirawan: I really love this advice, so thanks again for giving this plug, because I think a lot of people in the tech, especially the engineers, we always have this imposter syndrome, and we think that other people might know better than us. The speakers, the authors, maybe the guests in the podcast, and things like that, right? But actually, it’s not true. Sometimes we’re all just winging it, so to speak. Or maybe we just give our opinions at that point in time, which might change in the future.

[00:30:49] Survival Mode

Henry Suryawirawan: So maybe if we can go back a little bit to the three team phases, you mentioned about survival mode, and you mentioned the time when the team doesn’t have learning time. I would imagine this kind of a chaotic team where you are firefighting, solving problems, incidents, and things like that. So tell us more why it is important to have learning time? And when you are in survival mode, how can you create more learning time? I think that’s probably in the mind of a lot of people.

Roy Osherove: So the way that you create learning time. So if you are in the situation where everyone is running around like headless chicken, and you’re just fixing fires, how do you move from that into learning mode? So the answer is, first of all, is that the mode of the leadership changes to more command-and-control, because the sentence in your head should be “When the ship is sinking, the captain doesn’t call a meeting. The captain gives orders.”

The orders might be everybody does what they’re best at for the next month. But then, during that month, you can look at all your current commitments. See whichever ones are prioritized and will fit in that month, and then everything that doesn’t fit, you re-estimate, you go to your management and your leadership, and you say, we are currently in a death spiral. If we keep going down that route, we’re going to be in a worse situation in three months. And so here’s the way that I intend to get out of it. For the next month, we’re going to finish whatever we can finish from these stories. After that, everything doesn’t fit in that month, re-estimate to three or four or even five times longer. Prioritize and then start working on it. And that’s the way that we gain our sanity back.

Now some people might be listening to this and saying, “Yeah, never.” Because they’re not going to feel safe saying that to their management. Some people will be safe saying that to management. They just don’t know it. They’re just afraid. One of the things that I highly recommend, there’s a book by Jerry Weinberg called “Becoming a Tech Leader”. And he talks about the idea that leadership done right is a tough job. So if you’re doing it right, it’s difficult. If it’s not difficult, you’re not doing it right, in the other words. A lot of leaders like to take the money, but not do all the difficult parts. And what are the difficult parts? The difficult parts are working with people, telling people things that they don’t want to hear, changing and looking sometimes weak in front of others, stuff like that.

So what I’m suggesting here is being very fragile, and putting yourself out there and saying, we need to change the way we’re working. You have to convince management, and that might be scary for a lot of people. That’s exactly why you should probably do it. Because it’s scary. Because there are two things at play here. First, this is absolutely needed for your team. So you should do it for the team, cause that’s what you get paid to do, is to do all the tough parts, to talk all the tough conversations. If you’re not going to say it, nobody’s going to say it. Your managers don’t know what the right thing to do is. They expect you to know. Otherwise, you’re just taking the money, not doing the difficult part.

The second thing is that by doing the scary thing, you will become a better leader. Because you have to be able to be in a place where you’re not comfortable, to be in a place where you’re doing something that scares you. Because you’re also going to be asking the people under you to do those same things. You will ask them also to be uncomfortable. As you go into learning mode, you might ask them to do things that they’ve never done before, etc. And when that time comes, it has to be from an experience. You can’t demand it from somebody, but not demand it from yourself. You have to come from a place of knowledge, so you’ll know how difficult it feels to do that stuff. And when you talk to them and you explain, they’ll see that you know what you’re talking about. Otherwise, it’ll be theoretical and people will see it.

So it’s good for you as a leader to do the difficult stuff cause you want to ask your people to do difficult things. For example, backend people to work on frontend, or people that like to work alone to do pair programming, or people to let go of some of their decision and allow others to make some of those decisions, blah, blah, blah. There are a lot of different points. So you have to be the example. You have to go and do those things, and then you’ll see that it’s not as bad as you thought it would be. And then you’ll know that it’s okay to also ask it from them, cause it’s not as horrible as it feels like.

Going to management, in many ways, can also be great for you. Because management will, well some of them will, some of them won’t, some of them will appreciate the fact that someone is finally telling them the truth. Cause they probably already feel it, feel the truth. They already know what’s happening. But they feel like they can’t trust the dev team up until now. Maybe now, finally, there’s a team they can trust. It’s about building a new relationship. And some of them won’t like it, and that’s fine too. But the reality will not change just because they don’t like it. So at least you’re going to have to say it, because if you don’t say it, the reality still sucks, and you’re just saying that everything’s great, which is absolutely wrong. So the hammer will come, but you’re just pushing it further away.

Henry Suryawirawan: Yeah. Thanks for reminding all these leaders who are probably in the survival mode. So you need to take charge. Command-and-control is the leadership style here where you need to take charge and make sure that the team survives. That’s the first probably priority for you as a leader, right?

Roy Osherove: Yeah. But not just survive as in stay in survival mode and just be strong. Because a lot of leaders are actually very good at staying in survival mode. So there is a big anti pattern here. A lot of people, the only thing that they know how to do is to work in survival mode. Like they’re great at waking up at two in the morning, fixing the red build and doing all that stuff.

The idea is that you are taking charge for a month. There is an end. There is an expiration date, and that is the scary part. The expiration date is when you actually move into re-estimation and learning mode. That’s the difficult. A lot of leaders are already working great in survival mode, but they perpetuate it. They never get out of it. This is the problem. There’s a cycle there. If I’m in survival mode and I keep fixing those fires, what happens? I just have more fires, because I didn’t take care of the things that I should have taken care of today, cause I’m taking care of the things from three months ago. So the things from today are going to be there in three months for me, so I’m going to be in a perpetual motion. You have more features that you have to test and all that stuff, so things will just become worse and worse. That’s the problem. It’s not about managing yourself in survival mode, it’s that in survival mode, you are command-and-control for a specific purpose. And that purpose is that you want to get out of it.

And how do you get out of it? Well, you tell people what to do with the work on the thing, but you prioritize, and you remove commitments, and then you switch into the learning mode. Removing some of the commitments, that’s the key part. Re-estimating, that’s the key part. The command-and-control is absolutely necessary, but a lot of people already do it. If you’re not doing it, command-and-control is really, really important. You cannot take a team that’s in learning mode. And then treat them as if they’re self-organizing.

For example, sending them on a three days TDD course and then expecting them to actually implement it. It’s not going to work, cause they’re going to go get right back to work. They’re not going to have time to implement it. Don’t expect anything to change. Or calling up a meeting and letting people make mistakes in learning mode. You’ve already made all the mistakes. You don’t have the bandwidth from extra mistakes at this point. You need bandwidth for more mistakes.

[00:37:52] Slack Time

Henry Suryawirawan: Thanks for sharing this anti pattern, right? So the goal is not for you to perpetuate and keep standing strong, and be in the survival all the time. I think the key definition in your book you mentioned about slack time, right? So the team in survival mode basically doesn’t have slack time. It’s all firefighting. It’s all about resolving issues. But the team in learning mode starts to have more slack time. So I think this is a good kind of like definition or variable where you should aspire to have more slack time for the team. So tell us more why slack time is very important? Why we should be in learning mode? Why teams should have slack time?

Roy Osherove: Well, without slack, without time to make mistakes, you can’t learn anything. The whole idea is that it’s teaching your kid how to tie their shoelaces. You don’t give them time. You have to get into the car right now. You’re going to tie their shoelaces for them. That’s okay if you’re in survival mode. We get into the car. There’s a lion chasing us. I’ll tie your shoelaces. But get into the car, there’s no rush. I’ll tie your shoelaces for you. That’s a problem. The whole idea is that I want you to have time. Maybe we’ll leave 15 minutes early so that you have time to practice tying your shoelaces. That’s what slack time is.

Henry Suryawirawan: And you mentioned few techniques that leaders can do is by, for example, doing more delegation. So depending, like what you said, if the kids can start tying their own shoe, you give the time for them to learn how to do the stuffs. You also give some kind of like homework, personal commitment for them to improve. The other things about commitment language, right? So how people should actually commit to certain things that they want to do and then learn from that experience.

[00:39:21] Self-Organizing Mode

Henry Suryawirawan: And then the ultimate team phase is actually self-organizing mode. So probably not many team leaders are in this mode, I believe. Because from my experience, it’s really kind of like hard to have a fully self-organized team. So maybe can share a little bit more. How does self-organized team look like, actually? What kind of differentiation that you can see from a self-organizing team?

Roy Osherove: Well, a self-organizing team, I would say, maybe 5% of the teams I’ve ever seen are self-organizing. The idea in a self-organizing team is that the team knows how to solve any problem that they face. So I think of them like a team of team leads.

What is a team leader, usually? It’s someone you can ask almost any question and they’ll find an answer for you. So imagine you had a team of team leads. That team is self-organizing cause whatever you throw at them, they’ll figure it out. That’s the idea. If your team cannot figure out some of the stuff, then they’re not self-organizing. In self-organizing team, you want usually just set goals, maybe have some metrics but you don’t want to tell them how to do their job. So you might just want to influence the structure of the team by changing people, or by changing the meetings that they have, or by measuring differently. So you really use a lot of the influence forces that I mentioned in the book.

The influence forces are powerful thing for both learning mode and for a self-organizing mode, and those are personal influence forces. There’s community and then there is environmental. When we’re talking about self-organizing teams, it’s usually the last two. So we have the people around people and we have the physical environment around people. Also, it could mean the rules and the reward systems or the punishment system in the company. So changing metrics would be changing the reward system in the company. You’re measured on code coverage is different than you’re measured on pair programming or you’re measured on bugs found in production. So there’re a lot of things that we can do without telling people how to do something.

[00:41:18] Learning Mode

Roy Osherove: But I would say that for most leaders, learning mode is more challenging than self-organizing mode. Because learning mode is really about how do you spend time as a team continuously learning things that you’re not comfortable learning? And there are a lot of different techniques. One of them, as you said, is commitment language, for example. Or you change the way that you ask questions or speak to make sure that people are actually committed to doing something. So you might use a specific type of language. For example, I will do something by X. Instead of saying, “Well, I could, or I can try, or I might, or let’s try and blah, blah, blah, blah”. All those things, they have this connotation where there’s an exit point. There’s a door. Don’t say, “Well, I did say let’s try. I didn’t say we’re actually going to do it”. If you don’t give a specific end date or time, then again, “Yeah, I said I’ll do it. I didn’t say when”.

So sometimes in learning mode, sometimes it’s useful to ask people to frame what they’re actually committing to and say, “Okay, so you will do what by when?” And then you get to see how people react. Sometimes people will not be able to promise anything because they don’t know, and then you’ll figure out that there is a problem with the commitment. For example, if I asked you to, let’s say, get a budget for a specific build machines. You might say, “Okay, fine, I’ll do it,” or “I’ll give it a try”. I said, “Okay, so what will you do? By when?” And that forces you into a very specific state of mind, which is, what is the physical thing that you can measure that I will do? I will get the budget for this by the end of the week doesn’t make any sense because you can’t commit to it. And even if you told me that, I can say, “Well, you can’t commit to it, right?” It’s like saying, I’ll fix the bug in the next three hours. You don’t know how long it’s going to take to fix the bug. So you can’t commit to things that you don’t control, but you can commit to an action that you do control. For example, I will set up a meeting with the stakeholders. I’ll send the invite by the end of today. That’s the first step. That’s an example of committing to something you control.

That’s also the reason why I don’t like where teams have commitments at the end of sprint. I don’t like Scrum in that regard because the team cannot commit to finish their entire features. They can commit to working their hardest. They can commit to working specific amount of hours a day. They cannot commit to finishing it. Because, in reality, there is a lot of stuff that happens before you can finish something, which is not under their control. Customer might change their mind. Product might not write things in a clear way. Or they’ll work on something and realize it’s actually much more difficult. And then what happens is that if you commit to something not under your control and then you fail, you feel like a failure even though it’s not your fault. And I was part of something like that. I was part of a team that was doing test driven development, and consistently, we would fail our commitments. We felt like idiots every sprint. We did amazing work, but we felt like failures. So you get this huge moral problem as well. So I don’t like to even call it commitments. There are goals. But goals can be set and might not always be achieved. But can we commit to working at least X hours a day on this stuff? That’s an example of a commitment or something that’s under full your control.

So in learning mode, there’s a lot of that stuff going on, which is facing what we’re actually doing, trying to change that. How are we actually changing it? Challenging people to change how they work, etc, etc, etc. So there’s a lot of coaching happening. A lot of coaching. And a lot of leaders are not good at coaching, or they’re afraid of doing it. Especially if they’re coaching their friends. Then it becomes really difficult.

Henry Suryawirawan: So I really love this commitment language. Sometimes when we ask people to do some stuff, especially the things that they don’t know how to do, sometimes they’ll just give abstract, “Okay, I’ll do it. I’ll promise to finish it”. But I think the moment when you said you need to ask a person to do something by something. And also to focus not on the lagging indicators, right? So when you mention about finishing something by end of the sprint, for example. Sometimes that’s the lagging indicators. So something that we cannot control because of various factors. But maybe if we can focus on the leading indicators, maybe like working certain amount of hours on that particular problem, maybe that will lead us to a better result. So I think that’s a really insightful idea. So for team leaders out there, if you want to coach or grow your people, try to use this commitment language so that people bring up accountability in one aspect. And so make sure that they can actually think more before they promise something. So I think that’s always a key idea here. Thanks for sharing that, actually.

[00:45:47] Line Manager Manifesto

Henry Suryawirawan: So, you mentioned about team of team leads. So for people who are manager of managers, any kind of different things that they should think about? I know that you have a line manager manifesto. Maybe you can share few tips for this manager of managers.

Roy Osherove: I think at some point, it’s really more about bottlenecks. My job is always to remove myself as a bottleneck. So as a leader of developers, maybe I’m the bottleneck for some decision making. But if I’m a leader of team leads, then what is my role? How do I measure? The answer, again, to me is, what is the thing that they need me for? Do they need me for specific planning purposes cause I see something farther into the future? Do they need me for specific experience that I have? Again, I teach them how to work as if I was there, but I’m not. How would they do it if they were me? That’s the idea.

In developers, I’ll teach a developer how to become a team lead. If I’m leading leads, then I’ll teach the leads how to lead leads. I always go one level up. So, if I’m an architect, I’ll teach developers to think like an architect. If I’m a chief architect in charge of multiple architects, I’ll teach my architects how to think like a chief architect, and how to connect all the dots across the company. So whatever level you are, you teach people how to be whatever it is that you are. That’s how I think about it very, very simply.

The reason you are there is because there’re some things that you’re supposed to be doing, and sometimes, by definition, you’re supposed to be a bottleneck. It’s by definition because that’s the company policy, but doesn’t mean it has to be. So, by definition, I have to be the one making a hiring decision, right? What happens if I’m not there? No one can hire? Doesn’t make any sense. Should be able to hire people. Now maybe we come up with a protocol on how to hire, so we have certainty or at least some numbers, etc. But whatever it is, the same risk applies if I’m not available. So that’s what I want to work on. That’s my bottleneck theory. I want to remove myself as bottleneck.

Henry Suryawirawan: I just want to put a plug as well for your line manager manifesto. “The goal is the overall long term growth in skills of self-organization and self-sufficiency in every employee under your management.” So like the things that you mentioned, right? Removing yourself as bottleneck. I think the goal here is to have a self-organizing team and self-sufficient individuals. They should be able to solve problems by themselves. So thanks for sharing this plug. I really like all this elastic leadership concept.

[00:48:13] 3 Tech Lead Wisdom

Henry Suryawirawan: So as we reach the end of our conversation, I have one last question for you, which I normally ask all my guests, which is to share about three technical leadership wisdom. So think of it like advice or tips that you want to give to maybe aspiring team leaders out there. What would be your three technical leadership wisdom, Roy?

Roy Osherove: So assuming that you’re able to, and assuming that it’s not going to ruin your life, take chances. Some people cannot take a chance. But take chances and try to do things that are out of your comfort zone. Try to do more difficult conversations.

Second, learn as much about people as you can. Read as much as you can about people. Read everything by Jerry Weinberg and Johanna Rothman, the great authors and mentors.

Three, I think you should always have a story in your head what you’re trying to achieve. So if you’re doing something and somebody asks you why you’re doing that something, why did you choose that metric? Why do we want to change the structure of this team? Why you bring this person? There should be an overall arching story. That might change every few months, but you should always have an initiative or something that you’re pushing for. And they all connect to something that you always believe in, which means that no matter what somebody asks you, it always eventually connects to something that you care about. Eventually, maybe in 10 years.

So, for example, if you ask me about any of the books that I write or the consulting that I do or whatever, they are all connected to the same underlying set of principles that I care about. They’re all connected. Like the pipeline-driven stuff is about continuous delivery, and it connects to the unit testing stuff, and elastic leadership is connected because changing an organization and transformation requires these leadership skills. They’re all connected. So you should find the theory of everything that makes you tick. If you’re an organization and you’re just doing something for the sake of doing it, then you’re probably not going to succeed. There has to be a bigger reason and you have to find that reason, and then you will always have a good answer when somebody asks you why do you want to do it? And maybe at the beginning the answer is, it doesn’t feel right. Your job is to find how to explain it with a number or with a cost or something. “This isn’t right and I want to change this stuff”. Or it could be, “I believe that this makes me a better leader by growing people. And so that’s what I do”. That’s my mantra. That’s how I grow people. That’s how I work. Just like if I’m a developer. This is how I write code. I document it. I make sure it’s easy for people to read. Like every decision I make is related to that stuff, eventually.

So I would say always have a reason, or an eventual reason, for anything that you’re doing, which is pushing some buttons. I’m talking about tactical and strategic decisions that you’re making in the company, or that you’re pushing for, or you’re going to convince people to do. There should be a bigger reason why you’re doing it, other than this code sucks. That’s a very small point. How about the other code? Are you changing this, but in an effort to make something bigger out of it? Are you changing this because then it enables something else bigger? Or maybe this is part of a set of actions that you’re taking, which is part of a bigger strategy. Whatever it is, there should be something like a 1, 2, 3, 4 year horizon that you’re pushing for, and it’s okay and it takes time. It’s a marathon. But if you have that, there’s always the next task, etc. It doesn’t feel like you’re just repeating yourself. And I think then it’s easier if you have like this thing that you’re pushing for.

Henry Suryawirawan: Wow, I really love the last one. So always have a story of what you want to achieve, and the best will be to connect to what you believe, right? Maybe the values or maybe the kind of aspirations that you want to do, right?

Roy Osherove: It has to be, or you will not be able to stick to it. You will stop. It has to be something you really care about, then you want to see it happen. It cannot be somebody else’s story. It has to be yours, and maybe it’s connected. Maybe you believe what that person said, but it’s your story. It’s the reason you get up in the morning in that company, eventually. I know you get up so you can feed the family and all that stuff. But as you’re doing that stuff, is there any kind of change? I think it’s okay to also say I don’t have a story. I’m not trying to change anything. I’m a nine-to-five person. That’s fine. But most leaders are tasked with situations that force them to make tough decisions. And when those tough decisions happen, they have to have a reason why they chose this specific thing. So even if your story is, I want to make sure that employees have a specific way of thinking about something, or I want to make sure that no matter what, people have work life balance. That’s fine too.

Just have a reason. Explain yourself why, and that way you will never be speechless when you’re stuck in a meeting. And manager says, “Why do you spend a hundred thousand dollars on three months, and I’m not seeing anything for it?” It could be a problem that they’re not seeing. Maybe you’re seeing. Maybe you have to learn how to show them what they’re supposed to see. But if you can see it and you just can’t explain it, it’s much better than if you did it and you don’t even know why you did it. So that’s kind of the idea. And I think that works also as a consultant and also as an entrepreneur.

Henry Suryawirawan: Yeah. I think sometimes we do stuff without actually understanding the underlying reasons or maybe the bigger picture. So we just for the sake of doing the task, yeah, we just do it. Thanks for reminding us. I think it applies not just at work as well, maybe to your personal life. Thinking about what is the bigger story about your personal life, maybe any aspirations or goals. I really like the concept. Also, ties it back to your beliefs and values. So thanks for putting this as a wisdom for us.

So for people who love this conversation and want to connect with you online, is there a place where they can reach out or maybe talk to you?

Roy Osherove: Yeah. I’m on Twitter, Roy Osherove on Twitter or at Osherove.com, or at ArtOfUnitTesting.com or at 5whys.com. That’s the blog that started the elastic leadership. So the number five, and then whys.com. So there are a lot of ways to just find me. I have a lot of YouTube talks about that stuff as well from different conferences. I’m going to be in Copenhagen this month, actually, during the Elastic Leadership training. So people are always welcome to get in contact with me and I’m always happy to hear about new situations. I promise I will probably learn from them just as much as you will learn from my own experience.

Henry Suryawirawan: Yeah. Unfortunately, we couldn’t cover the pipeline-driven organization, but one day I think we will reach the time when you publish the book and I’ll arrange another episode for that. So looking forward for that one.

Thanks, Roy, for your time today. Really love the conversation.

Roy Osherove: Thank you, Henry. It was a pleasure.

– End –