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.
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.