Deliver Better Results: How to Unlock Your Organization's Potential | Gil Broza

0:00If 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. Gartner just released their market guide showing that software engineering intelligence platforms help engineering leaders significantly improve both team productivity and value delivery.

0:41Through Gartner's in-depth analysis on the critical features of SEI 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 SEI market guide. Head to the link in the show notes to download your complimentary copy and learn how you can unlock the transformative potential of software engineering intelligence for your team. Hey, what's up, everyone? Welcome to Dev Interrupted. I'm your host, Dan Lines, Linear B COO and co-founder. And today I'm joined by Gil Broza, author of the book, Deliver Better Results.

1:21Welcome to the show, Gil. Thank you so much for having me here. it's really cool having you on and we were just chatting 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 we know that you wrote this incredible book we're going to get into the book, but can we hear a little bit about you, your background, what you're all about, your career, and then we'll dive into the book.

2:05I 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 the way of working because we work on the three pillars of effective product development thinking in systems putting people first and being intentional about mindset like i said it's been about 20 years 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 i work primarily with you know u.s canada and europe but that's i want to help the entire world so 15 years ago you started you said like independent practice your own your own business yes which is intentionally unaffiliated non-certifying giving my clients the best that they deserve and not just somebody else's ideas Very cool.

3:10And what did you do before that? Previous to the 15 years ago, you start your independent business. What happened before that? 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 able, 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. Gotcha. Yeah. So, you know, early, early 2000s, lots of companies, I think maybe thinking, well, I mean, that, that may be, may be even the timeframe where it's like agile is a little newer.

4:01Like 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 I, what it sounds like. Yes, 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.

4:41Yeah, that's a ton. And we're going to have to unpack. all of this stuff. Exactly. Or as much as we can in this podcast. So let's start with this. So your book, Deliver Better Results. Who is your intended audience? Who should read this book? It is 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. So it is written also for the very busy CTOs and VP Engineering. Although I do expect that we'll have all roles and seniorities read it. Okay, cool. And can you give us a little bit, I guess, an overview of the book or, you know, some of the, like, what am I going to find there in this book?

5:32Okay, so what you're going to find there is a focus on something that actually 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. 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.

6:20And the book provides something that's been missing in our industry, which is a roadmap to improving and optimizing that system. oh that sounds cool yeah because the industry has offered a bunch of target states like you know scroll or safe right without actually saying how you get there and they may not be right for you right 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.

6:56So what I offer there is really two kinds of things. One is how do leaders behave and speak and enable and support in order to make improvements possible and sustainable? And the second thing is a set of 10 strategies, sequential and incremental, to get there. 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? 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 some form of vertical, a program.

7:43They'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 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 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. 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.

8:23Oh, yeah. It seems like you do maybe like small chunks of teams or like system by system. Is that the way to go through the change management process? 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, and again, for all of our listeners, everybody is working in one specific system. to think of your product or solution as if it were a movie. And think to the end where the credit roll is. It's like, well, who contributes to this movie? Who makes decisions? Who enables? That whole list of people. That is the scope you're working with.

9:02So both ACs and their managers, it's not going to correspond neatly to the org chart. 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.

9:45Decisions have ramifications throughout the system and not just in a linear fashion. So there is a stream here and that work keeps coming in and we keep delivering. But what happens inside is more like a network than a stream. That's really 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. Or some would say even complex, right? Because it's really hard to predict all the results of actions. And so the book really encourages readers 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.

10:31No, 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. Okay. 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 for free. It's called The Big Picture.

11:14Right. And I just have a little blur 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 heard on podcast dot deliver better results book dot com. Of course, we'll include that information. 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 right to start there yes 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 I just read chapter one it's 20 minutes you'll know the main thing so for instance one of those things is that when we want to deliver better results.

12:05What we're really targeting is for the system to work better. And what we're hoping to increase is that system's fitness for purpose. How well does it help the company achieve its mission and objectives? 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 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 dig into that and give the specifics and ideas and whatnot without prescribing anything That's really cool, actually, because what was on my mind is, you know, we talked about the system.

13:08We talked it's a network. We talked maybe it's a little complex. How do I identify like my current state? Do you have a process that I can go through to even like think about that? Absolutely. And I've really taken pains to explain this in the simplest language possible, right? Because I'll tell you this, almost every treatment of system thinking that I have come across, it got really technical and jargon heavy, and it felt like a lot very quickly, right? 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 really sticking, the changes don't stick, or you get unintended consequences or you just get too much business risk.

14:07Okay, 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 VPN, VPN 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 crown blossom. 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.

14:48That'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 help my career? is this for me like uh you know everyone wants to have a great career journey of course 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 okay so i treat every reader of the book as what i call there an improvement leader and what this is it really goes back to one responsibility that leaders have And by leader, it can be really anyone from team lead or scrum master or coach all the way to C-level.

15:35And, 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 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 effectively.

16:13And this will help your career because 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. 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 type of thing.

16:58Yes. Which I always 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. Yes. And one super important thing is that we want to manage the whole. But usually when we work, you know, work never stops. There's all the more to do. Always more planning, always more this and that. it's very easy to lose sight of something. So for instance, we might be, 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.

17:35What 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 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. That's really the angle this book takes. That's really interesting. I want to dive in there. So we're talking about engineering and product relationship. One of the most, I think, also complex relationships. What have you seen there? Some of the pitfall, like you've worked with companies, what are the common issues you see with that communication?

18:16Right. 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. We're not wanting to be seen as a troublemaker. Another one is really kind of let specialists do their thing. So let product do their product thing and let engineer do their engineering thing. And without realizing that nobody's choices are entirely context-free or ramification-free, right? Again, the system. So I can tell you where I've been, where results were really, really great.

19:03There 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 had trust. They collaborated to some extent. They made it possible for everyone in their respective groups 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, you know, a counter example to that is from way back before I started, you know, kind of coaching in agile context.

19:53I was leading a server development team and my manager was awesome in terms of, you know, empowering me to do things. 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 counter-frives, and he would talk to his people. And like, seriously, these people are sitting across the hallway from me. That made no sense. And product? Nobody even talked to them. They just gave us documents, right? Now, this is, of course, old pool, but I see the same dynamic continue to play out these days still.

20:28And part of it is the pressure that everybody's under. The race to be dominant has not relented. 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 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 just product management calls, UX calls, and engineering calls. It's everybody's calls, including the VP who deprioritized something.

21:08Yeah. 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. And yeah, 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 you see maybe most often leaders are getting wrong? Hmm.

21:52Like in terms of, you know, unlocking organizational potential. Yeah, exactly. Okay. So I'm going to start with my pet peeve. 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 got three, can we trade? We're not thinking of them as people. We're thinking of them as units of labor.

22:28and when you know by extension the entire company works this way then 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 thing. That's a great one. Yes. And also, by the way, as long as people are resources, then the whole thing that we say about, you know, collaboration or trust or safety, it doesn't matter.

23:10It doesn't matter. Yeah, it's dehumanizing. 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 nowadays I think things are a little better, but not enough. So, okay. Another thing is 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 like a babble. 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 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 and organizations, for the most part, is that they don't have an explicit and intentional mindset choice-making, right?

24:25They 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 bunch of stuff. Okay, and so if you want to deliver better, one very basic thing you need to do is basically define how do we want to be around here?

25:10not 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, 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. Yeah, that's interesting. Because it's cool to say, yeah, we're innovative. Of course, it has to be. We're all innovative. Or we're collaborative. If you're not innovative, you're looked down upon. Or, you know, you wouldn't say, no, we want silos here.

25:43We 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, reverse engineer the 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. I think the mindset thing is always, like you brought it up, it's a tough one because it sounds very soft or maybe out there.

26:23But 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 direction of mindset yes 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 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.

27:09Do you have any tips between a product engineering company organization that helps with that? Once you have the mindset that you want, like how do I actually roll that out? 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 forever 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 and whatnot and 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 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 and 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 by being explicit and in a lot of companies they don't have that i'm gonna go through this assessment in your book and understand my system and my network a bit right and then eventually i'm gonna 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.

29:15Have you found that like an engineering leader or a 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 have you seen? Well, look, obviously I am biased because I am the outsider, right? 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 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 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.

30:32You 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 pay enough attention to what I say or they think I'm biased. Yeah, I think that's a good, like, thank you for sharing that. I think that's like a really honest assessment. What I would say what caught me the 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.

31:16That'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 ahead. Exactly. And that's exactly the value proposition I go in with. And it'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.