Mental will be is a silent pandemic. According to the who depression and anxiety caused the global economy over one trillion US dollars every year, it's time to make a difference. Learn how to enhance your life's true. A master class from Founders well-being, and my good friend Sunday brow on mental Wellness, visit Founders well-being.com / Master Class to enroll and enter tlj 24. A 20% discount be a better version of yourself and make an impact.
The ISA QB software architecture Gathering is the International Conference highlight for all those working on solution structures in IT, projects primarily software Architects developers and Professionals in quality assurance but also system analysts who want to communicate better with their developers. A selection of well-known International speakers will share their practical knowledge on the most important topics in the state of the art software
architecture. The conference takes place online, from November, 14 to 17. And we have a 15% discount code for you. Enter tlj underscore MP underscore 15 for 15 percent discount, 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 if they can solve more problems without me this week than they did last week that I'm doing a better job.
You will actually become um, 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, hey everyone, my name is Henry Surya with Robin.
And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello again, to all of you, my
friends. Welcome to the Tecla 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 tackle a 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 technology.
Know that death / Patron, my guest for today's episode is Roy or Sheriff. 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 describe what elastic leadership is. He explained, the different leadership styles based on the three team faces, which are the survival mode, learning mode, and self-organizing mode, an As 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 to add 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 themes face. 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 the conversation, let's hear some words from our sponsors definitey is the top International software development conference, with an emphasis on coding architecture and Tech leadership skills.
The lineup for this year is truly stellar and features many Legends in Saw. Development names such as Robert Uncle Bob. Martin can back Scott Hanselman, Franca subramanyam Carolyn honey Alan. Hello, Mary poppendieck and many other prominent names including some of those who have also appeared in this podcast before the conference takes place online. So you can enjoy it from the comfort of your couch. We spoke to the definite, the organizers and I'm happy to
share that technology. You know, has got the 10% discount code for you, enter the promo code. Code, awsm underscore tlj. When you purchase the ticket on definite e.com, here's the promo code. One more time awsm underscore, tlj. Depending on the time when you purchase a ticket early price is still available. See you there. Today's episode is proudly sponsored by skills matter. The global community and events platform with more than 100,000 software professionals here members.
Can organize their Experiences around the technology topics. They care about most you get on-demand access to their latest content thought, leadership insights, as well as the exciting schedule of tech events running across all time zones. So whether devops our data science is your bus or you are fan of functional programming or all things Cloud, you can make real connections with people who share your interests head on over to skills method or Cam to become part of the tech
community that matters. Most to you. It's free to join and you will find it easy to keep up with the latest tech Trends. Hello, welcome back to another new episode of the tekhelet journal podcast. Today, we have a guest name for oil or Sheriff, 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 the 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 right when I read your book elastic leadership, I think it was one of the insightful book that I read especially teaching about leadership stops. So hopefully, we can discuss a lot about that book today and yeah, looking forward for this conversation.
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. They're 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 with to share with the audience
here. Well, I've been in the software business over 20 years, so they've 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 Entrepreneur these days as well and also working in different countries. I'm 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 any turning points there. So, if I try to talk about the 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. It 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 meet-up, but before meetups existed before the meetup.com existed and that was 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 ask 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 meet up. Then he was called the user group and I help be part of like a dotnet beat up.
Then later, I created the agile, Israel user group and I found my first customers in those. Meetups in those, these are groups once I had the first customer, which was a big customer for me alone. I started down that path. So I had to 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. They'll go out and I'll start spreading across multiple organizations, and come back in. So, to Turning Point was realizing, I can do this training.
Stuff enjoying it. The other turning point, 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 speak and conferences about those books and then Consulting about those books and then moving on to 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. 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'd stayed with test-driven development in unit testing it some point it would run out
basically. I mean there's always working 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 deaf. Lately I have a lot of different facets that I can talk about in consult about and all these things are related to things that I really, really care
about. So to me, they're like a Marvel, I'm see you, each facet is a specific skill that I wish developers had and then I learned that than that, I bring that, and then I work in it. Etcetera. Etcetera. Thanks so much for sharing your journey. I think it's a really admirable
right? The way you kind of like change facets, Mike from being as an employee to be a consultant and you switch moat Ben 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. 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, Genin it was really insightful especially if you're working in a may be non performing teams or in a start-up 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? The book elastic leadership is based on a blog post on a Blog that I started writing. When I start becoming a team lead as I was growing as a team lead, I would document my own realizations about things and it 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 Kevin any, 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 lead, 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 though, 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 is a team lead, there's been a lot of that stuff trying to come up with different ideas. I'll give it a simple example. My first team I was Very much a command-and-control either. 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 all that stuff.
And I believe that if you're not going to control, what the team is, who the team talks to them, everyone will control the team instead of you and that seemed to have worked for a while. And then I spoke about it at a conference. 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, approach me 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. What don't you believe in that stuff?
And I said, well actually I do I think that's really good ideas and he said well how can you believe that then also believe in what you just taught which is if you 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 that? List 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 are too busy, fighting fires. They don't have time to make mistakes and that situation command 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 And 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 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 that he might be in survival mode, the next week to the two might be in learning mode and the week after the team might be in self-organizing old 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 Ample, if I have a team of developers that have been building websites hundred websites, the past year, and I'm asking him 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 a 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 that team would immediately be in what we call survival mode because they're probably overcommitted. 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. I'll 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 It's time to learn is actively engaging and learning. While 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 will 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're slowly practice
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 is. So let's just give them an extra 20% of time but truly what we should be looking at is five or ten times more time to actually do and make mistakes and learn things the hard way, or at least a month or two.
So learning, what 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 building. So with the Six. 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 we 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 In people, it is not scrum, it is not agile, it's 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. 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 video 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 late, especially the new ones who just got promoted from being a good. I see, they just got promoted as a team. They don't understand this kind of nuances in your book.
We 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? So the manifesto is basically. It's a compass. My realization for myself is that as a team lead, 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 the 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 World View, and that world view 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 that I'm doing. I'm 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 by me, 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 consultant with or that Has the experience to give an opinion what to do something and people will not move forward. Without you, you're essentially
bottleneck. Another way to say it is that you are a bus factor. I love. 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. Now, bus factor of 1 means you have oldest 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 to 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 working consent psychology a little bit because part of our job is working with people guides and 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 1 style, one size fits all, which means that we look at the current faces 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 yourselves about the mic 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 being 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 Trying to learn things that you've never done before, which feels really ring sometimes frustrating or annoying. So do all these things together. They form dist moral compass every day. Am I a bottleneck more or less? A my 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. So when I read this Manifesto definitely strikes me because as a team lead, sometimes we tend to focus more on like project staff. Yes. 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 faces and also you mentioned that the job of a teenage to grow the people and to be able to remove themselves from the bus factor or the bottle that 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's a leader. They are like the crucial person inside. He may be to make decisions or maybe to advise people at 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. 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 team.
We all aspire to have someone who can come and save us. Maybe consultant, maybe from books, for whoever thought leaders tell us more about this phrase. Because when I read it is really Testing, they are not expressed as only as my friend, Jeremy, the Miller at order that one of the conference's, the old at that 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 extras.
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 there, probably. Sing 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 our leader that day will come and hopefully it's 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 will be in a room with other leaders in other managers and you'll talk to them about those things that you're experiencing what you're learning etcetera.
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 a 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, 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 rolled in you, they might even have less experience than you about that specific thing or problem or situation itself. Up. 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've 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 last week leadership. Mmm. Who the hell am I to create this state 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 talked about it and I explained 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 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 at least speak at a conference, and then suddenly, you get, sometimes, slaps in the face. Like that doesn't 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 I talked, 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 there speaking and they're in the process of figuring it out. And if the you talk to them maybe in three months, they're talking 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 Some things that I don't like anymore. Something that I changed in the second edition and they're not like small stuff. Anyway, something state which is
good, but some things did not. So I think that's a very apt advice for a lot of team leaders because sometimes when they are 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. Even yourself. Maybe you do research gather opinions, from field other
people, right? But at the end of the day, there's only asked, there will be no experts so to speak to come and help and solve the problems for you. Right. I would even say you don't even have to believe in yourself. I would say, the only thing you should believe is it 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 do you start making it? Actually, they're a bit scary. The better. You will become the more experience, you will become and you will learn. Let's say, for example, you have to do a serious one-on-one conversation with the person in your team. It's really scary and there's 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 it? The end of that conversation and you might find. Hey, that was easier than I thought or I thought it would go this way. Need to completely went to different way. Or I saw that, I will not be able to say something. And I did say something, I saw the person will say x and they said why?
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 the fuse things less wrong because you already made the mistake. It's like touching a 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 of the weeds, the first dent in the car, but there's a hundred of them. I really love this advice. So thanks again for giving this plot 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 speaker's, the author's, maybe the gas in the podcast, and things like that, right?
But, Actually it's not true. Sometimes we 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. So maybe if we can go back a little bit to the tree team faces, 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. Probably in the bind of a lot of people so the way that you create learning time. So if you're in the situation where everyone is running around like headless chickens and you just victim fires. How do you move from that into learning? What the answer is. First of all, is that the mode of the leadership changes to
more thematic control? Because the sentencing 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 do current commitments, see whichever ones are prioritized and will fit in that month. Then everything that doesn't fit you. Re-estimate you go to your head attachment and in your leadership and you say we are
currently in a death spiral. If we keep going down that route, we're gonna 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. Mate 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, he'll 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 if they're just afraid. One of the things that I highly recommend, there's a book by jury 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. 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's might be scary for a lot of people. That's exactly. 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 because 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, nobody's going to save 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 it, by doing the scary thing, you will become a better leader because you have to be able to be in a place where 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 Sarah 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, Explain, they'll see that, you
know what you're talking about. Otherwise you will be theoretical and people will see it. So it's good for you as a leader, to do the difficult stuff, because you want to ask your people to do difficult things. For example, back-end people to work on, front-end 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
blah. There are a lot of different ways so you have to be the example, you have to go and do those things. Things and then you will 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 because 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. Well some of them won't some of them will appreciate the fact that someone is following me telling them the truth because you're 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. In your 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 is great, which is absolutely wrong. So the hammer will come, but you're just pushing it further away. Yeah, thanks for reminding. All these leaders who are
probably in the survival mode. So, unique 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? Yeah, but not just survives 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 2 in the morning fixing the red-billed and doing all that stuff. The idea is that you were taking charge for a month. There is an end, there's an expiration date. And that is the scary part. The expiration date is when you actually moving to re estimation and learning what 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 you, 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, because I'm taking care of the things from three months ago. So, Oh 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 a 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 this thing, but you prioritize and you remove commitments and then you switch into The learning mode, the removing some of the commitments that to keep our tree estimating. That's the key part. The command control is absolutely necessary, but a lot of people already do it. If you're not doing it, command 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-day tdd course and then expecting them to actually implement it, it's not going to work because we're going to go and get right back to work. They're not going to have time to implement it. Don't expect anything to change. JH 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. 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 mention about select time, right? So the team in survival mode, basically doesn't have select time. He'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 most like time for the team. So tell us more White's like button is very important why we should be in learning mode. White team should have select time. 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 into rival mode, we get into the car. There's a lion chasing us. I'll tie your shoelaces. Yes. 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. And you mentioned field techniques that lead us can do is buy, for example, doing more delegation. So, depending like what you said, if the kids can start buying their own show, you give the time for them to learn how to do the stuff.
You also give some kind of like, Work 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? And then the Ultimate Team face is actually self-organizing mode. So probably not many team leaders are in this mode I believe because from my experience is really kind of like hard to have a fully self organized team, so maybe we can
share a little bit more. How does self organized team look like actually, what kind of differentiation that you can see from a Seeing team well of self-organizing teams I would say maybe 5% of the team's I've ever seen or self-organizing. The idea in a self organizing team is the team knows how to solve any problem that they face. So I think of them like a team of team leads, what is the 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 because whatever you throw at them. Don't figure it out. That's the idea if your team cannot Figure out some of the stuff then they're not. So for conniving, a 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 mention in the book, The Influence horses are powerful thing for both learning mode and For self-organizing mode. And those are personal influence forces, there's community. And then there is environmental, we're talking about self-organizing teams. It's usually the last to.
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 your measured on purpose. Coming or your measured on bugs found in production. So there's a lot of things that we can do without telling people
how to do something. 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 is he said is commitment language. For example where you change the way that you ask questions or speak?
Seek 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 is an exit Point. There's a door, almost a. Well I did say let's try and didn't say we're actually going to do it if you don't give a specific end date or time.
Then again, yeah, 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. It or I'll give it a try and 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 if you knew, 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. Temple. 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 Sprints. 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 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 the clear way or they'll work on something. A realize it's actually much more difficult. And then what happens is, 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 sail our commitments who 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. The commitments, there are goals, but goals can be set, and might not always 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 year of control. So, in learning mode, there's a lot of that stuff going on which is facing what they're actually doing trying to change that how we're 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. So I really left this commitment language sometimes when we ask people to do some stops, 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 set you need to ask person to do something by something and also to focus not on the lagging indicators, right? So when you About finishing something by end of the Sprint for example, sometimes that's
the lagging indicators. So something with that, we cannot control because for various factors, but maybe if we can focus on the leading, indicators may be like, working certain amount of hours on that particular problem, maybe that will get us to a better results. So I think that's a really insightful ideas for 4th, team leaders out there. If you want to coach your 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 really think more before they promised something. So I think that's always a key ideas here. Thanks for sharing that actually, so you mentioned about teams 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 can share a few tips for this manager of managers.
I think it's 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 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 meat for specific planning purposes? Because 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 someone architect I'll teach developer to think like an
architect. If I'm a Chief Architect in charge of multiple Architects, all teach my Architects at the 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 very, or simply, the reason you were there is because there are some things that You're supposed to be doing and sometimes by definition.
You're supposed to be a bottleneck 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 the protocol on how to hire is, so we have certainty or at least some numbers Etc, but whatever it is the same risk. Apply.
Sighs if I'm not available. So that's what I want to work on. That's my bottleneck Theory. I want to remove myself was bottleneck. I just want to put a plug as well as, for your line manager, manifest or the goal is the overall long-term growth in skills of self-organization, and self-sufficiency in every employees under your management. So, like the things that we mentioned, right? Removing yourself as bottleneck, I think the goal here is to help her self-organizing demon
self-sufficient, individuals. They should be able to solve problems by themselves. So, thanks for sharing this Vlog. I really like, All this elastic leadership concept. 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. So assuming that you're able to and swimming 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 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 asked, 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 are you bringing this? And 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 consultant that I do or whatever, they are all connected to the same, underlying set of principles. Balls that I care about, they're
all connected. Like the pipeline driven stuffed about continuous delivery and it connect 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 just doing something for the sake of doing it, then you 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 Good answer, when somebody asks you why 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 the 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 documented and make sure it's easy for people to read. Like every decision I make is real. Led 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 with your part of a bigger strategy, whatever it is. There should be something like a one, two, three, four year Horizon that you 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 etcetera. 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 while I really left the last one, so always have a story of what you want to achieve and And the best will be to connect to what you believe, like maybe the values, or maybe the kind of aspirations that you want to do, right? As 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 your 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 It's okay to also say I don't have a story I'm not trying to change anything. I mean 95% that's fine. But most leaders are tasks with situations that forced 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, what something or want to make sure that no matter what people have work-life balance, that's fine to just have a reason. Plane 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 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 what you did it. So that's kind of the idea and I think that works also as a consultant and also isn't it. Up north. 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, shall 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 may be any aspirations for 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? A out or maybe talk to you. Yeah, I'm on Twitter. Royal shrove on Twitter or I do assure of.com, or a tort of unit testing.com or it five wise.com. That's the block to start the elastic leadership. So the number 5 and then wh-why s.com. So there are a lot of ways to adjust find me. I have a lot of YouTube talks about that stuff is well from different conferences. I'll never be in Copenhagen this month actually. During the classic 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 learn from my own experience. 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 what we call it for that one, thanks for your time today. Really love conversation.
Thank you, Henry, it was a pleasure. Thank you for listening to this episode and for staying, right until the end, if you're highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow these podcasts better.
You can also find the full show notes of this conversation on the episode page at Tecla Journal. .F website, including the full transcript interesting. It's and links to the resources mention from the conversation. And lastly, make sure to subscribe to the shows mailing list on pack leader dot f to get notified for any future episodes. Stay tuned for the next technology. No episode. And until then goodbye.