Dan Lines is joined by Gil Broza, author of 'Deliver Better Results,' to discuss how you and your organization can achieve better results by focusing on processes. Gil shares his 20-year journey in the Agile field, focusing on product development, system thinking, prioritizing people, and mindful mindset adjustments.

The conversation covers the book’s target audience, the concept of the value delivery systems, and the roadmap for holistic improvement beyond traditional Agile methodologies. Gil also highlights common pitfalls leaders encounter, such as treating people as resources and the importance of a unified organizational mindset.

As a thank you to our listeners, we’re giving away the first chapter of ‘Deliver Better Results’ for free, check it out here

If our listeners take something away from this, look beyond your immediate scope.

If you just try to improve engineering or just try to improve product, or you let teams do their own retros and continuous improvement, you run the risk of things not really sticking. The changes don't stick, or you get unintended consequences, or you just get too much business risk.

You want to understand the boundaries, you want to have this coalition of leaders who care about the system and want to improve it.

Episode Highlights:

00:58 What led Gil to write ‘Deliver Better Results’, and who should be reading it?
06:20 Is there a certain size of team that would benefit from this book?
12:08 How can leaders identify the current state of their team?
17:01 How can engineering and product work better together?
20:49 What do leaders get wrong about people?
34:14 How can managers avoid finding someone to blame?
40:10 How can you avoid falling back to old habits after you make changes?

Transcript:

(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)

[00:00:00] Gil Broza: If our listeners take something away from this is, again, look beyond your immediate scope, right?

If you just try to improve engineering or just try to improve product, or you let teams do their own, like, retros and continuous improvement and whatnot, you run the risk of things not really sticking, the changes don't stick, or you get unintended consequences, or you just get too much business risk.

You want to understand the boundaries, you want to have this coalition of leaders who care about the system and want to improve it.

[00:00:30] Conor Bronsdon: Gardener just released their market guide, showing that software engineering intelligence platforms, help engineering leaders significantly improve both team productivity and value delivery. Through Gardner's in-depth analysis on the critical features of sci platforms and how they can be used to drive engineering excellence.

Linear B was named as a representative vendor. And therefore we're giving away a complimentary copy of Gartner's sci market guide. Head to the link in the show notes to download your complimentary copy and learn [00:01:00] how you can unlock the transformative potential of software engineering intelligence for your team.

[00:01:04] Dan Lines: Hey, what's up everyone? Welcome to Dev Interrupted. I'm your host, Dan Lines, LinearB COO and co founder. And today I'm joined by Gil Broza, author of the book, Deliver Better Results. Welcome to the show, Gil.

[00:01:24] Gil Broza: Thank you so much for having me here.

[00:01:26] Dan Lines: It's really cool having you on. And we were just chatting be Before the show you're in Toronto.

I'm in Rochester, New York. We're actually pretty close to each other. Not too far away, which is awesome Usually I can't say that for people that are coming on the show. But I have seen actually a lot of good stuff happening in Toronto some startup companies that type of thing, which is really cool. So awesome to have you on. Could we start out?

What was Gil Broza's background that led him to write Deliver Better Results?

[00:01:52] Dan Lines: We know that you wrote this incredible book. We're gonna get into the book. But, can we hear a little bit about you, [00:02:00] your background, what you're all about, your career, and then we'll dive into the book.

[00:02:05] Gil Broza: I have been specializing for the past 20 years in helping software leaders deliver better results, hence the name for the book.

And they do that by upgrading their organization's way of working. And they achieve sustainable upgrades to their way of working because we work on the three pillars. Product development, thinking in systems, putting people first, and being intentional about mindset. Uh, like I said, it's been about 20 years, um, I'm pretty well known in the Agile space.

I've worked with about 100 clients since starting my independent practice 15 years ago. And, um, I work primarily with, you know, U. S., Canada, and Europe, but I want to help the entire world.

[00:02:51] Dan Lines: So 15 years ago you started, you said like independent practice, but like your own, your own business.

[00:02:58] Gil Broza: Yes, which is [00:03:00] intentionally unaffiliated, non certifying, giving my clients the best that they deserve.

And not just somebody else's ideas.

[00:03:10] Dan Lines: Very cool. And what did you do before that? Previous to the 15 years ago, you start your end of independent business. What happened before that?

[00:03:19] Gil Broza: Pretty common engineering track. I started as a developer, senior developer, team lead, R& D manager. And it was around that time that I discovered agile methods.

I was. So we're talking about like 2000, 2001. I was able to apply them in a couple of companies. And it's then when I realized, you know, I want to help more and more companies rather than stay within the confines of one.

[00:03:45] Dan Lines: Gotcha. Yeah. So, you know, early, early two thousands, lots of companies, I think. Maybe thinking, well, I mean, that, that may be, may be even the timeframe where it's like, [00:04:00] Agile is a little newer, like, how do I do this?

And then, yeah, yeah, yeah. And so you kind of said, okay, let me go and make this, you know, a career for myself, but I can, I can help many, many people. That's what it sounds like. Yes,

[00:04:14] Gil Broza: because the realization was that how we work matters. And for the longest time, we had just one way of getting work done, right?

The traditional kind of project management approach. And, you know, I sort of happened upon this alternate reality where teams can be collaborative and cross functional and planning frequently. And managers don't have to be bossy. And I realized, you know, There is a lot here, and I want to help others.

[00:04:41] Dan Lines: Yeah, that's a ton, and we're going to have to unpack all of this stuff. Exactly. As much as we can in this podcast. So let's start with this.

Who should be reading Deliver Better Results?

[00:04:51] Dan Lines: So your book, Deliver Better Results. Who is your intended audience? Who should read this book?

[00:04:59] Gil Broza: It is [00:05:00] for leaders in software development who need their teams and orgs to work more effectively and efficiently.

I've written it so that it's readable and applicable by managers at all levels. Okay, so it is written also for the very busy CTOs and VP engineering. Although I do expect that we'll have all, all roles and seniorities read it.

[00:05:22] Dan Lines: Okay, cool. And can you give us a little bit, I guess, an overview of the book or, you know, some of the fallout, like, what am I going to find there in this book?

[00:05:32] Gil Broza: Okay. So what you're going to find there. is a focus on something that actually very, very little literature focuses on. And it's what I call the value delivery system. It's this part of the company, both contributors and managers, and how they work, all the way from idea to delivery, to make technology that benefits the customers.

Okay, so it is bigger than a team or a set of teams, and it's smaller than the company. And bigger companies have more than one. [00:06:00] The premise is that if you want such a system to deliver better results, basically make a bigger difference to your customers and your business, you have to improve the system, not Improve locally, like, you know, a team, an agile team, engineering, product, design, test, but rather improve holistically.

And the book provides something that's been missing in our industry, which is a roadmap to improving and optimizing that system.

[00:06:29] Dan Lines: Ah, that sounds cool.

[00:06:30] Gil Broza: Yeah, because the industry has offered a bunch of target states, like, you know, Scrum or Safe, right? Without actually saying how you get there, and they may not be right for you.

Right? Uh, the industry has offered practices that you should copy because some big player uses them. But of course the big players use different things. Right? So which one should you take? It has offered leadership models, it's offered continuous improvement, retrospectives, but not a roadmap to holistic improvement.

So what I offer there is really two kinds of things. One is, [00:07:00] um, how do leaders behave and speak and enable and support in order to make improvement possible and sustainable? Right? And the second thing is a set of 10 strategies, sequential and incremental, to get there.

Is there a certain size of team that would benefit from this book?

[00:07:14] Dan Lines: That's awesome. And in terms of the audience again, is there a certain size company or size product engineering team that would benefit most from the book?

[00:07:27] Gil Broza: No. It's actually useful for all sizes. And the reason is that even the very big, right, they have Several of those systems in there. They might be a product line, they might be, uh, some form of vertical, a program. Uh, they're organized in such a way that they already manage their scale. The thing is, within that, what do you focus your improvements on?

So, for instance, you can go to the head of engineering and try to improve all of engineering, even though it crosses multiple systems, and [00:08:00] sometimes you get some problems with that. So the book is, you know, one system at a time. For most companies, that's anywhere between 10 people and like a couple of hundred.

But if you have, I don't know, a thousand people for sure, you're going to have several of those value delivery systems for sure.

[00:08:16] Dan Lines: Gotcha. So it sounds like when you've done this and what the book prescribes, you also said you've done this at a few companies. It seems like you do maybe like small chunks of teams or like system by system.

Is that the way to, to go through the change management process?

[00:08:33] Gil Broza: Yes, it is. So the first thing you need to do is actually understand where the boundaries go and one really easy way to think about this. Um, and again, for all of our listeners, everybody is working in one specific system, think of your product or solution.

Uh, as if it were a movie and think to the end where the credit role is and say, well, who contributes to this movie? Who makes decisions? Who enables this whole list of people? [00:09:00] That is the scope you're working with. So it's both ACs and their managers. It's not going to correspond neatly to the org chart.

Uh, people will report to different managers. That's okay. But everybody's decisions affect other people's decisions. That's a system, and therefore you have to improve things holistically. And by the way, chances are, , a lot of our audience uses the term value stream. That is the closest thing to this. My concerns with this term, just based on what I've seen, is that it connotes that work flows only one way.

Kind of like it did in Waterfall. But then, realistically, when you think about, Stuff happening in the system, which is again, all, it all boils down to decision making. Decisions have ramifications throughout the system and not just in a linear fashion. So there is a stream here in that work keeps coming in and we keep delivering, but what happens inside is more like a network.

[00:09:57] Dan Lines: That's really [00:10:00] interesting. I definitely agree. When I think of stream, I think one way, right? Value stream. I'm creating something. I'm just sending it out. It's done. Much more complicated than that.

[00:10:12] Gil Broza: Uh, or some would say even complex, right? Because it's really hard to predict all the results of actions. And so, the book really, um, encourages, um, The reader is to take a system thinking approach, not in the sense that everybody should be able to draw, you know, all sorts of causal loop diagrams and this and that.

No, just think, you know, beyond your immediate scope. If you decide X or you decide Y, what might be the ramifications? How might things in the system, people's behaviors, choices, whatever, compound your change or fight it? That's basic system thinking, right? So there's reinforcing, right? And there's balancing.

Or in other words, you might get vicious loops, vicious cycles, all sorts of things that can hamper your efforts. So just think about that. [00:11:00] Okay.

[00:11:00] Dan Lines: So, before we dive in more, I do want to let the audience know, Gil, you're offering our listeners the book's first chapter.

[00:11:11] Gil Broza: Yes.

[00:11:11] Dan Lines: For free.

[00:11:12] Gil Broza: Yes.

[00:11:12] Dan Lines: It's called The Big Picture.

[00:11:14] Gil Broza: Right. Yes.

[00:11:15] Dan Lines: And I just have a little blurb on it. It sounds like it's a concise presentation of the main ideas and advice in the book. For our listeners, and I'm sure we'll include this in our links to receive that chapter, go to heardonpodcast. deliver. com. BetterResultsBook. com. Of course, we'll, we'll include that information.

Um, did what we just cover here outline kind of that first chapter you know, is there anything else to say kind of about that big picture to start there? Yes.

[00:11:47] Gil Broza: So that chapter actually has more things it's written in such a way that like if you want to hand the book to your boss and you want your boss to read this, the boss says, I don't have time.

Because just read chapter one, it's 20 minutes, you'll know [00:12:00] the main things. So for instance, one of those things is that when we want to deliver better results, what we're really targeting is for the system to work better. And what we're hoping to increase is the system's fitness for purpose. How well does it help the company achieve its mission and objectives?

Uh, and it turns out that there are five levels that systems go through. In real life, this is not some academic theory, this is based on observations. And that in order to, you know, choose which strategies to apply, you need to know what your current level of fitness is. And that chapter has a quick assessment, intentionally designed to take 10 minutes or less, so busy people do it.

It doesn't require metrics, or big surveys, or big consulting, or anything like that. And it's also not really gameable, usefully. And so you assess your current level, and that shows you which strategies to employ. And you're off to the races. The rest of the book digs into that and gives the [00:13:00] specifics and ideas and whatnot without prescribing anything.

 

How can leaders identify the current state of their team?

[00:13:03] Dan Lines: That's really cool, actually, because what was on my mind is, you know, we talked about the system, we talked it's a network, we talked maybe it's a little complex, like, how do I identify, like, my current state? Do you have a process that I can go through to even, like, think about

that?

[00:13:19] Gil Broza: Absolutely, and I I've really taken pains to explain this in the simplest language possible, right? Uh, because I'll tell you this, almost every treatment of system thinking that I have, that I have come across, uh, it got really technical and jargon heavy, and, and it felt like a lot, very quickly. You know, if our listeners take something away from this is, again, look beyond your immediate scope, right?

If you just try to improve engineering or just try to improve product, or you let teams do their own, like, retros and continuous improvement and whatnot, you run the risk of things not [00:14:00] really sticking, the changes don't stick, or you get unintended consequences, or you just get too much business risk.

Okay, so, you want to understand the boundaries, you want to have this coalition of leaders who care about the system and want to improve it. Okay, so like in a smaller environment it might be VP Engine, VP Product, in others it might be a bunch of directors, it varies. And for them to kind of work from a model, and the book presents a model that they can follow.

As opposed to saying, hey, I heard Scrum's awesome, we should do Scrum. Or, in my previous company, we did Safe, we should do Safe. No, this is, this does not prescribe anything, but it gives you ideas and explains why things kind of go the way they do and what might improve them.

[00:14:48] Dan Lines: That's really cool. One of the things that I always think about our listeners, so the people listening to our podcast is, I have my career on my mind.

You know, how will this [00:15:00] help my career? Is this for me? You know, everyone wants to have a great career journey, you know, and it's wonderful to do that. How do you think this book relates to someone that's interested in improving their career?

[00:15:16] Gil Broza: Okay, so I treat every reader of the book as what I call their an improvement leader.

And what this is, it really goes back to one Responsibility that leaders have and by leader I it can be really anyone from team lead or scrum master or coach all the way to C level and you know you're already supposed to manage people, objectives, budgets, planning, execution, whatnot, but something that we don't talk about enough is to improve how work gets done Right?

So that you achieve more for the company given what you have. And sometimes that is in the blind spot due to inertia. Sometimes it's just kind of narrowly defined as, you know, look for efficiencies. Which is not the best [00:16:00] lens in which to view product development anyway. Sometimes we look for automation or AI or whatever.

But this will give you the language and the models and the advice to carry out that responsibility. And this will help your career because, uh, your company will get more from you. You will be a lot more valuable for your employer, for your client, in the sense that you're able to achieve more. Without compromising, you know, the team's health or your future delivery, things like that.

[00:16:37] Dan Lines: Yeah, that's really nice. And I think also if it sounds like to me, if you're interested in improving your career, you're reading this book, you know, it's taking this holistic look at your system. I mean, even going through that assessment can probably give you a little bit of an understanding, I assume.

What, you know, what's working, maybe what's not working, that, that type of thing, um, which I [00:17:00] always find, find is like a great exercise, you know, regardless of any leadership position that you're in, probably going to help you out a little bit.

[00:17:09] Gil Broza: Yes. And once, one super important thing is that we want to manage the whole, but usually when we work, you know, work never stops, there's always more to do.

Always more planning, always more this than that. It's very easy to lose sight of some things. So for instance, we might be. Uh, I don't know, leading an engineering team and really taking a lot of interest in our delivery metrics. Nothing wrong with that, but it's only one part of the picture. What about, are our deliveries making a difference to people?

Or to what extent do they do that? Now, you might say, well, that's not my responsibility, that's product. Well, But product, product needs you to succeed and you need product to succeed. So maybe you should talk to them and come up with something that matters to both of you. And that's really the angle this, this book, this book takes.

How can engineering and product work better together?

[00:17:56] Dan Lines: That's really interesting. I want to dive in there. So we're talking about [00:18:00] engineering and product relationship. One of the most, I think, also complex relationships. What have you seen there, some of the pitfalls, like you've worked with companies, what are the common issues you see with that communication?

Right, so those relationships are all over the place, right? The relationship I see most commonly is the order taking relationship. Engineering does what product wants them to do. Another relationship I see a lot is kind of being afraid to raise issues. Not wanting to be seen as a troublemaker.

[00:18:37] Gil Broza: Um, another one is really kind of let specialists do their thing. So let products do their product thing and let engineers do their engineering thing. And without realizing that nobody's choices are entirely context free. Or ramification free, right? Again, system. So I can tell you [00:19:00] where I've been working.

Results were really, really great. There are some things the leaders did. One of them is that the engineering leaders and the product leads, they took shared responsibility, not just for what will we deliver, but how will we get better at doing it? They spoke to each other frequently. They, they had trust.

They collaborated to, to some extent.

They made it possible. for everyone in their respective groups to, to own things. Not just in theory, but actually own things. And also made it possible for them to speak with other people in the system who were dependent on that. Okay? Uh, you know, a counter example to that is from way back before I started, uh, you know, kind of coaching, uh, in Agile, uh, contexts.

I was, uh, leading a server development team and my manager was awesome in terms of, you know, [00:20:00]empowering me to do things. I mean, this goes back a long time, but if I needed anything from the front end team, I had to go through the channels. I had to go up the hierarchy. He would talk to his counterpart and he would talk to his people.

And like, seriously, these people are sitting across the hallway from me. That makes no sense. And product, nobody even talked to them. They just gave us documents, right? Now this is, of course, old school, but I see the same dynamic continue to play out these days, still. And part of it is the pressure that everybody's under.

The race to be dominant has not relented. Uh, we get more things. Hey, AI now, right? But the race just got harder, okay? And so, we still need to remember that what our customers care about is That's not how we divide work internally.

They don't care who does what. They don't care who reports to whom. They care that the thing works and does the job it's meant to do and that doesn't upset them and all of that stuff. And those are not [00:21:00] just product management calls and UX calls and engineering calls. It's everybody's calls. Including the VP who deprioritized something.

[00:21:08] Dan Lines: Yeah. The way that you describe it, there definitely has me thinking about the system, how every decision and how it impacts. And, you know, if the decision making is only one directional product tells engineering everything to do. Obviously that's not a great situation to be in because engineering has a ton of context of their own.

Uh, and that, yeah, I, I can see that, you know. I've experienced that before. I've seen that happen as well. I wanted to ask you a little bit more of like some of these other, I guess, pitfalls or like what not to do.

What do leaders get wrong about people?

[00:21:44] Dan Lines: What do you see, uh, maybe most often leaders are getting wrong?

[00:21:52] Gil Broza: Like in terms of, you know, unlocking organizational potential?

Yeah, exactly. Yeah. Okay, so I'm gonna start with my [00:22:00] pet peeve. Okay. Something I've written about plenty. I think it's in every one of my four books, and that is people are not resources. Repeat after me. Do not call people resources. Now, I know a lot of people say, what's the big deal? I mean, we know they're people, right?

It's just a word, but it's not a word because it reflects how we think. So when we talk about, Hey, I got five devs, you've got three. Can we trade? We're not thinking of them as people. We're thinking of them as units of labor. And when you know, by extension the entire company works this way, then you, you're really looking for, you know, labor for results as opposed to.

Basically our last remaining You know, um, advantage over the AI we're building, which is we can think and reason and generalize and collaborate and come up with new things. So it's not just about, you know, turning requirements into deliveries. There's something greater going on here. So that's one [00:23:00] thing.

[00:23:00] Dan Lines: That's a great one.

[00:23:01] Gil Broza: Yes. And, and also by the way, as, as long as people are resources, then the whole thing that we say about, you know, collaboration or trust or safety, it, it, it doesn't matter. It doesn't matter.

[00:23:11] Dan Lines: Yeah, it's dehumanizing.

[00:23:12] Gil Broza: Yes, and everybody sees through that. And, you know, the whole concept of psychological safety entered the, you know, the discourse 10, 15 years ago.

It's still not entirely there, but everybody has always felt it. Okay. And, and nowadays I think things are a little better, but not enough. So, okay. Another thing is, uh, and that goes back to work I did a few years ago on mindset. And I know a lot of people kind of either see it as a vague thing, or they look at it as, you know, it's just psychobabble.

But the way I explain mindset is it's your choice making. So when you do something, there are certain principles and guidelines in the back of your mind that guide how you approach the work. Right? So for instance, [00:24:00] you, let's say you need to produce a spec. You can do this collaboratively, or you can do this totally on your own.

You can be perfectionist about it. You can take your time. Whatever it is, all those are principles that guide you. And what happens in organizations, for the most part, is that they, they don't have an explicit and intentional mindset choice making. They do stuff and they have processes and procedures and tactics, but they don't articulate clearly enough how they want people approaching them, so that they act harmoniously and not work at cross purposes, and that they get the results that they want.

So, for instance, as a senior leader, I can say, Look, I think we will be more successful if we're more collaborative. That's a mindset type of setting statement, but I also want to act on it in terms of assigning work and Checking progress and metrics and a whole [00:25:00] bunch of stuff. Okay, and so if you want to deliver better One very basic thing you need to do is is basically define How do we want to be around here?

Not at the level of psychobabble, but at the level of what are we optimizing for? Are we optimizing for innovation or prediction? You got to choose You Right? And a lot of companies say, yeah, yeah, well, of course, we need innovation, but then you look at how they actually plan and what they actually do and how they actually talk.

No, they're optimizing for prediction.

[00:25:30] Dan Lines: Yeah, that's interesting. Because it's cool to say, yeah, we're innovating. Has

[00:25:34] Gil Broza: to be.

[00:25:34] Dan Lines: We're all, we're all innovating. Or we're collaborative. If you're, if you're not innovative, you're looked down upon. Or,

[00:25:39] Gil Broza: you know, you wouldn't say, no, we want silos here. We want to utilize people 150%, we want everybody busy.

No, the cool thing to say is, no, we collaborate. We tap into everybody's wisdom. But what matters is what you actually do. And then from this you can infer or reverse engineer the [00:26:00] principles and values that guide all of those behaviors and choices. And then you can say, no, you're actually favoring individual work.

That will get you some things, of course. It will not get you the effects of collaboration if that's what you're after.

[00:26:14] Dan Lines: I think the, the mindset thing is always, like you brothered up, it's a tough one because it sounds very soft.

[00:26:21] Gil Broza: Yeah.

[00:26:21] Dan Lines: Or maybe out there, but also what we're saying is it leads to a lot of, depending on what the organization's mindset is, we're making decisions every single, I don't know, hour, minute, second, and you know, you brought, I think this was your second pitfall, like either, maybe it's not having a harmonious mindset or not everyone in the same, uh, direction of mindsets.

And I do want to ask you about. Other pitfalls, but if we just stay on this for one more minute, I always think it's, [00:27:00] it's one of the hardest things to get everyone thinking the same way. And I'm just wondering if there's any, about anything, software development, anything, really. Do you have any tips between a product engineering company organization that helps, With that, once you have the mindset that you want, like, do I actually roll that out?

[00:27:20] Gil Broza: Yeah, well, it's actually what I do for a living, right? I mean, that's a lot of what I do for clients. It's actually not that hard, but it's something that has been in the blind spot. It's something that gets lost because we're always busy executing. It gets lost because we really have this mentality of copying what other people did that was successful, or copying what we did with our previous employer, and we go for best practices and whatnot.

And we forget context, and we forget that copying things superficially doesn't tell us how they were executed. Okay. Uh, so in terms of [00:28:00] making this happen, yeah, so you start by making everything explicit. Hopefully you involve your team. It's not just top down. And the second thing is you keep looking at what you say and don't say, what you do and don't do, what you reward and punish.

Um, What messages you're sending people through all of this? And you say, does this support what I want to accomplish? For instance, if one of our choices is we want to be collaborative, look at how you engage in team meetings and one on ones, um, how you put plans together and say, well, are we collaborating here?

Are we collaborating enough for now? Or are we really just going, you know, person by person? And that will give you the feedback you need. And so you can basically start building good habits. around acting on what you want there to be. But it starts with being explicit and in a lot of companies, they don't have that.

[00:28:58] Dan Lines: I'm going to go through [00:29:00] this assessment in your book and understand my system and my network a bit. Right. And then eventually I'm going to need to go take action and make a change, right? I'll probably understand my system is not perfect and I want to do something about it.

Have you found that, Like an engineering leader or product leader or whoever's kind of taking this initiative is, can do this on their own? Or does it require bringing in like outside resources to help with this change management? Like what, what have you, what have you seen? Well,

[00:29:31] Gil Broza: look, obviously I am biased because I am the outsider, right?

I'm, I'm the external one. What I find is that yes, many, many leaders can do this on their own. However, first they're really busy. Second, they're missing a model by which to do this, as opposed to, again, just here's a target state. Take Scrum, do it. Right? And third, and that's really one of the Value propositions of [00:30:00] having a coach or a consultant.

It's pointing out to you all the stuff that you have missed, the stuff that you already know, the stuff that is in you, you know, to do that. And you know, it's good, but you have missed it. You have let it lapse or something like that so that you accomplish what you need to accomplish, right? I have had wonderful clients.

Some of them are like the best. Best enabling leaders I know, and even they have their occasional missteps or they don't quite know what to do. And that's where somebody from the outside really helps. You can do this with internal staff, like internal coaches and whatnot. And what I keep hearing from many companies is, yeah, but, and the but is because I'm internal, they don't, they don't pay enough attention to what I say, or they think I'm biased.

[00:30:52] Dan Lines: Yeah, I think that's a good like, uh, thank you for sharing that. I think that's like a really honest assessment. What I would, I would say what caught me the [00:31:00] most is it's hard to make change when you don't, you feel like you don't have time and there's so much going on and you're trying to deliver in product engineering and you have timelines, but then you're also supposed to Get mental space to say, let me look at my system and make this change.

That's where I think bringing in someone from the outside that can kind of accelerate that thinking for you to say, Hey, I've already done this a bunch of times, let me like jump you. Absolutely.

[00:31:26] Gil Broza: And that's exactly the value proposition I go in with. And that's why I charge what I charge, because I can help you accelerate and reduce the risk.

And so for instance, you know, there is a case study in the book. At the end, in one of the appendices of how I helped a company go from like a really troubled value delivery system, it was a product company, 40, 50 people, all the way to like really good, really, really good in 10 months. Typically in the industry, you would need a couple of years easy.

And it wasn't because of my [00:32:00] awesomeness. It was particularly because we did things in a certain sequence. And when they had questions, they got answers, as opposed to just relying on what they already knew. And calling them out on behaviors and issues. Um, and the other thing that happened there, which was particularly lovely, is that management was so thirsty for learning, and just, you know, They basically, they, okay, they didn't entirely say it this way, but it was like, tell us what to do and we'll do it.

And I'm not of the telling kind. I don't want to prescribe what's right for you because you're going to have to live with it, not me. But you know, through a bunch of, you know, coaching techniques and whatnot, I, we came up with suggestions and they just went ahead and did them. And so when you have this type of willingness and when they care enough about the thing, you can move really fast.

So then what remains is that you actually work from a model that gives you a good roadmap. As opposed to kind of meandering, like, you know, let's just do a whole lot [00:33:00] of team retrospectives and eventually we'll be great. No, you won't. It will be locally optimized.

[00:33:06] Dan Lines: That's really cool. I, well, I like what you said is there's almost like a, a step by step to go through instead of kind of like, okay, everyone do a retro, keep doing these retros, eventually it will work out like for the better, that's the point of a retro, we get better after, after it.

Yeah, I've seen, I've seen it work. Over maybe a long period of time or if you have incredible, incredible leaders at every single team, which is really hard to do. It sounds like in the book or with your, your coaching, we get more of this step-by-step. Is that the 10 strategies Yes. Processes that you 10 strategies.

Yeah.

[00:33:39] Gil Broza: But so, so they are kinda stepwise. Yes, but they are high level enough, so, so I don't actually prescribe to you what you should be doing or what that would look like. So to just, just to give you an example, if you assess your system as a level two. There are two things to do there. One of them is you want to plug holes in decision making.[00:34:00]

A system whose fitness is at level 2, uh, you know, some decisions are kind of hazy or easily reversed or things like that, and they just need clarity on who makes them and when. The bigger strategy at level 2 is to stabilize the system so, you know, it has demand and it has supply. The demand is like your roadmap and the supply is what you deliver.

And at level two, the relationship is kind of erratic. You can't really tell when stuff would come out and in what shape. Uh, like with reasonable confidence. And, and the strategy is to stabilize it, right? To get to a good balance between the two. And I give lots of techniques and tips that have worked from Kanban, from Agile, from whatnot.

Um, but it's up to you to choose which ones. And you may find that three of them are enough for you and that two of them, they will just never fly and that's okay. Okay.

[00:34:53] Dan Lines: Sounds like those, there will never be a one size fits all. How can there be?

[00:34:57] Gil Broza: Right? Our business context is different. [00:35:00] Our people are different. The competition is different. Our legacy is different. Everything is different, which is why we're not also resources, right?

[00:35:08] Dan Lines: Absolutely.

How can managers avoid finding someone to blame?

[00:35:09] Dan Lines: Let's go back and I think we'll have time for one more. I like the pitfalls. Do you have another pitfall?

Talk to us about that.

[00:35:18] Gil Broza: Okay, this is a

juicy one. Let's say you have some performance issues in your team. Let's say you have some behavior issues in your team, or maybe some faults.

Somebody brought out down production. How do you think of that? The pitfall is, and this is on us as humans, not just as managers or leads. The pitfall is we look for somebody to kind of pin the cause on. I mean, sometimes we go as far as outright blaming, but even if we don't, we, we want to know like, who did this?

Right? And why did they do it? And all of that. And system thinking will tell you that well north of 95, [00:36:00] of 90 percent of what happens in your system is because of the system, not the individuals. So let's say you have somebody on your team who's just being nasty to their colleagues, let's say. Okay? It's so easy to just say, well that's their personality, they're a difficult person, whatever.

Or maybe, um, I don't know. They didn't get the training. Okay. If we take a system thinking approach, we might say, well, what is it about the system they, systems that they inhabit, which are their team, their functional group, um, their family, their community, their neighborhood, their city. Those are things we don't know much about, but they are there.

How are they affecting their behavior? So without even getting, you know, to, you know, psychological stuff, like, you know, what did, what happened to them as kids and how, you know, what were their parents like? We're not even going there. [00:37:00] But what we're saying is how is that person responding to something that's happening around them?

And maybe what's happening around them is that they get tasks that they find boring and basic, whereas somebody else, um, gets the really juicy and interesting ones, and that someone else is gonna get the bonus, the promotion, the treatment, the whatnot. And so the person who's being nasty is trying to kind of look, I don't know, more important, or more impactful.

Because they can't do this through the tasks they're working on. So it's not a matter of personality. If, if they ended up in the right position, maybe instead of being a developer, they need to be a test engineer. I don't know. There are contexts in which they would shine. So it's not like they're inherently broken.

So, so the, the takeaway here is attribute to the system [00:38:00] before attributing to the individual.

[00:38:03] Dan Lines: Got it. Now it makes perfect sense why we need to start with the assessment of the system and chapter one. No, that's actually really cool. Cause that is like a, I think a pretty juicy. It's easy to say, well, that person, that's a, they're just a jerk. No, it's, you know, they're just, uh, they've never been easy to get along with.

Yeah. Usually I think like human behavior, you have all these environmental factors coming on to you and it creates like an output, whatever it is, whatever that good, it could be a good output. It could be a bad output. And it's not even

[00:38:35] Gil Broza: just the people, even stuff that happens within your process. Let's say a lot of defects escape to production.

You might say, well, Um, Let's look at how many defects are by developer A, and how many defects are by developer B, and maybe we have a weak link there. Now, that might be true. Not arguing that, but it could also be that defects escape to production because of other things that you do. It could also be the technology you're using.

It could be the [00:39:00] tests that you write. It could be the go, go, go pressure, so we never actually finish things properly. So we might have really good developers who would otherwise do really good work, but in a hamstrung.

[00:39:14] Dan Lines: Yeah, totally makes sense. All right, Gil I think we have time. If you have another one for one more pitfall, and then we're going to, you know, start wrapping up.

[00:39:24] Gil Broza: Okay. So I would also say it's really the whole thing about managing in silos, right? So I'm an engineering manager. I manage in my engineering team.

I'm an engineering director. I do the same for my set of teams and same goes for product and whatnot. And yes, that's kind of how the organization is built up. And I get that. But what happens is that people end up, they kind of default to optimizing for themselves. Right? Uh, we have seen the same behavior with Scrum Masters and Agile coaches who, who basically say, you know, the organization's not going to go Agile, but I'm going to do the best for my team.

I'm going to remove all the impediments so my team can be great. And by [00:40:00] implication, I will have done my work. And this is well intended, but it's not helping us holistically. Right? Because you may be optimizing for your one team by, let's say, forging great relationships with people outside the team who you need sometimes, like your staff engineer, or your, I don't know, somebody who kind of helps you kind of move things on occasion.

And instead of, you know, getting in line and asking for their time, you kind of get them on the side. But then you're hampering the progress of other teams. And it could be that in the aggregate, You're setting your system back. You mean well, but it's the outcome. And so even though people will continue to have local responsibilities and accountabilities, you want to be really mindful of are you managing, measuring, incentivizing in the local [00:41:00] scope, rather than the system scope.

[00:41:03] Dan Lines: Got it. That's a good one.

How do orgs ensure they don't fall back into old habits once they've made changes?

[00:41:05] Dan Lines: The last question that I want to ask you, so we talked, you know, we talked about your book, we talked about, hey, you can get this first chapter for free, we talked about a bunch of pitfalls, now let's say that I've done my system analysis, I decided that I need to make a change, I brought in Gil, Gil came in, 10 months later, things are, have improved.

How do you think about sustainability the next 10 months after that, or the next year after that? How do I not like fall backwards?

[00:41:39] Gil Broza: So if I have done my job properly, and I like to think I do, then what happens is that your understanding of what to pay attention to is better. Right? You pay more attention to the system.

You, you do the assessment frequently, because at that point it really takes you five minutes every time you do it. So you can see if there's any [00:42:00] backsliding. You have your ears and eyes open, so that you know, um, you can watch for signs, right, and signals. You have also, because you've gotten your system to like a really good level of fitness, you have also distributed control.

We call this empowerment, right? But you've basically enabled more people to take responsibility and behave and act. And together with them, you're all kind of looking at this thing. Okay. You know, an analogy I can think for this is family, right? It's not the same when you've had your firstborn and the kid's a month old, or you're, you have several kids and there are now in their teens, right?

You're in a different spot as a parent. At this point, you kind of know about the warning signs and you know what to look for. That's really the big deal. Okay, I definitely don't want to create dependence on me as a, you know, as a [00:43:00]consultant coach, but not, um, that would not be ethical.

[00:43:06] Dan Lines: Awesome, Gail. So, is there anything else that we should know about, anything that you want to say about your, your book or any, you know, final advice before we sign off here? Okay, so

[00:43:16] Gil Broza: you asked me about, you know, basically how I, I help companies. Because I come from the Agile space, there is something that has become A bit of an expectation in this field, and that is that if you need help improving things, you're going to get somebody to kind of live with your team, like embedded coaching or something like that.

That if you need help, somebody comes in and spends months with your team, several days a week, maybe occasionally talks to senior management. That's an expensive proposition. Okay. Uh, I, I have a different model. My model is you spread your budget over a long, much longer period of time so you can have access to me for months, but you only see me, you know, once every two [00:44:00] weeks, once a month.

You know, it kind of, uh, gets, uh, more spread out as things get better. And that is, it's a different model than what's normal in, in the space. And I would especially love it in our day and age when, you know, budgets are scarce, that people realize that it's not like either they pay six figures for something, or they do nothing at all and they stay with their inertia.

No, there is a middle ground. And the middle ground is super affordable and it makes a big difference. It's like I have a leadership advisory service, stuff like that.

[00:44:35] Dan Lines: That's really cool. And thanks for, you know, sharing that model. It's definitely a different style model than I'm used to and it's a, it's a little bit, uh, refreshing.

Yeah, you know, you

[00:44:46] Gil Broza: just, I know I mentioned the example with that company went from, you know, troubled to really great. I spent a total of 30 half days with them, with the entire company over practically a year. Yeah. 30 half days because [00:45:00] we work online, you know, after doing some initial training and an initial assessment.

And that was it because I work mostly with leaders. And so, you know, things don't move on a daily basis at that level.

[00:45:11] Dan Lines: Yeah, I love that you have the, uh, cost in mind, the long term efficiency in mind, and Gil, you know, thanks so much for joining us today and sharing all of, you know, some of the, I know we only got to like some of it, but some of the knowledge that you have, and I highly recommend that everyone goes and checks out Gil's, book.

Uh, where can listeners find your book? Uh,

[00:45:35] Gil Broza: so it's

sold pretty much everywhere, both electronically and in print. For people who are not keen on paying Amazon, there's Barnes Noble. Uh, the digital formats are everywhere. Uh, you can get them on my website,

[00:45:48] Dan Lines: Excellent.

And listeners, if you haven't yet, consider checking out our Dev Interrupted YouTube channel to watch this episode and tons of behind the [00:46:00] scenes content. Thank you everyone for listening and Gil again, thanks for coming on the pod.

[00:46:04] Gil Broza: Thank you so much.