#160 - Deliver Better Results: How to Level Up Your Value Delivery System - Gil Broza

[00:01:39] Episode Introduction

Henry Suryawirawan: Hello again, my friends and my listeners. You’re listening to the Tech Lead Journal podcast, a podcast on technical leadership and excellence. If you haven’t, please subscribe on your favorite podcast app to get notified for new episodes. Tech Lead Journal also provides bite-sited contents on LinkedIn, X, Instagram, YouTube, and TikTok.

My guest for today’s episode is Gil Broza. Gil is an Agile leadership expert and the author of the latest book “Deliver Better Results”. In this episode, Gil discusses ways to level up our value delivery system to deliver better results. We first delve into the fundamental concept of systems thinking and cause effect relationships, which are exemplified by reinforcing and balancing loops. Gil also explains the importance of ways of working, particularly on shifting mindset and focusing on people first before the process. Gil then explains the SQUARE Model detailed in his book, and how we can use it to assess our fitness for purpose by understanding the distinct levels described in the model. He also shares some of the 10 strategies from his book that we can use to enhance our fitness level and deliver better results.

I hope you enjoy listening to this episode and learning a lot of insights to improve your value delivery. Remember to share it with your colleagues, friends, and communities, and leave a five-star rating and review on Apple Podcasts and Spotify. Now let’s go to my conversation with Gil.

[00:03:14] Introduction

Henry Suryawirawan: Hello, guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I’m sitting here with Gil Broza. He’s the author of a book titled, “Delivering Better Results”. So, I’m sure all of us here want to deliver better results, right? But sometimes it’s very hard and challenging to know how to deliver better results. So today I hope we’ll be learning a lot more things about how we can deliver better results in a systematic way, right? So Gil, welcome to the show.

Gil Broza: Thank you for having me.

[00:03:43] Career Journey

Henry Suryawirawan: Gil, I always love to ask my guests to first introduce themselves by telling us about highlights or turning points in your career that you think we all can learn from.

Gil Broza: Okay. I started like many people as a developer, then became a manager and that was my exposure to the significance of process and the significance of collaboration. And after moving a couple companies, I discovered also what’s the difference between a loose and simple process and a big and heavy one. And I really didn’t like the big and heavy one. So I that’s around the time I discovered XP, eXtreme Programming, and I really got into that. And the turning point for me was when I decided to make this my full-time profession, became an XP coach, right? At the time, nobody said Agile coach. It was just XP. And, uh, I got exposed to so many interesting companies at all sizes. We didn’t even use the term scaling back then, but I had some really large clients. This became, you know, my work of a lifetime.

And then a turning point for me was when I realized that I approached my coaching work and the advice I give clients in a different way than most. I really emphasize the human side. So yes, there is process, there are techniques. I taught test-driven development. I paired up with developers. I did all of that. But it was all about how we engage as a group in the creation of value. And so that ended up being my first book, “The Human Side of Agile”, which was pretty unusual for its time. 2012 or so.

So that was a big turning point to the next one was when I realized that another aspect of what I do is to help people be cognizant of the choices that they make. And how, you know, you can execute the exact same practice, like continuous integration or story point estimation, or any of those things, you can execute with one mindset or different mindsets - basically choices. And you get totally different outcomes. That turned into the second book and into some really super interesting clients. And since starting, I’ve worked with about a hundred clients, so I’ve seen so much. I’ve seen the good, the bad, and the ugly. I’ve seen the big and the small, the fascinating and the boring, I’ve really seen it all. And I really love this angle or, uh, perspective that I have on our industry. And this has really turned into some of my newest work, which is what we’re gonna be talking about today.

Henry Suryawirawan: So I think it’s very interesting, right, when you have coached so many different clients, right? Big, small, fast moving, slow moving, right? I think you’ve seen a lot of patterns. I’m sure today we’ll be learning a lot from you today.

[00:06:25] Deliver Better Results

Henry Suryawirawan: So you wrote this book, “Deliver Better Results”, maybe a little bit of background story. How did you come up with the idea? What kind of problems are you trying to solve in this book?

Gil Broza: So like I said, I’ve worked with about a hundred clients, but I’ve spoken with a lot more companies. So, you know, a VP will call me up. Or a director, CTO, they’ll say we need some help here. So I do discovery calls and I really learn how the companies work and what’s getting in their way. And I found it a little bit difficult to articulate what exactly needs to be done now without doing a really serious assessment. To really understand the lay of the land, what’s connected to what, what’s affecting what, and so on.

And, you know, a lot of the clients I work with, they do actually start with an assessment. And they pay for it and they get, you know, basically we strategically design the next few steps. But I was looking for something that would be quick and simple. So quick and simple that an executive can, you know, in 10 minutes figure out we are doing this well, and therefore we need to do A, B, and C to level up. You know, think about it, uh, like in terms of health. We can step on the scale and we can weigh ourselves. And that is, I mean, we get a precise number. But what matters is like what range it is in. And based on the range, we can sort of understand, you know, how well we’re doing. And even that is a partial metric. But it’s sort of a starting point.

So I was looking for something that would be this simple. And at the time I didn’t even have a term for this ‘how well we’re doing’, and even what is we. Because I come from the Agile space where for the longest time our focus was the single team. And then the focus became the bigger teams and like, you know, scaling frameworks and whatnot. But when it comes to creating software, when it comes to delivering value, more people are involved in that. The analogy I give to this is like, you know the credit roll in a movie, right? Yes. It starts with the producer and director and actors and the writer, but there’s a million more people And every little decision they made had an impact on the end result. Even the people who took care of the catering, right? Because, you know, hungry actors probably don’t perform as well as they do when they’re not hungry.

So I was looking for a way to describe this construct that creates value. And a way to understand what I learned came to term. It’s fitness for purpose. So in the book I talk about the value delivery system. And that’s a whole bunch of people – if you’re in a product company, and I think a lot of the listeners of this podcast are. You’d have product people and engineers and SREs and UX and whatnot, content. And it’s all these people and all their managers who make decisions and how they work so that at the end your customer is able to do something different. So that’s a system of value delivery.

Now, we do have terms in the industry. There’s like value stream, but in many cases it’s not the complete system. It’s a portion of it, at least, that’s what I’ve seen. I’m sure there are exceptions. And when we say value stream, we sometimes blind ourselves to the fact that some dependencies go backwards. It’s not a sequential flow, whereas a value stream sounds like everything kind of goes downstream. So everything is connected and that’s the concept of system from system thinking. And then I came up with the definition of fitness for purpose. And you know, it took me a few months to figure out what I was doing here. But then I came up with this model and I was able to say, you know, here in 10 minutes, literally 10 minutes, I can have a conversation with you or you can do it on your own. And you can say, well, we are at a level two, here’s what level two means. Or we are at a level four, here’s what level four means.

And the amazing realization I had is that this is not really a lossy calculation in the sense that, oh, I’m level two, okay. Anybody could be level two, then what? No, if you’re at a level two, sustainably so, you really need to do these couple things, what I refer to as strategies, to level up. And I tested this with so many people, and it seems to work. So this has been the background in how it evolved. So I spent about a year doing all of this and trying it out, and then another year writing the book. And of course, any of the process, it evolved even more.

Henry Suryawirawan: Right. Thanks for sharing this story, right. So I think it’s pretty interesting. I mean, you know what, just a couple of months back, I was trying to do the same thing, right? So assessing how my engineering team is working in the company, right? And trying to get, so-called the maturity model, I call it, borrowing from like CMMI or maybe all other maturity model out there and trying to assess level one until maybe five, right? And also figuring out like what kind of practices that maybe, level one versus level five should be different right? Um, think it’s pretty much the same idea. And I think, uh, when I read your book, some concepts really resonate with me.

[00:11:15] Systems Thinking

Henry Suryawirawan: So I think the first thing is about value delivery system, right? Some people call it value stream as you mentioned. But you emphasize a lot about the system aspect of the value delivery system. Tell us a little bit more like why some people seems to not get this idea, you know, like software engineering is a sociotechnical problem, some people say, right? It’s system thinking instead of thinking in parts. So, yeah, maybe elaborate a little bit more.

Gil Broza: You know what? I don’t think it is that people don’t get it. I actually think that a lot of professionals in our industry definitely get the concept of a system. We see it all around us. We know vicious cycles when we see them. Or maybe when they’re pointed out to us. But we know what that is. We know virtuous cycles. We know about feedback. Feedback isn’t just, you know, customers saying yay or nay. Any type of thing is a feedback. A failing test is a feedback. So we get it.

But I think we have such a history of working sequentially, functionally, handoff, throw over the wall, right? Our organizations are structured this way. And the way the organizations are structured, somebody who could be, let’s say director of engineering, right? That’s somebody with authority, right, in the span of authority, but they don’t actually have authority over the entire system in most cases. Because there’s product people and there’s the designer. And there is maybe a marketing person who also participates in deciding what to work on or whatever. So I think it’s also what we’re used to and what we perpetuate through the org structure and the management ethos.

But I have seen so many exceptions. One of my clients, I love them. Their VP Engineering and the VP Product, yes, they owned the separate groups, but they always traveled together. I actually tell the example in the book, right? Every time I met one of them, the other one came in. And these are busy people, right? And they had this understanding that neither one would do something to surprise the other. Cause, you know, it’s hard to coordinate schedules. So that’s an example of how you can manage, even though you have more than one person in charge of the place.

Or generally, you know, simply making decisions while, you know, consulting with your colleagues, right? So for instance, uh, you might be an engineering manager and you want to turn out better code, okay? Better quality code. That’s useful, right? But we live in a system meaning that whatever you decide will have ramifications. If you decide to regression test everything, obviously, that will slow everything down, right? If you constantly regression test, you can be writing a ton of unit tests. That’s good, assuming the unit tests are good. But even then, if you’re not being strategic and you’re unit testing everything ‘cause you want 100% coverage, that’s gonna slow things down, because you’re gonna apply some of your effort to things of low value and low change.

So for the most part, we just need to be aware that we operate in this type of environment. Which is why in the book, whenever I explain system thinking, it’s in plain English. I don’t draw diagrams. I don’t talk about all sorts of amplifications and this and that and whatnot. Because I don’t think people need too much theory. It’s a pretty straightforward concept.

[00:14:15] Reinforcing & Balancing Loop

Henry Suryawirawan: So I find also very exciting whenever I read about systems thinking, right. So I think if more people read about this concept and some examples, typical examples in software engineering, I’m sure they will all get it. There are two things that I want you to try to explain a bit more. So this concept of reinforcing loop and balancing loop, I find it is also very, very insightful, especially for people who don’t know about the terms, but I’m sure when they experience the situation they will get it right.

Gil Broza: Yeah. So reinforcing loops is when you do something and that creates a response and that response maybe triggers another response and so on until it kind of comes back to you, okay? And it comes back to you and it reinforces something that you are trying to do. And it may not be positive, it may actually be negative. So when we think about increasing psychological safety, for instance, or having people collaborate more, that’s usually a good reinforcing loop. In that it creates positive effects, but it doesn’t end with those effects, that again, it kind of cascades down and creates more positive effects, for instance, in engagement. Okay?

Balancing loops push back against your change. The example I gave in the book is really with in terms of like, again, writing unit tests. Writing unit tests is the type of thing that most tech leads and engineering managers that I know, they think it’s a good thing. And it is a good thing, but somehow it tends to die. This idea tends to die in organizations. Now why? Because it pushes against all sorts of things, such as when is this feature gonna be done, right? And I need you to deliver now. I don’t need to worry about the future too much. And all sorts of system forces which basically manifest in behaviors and meetings and complaints and escalations and whatnot. And the loop here is that eventually the pressure comes back to the people who want to write those unit tests and they say, you know what? Maybe not this time. And maybe not this time. And before long the idea dies.

Henry Suryawirawan: Right. Thanks for explaining those two concepts. I’m sure if people listen, they would get it, right? So this kind of reinforcing loop and balancing loop.

[00:16:24] Ways of Working

Henry Suryawirawan: So another thing in the book you mentioned a lot, apart from just looking at the system holistic level, right. So you mentioned ways of working. So maybe touch on a little bit like why ways of working is very, very important for delivering better results.

Gil Broza: So if we want to deliver better results, what should we do? We can tell the team, deliver better. Here’s the metric, raise it. Increase it, increase your velocity, reduce bugs, uh, I dunno, whatever. We can slap goals on things. We can say by next year, 20% increase in productivity. Okay, so how do we achieve that? By working harder, by typing longer, by doing what? We need some model that says what improvement looks like, but we also need to focus our attention on the things that matter. And the way to do this is by changing the system.

Now, what does it mean to change the system? So, like I said, you know, the system is a whole bunch of people and their ways of working. So we’re not changing the people, unless it’s an extreme case, of course, but we’re changing how we work. So we change the process, we change practices, we change team structure, we change how we make decisions. We change what we commit to. We change who makes which decision. Things of that nature.

A way of working is basically made up of two things. One is all the tactical stuff, practices, processes, roles, tool usage, meetings, artifacts like backlog or whatnot, and the choices that we make in their use. So if I use the backlog as a short, small holding place for good ideas and I update it frequently based on new information, that means I’m using it with a, probably, an agile mindset. And if, uh, instead I use the backlog as a holding place for everything that management wants and nothing’s coming off the backlog, and we’d like not to put more things on it and whatnot, then I’m approaching it with a more traditional mindset which kind of equates the backlog to a project plan. So that’s why I never talk just about process, because process is meaningless without the choices that we make in the use of it.

So a way of working is both the choices which is what I refer to as mindset. It’s not some loosey goosey psychological thing. It’s simply a collection of what we value, what we believe in, our principles for action. And those tactics, both of them together. So if you want to deliver better results, you need to do something to your way of working. Maybe you keep the process constant, whether you change the structure. Maybe we go the other way. Usually, we do both so that we engage with the work differently and, you know, we take inputs, we convert them differently to outputs. That’s basically what it is.

[00:19:08] Mindset: Values, Beliefs, Principles

Henry Suryawirawan: I think I assume many people when they do this kind of transformation or maybe changing the productivity, right? They focus a lot on so-called the tactical aspect of what you mentioned, like processes, team structure, maybe new leaders coming in, right? But they probably, they seem to neglect a lot on the mindset part, right? What you mentioned values, beliefs, and principles. So why should we consider a lot more on the mindset, maybe a little bit here? How does the values, the belief, and the principles actually work in the way of working?

Gil Broza: Okay. So the way it works is that we choose what’s important to us in the doing of work so that we’re successful. Historically, those are the values. Historically, what we chose is predictability. We chose standardization. We believed that, that’s the other component in mindset, we believed that we can have a process or workflow or whatnot, SDLC, that will guarantee success no matter which person carries out the activities. Because people come and go. And maybe we need contractors or we hire or we fire or whatnot. But people were the variable, the assumption was that process can be the constant. Okay. So that’s an example.

Agile comes along and say, no, we value adaptation. For us, adaptation is so, so important that we’re gonna reflect it in everything that we do. Now, why do we value adaptation? Not because somebody said so, or because it’s popular, but because if we don’t adapt, we’ll die. If we don’t adapt, we’ll fall behind. If we don’t adapt, we’ll get disrupted, whatever. So the values are, again, what we are optimized for and the beliefs are sort of what we take for granted or what we think is true. And they give rise to everything.

So the third component in mindset is principles. For instance, collaboration, self-organization, transparency, psych safety, deferring decisions to the last responsible moment–that one’s from lean, organizing functionally, handing off, sign-offs. All of these are principles. So nothing in what I described as a practice or a tool or a procedure. It’s something that permeates everything that we do. So, for instance, if we want collaboration, it’s not just between two devs. We want collaboration between, uh, product and engineering, between IT and business, between us and customers. And if we have too many customers and we need go-betweens, let’s at least collaborate with the go-betweens. So these principles permeate everything that we do. So the way it works is values and beliefs give rise to our choice of principles, which in turn kind of determine which tactics we will actually be using and how we would be using them.

Now, just going back to something that you said before you asked me the question. I don’t know that people necessarily neglect them. I think for the longest time people were not aware that that is the role that values, beliefs, and principles played. And one reason for this is because for decades we’ve been taking things for granted. Again, those are beliefs. For instance, we believe in 10X developers. We believe that if every specialist or expert does their part, the result will be great. So hire the best, right? And if you do any system thinking, of course you realize that there’s more to it.

And the other thing is those values, they’re invisible. So yes, organizations talk about values, but they talk about cultural values and they put them on a wall in a poster. But those cultural values don’t actually say anything about what matters when it comes to doing work. So yes, we can be inclusive and diverse and whatnot, and yes, we should be, but how do we carry out work? Are we being adaptive? Are we being predictive? Are we being collaborative or are we being siloed? We’re optimizing for something. We’re optimizing our way of working to achieve certain effects.

And nobody thought this way. Because for decades, we optimized for the exact same things, the predictability, the standardization, the making early commitments, and be on time and on budget. That’s what we knew. And in a lot of organizations, that is sort of what management still optimizes for, because their boards pressure them and there’s a whole mess there. But fundamentally, there is just three, four, maybe five of those values that govern your entire value delivery system. Be aware of them. Choose them intentionally and be explicit. And sometimes that’s all you need. Honestly.

[00:23:22] People First vs Process First

Henry Suryawirawan: Yep. So I think I’ve been there as well in multiple companies, which are doing transformation, right? They seem to get a new leader, put up posters, here are new values, here are maybe, you know, new whatever that we are adopting, right? And let people follow. So I think what you mentioned here is sometimes like the people aspect, right? Because changing human is actually very difficult, right? And no one can predict. So maybe a little bit more on this concept, right? You put people first versus the process first. How can leaders be more intentional and be more conscious in the decision to put people first?

Gil Broza: Okay. So first, let’s define this. What does it mean to put people first? What’s second and what’s third? So typically, nowadays, the understanding is and that is by the way, aligned with the Agile line of thinking, is that people are first, product is second, and process is third. Now, that doesn’t mean that we don’t care about process. It doesn’t mean that we don’t care about product. But what it implies is that if we take good care of our people, if we’re being good enabling leaders, we draw good boundaries, we trust there’s safety, there, there’s a whole bunch of stuff there. If we enable people to bring their best selves to work and all, all, all this good stuff, they will take care of the product. And they will come up with a process that makes sense for the making of this specific product. So that’s what that means to put people first.

Again, historically, we put process first and product second and people last, which is why every person is a resource, right? If we’re standardizing, then we’re standardizing people too. Headcount, FTE, buzzword resumes, and all of that stuff. We’re standardizing people. Now, we can believe that that’s legitimate, because the entire industry is doing it. We can believe that that’s a useful way to go, or we can believe something else. And there are many, many leaders these days who believe something else that if you trust and enable and support and catch when they fall, but you still lead, right? You’re not a pushover. You still lead. You give direction. You show what good looks like, and, and all of that. This tends to create better results. And we see this in engagement scores and in product success and in retention in a whole bunch of things.

Now and even that, I say, well, you believe this or you believe that, but even that is a little bit black and white, because there is context. I may believe that my team - let’s say I’m a team lead - I may believe that my team means the best. But I may not believe that they could actually pull off the entire work, because maybe they’re all juniors. Shouldn’t be this way, I know, but maybe that’s how it is. And so I may need to support them more, look over their shoulders sometime, trust and verify, and all of that so that they’re actually more successful.

Henry Suryawirawan: So yeah, I think, or what you speak just now is really, really true, right? Leaders should care about people more, right? Every decision that leaders take, I think they should also think about the implications to the people, because most likely the people are the one who get affected.

Gil Broza: Yes. And by the way, when we say people, the typical interpretation is the team, because that is the unit we typically talk about. But managers are people too, in case we haven’t noticed. Customers are people too. They have complete lives and wants and needs and frustrations, and they would really love not to have to use our product. But, you know, the good outweighs the bad. And our C-levels, they don’t get it, but they’re people too. They have fears, they have wants, they have constraints. So that, that’s really what it means.

Henry Suryawirawan: Yep. Thanks for the plug here. I think it’s very important, right? Don’t think about people as just the employees, the staff who are working on the problem, right? But also think about the managers, the customers, and also the executive leaders, right?

[00:27:08] SQUARE Model

Henry Suryawirawan: So for delivering better results, apart from system thinking, improving ways of working, I think the most important thing also, like coming up with a model or framework for people to follow, right? It’s like a playbook some people say. And in your book you mention this model called SQUARE model. Maybe let’s go through your model and maybe elaborate a little bit more. How does SQUARE work? What are the kind of the that we can learn from this?

Gil Broza: So SQUARE is basically the entire subject matter of the book, and it has several components. One of them is, first off, the realization that we care about the fitness for purpose and we want to improve it by, you know, upgrading the ways of working. So one of the components is what is fitness even made up of? Cause it’s pretty vague. I mean, even think about fitness of physical body, right? There is agility and speed and flexibility and there’s a whole bunch of stuff there, it’s not just I’m fit.

So I define six aspects of fitness which, contrary to a lot of what I saw out there, is not about how well you track to a particular process framework. How will you do Scrum? How will you do SAFe? How will you do this or that? But for your system to be fit, it needs to have its kind of outward looking aspects at a certain level. It’s throughput of delivery, the outcomes it accomplishes, the timeliness of its deliveries, how adaptable it is, how consistent it is, and how cost efficient, actually. All of these are aspects of how the system helps the company achieve its mission and objectives, which is really how I define fitness for purpose.

And so part of SQUARE is also a fitness assessment tool. We can already say this spoiler alert here, right? That the listeners are gonna get it, right? This fitness assessment tool. Super simple. It takes 10 minutes. It’s, I don’t know, 15 pages in the book, because it’s like mostly examples of how to use it. Very simple. You don’t need metrics, you don’t need data. And in 10 minutes, you kind of rate how these aspects are with relation to what’s optimally possible for your system. And out of that you get one of five levels.

So fitness, I discovered it kind of grows along a scale of five levels, 1, 2, 3, 4, 5, uh, which are really characterized by, again, how well it helps the company achieve its objectives and mission. For instance, a level two system, and those are, I think, the most common, a level two system helps achieve the objectives, but it’s not effective or efficient enough. Or at level three, results are satisfactory, but they’re really dependent on just a few people who make all the big decisions. So it’s sort of defined by the risk there.

Another element in SQUARE is once we know the level, what do we do? And there are 10 strategies. And what’s really groundbreaking about this model is how it sequences the strategies. Because you know, our listeners, when you hear about them or when you read about them, many of them won’t surprise you. But the cardinal sin that we commit all the time is that we overwhelm teams with change. We put people in cross-functional teams, and we give them the boards, and we expect this type of velocity, and we want to write our unit test, and everybody’s in meeting and planning together and whatnot. And I’ve been guilty of doing the same thing for years in terms of, you know, just creating a whole lot of change at the same time. And human systems, sociotechnical, like you said, they have limited capacity.

Now, that brings up something interesting. A lot of leaders know that, you know, you don’t build Rome in a day, right? So you do have to choose what to do for a second, third. And what this model says is, what is the sequence of doing things? For instance, to get from level two to level three, one of the strategies is to stabilize the system. To use Deming terminology, it’s to reduce the variation and eliminate special causes. But it’s more than that. It creates realistic expectations for, you know, how inputs transform into outputs are, how your requirements and projects and epics and commitments and roadmaps. You know, kinda when and in what shape will you get things, right? So if you can have, you know, a sort of good balance there, your system is stable.

Okay, well, how do you do that? Well, there’s plenty of good ideas from Kanban, from Agile, from Lean. The nice thing is they all fully apply, even if you use waterfall, which is not a bad word. But what the model says is you do this at level two, you don’t do this when you’re level one. At level one, before you ever got to level two, you had to manage your project portfolio strategically, meaning you cannot overwhelm the teams with too much work at the same time. So you can limit WIP and visualize, and again, common ideas, but you first have to limit, again, your portfolio WIP to really manage it to capacity, manage it strategically, and only then all the team level stuff that everybody does like with their Kanban boards and their lead times and this and that, only then it would even stick.

We kind of do things backwards, because managing the project portfolio takes a lot of work from senior managers and a lot of accountability and a lot of saying no and not yet. And, you know, it’s tied to managers objectives and OKRs and what have you. So it’s sort of easy, hey, teams, you just do this thing. But it won’t matter as much. It won’t stick as much. It’ll quickly kind of degrade if the teams keep getting overwhelmed and you keep reprioritizing and you keep running escalations. So there’s 10 strategies in all. You need two to go up from level one, two from level two, three from level three, and three from level four.

But the other big deal is that you need to apply them across the system. It’s not gonna be any good just doing something in your engineering teams. Even if you have cross-functional teams and in every team you got the product owner, let’s say. Let’s say you have five teams and you have five POs, right? So it’s like textbook Scrum. If all you’re changing is how the engineers behave, or some of the choices they make in terms of producing good code, but the POs still act in a bit of a different way or like how they acted a month ago, you’re gonna run into trouble and you’re not gonna get the improvement that you’re looking for. You might get some temporary improvement, but because of those balancing loops, things are gonna fall down pretty quickly.

So we gave… what example did we give for…? Unit testing, how that idea dies. Another idea that dies on the product side is experimentation. So we might have a product manager say, we need to experiment and do A/B testing and let’s buy this platform and do feature flags and whatever. But if management still wants you to commit to a lot of things, if your reward structure has to do with executing on a backlog as opposed to proving what should not be done, if you still measure velocity on things, but experiments, we should measure them differently. Then, you know, people respond to the pressures from the environment. We might think of pressures as incentives or constraints, but it’s pressure. So we need to make these changes. And all of these 10 strategies are very much about changes that we make across the system. And the way we carry them out is by having leaders just work with each other. It’s that simple.

Henry Suryawirawan: Thanks for the overview of the SQUARE model, right? I’m sure it’s a lot for listeners to you catch up. But don’t worry! Gil later on will share the summary of the book, right, also give you the free assessment, so that you can understand where you are in your current situation and what kind of levels that are out there for you to aspire to.

So you touched on a little bit more about a few strategies, right? There are 10 strategies in total for the book. So maybe we won’t be able to cover all of them for sure, but maybe we can cover some more.

[00:34:36] What Matters Most

Henry Suryawirawan: So the first you have already mentioned about managing the project portfolio, right, with greater strategic control. So in a sense, some people also understand this like limit work in progress, right? Not to have too many in the company at the same time. And then the second strategy is actually to design way of working based on what matters most for achieving the mission and objectives.

Gil Broza: Oh, my favorite. This is my favorite. So what’s the big deal? So we talked earlier about what the way of working is, right? So again, the minds, the tactics, structure, process, isn’t that? Companies will sometimes restructure, sometimes they’ll transform, they’ll hire a, let’s say, middle manager or senior manager who says, hey, I know how to do this stuff, and, you know, creates a new structure and creates a transformation and a journey and, and whatnot. The question is, what is the target state? How will we come out of this? What structure will we have? What process will we have? How will we engage with each other?

What I suggest in the book, and this is really how I work with clients is, you want to design this rationally. And if we go back to what I said before, values, beliefs give rise to principles, give rise to tactics, you basically follow this flow. You articulate collaboratively what we should be optimizing for if we’re to be successful. You kind of validate this against your model of the world, your beliefs, like what you think is going on here and so on and so forth. This is explained in the book.

What comes out of this is a custom design. This is super different from what I’m gonna say 99% of the world does, which is to go with the popular or familiar or certified or I’ve done this in my previous company. And this is not necessarily bad, because, you know, if you work in a similar setting, then it might make sense to have a similar type of setup, right? But there’s a limit to how similar those are. And so every company is different. You can be a tech company, a product company staffed with super intelligent people, gifted developers, and so on. But they’re different because they’re different humans and you’ve hired them, you know, based on a certain company culture. And your business landscape is different and the constraints that you have are different. And the pressure from the market, the pressure from the board, your legacy situation, all of these complicate things.

So I just don’t see how it’s possible to say, let’s just take Scrum. Let’s just take SAFe. Or for that matter, let’s just take Kanban and start where we are, right? That’s how Kanban does it and sort of iterate our way. I think it needs to be a bit more holistically designed. And let me tell you, this doesn’t take long. This is most of, not most, but this is a step I’ve done so many times with my clients. I mean, you’re looking at like a day or two of work. Seriously. Might be spread out across a few meetings, but that’s it. Now what you end up with might happen to look like Scrum. If that’s a good fit. That’s fine, I’ve had clients like that. Or it might look like nothing in particular. I have had clients like that too.

But the thing is, it’s not a mix and match. It’s not a “pick”, air quotes for people not seeing the video, “pick” best practices and just put them together. It doesn’t work that way. You start by identifying your values and because that’s what will make you succeed, not a backlog in a daily standup. And based on your values, and again, the context for them, which is the beliefs, based on that, you come up with the structure. You don’t need to be a process expert. It helps, but you don’t really need to be one. It helps to have somebody who kind of gets, who has process education or theory in the room, which is really why I make a living. But that’s it.

And the other thing that’s remarkable about this is that you end up with a fairly simple and informal process. Because you start with, okay, values, principles, yeah. So we wanna optimize for adaptation, and we want to really be collaborative with our customers, and therefore we’re gonna do short cycles and we’re gonna do quick reviews and quick and dirty prototypes and, I don’t know, whatever. And then you don’t need to worry about little things like, okay, so what exactly do we need to do our code reviews for? Of course, your code reviews are important, but they will be so easy to do, like to define the standard for code review after you’ve designed the framework, as opposed to saying, no, no, no, let’s look for, let’s google for the most comprehensive code review thing ever, and just plug it in. Or you might realize that doing pull requests slows you down. Because in your context, if you wanna minimize delays, why do them asynchronously if you can just call your colleague over or share a screen and say, hey, take a look. I’m not telling you, I’m not biasing you, take a look and then we’ll have a conversation. That will reduce your delays. That’s the big deal with designing your way of working. And it creates so much engagement. It shows trust and it shows that, you know, autonomy and safety to the extent we have them are for real. It’s a big deal.

But the thing is you will not be able to graduate much past level two if you got there on a shaky way of working. And I see this all the time. Companies call me up and they say, well, so we’ve got in whatever, let’s say Scrum, just because it’s popular. We got Scrum and things are not great. Yes, we have sprints. Yes, we have deliverables every two weeks, but things are not great. And I look inside and I see, yeah, you know, Scrum could be a good fit if it were modified. If other things were in place that bolster that, maybe if we took away a couple things, that’s really all it takes. But instead of being reactive, you can just, you know, take a day out of your, you know, your team’s life and say, well, let’s just design our thing.

Henry Suryawirawan: Right. So I think, um, those two strategies are the key, so-called key strategies, right? For you to move from level one to level two right? So again, just to recap, right? The first strategy is to manage the project portfolio for greater strategic control. And the second one is about designing the way of working that can help you to achieve the company’s missions and objectives.

[00:40:48] Clear Decision Making

Henry Suryawirawan: So after level one, hopefully people have moved on level two. You mentioned maybe most companies are in this level. So there are two strategies you kind of like cover a little bit on the first one which stabilize the system. The other one is about establishing clear and appropriate decision making. So maybe tell us a little bit more about this strategy.

Gil Broza: Yeah. So what happens at when companies… well, not companies, systems, reach level two is they, they tend to have gaps in decision making. Again, this is not to pick on Scrum, Scrum is actually fairly clear, but I’m just saying what I see out there in the wild, you can have a meeting at the beginning of a sprint or a release cycle or something, and you can set a date for a big release. Maybe not just out of a sprint, but something like big and impactful. Okay, so we know who gets to set that date. What happens if we’re midway through the release and we discover that there’s, I don’t know, a ton more work to do and quality is kind of here and there, and we need to shift the date. Who makes that call?

So again, Scrum has something to say about that, but I’m looking at what’s your reality in your specific organization with your specific people and its specific chain of command and culture and this and that. And what happens is that in many of those situations, this example, and there’s a bunch more, they don’t have good answers. Is it the product owner? Is it the director of engineering? Is it the business sponsor? Who is it? Is it all of them together? If it is, does one decide? Is it consensus? How is it? We don’t know. So sometimes we default to things like cultural norms or the chain of command.

The strategy is simply this. Every product impacting decision needs to have a home. So list them out, and if some of them don’t have a home, decide who makes it and how. That’s it. I’m not telling you to decide what consensus and what, what whatnot. Just make sure that they have a home. So we don’t end up in this situation when some decisions get overturned or not really implemented, or they’re just kind of vague, because we just didn’t make them properly. I want you to make them properly and maybe be wrong. This will happen. Instead of just kind, you know, half-assed them. So this is, uh, what you need to do to get to level three.

So level three, again, results are satisfactory, but sort of dependent on a few key people. Now, those key people are usually not a team. They might be a product lead, an architect, a director of engineering, someone like that. They don’t act as a team, but they basically hold the place up and they make all the big decisions. So what we want to get to level four are three things. One of them is to, and this is the beginning of what we do, is to increase the safety and the teamwork and the collaboration. A lot of systems reach level three. They have so-called “teams”, air quotes, but those are not teams, they are groups. They don’t act as teams. Now is the time to fix that. People don’t collaborate enough, not just within their teams, but they don’t collaborate across teams. They go through the hierarchy. We need to fix that. We don’t need to make it a free for all. That’s not the goal at all. But we need to bring it to a point where people feel comfortable to contribute, if something needs done, it needs to be done. It’s that simple.

Once we have implemented this strategy, again, just enough, the other one we want to do is to start deferring commitments and increasing release frequency. So this does not mean that you need to go to continuous delivery. That’s not the point at all. You need to make less commitments to what exactly and how you will deliver when. You need to relax some of these, because the more of them that you have, the less freedom to move you have, which means the less fit the system is.

So this is super situational. If you read this in the book, it’s not like I’m telling you do this, but I am telling you if your, for instance, if your releases are every six months, consider going to every two months or three months. If you release every quarter, let’s say you do SAFe, and maybe you have some big, big release at the end of a quarter, maybe you can also have interim releases. Maybe this is not your situation, so don’t bother. Don’t worry about it. But if it helps you become more fit, do this. So these two kind of go hand in hand, but the big idea is to first defer more of the commitments, because they have ramifications across the company. Every commitment you make, it affects marketing and customer support and finance is gonna care and whatnot. So we need to work with them.

And the third thing is to really engage people in planning. So it’s not just always the same people deciding what gets on a plan. You probably already have teams sitting in planning meetings, like from level two, but typically, what’s still happening is that they don’t actually contribute significantly. And that’s what we wanna change. So you do all of these and, and by the way, every strategy, it’s not like you need to do it to perfection. The book actually says how far you need to go, like what would you see if you’ve done enough so that it’s done its part. So we’re not looking for perfection. There’s really no need. But each strategy does have a threshold. And If you kind of stop before or you don’t really ingrain it, it needs to become second nature, then you won’t be sustainable at your next level.

Henry Suryawirawan: Thanks for overview of the, uh, level three strategies, right? So I’m sure there are plenty of things that people should learn from the book, right?

[00:45:58] How to Get Started

Henry Suryawirawan: Maybe one last before we wrap up at the end later on, right? So people understand about this model. They understand about system thinking now and the way of working, how important it is, how to get started, right? So assuming that all organizations are in the chaotic moment at this point in time, right? How can they start, you know, using your book or using your strategies?

Gil Broza: So you start by getting together with colleagues that are in the system. You make sure you’re clear about the boundaries of the system, so who’s in it. Again, it’s not just a bunch of engineers, it’s also, it’s everybody who is part of making and delivering your product. Again, think movie credit roll. Do the assessment together. Start it on your own so you don’t bias each other, and then compare your notes, because that will show you how aligned you are on how things need to be and how they are right now. And based on the level you’re at, see if the strategies from the lower levels are really baked in. If they’re not, fix that in ascending order. And then turn your attention to the strategies from this level.

Henry Suryawirawan: I think that’s a pretty good way to summarize how we can get started, right? So of course you understand the system first, right? Not just optimizing at the team level.

[00:47:07] The Danger of Metrics

Gil Broza: Yes. And by the way, I know everybody loves their metrics. One reason my model does not use metrics, I mean, it does recommend a few for some things, but it doesn’t rely on metrics to know where you are, like what your current fitness level is. Because nobody has a complete set of metrics that covers everything about system’s fitness, and it is accurate, it’s not garbage and garbage out, and it didn’t get funged and played with. So it’s like, you know, if you look at DORA metrics, they’re awesome, but they’re just one side of your system. They don’t talk about did your features actually make a difference? And are you being cost efficient about it? And how adaptive are you? They don’t, that’s not what they were supposed to do.

So yes, there’s a whole bunch of, you know, frameworks and this and that, but people get into so much trouble and they make such headaches for themselves, trying to get just the right metrics and so on. And I was looking for something that can be, you know, quick and useful enough. Am I 20 kilos overweight or 10 overweight? I could use that information. If I’m 20 overweight, I’ll do this. If I’m 10 overweight, I’ll do that. As simple as that.

Henry Suryawirawan: Yeah, I think we all want to chase for silver bullets, right? And want to have precision, so to speak. So that’s why all these metrics, you know, some people chase for that, right? What’s the industry best practice and, you know, just follow and implement that in the organization. But I think like what you mentioned, right, a system has a lot of dimensions. It’s not just one aspect. And actually capturing metrics is also difficult and could be expensive as well. And in the end it may not be accurate.

Gil Broza: I know. Yes, accurate. But also sometimes partial, right? And there’s something else. Every time you have a metric and it has management’s attention, maybe it comes up in management meetings or it somehow has to do with allocation of budgets or rewards or what have you, people will modify their behavior. Like if you have velocity X, if you measure velocity at all, and you want to increase it, everybody’s going to infer that velocity is important. So they’ll work on increasing it at the expense of something. I don’t know what that is. I know what it usually is, but I don’t know what it’s gonna be in your case.

Or what’s another metric? Escaped defects. Escaped defects are really, you know, that’s a good metric to know, right? The defects that you discover in production. But what do you do about it? Do you use it as a signal for changing the way of working so that you’re better? Or do you use it in a blaming way or in a way to put people on improvement plans or I don’t know what. But every metric is gonna have some form of consequence. And maybe AI can do this for us, but we are not in a position to know what all those consequences are gonna be.

So I’m not against metrics. But I want you to use them with caution. And I want you to have just a few. And I want you to be very careful what you say and don’t say and do and don’t do as a result of the metric. So that’s why, again this model, it assesses fitness. And by the way, also is a relative measure, not as an absolute. It’s not like you deploy 50 times a day, therefore you’re elite. No. Because it could be that deploying 50 times a day is totally useless for you. Yes, your team has built it, but it actually makes no real difference to your business. And it could be that deploying once a month is perfectly fine for your business context. And maybe the theoretical optimum that is, again, relevant and practical is every two weeks. Okay. So you’re not there yet. You’re not doing great on that aspect, fine. But it’s not like you’re doing poorly because it’s once a month and everybody’s talking continuous delivery.

Henry Suryawirawan: Yeah, I think, don’t forget, right, people behave as how they’re measured, right? So always think consciously the kind of impact when you create measurements and metrics.

[00:50:52] 3 Tech Lead Wisdom

Henry Suryawirawan: So Gil, thank you so for sharing about your model and also “Delivering Better Results”, the book, right. So people later on, we’ll put it, uh, in the notes, right? Some of the links that they can check out. I have one last question that I would like ask you before we end the call, right? So this question is called the three technical leadership wisdom. You can think of it just like advice you want to give to us the listeners. So maybe if you can share some of your three technical leadership wisdom.

Gil Broza: Okay, so one of them that will come, is no surprise because we’ve talked about this, uh, regularly work with your colleagues across the system, so not just in your silo. Make choices with the system in mind. It’s always good to have connections, friends who do slightly different work, but you all contribute to the same thing.

And number two is really people before process. There is a quote from Deming that says that a bad system will beat a good person every time. Meaning you can have the most wonderful ICs and managers and whatnot, but if the system is broken, they will not perform at their best. They will struggle, they might cause mental issues. They’re all sorts of things.

And the third thing, we haven’t touched about this today, but it’s a big one for me. Your words reflect how you think. If you ever refer to people as resources, what are you communicating by that word? If every work item is a ticket, what is that communicating and how does that affect the motivation of your team? I don’t know. For me, ticket sounds like there’s an endless flow of them and they’re boring. That’s, that’s me. If meetings are ceremonies, are you implying that they’re repetitive and boring and you’re doing them because somebody told you to? Every word you use carries some associations and connotations, and there are many words that we’re just used to using, and we don’t even notice the effect that they have. So your words matter.

Henry Suryawirawan: Right. So I think that’s really important. Yeah, sometimes we unconsciously pick a word and, or maybe even like from the industry practice, right? Ceremonies, right, you mentioned. So I think some blog posts mentioned about that. So I think do choose the correct words in your context. And especially people have different cultural background these days and some words actually matter a lot more to some cultures.

So Gil, for people who would like to follow you or maybe ask you something online, is there a place where they can reach out?

Gil Broza: Yeah. So the main place to do this is LinkedIn, but I think I would like to offer, and we, we mentioned this, I would like to offer our listeners something even better or like a next step. Something that they can immediately put into use. And that’s the first chapter of the book. It’s not an introduction. It’s actually both foundation for the rest of the book, and you heard a good deal about this today. But it’s also a just enough read if you’re a busy leader. Or your boss is a busy leader. So in like the 20 minutes it takes to read it, you get all the highlights, all the key points, what every strategy is like, and you get this in a written fashion, right? So you can also share that with colleagues or executives so you can all develop the same mental model. That chapter also includes the fitness assessment tool that I mentioned. So I’ve made this chapter available to our listeners at a wordy URL. It’s called heardonpodcast.deliverbetterresultsbook.com.

Henry Suryawirawan: Right. Yeah, we’ll put it in the show notes for sure, right, so yeah. And I’ve read the chapter one, right? It’s not the introduction kind of a chapter. Definitely, it’s very useful by itself. So thanks for sharing that for the listeners.

So thank you so much for your time today, Gil. I really learned a lot, you know, some of the concepts, right? And I hope listeners here also learn as well.

Gil Broza: It’s been a pleasure. Thank you.

– End –