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.