And I think that's a lot of where the agile and devops side
of things. They tend to miss in the lot of
the implementations people focus on the tools, they focus on the
processes. But what was most important was
that you actually understood what were the actual Target
outcomes that your customers trying to get to.
And then being able to establish the right level of shared
situational awareness, across the team to be able to allow
everyone to be able to make the right decisions to be able to
safely fail. And to actually be able to Learn
and improve from all of that. Hey everyone.
My name is Henry Surya, we 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 and my listeners after a one-week break.
I am back here again with a new episode of the package.
You know, podcast the podcast where you can learn about
technical leadership and Excellence from my
conversations, with great thought leaders in the tech
industry. If you haven't, please follow
the show on your podcast app and social media on LinkedIn.
Twitter and Instagram. And to appreciate and support my
work. Subscribe as a patron at
technology. No, dot f / Patron.
Or you can also feel me with coffee at technology.
Know that death / tip? My guest for today's episode is
Robert Benefield. Robert is the author of lean
develops. A practical guide to on-demand
Service delivery in this episode.
Robert shared insights on how we can apply the Linda, Rob's
mindset for building successful. It delivery organizations Robert
started by sharing what initiated him writing the book
and how it differs from the other available devops books,
Robert describe the concept of on-demand Service delivery.
And important Concepts such as knowing the target outcomes,
building situational awareness and making effective And Timely
decisions based on the ooda loop.
Robert also shared a few practices and techniques.
He outlined in the book such as Mission command workflow board,
Q monster service, engineering lead value, stream, mapping and
Ironhide. This is such a great refresher
of the lean mindset combined with the devops culture and
practices and I hope you enjoy listening to this episode and
learning a lot from it. And if you do, it would really
be awesome. If you can also share this
episode with your colleagues, your friends and your
communities, and also, don't forget to leave a five star
rating and review on a podcast and Spotify.
It may sound simple but it will help me a lot in getting more
people. Discover the podcast on the
platforms. Let's go to the conversation
with Robert after hearing a few words from our sponsors.
Hey a quick message, for those of you who are listening to this
episode on Spotify, I have a small favor to ask Spotify now
Allows mobile users to rate podcasts, I would really
appreciate it. If you can take a quick pass to
go to the technology on our podcast page and leave your
favorite show, your best rating on Spotify.
It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot, everyone.
Welcome back to another new episode of the technology on our
podcast today. I have with me, a guest named
Robert Benefield. He is the author of a book,
titled, lean devops. So if you think this This is
just another devops book, I think when you find the book and
reread it I think it's really offer something different from
the other devops books that I have read in the past.
So Robert today, I'm really looking forward to discuss about
topics from the books and maybe learn something new from the
angle of perspective of devops compared to the other books.
So welcome to the show. Thank you, Robert.
I always love to ask my guess to introduce themselves by telling
their Caribbean, especially the highlights or turning points
that you feel are useful for This to learn from okay.
Yeah my career journey is actually played a really
important role in the way that I think which ultimately is a lot
of what the book is about. So while I've always been
interested in technology, I started out playing with piles
of components and soldering irons and all that sort of
thing. Really.
My true interest of all been around understanding the
Dynamics of systems. So I always wanted to know how
things work. But most importantly, what I
wanted to know was actually how things Is break.
And what causes them to break. This goes with not just
Technical Systems, but also biological and social systems.
There is always factors that are unknown or poorly understood
that caused the unexpected to happen.
I mean, if you think about it, like, you know, we live in a
crazy day with crazy politics and all kinds of things and
there's all sorts of weird things that happen and it's hard
to actually understand that let alone to be able to go through
and reverse it. And so learning how to see what
Can and then figuring out how to effectively manage the
repercussions of that helps. You actually improve your
chances of success. So my career, I studied
aerospace engineering and international relations.
Both our disciplines that require working in a system of
complex systems. And so I realized quite early on
that focusing on just a fragment in isolation, was a sure file
path for failure. So I've been really fortunate in
my career. Sometimes I feel Like I was
like, Forrest Gump and how lucky I've been.
So a lot of it was solving problems that no one had
actually ever done before and me being too domed actually
realized that no one had done them before half the time and
also having fortuitous circumstances.
So like for instance, I learned a lot of concepts of lean back
in the 1980s because I happen to actually run into some
industrial Engineers from master sheeta.
And so I was interested in engineering and they showed me
industrial engineering and lean and So I took lean as actually
being industrial engineering and I took a lot of the learning
start. Similarly later on, I ended up
working for the u.s. government and I met some of the fighter
Mafia of Boyd's fighter Mafia people and the concepts around
Buddha and decision-making. And again I thought that was
normal and I thought oh this is how you actually go through and
make effective decisions. And from there, I actually
learned the importance of actually having a shared
understanding of what's going on and the importance of Of
understanding the desired outcomes in the means for
maintaining enough situational awareness to make effective
decisions. I saw it with my own eyes that
any weaknesses could lead to bad decisions and failure, even when
you had the best technology money could buy at your
fingertips. So, again, at the government, I
was lucky that I was one of the teams that it was originally
tasked on putting the government online built, the first news
site, ever, in the first digital audio sight ever on the
internet, This was before web browsers.
This was before the NCSA web server was out there, we did it
with FTP and gopher. So that's how long ago it was.
I then went to a company that was building electronic trading
and Crossing systems for investment Banks.
And again it was a brand new world, very few people that
actually been going through and working on this thing and we
were fortunate enough that we got bought by Jeffries because
it was a start-up. And one of the things that was
important there was you needed to First and the business, we
work closely with the Traders. We were technical, we were
helping build the trading strategies and we really needed
to be in tune with what were the desired outcomes that people
were trying to go through and Achieve.
Then I went to Silicon Valley, the beginning the.com boom and
managed to go through and helped a bunch of startups.
Get off the ground ones, that many of us have heard of did
Road shows, and also crash some and learned from that back.
Then, in the valley, it was a really small world.
Everyone knew everyone and I got in arguments with Marc
Andreessen about things. I helped our Gobi off.
It was one of the early people at Google with helping getting
Google off the ground. So it was a really interesting
world to be able to go through and try things out.
And since then I learned all these interesting techniques, I
learned what it takes to build effective and scalable and
ultimately successful, delivery organizations how to build
highly productive teams and to figure out, What was that actual
trade off? And I realized that it wasn't
just the really the technology and tools or even the quality of
the engineers. I mean sure that's important
kind of like having enough cash on hand to be able to go through
and do things. But what was most important was
that you actually understood what were the actual Target
outcomes that your customers, the people actually use your
stuff or trying to get to. And then being able to establish
the right level of shared situational awareness, across
the team to be able to allow everyone to be able to Make the
right decisions to be able to safely fail and to actually be
able to learn and improve from all of that.
And I think that's a lot of where the agile and devops side
of things. They tend to miss in the lot of
the implementations people focus on the tools, they focus on the
processes and well, they can be effective for reducing some of
the noise. The problem is that they miss
the point of what is they are actually trying to do, what is
it? You're trying to actually solve.
How can you go through and improve the quality?
And the timeliness of the decisions that you're trying to
make. And so I figured all that stuff
out and then I thought okay let me go try some things out so I
went to a start-up and we were working on the collaborative
software development environments for both large
companies, as well as open source.
So we helped HP Imaging of training isn't one example,
rebalance all of the features that they had an older printer
lines and they managed to reduce their delivery lifecycle from 36
months to get a new feature out. Down to about two or three
months, you know, big thing, really big thing.
And then from it, when I was there, I started to really build
a lot of the devops Centric model that I actually talked
about my book. So how'd it go through and
actually work closely with the customers, how to go through and
combine the operational side of things.
With the engineering side of things, we were a truly software
as a service, as was back when I was working at the Investment
Bank that we provided all of our stuff.
As a A software as a service, which in the mid-90s was
completely strange. Nobody had actually thought of
that. So then I thought, okay, well,
I've done this. Now, let's go and try to do this
at scale. So a bunch of the people at the
company. We went to different places, a
lot went to Google, someone to Facebook, I ended up going to
Yahoo and at Yahoo that was a really amazing experience.
I was given a complete free hand to do and show what was possible
there. They had just signed service
level agreements with AT&T. And with Rogers and with DT and
they were trying to figure out, how do we do that?
How do we go through and actually build things at scale
with high availability? High reliability.
So, one of the things that I worked with people on was
pioneering, we called it service engineering, which looked very
similar to what a sari looks like at Google and production
engineering books like at Facebook, we built automated,
see ICD pipelines, we call them code, Pipes.
This was before again there was such a thing we created
rudimentary container system before that stuff existed we
also created what I consider to be a real Masterpiece of how to
go through and actually manage all of the software and
configurations and services all throughout the whole ecosystem
and how to do that at scale and how to affordably understand
what was actually going on. And then most importantly how to
go through an instrument up all of the We're in services and
everything like that. To really figure out what the
customers experiences were and figure out most importantly,
what matters. So with all of that, we started
doing a lot of really amazing things out of that we came up
with zookeeper, we were working on a lot of the Big Data side of
things. We brought in the people who
create it to dupe and built a whole big data side of things
around it. And again, all this was really
early days and people go, yeah, it might go.
Yeah, yeah. But you know, again, we're
talking Talking about like 2006, 2007, 2008 timeframe.
So eventually the politics at Yahoo, got to be a little much.
So I decided with my family, we decided to move to Europe and
Europe was where I realized that all of the concepts and habits
that I picked up before, early in my life, they weren't normal.
They weren't the things that normal people do.
And so I spent the next few years carefully examining and
trying to figure out how is it that I actually Solve problems.
How is it that I build effective teams and are there things that
I can actually go through and help teach others?
Are there things that I can help to actually help others be able
to be successful. And so I ended up working at a
bunch of big companies. I worked at British Telecom, I
worked at a Energy company called rwe and they're all over
the world but they're primarily in Germany.
This was also at the time where the Germans had come up with
energy Venda which is we're going to shut down all The
nuclear power plants. Oh my God, how are we going to
power everything? So that was an interesting
challenge. I was at Skype and a bunch of
other places as well and the output of a lot of that.
Actually, ultimately came and built the book.
So that's a bit of my journey. Wow, sitting here and listening
you telling the story, right? I'm very amazed with what you
have done. You seem to be at the edge, the
first pioneers of so many great technology.
So many great practices and I can tell, as well, you summarize
some parts of Books. I'm Des of the books throughout
your introduction as well, write things like Target, desired
outcome situational awareness, and things like that, which is
the interesting thing that I pick when I read this book is
that I find it a bit different than some other develops books
that I have read. For example, I've read devops
handbook. Accelerate Phoenix project or
those sounds very different definitely, but can you tell us?
Maybe what would be the Silver Lining?
When you write the book, write, what is something that you want
to offer different from the other devops books out there or
there? Ops practitioners that have been
established throughout the last few years.
So I think that the biggest thing that most people miss and
this is something I've talked with Jean came about, I've
actually had great conversations with people like jazz humble and
Dave Farley about as well. It's not about the tools, tools
will come in tools will go. In fact this was something when
I first wrote the book and I gave it an early draft of people
they went and in fact one of them was Mary poppendieck she's
like why aren't you talking about containers?
Like Containers is an implementation thing, and I can
tell you my career, it will come, it will go, they'll be
something else. And so if I just focus on the
Technologies, I'm missing the point.
The point is, how can you go through and make better
decisions? How is it that you're able to
achieve the actual outcomes? This is something that actually
drives me a bit crazy with a lot of the devops community people
focus so much on outputs, they focus on up time, but they don't
actually Really think about what is it that the customers are
trying to do and what's important and I give a story I
was working for the company that did a lot of Commodities
trading. And when I came in, they said
well we're trying to produce all of our systems and our services.
We want to have five nines up time.
I went oh that's interesting. So tell me more.
Why is it in 5/9 up time and they went?
Well, our service is really important and we can't afford to
be down. If we were down at, then our
Traders can't trade and I said, Okay, so are your Traders
trading in the middle of the night and they went no and so
they trade in on the weekends? No no no.
So when is it that they're trading and find out that when
they're trading and they did have a bit of an extended day
but they're extended day was like 9 a.m. to like 7:00 p.m.
and I went okay so 9:00 a.m. to 7 p.m. you need to be up 100% of
the time. The rest of the time.
The whole thing could be down and the way.
Yep, so it's not about five nines up time.
It's About understanding what it is that you're trying to do,
this is something I learned when I was at the investment trading,
we're building the trading systems for us.
The crosses were the most important.
It was 9 minutes that we had to have 100% uptime.
The rest of the time, it was 9 minutes since, like six Windows
during the day, the rest of the time, the whole thing could be
down, but those times everything needed to be up in need to be
performance. It needed to respond, exactly
how it was that I wanted. And I think that's something
that people Miss, they miss, what is it?
If people are trying, Do what is it that they need to try to
solve my experience of watching video is going to be very
different than if I'm actually grabbing a regular text website.
If I lose frames the world comes to an end when I'm actually
watching a video, if I get a re transmitted on the something
that's text, I'm not even gonna notice and you need to be able
to actually understand that understand those things and then
build your echo system to be able to go through a managed all
of that stuff. So that's why I'm constantly
going through and saying So what is it?
What is your purpose? How is it that you actually know
what's going on and how you're meeting your purpose?
What is the data that the information the awareness?
Because it's not just what, you know and not just the data that
you have. But what your ability to pull
those things together to be able to go through and make effective
decisions. Do I deploy this way or that
way, do I build it this way or do I do it that way?
Those are things that really come by actually understanding
that true north of what actually Matters, the customer.
That is something that time and time again in the community
people. Miss they miss, what is it that
I'm trying to do. Why am I doing it?
They miss, if I do things in one way, it's going to hide
information. That might be important to me or
it might flood me with so much information that isn't actually
important at. That makes it very difficult for
me to sit through it to be able to make decisions.
And that is the big thing that I see in the community that I
really really, really Want people to learn and improve.
And again it's not that the tools are bad.
Tools are great but understand what the tools are doing.
Understand how it is helping. You understand what it is that
it's simplifying and hiding from you and understand if that is
actually something that doesn't actually matter or ultimately,
it's going to be important to you.
Thank you for giving the context.
Why you wrote this book and why it differs from others.
So, the subtitle of your book, also, I find very interesting,
you mention A practical guide to on-demand Service delivery.
First of all, what are you referring to On Demand Service
delivery? Is it some specific thing about,
you know, I don't like software consulting or is it likes of
engineering team? Or is this something that is
applicable to all engineering team?
No matter what? And if you can also give us some
highlights. What are some of the problems
that it Service delivery are dealing with in this modern
days? Sure.
So the reason I say on demand Service delivery is when I
worked in different types of delivery organizations, I've
worked in ones that build shrink-wrap software, and of
course I've worked in ones that actually have services and why I
talk about on-demand Service delivery is if you're in a
shrink wrap software world or one where you have low
engagement low cycle loti to your customer, Or you can ignore
a lot of things or you can push back on to the customer and
their it organization. A lot of the heavy lifting of
what's going on. But if you're doing on demand
Service delivery, much like your telephone internet connection,
all of that stuff, the quality of the whole end-to-end matters.
You need to make sure that you actually understand who your
customers are and what your customers are doing, and that
part is actually really important.
And that goes back into the IT service delivery team.
There's this interesting thing and I've seen it far more since
I've been outside of the valley and that they're still this
difficulty for a lot of organizations.
And not just the technical organizations, but actually the
non technical managerial organizations to really
understand how integral the IT service, delivery, the
technology and the teams that are building, random technology
are to understanding and working with the business to actually
achieve what is needed. So a lot of people We'll go.
Okay, well, I'll just go through and give them a bunch of
requirements. I don't need to tell them.
Anything Parts is Parts. In fact, some people go even
further and go. You know what anyone can sling
code? So if I just give requirements,
I can Outsource all that stuff and I can Outsource it to some
random other company. That doesn't need to know
anything about my company or my industry or any of that and I'll
get something back and I'll be able to use it and then what
they quickly realize is. Yeah, okay, that works for some
generic things but it when it's actually Something that's core
to your business. It doesn't work.
Things start to fall down things, don't behave.
Exactly how you would expect that they would.
And that is a big, big problem, and that gets back into
something that I talked about quite a bit in the book.
I talk about Mission command. So Mission command is very much
this and this, I got a lot of heat about in the beginning
because there's a lot of the world out there that finds
anything that ever came out of the military to be a bad thing.
Not realizing In that there are a lot of interesting learnings
that come from there that are not militaristic.
Even remotely that are actually incredibly helpful for being
able to help do the right thing. So, Mission command is very much
this mechanism that is about talking about and making sure
that there's a shared understanding of what the actual
objective or ultimately, the target outcomes that you're
trying to achieve art and the entire structure of it is all in
and around. How do you Enable the people
that are down in the ground to make the right decisions in
order to do things. And why is that important?
That's important? Because the people that are down
on the ground of the ones that are going to have the most
context of exactly what's going on and if they don't actually
understand what the underlying intent of what you're trying to
achieve is they're going to do whatever they're going to do.
In fact, this is actually something that you can see in
Ukraine, right now. So, the West spent quite a bit
of time after 2014 teaching the Ukrainian military about
mission, Command. They originally were in the
command and control style military structure.
Much of like what you're seeing in Russia, the Chinese do the
same thing. So the people at the top, tell
the people at the bottom, what to do the people of the bottom,
do what the people, the top do. And they just act as otamatone
its Mission command flips it and says, I'm going to tell you what
it is, that our goal is and I'm going to tell you what the
constraints are of what you can't do.
You can't go into the village and kill everybody.
Or whatever it is man in software, it may be.
Well you have to be really careful that you don't lose data
or some other type of concept like that.
And so what you do is and they call this a briefing, you give
them a briefing. If you don't tell them what to
do, you tell them what the goals are and you tell them what the
ante goals are the, what are the constraints?
And then what you do is you say, okay, go off and tell me what
you think you're going to do and so what happens lower down,
people will then go down and they'll talk amongst themselves
and sometimes if they're like middle management they'll go
down and down and down until you get Give the people at the
bottom and they will go in and they will come up with some
ideas and some plans and they'll come up with something that's
called a back brief. So back brief is, this is how we
think we might do it. And here are some questions that
we have. And here's what we think that we
might need this allows them to have the flexibility, to be able
to have the conversation. So back brief is very much a
conversation, they'll present back the people above will go.
Okay, this isn't quite right and they'll tune in, they'll tune
until they are given the right resources and everything to go
out in the field. It's not done now, the people
are out in the field. That's when, you know, the crud
hits the fan and as they say, no plan lasts into battle.
And so, again, the people understand what the ultimate
objective is, they understand where the antique goals were.
The constraints are and they can then go through and do what is
necessary in order to meet the objective.
And I gave, I think I give an example of this, in the book of
say. For instance, somebody is told
that they need to go out and take a hill in order to be able
able to understand what's going on with the Enemy did then be
able to go in and stop the enemy from being able to advance.
So the outcome is stop the enemy from being able to advance and
the team is going through, and they're going towards the hill.
And they notice that they get behind the Enemy Lines and they
see where they can go through and take out a command and
control center. So they could continue up the
hill, but if they take out the command and control center,
well, that meets the objective even better than taking the
hill, doesn't it? And They're given the freedom to
be able to go through and do that.
And that is something again that I think is really important with
on-demand Service delivery. We hire smart people and we need
to give them an understanding of what the goals are, and give
them what the constraints are that they need to work with and
then allow them to use their brains to be able to go through
and make the right decisions and that's something that time and
time again. I see Technical and
non-technical people like completely missing and and when
they actually see what's possible, when you actually get
people to use their brains they're just like oh I didn't
realize that. And every like this light bulb
goes off in their heads and they're like, oh wow, they're
actually Partners. They actually care about the
business. They don't just care about
playing around with technology and it's like, no actually they
genuinely care. And that's you know, people want
to be proud of what it is that they do and not just the
technical Parts. They want to be proud of what is
it that their contribution ultimately is able to go
through. Achieve.
And so that's something I think, is really, really important.
Thanks for explaining this concept of mission command.
When I read the chapter so I find it quite fascinating,
right? This concept borrowed from
military and that X also explains a lot of why like I
interviewed some product people as well.
They always talk about explain the outcome, not the output try
to get engineering being involved in, making the
decisions how things should get done.
Not just coming from the top and I think you also borrow a lot of
other military concept. One is the the great work by
john-boy's the ooda loop, which is sometimes also quoted in the
agile methodology books, right? Maybe if you can give us also a
glimpse like what is this Outer Loop?
And how do you use it to apply in the Lynn devops concept?
Sure, it'll work is probably also one of the most along with
lean is probably some of the most misunderstood things out
there, who do Loop is all about decision making and how to go
through and make more effective, more timely decisions.
So, a lot of this Came out of Boyd is an interesting
character. See, he wanted to figure out how
you could go through and out to the enemy.
So first he did what all us? Technologists do, he went
clearly having the best technology that's going to get
you there. So he came up with this thing
called Energy maneuverability Theory.
And so this is a Formula that allows you to be able to go
through and determine with any aircraft.
What is the maneuverability of the Aircraft, you can compare
different aircraft in the values of different aircraft, you can
ultimately decide which one is better and which one will
ultimately succeed. So he stole a bunch of Mainframe
computer time and ran all these calculations and everything and
came up with this amazing Theory, that's still used today
in Aerospace. Then what he did was, he
happened to be a fighter pilot during the Korean War and so the
North Koreans were using the make 15s and the US was using
f-86s. So the US had a kill ratio that
was just astronomical just knocking out.
Lots and lots of the enemy planes say went clearly.
This is going to be an example where the f-86 going to be a
better plane. Then the mig-15 then he ran the
numbers, Danny ran them again, many ran them again, every
single time, the mig-15 came up as a better plane.
Hey, what? Huh, that's interesting.
And so we ran it against a bunch of other aircraft.
And found that there actually was no relation between the two
for when it came into combat. So then, He went to try to
figure out, well, what was it? So ultimately what he found out
was the first thing that was important was that you needed to
actually understand what is the outcome that it was that you
needed to do. He also understood that, any
actually spent a lot of time studying ancient military,
people spent a lot of time working with people who have
been in the environment that have been really massively
successful during World War Two. And what he realized was it was
all about. How quickly you can make
decisions. And if you can make decisions
more effectively than the enemy and more effectively means both
quicker and better. Then you're going to win.
And the best way to do that is first understanding, what is it
that you're trying to actually do?
What is the outcome then be able to go through and he has this
observe an Orient which is the first two o's how do you go
through and pull that information together?
How do you go through and build context?
So that you can then hit that D, decide and act.
And if you you get within the enemy's decision Loop, meaning
that you're able to make decisions faster and act on
those decisions faster than the enemy can actually figure out
how to observe an Orient. You can now maneuver the enemy
all day long. So that's where Buddha came in
place and so Boyd interestingly enough wasn't the air force that
ended up taking his knowledge though.
He did come up with in this was part of his journey as well.
He thought okay well if you can come up with practices and you
have Our practices then the enemy then you'll do better.
And so he came up with the book, these seminal book that every
military uses on all of dog fighting tactics and he found
out that didn't work either that that is not about practices.
It's not about methodologies, they're not going to get you
there but he figured out that okay.
Well if you have all this information and you're actually
able to make the right decisions, you'll get there.
So in their Force, they didn't take much of it on.
They totally took is an Theory stuff.
They Totally took his dog fighting stuff.
They thought he was a nut, but the US Marine Corps and more
importantly, the special forces units, both the US and the UK
very much liked the way that he thought and actually at Quantico
the Marine Corps actually built a library around.
A lot of is teachings. He spent a lot of time training,
a lot of Marine Corps leadership of how to go through and make
more effective decisions. How to go through and pretty
much took Turbocharged, the whole mission command side, of
things, to be able to go through and help decide the enemy.
So, that was the reason that I put it in my book was, if you
can actually understand how the decision making process works.
And even more importantly, you actually can understand what can
get in the way of making decisions.
And this is everything from biases.
So we all bring our own biases to work, whether it is our
favorite Technologies languages or ideas.
About how things work or not work or like information flow.
Am I getting the right information?
The right time? Am I getting in the right
context? Or am I getting too much
information in the wrong context?
And then poor framing of the problem and the context of the
information to be able to decide to how to go through and solve
that problem who's constantly get in the way of people, being
able to make effective decisions, if you can understand
those things and you can understand where they're coming
from, you're not going to be able to stop them all, but it's
going to be able to allow You to set the right trip wires and
filters to be able to go through and at least catch when those
things happen and then be able to learn and failed to figure
out how to improve and overcome those.
When I read this chapter is part of ooda loop, right?
Is quite fascinating, I would say thinking of the observe
Orient decide Act and the associated things that are
involved to do all those things, which you summarize there in a
couple of key points, which becomes chapter as well in the
later chapters. Right things like of course.
Do you mention it? Probably around 10.
X rated by not knowing the target outcome.
And then the second is building situational awareness about your
situation, the contacts, and also a friction, right?
You mention about what other things that stand in the way.
And the last part is about learning, right, how the team is
able to learn and learn from the mistakes.
So, I want to go to the second part building situational
awareness because sometimes in ID Service delivery and
engineering team, we are always busy.
No matter what, right? We got requirements, we got
issues incidents on called duties and things like that.
And even, we have so many Disruptions along the way and
also new technologies coming. We are basically constantly
interrupted and distracted. So, how can we build better
situational awareness? Maybe you can give some advice
here? Sure.
So actually, I talked about this in some of the Practical
sections of the book. So my book is kind of split up
into there's a introduction part and then there's Theory chapters
and there's actus chapters. And so what I talk about is a
term that it's actually the title of one of the lien book.
It's learning to see. So there's a lot of things that
are floating around in all of our organizations, how can you
go through and organize the information and filter, the
information such that you're able to learn to see.
And so I come up with a bunch of different mechanisms and they
aren't those like solid Thou shalt thou must do sorts of
things. These are much more patterns
that I've noticed that tend to work, so what I try to go
through and do Is I try to go in and look at how to go and
organize a lot of the work that's coming it.
And so I talked a lot about workflow boards and so these are
more or less like kanban boards, but I don't get super caught up
on all of the con, Bonnie sorts of things.
I've actually talked quite a bit with David Anderson and some of
the common Bond hooks about this.
And it's not that they're not important, it's that you need to
actually understand what's important in your context, which
is to actually We understand what's going on in your echo
system, so I try to go through and make sure that all work goes
through there. Including even the most simple
dumbest things. Like I'll give one that.
Hopefully, most of us don't have to deal with these days ass
word, resets and printer, things or stuff like that being able to
understand those and being able to actually capture those.
Even if it is no more than a tally board.
Actually allows you to understand what is the size of
Prize by actually fixing that problem, either by putting in
some form of automation or doing something that makes it go away.
And what I do is I tend to have the top of the workflow board, I
have the concept of a I've used very terms for this.
The one I used in the book is called a cue Master.
We've called them Ops monkeys, we've called them all sorts of
things. And in essence, this is the
person that is there to watch what's going on in the board.
They'll often be the one. That is Fielding things that are
coming in randomly and they're the ones that will go through
and work with the team to go through and make sure that that
work that gets stuck. They can get unstuck, they'll
help go and fix this. Oh, is it being the combination
of like in scrum? Kind of like a scrum Master par
product owner part. Like, how am I going to go
through and help the team succeed?
But the other thing that this person does is they're allowed
to go through and take a step back and look at What is going
on and the big picture? And every place that I've
implemented a cue master, I almost always start with the
first person on the team, that feels the strongest against
actually doing this. And I go, okay, congratulations.
You're going to be Q master, and every single time, every, every
every single time that I've done that by day, three at the
absolute latest. And often before that, they come
to me and they go, oh my God, I get it.
Why is it that they get it because they can see what's
going on. They can see the man and all it
is. This is about helping the team,
be able to see what's going on. And I have some again pattern
processes and therefore being able to go through and get the
team to be able to understand what's going on, to be able to
go through and get debrief, to be able to allow the teams to
learn and improve from what's going on.
I also have other patterns for whether you are doing, whereas
all of the operational side of Is within a Dev team or if it is
you have separate operations and Dev teams.
And I have the concept of what I call a service engineering lead.
And this is kind of similar to the SRE side of things.
You don't always have to have it, but it is kind of that
expert to be able to allow you to go through and make sure that
if you need help or you're missing something that they can
go in and actually help you go through improve and get better.
They're not a placement, they're not the one that's going to say
whether or not not you can go live or any of that stuff, but
they're there to be able to go through and help make sure that
everything's coming together. They make sure that if you're
working in an echo system where you have lots of other teams
that are doing things, they will work to help to make sure that
you have connections with those other teams.
And again I've noticed this, I've gone in a lot of companies
lately. They use a Spotify model and
they'll set up tribes and squaws and chapters.
And what I've noticed is things will work quite well within a
tribe and This will tend to be aligned to a product line, but
the problem is customers. Don't tend to use a product
line, customers go across products and the problem that
you have is is when a customer is cutting across products.
Like, for instance, I'll do things in Banks.
And one of the things that cuts across all products is know your
customer. So this is what are all the
things to be able to make sure that the customers who they say
they are, and they're not doing some sort of illegal things,
those always break down in companies that have silos.
Those silos of whether they're agile, silos Spotify, silos,
waterfall, silos, whatever. And what I've noticed in those
is I often create a highly effective team often looks like
a squad but really it's a kind of a cut on the service
engineering lead model where they cut across the various
different squads to go through and help Stitch things together
to be able to help people be able to learn to C, be able to
help them be able to make better decisions and Able to understand
what the actual outcomes are and be able to deliver those.
So that answer some of that, I know that is kind of skip
through a bunch of things and I didn't talk through the friction
stuff, but I can as well, because that's also important.
Sure, I'm quite interested when you sharing this story about
implementing Kumasi and you turn a skeptic into a promoter within
just a few days, right? So for people here, who are
intrigued as well? Maybe can you tell us a little
bit of summary or just especially I find that many
Enterprise, you know, big Rise or even the startups these days,
right there are just so many things to do, the company has so
many initiatives, so many parallel tracks and especially
at the bottom, the engineering team, you know, like the tribe
or the squad that you mentioned. People just are not aware of
what are the things that are probably happening in the
company. Second thing is about
dependencies, how we align different teams, across each
other, right? So maybe if you can, align
little bit about this concept of workflow board and Q Master on
how a company can help to see be able to see what is happening in
the organization. So that They can improve from
then on. Yeah.
So I talked quite a bit about both in the book as well as in
general, I talk about how you can go through, instrument up
your echo system and in the book, I also talked about I'm a
big fan of can even as far as being able to go through and
understand what sort of domain you happen to be operating and
because that defines the way that you can make decisions.
And so for people that don't know, can have in a talks a lot
about About complexity Theory. So you can have an obvious type
of environment, where everything can be pretty much plotted out
ahead of time all the way too complex, and even chaos.
And you have to take different approaches in those worlds
because what, you know, or don't know, and what I try to go
through and do is I try to go in and I try to build the
instrumentation mechanism, so workflow board and Q Masters and
those sorts of things. I'll also instrument Things such
as I really like to try to go through and get a lot of things
in around code metrics. Do I have a really complex,
branching strategy, what's going on?
As far as coach earn, do I have lots of people touching the same
code? Those get me little ideas of
things that are going on and it's the same with being able to
build observability and instrumentation within the
production environment. They'll give you some hints at
things. And then what I try to do is I
try to then rebuild? And reduce noise and build a
common understanding of what's going on within the teams.
So this gets into something that again, I talked about in the
book then something that Boyd found out which is something
called einheit. So einheit is togetherness, this
is being one team. This is knowing your team
members. This is knowing like good bad,
ugly building real relationships with them.
And what Boyd found out was that when The team themselves and the
people that are the leaders or managers of the team, actually
get to know the team, and they get to know each other.
You can, then understand how people are going to approach.
A problem, you'll understand where their strengths and
weaknesses are and you can go through and help them and you
can help them in ways where you're not getting in the way
and you can do it in a way where you don't have to actually say
lots of fat boy talks about this, it was like a German I
know of is a colonel or whatever and a lieutenant and they made A
couple of small talk and suddenly there were both like
able to go off to the races and be able to stay totally aligned
if you're actually able to build that and you're able to build
that level of trust within the organization.
Then that allows for when people make mistakes, they're not going
to hide them. They'll be able to go through
and surface them. Will be able to work together
with others to go. Hey I made this mistake.
Is there a way that we can make it more difficult to do this
mistake in the future and understand what the root cause
of that? Is, are there ways to be able to
go through and understand? Like, why is it that work?
Is taking too long and this gets into the friction side of
things. So to me, friction or all those,
various different things that get in the way of you being able
to not only make effective decisions, but be able to act
effectively. So, what I notice is, lots of
people focus on throughput and output measures.
How many features can I have? How quickly can I turn things
around? Those aren't super valuable.
What's more valuable is Is being able to go through and
understand what are the root causes that are happening
underneath. Do you have people that are task
switching all the time? Task, switching is really bad
because task-switching means that you'll get in your head,
especially if you're a programmer and any of
programmers out there will understand this.
I'm working on something and something else comes, you have
to set it down and then you work on that.
Other thing, when you come back and you're like, oh God, what
was I thinking? Okay, and then it takes you a
while to get back into it. And you may never ever get there
or having partially done work, which is another One mean you
have that same sort of a problem, another one that I
notice in this gets back into, I was talking about earlier with
silos, is you'll get over specialization.
So one of the things that a lot of companies have done got who
did this to me. In fact is a lot of companies
will have things like dbas and those sorts of people are
network engineers and they go, I do this one thing, I'm an expert
at Oracle databases and God help you.
I'm not going to do anything else and you go to them and
they're like, you know, If the Oracle says no, and what I do is
I Yahoo they gave me all Oracle dbas.
And the reason for that was I decided to break down the
specialization. It wasn't that those guys didn't
continue to do database work in one example, but they needed to
be part of delivering the overall outcomes.
They were there to work with the teams and try to figure out how
to help enable the teams to do. A lot of the things that they
weren't interested in doing half the time.
Building an index or something like that and it allowed the
team to be able to be faster allowed the team to understand a
bit more of what chaos and Mayhem.
They were happen to be doing two relational database.
So that they wouldn't do that, they would encode it that way
and it allowed the dbas to do. What I told them that they
should all timidly become D bees, database Engineers.
So that there were really focused on how can they deliver
an engineer solutions that are able to go through and get
there? And I noticed that all of these
things, Things seem to work. I go through and I use value
streams quite a bit to go in and try to understand where things
are getting caught up. It give an example at one
company I was at the delivery, teams are delivering to slowly,
it takes about between 14 and 18 months for something to get out
there. The delivery teams need to get
better. So I did a value stream.
And what I found out was that the delivery the vast majority
of the time was actually spent with the non-technical people
arguing and getting approvals and all that kind of stuff.
Their delivery teams. They took no more than five
weeks to deliver something once they actually got it.
And so I said, okay, I can improve that I can get it down
to probably for maybe three weeks, but that's not going to
save you the 14 to 18 months. So being able to get people to
actually see and understand what's going on and it's the
same with an engineering team. If your bills are taking too
long, try to understand, why see if there are ways to be able to
go through and reduce that go through and check your code in
early and often because again, if you're not getting that
feedback or you're holding on to something for too long, then
you'll lose contacts, it'll make it more difficult to merge.
If there's a problem with the build you'll be sitting there
scratching your head. Trying to go what the hell,
what's going on. So those are all things again to
be able to go through and improve and get people to
understand what's going on. And I also then teach
non-technical people as well, how to go through and understand
this information. So they don't need to be
technical but I'll go through and say, Do you understand that?
There's a lot of technical debt and these places.
You can see that there's a lot of code, sure, and that's
happening in these places. The teams need help or here's a
places where you have a lot of defects if you go through and
focus on giving the team's time to be able to go through and
deal with those, that will be able to help not only reach your
outcomes but we'll be able to make things be less difficult
for the teams. I also go through and do the
other thing of instrument up all of your features and everything
that are out there. There are there ones that
nobody's actually ever using and if they're not using them, maybe
you should kill them off, which is something that is like
telling a product person. You go kill their babies.
But again, it creates waste, it's something that has to get
maintained. It's something that you're
going, rev, an operating system or version of Java, or whatever
that you have to go through and spend time to go through and
maintain and people don't understand that.
They think that it's a one-and-done, sort of a thing
they don't. And that with technology is a
constant Evolution, that's a constant change, everything has
a cost associated with it, so get it so that they understand
that and that they can tune that side of things effectively.
So that's a lot of the way that I try to go about doing a lot of
those things. Well, thanks for highlighting.
All these different things. It's quite fascinating.
I highly recommend people to read this book part of the
summary that I learned from reading this book is that the
first thing is that you need to enable the team right?
The whole team to make Quicker decision making.
I think that is the crucial thing about all this, maybe
Linda walks or devops in general as well.
And one of the key first thing is to understand the target
outcome. So you mentioned about Mission
command and the setting, the goals, and the constraints, and
let people figure out how to do the solution.
And over the time you also need to build situational awareness,
understand the friction where things go wrong within the team,
being able to see what is happening.
Because many times, I think we are just busy, but we are not
able to see what are the things that are producing the friction
that we are facing. Today.
And the last part is, I think building the learning culture,
right? And also you touch on about
togetherness, where people know, each other personally and also
build the trust so that we can build a better, highly
performing team. So thank you so much for all.
But for all this great explanation, great insights.
Again, I highly recommend people to read the book as we reach the
end of our conversation. I have one last question that I
would like to ask you this question.
I call the three technical leadership.
Wisdom, you can think of it just like an advice that you want to
give people here to learn from you.
You about your experience or from your knowledge, throughout
your career so far, sure. So I would say the first one and
you probably heard me pound on about this all throughout it and
this is something that's important for everybody.
The no matter if you're the most Junior person in the team or
you're the CEO, and that is have a purpose.
Understand what are the Target outcomes that are trained to
achieve? Why are they important?
How do you contribute to Being able to be achieved and most
importantly, how do you measure whether or not you're on the
right track to progressing them and outcomes aren't outputs,
they're not feature or defect counts, they're not lines of
code. And in fact, this drives me
completely up below with things like okay ours, A lot of people
think that o stands for output and the key results are measures
of those outputs. No, it's all about
understanding. What are the things that matter
to people who drive? Are you from what you're trying
to deliver? So that's number one, and if you
don't know what it is, try to find out because that's what's
going to differentiate you from some J, random guy who knows
JavaScript, or whatever, that's out there.
And they'll go, oh my God, this person is able to go through and
Achieve things and make it happen.
If you're a leader, how do you go through and communicate that
stuff to your team's that's going to be important and it's
don't telling them what to do or how to do it.
Tell them what it is. You're trying to achieve So the
second one is ensure effective decision-making.
So boys. Oh, de loop is all about how do
you go through and pull information and knowledge
together to shape the right context to make quick and
effective decisions. It's not about guessing.
It's about being able to go through and consider decisions
critically thinking through how things can go wrong and what
might happen when they go wrong this helps you be able to go
through and test the quality of your situational awareness.
It helps you filter. ER out assumptions and biases
and mitigate any unnecessary and controlled risk.
So, for leaders, one of the things that I find fascinating
is their most leaders don't realize that they're often too
far away. From what is happening to be
able to make the best decisions at the time that's needed.
Even if they have the information, they're not going
to be able to turn it around and be able to make it happen the
right way. And often times, they may think
they have the right information but they don't.
And this were Mission command comes in, are more people with
purpose. Help them, get the information,
give them the safety to be able to make the decisions that their
best place to make. And that way what decisions you
need to make our at the right level where you have the time
necessary to be effective and then if you're an individual
contributor, you also need to be able to be equipped to make
decisions. You need to be able to realize
what you know and you let you don't know where the gaps are in
your awareness. And gaps are.
Okay, this is where I night is. Oughtn't and understanding your
team is where information flow and Mission command come in.
You need to be able to feel safe to make mistakes and to be able
to learn from them. And learning is how we all get
better. And so this is where manners
isn't teams need to work together to make sure that
nobody is put into a situation where they must make a highly
risky decision with no support. And then the third one, which I
touched on a bit. And the first two is, you really
need to respect people. So people, Our most valuable
resource. You have to involve them in the
decisions. You have to make sure that they
feel safe and part of the decision, they need to
understand the purpose. You need to make sure that you
have an environment. That feels like it's a
supportive team where people feel committed to helping each
other pursue, the target outcomes.
And what I noticed time and time again, is that if you don't do
that, you build a low, trust environment and low trust
environments or where information gets hidden mistakes
get made, but they also get hidden.
And all of this damage is decision-making and it makes
learning nearly impossible. It's also really stressful and
inevitably it creates a situation where the people that
you can least afford to lose our usually end up being the first
to go. So by respecting people, you
make it. So that those people really
never want to leave, they always want to put it in at all.
They always want to be able to help be successful because again
they're there and they're helping be part of achieving the
target out. Well really beautiful message
for people who just listen, right?
I think respecting people is part of the very crucial
important elements of leadership I would say because at the end
of the day it's not just the leader, who do the job is
actually the people who actually helped to achieve the target
outcome. So Robert, if people want to
follow you or continue the conversation online, is there a
place where they can find you or buy the books and things like
that? Yeah, I remember the book, I
have a site that I'm slowly cobbling together Lane
devops.com, I do. Have a Twitter handle which is
leading devops. And sometimes I post things to
LinkedIn as well. So I haven't been quite as how
out there as I would like because I've been brought into
mother of all flaming projects at the moment and a lot of
people say new book and I'm like, nope, that's okay.
But it'll definitely be a learning experience and is
definitely one of those completely super important.
Very incredibly complex projects.
So those would be the places to go.
I also do try to go out from time to time to speak in the
community and people as well. So, you know, keep your eye out
there, you'll find very quickly, I am not a one-way sort of
person. I like to listen and understand
what people are actually seeing them as well as to be able to
provide any sorts of insights and help that I can sum the new
project is like similar last time, right?
You always seem to do things that I knew right?
Nobody has done it before and I wish you good luck with that
project as well. So thanks a lot for coming here
and sharing. Sharing your insights Robert.
Thank you. Thank you for your time.
Thank you for listening to this episode and for staying, right
until the end if you 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 this podcast better. You can also find the full show
notes of this conversation on the episode page at technology
node, death website, including the full transcript interesting.
Quartz and links to the resources mention from the
conversation. And lastly, make sure to
subscribe to the shows mailing list on package.
You know, dot f to get notified for any future episodes.
Stay tuned for the next package, you know, episode.
And until then, goodbye.