Hey, a quick message from me. Thank you for being part of the Techledjournal community. This show wouldn't be the same without your ears and you are the reason this show exists. Creating this podcast is a labor of love, but the truth is it also takes time, resources, a whole lot of passion, and an extra bit of caffeine. So if you're loving TLJ and want to see it keep on growing, consider becoming a patron at techledjournal dot dev patron or buying me a coffee at
techregional dot dev coffee. Every little bit helps field the research, editing, and sleepless nights that go into making this show the best it can be. Thanks for being the best listeners any podcast could ask for. If we want to deliver better results, what should we do? 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. So if you want to deliver better results, you need to do something to your way of working. Hey everyone, My name is Henry Surya Virawan and you're listening to the Technically Journal Podcast, the show where I'll be bringing you the greatest technical leaders, practitioners, and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team, and to make an impact in
your personal work. So let's dive into our journal. Hello again, my friends and my listeners. You're listening to the Technically 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. Keckley Journal also provides bite sites contents on LinkedIn X, Instagram, YouTube, and TikTok. My guest for today's episode is Gil Brozer. 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.
Hello guys. Welcome back to another new episode of the Tech Regional 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.
Thank you for having me. 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. OK, 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 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 speak and 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 pretty large clients. This became, you know, my work
of a lifetime. And then a turning point for me was when I realized that I approach 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. In 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 a different mindset, basically choices and you get totally different outcomes. That's turned into the second book and into some really super interesting clients. And since starting I've worked with about 100 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 perspective that I have on our industry.
And so this is really turned into some of my newest work, which is what we're going to be talking about today. 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 have seen a lot of patterns and I'm sure today we'll be learning a lot from you today. 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 with this book? So like I said, I've worked with about 100 clients, but I've spoken with a lot more companies. So you know, AVP will call me up, a director, CTO, they'll say we need, 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. I can 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, I do actually start with an assessment and they pay for it and they get you know basically we strategically designed 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 AB and C to level up. You know, think about it 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 in Sr. ES 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 a 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 or as 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 the level 2, here's what level 2 means, or we are at the level 4, here's what Level 4 means. And the amazing realization I had is that this is not really a lossy calculation in the sense that, well, I'm level two, OK, anybody could be level 2, then
what? No, if you're at a level 2 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 and how it evolved. So I spent about a year in doing all of this and trying it out, and then another year writing the book and of course any of the process that evolved even more. 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 1 until maybe 5, right. And also figuring out like what kind of practices that maybe level one versus level 5 should be different, right?
And I think it's pretty much the same idea. And I think I when I read a book, some concepts really resonate with me. 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 socio technical problem, some people say, right, It's a system thinking. So, yeah, maybe elaborate a little bit more. You know, 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. But 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, hand off, 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 travel 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 because, 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, you might be an engineering manager and you want to turn out better code. OK, 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 because you want 100% coverage, that's going to slow things down because you're going to 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. So I find also very exciting whenever I read about system 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 maybe to try to explain a little 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. 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, OK, And it comes back to you and it reinforces something that you were 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 and creates more positive effects, for instance, in engagement. OK, balancing loops, push back against your change. The example I gave in the book is really within 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 going to be done right and I need you to deliver
now. I don't need to worry about the future too much in 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, you know, tests and they say you know what, maybe not this time and maybe not this time. And before long the idea dies. Right, thanks for explaining those two concepts. I'm sure if people listen they
would get it right. So this kind of readforcing loop and balancing loop. So another thing in the book you mentioned a lot apart from just looking at the system holistic level, right. So you mentioned about ways of working, so maybe touch on a little bit like why ways of working is very, very important for delivering better results. 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. I don't know. Whatever. We can slap goals and things, we can say by next year, 20% increase in productivity. OK, 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, no 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 your information, that means I'm using it with probably an agile
mindset. And if 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. And 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, wait till you change the structure, maybe go the other way.
Usually we do both so that we engage with the work differently. And no, we take inputs, we convert them differently to outputs. That's basically what it is. I think I assume many people when they do this kind of transformation or maybe changing the productivity right, they focus a lot on the 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? OK. 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'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 the process can be the constant. OK, so that's an example. Agile comes along and say no, we value adaptation for us. Adaptation is so, so important.
That we're going to 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, sex, 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 2 devs, we want collaboration between 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 believed in 10X developers. We believed 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 and 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 3-4, 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. Yeah. 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 a posters here are new values who 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? OK, 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. No, 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 their safety there. There's a whole bunch of stuff there. If we enable people to bring their best selves to work and 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 1st and product 2nd 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 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 and look over their shoulders sometime, trust and verify and all of that so that they're actually more successful. So yeah, I think 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. 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 or 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 sea 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. Yep, thanks for the pluck 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 so the executive leaders, right? 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 of framework for
people to follow, right? It's like a playbook, some people say. And in your book you mentioned 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 things that we can learn from this? So Square is basically the entire subject matter of the book and it has several
components. One of them is the first of the realization that we care about the fitness for purpose and we want to improve it by in operating the ways of working. So one of the components is what is fitness even made-up of? Because 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 unfit. So I define six aspects of fitness which, contrary to a lot of what I saw out there, is not about how will 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, its 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's the listeners are going to get it right. That's fitness assessment tool, super simple, 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 O 5 levels. So fitness, I discovered it kind of grows along a scale of five levels, 12345, which are really characterized by, again how well it helps the company achieve its objectives and mention for instance, a Level 2 system. And those are I think the most common. A Level 2 system helps achieve the objectives, but it's not effective or efficient enough. Or a Level 3 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 our listener is. 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, it's planning together and what's not. 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, social, technical, like you said, they have limited capacity. So 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 2 to Level 3, 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 the realistic expectations for you know how inputs transform into outputs, how your requirements and projects and epics and commitments and road maps. You know kind of 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. OK, 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 1, before you ever got to level 2, 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 content boards and their lead times and this and that only then it would even stick. We kind of do things backwards because managing the product 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 OK Rs 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 will 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 2 to go up from level 1-2, from level 2-3, from Level 3, and three from level 4.
But the other big deal is that you need to apply them across the system. It's not going to 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 5 POS, right?
So it's like textbook Chrome. 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 going to run into trouble and you're not going to get the improvement that you're looking for. You might get some temporary improvement, but because of those balancing loops, things are going to fall down pretty quickly.
So we gave one example. Did we give before unit testing? How will that idea dies? Another idea that dies on the product side is experimentation. So you might have a product manager, say we need to experiment and do AB 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. Thanks for the overview of the Square model, right?
I'm sure it's a lot for listeners to catch up, but don't worry Jill. Later on we'll share the summary of the book, right and also give you the 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 touch on a little bit more about 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. 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 companies 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. 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, mine's the tactic. Structure, process isn't that companies will sometimes restructure. Sometimes they'll transform. They'll hire a, let's say middle manager or a 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 what not. 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 going to 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 you 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, not what you end up with. It 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. And. 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 the daily stand up. 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 OK values principles. Yeah. So we want to optimize for adaptation and we want to really be collaborative with our customers. And therefore, we're going to do short cycles and we're going to 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, OK, 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 pluck it in. Or you might realize that doing
pull requests slows you down. Because in your context, if you want to minimize delays, why do them asynchronously? If you can just call your a colleague over or share a screen and say, hey take a look, I'm not telling you 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 2 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 it 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 bolstered it. Maybe if we took away a couple of 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. Right. So I think those two strategies are the key, so-called key strategies, right, for you to move from level 1 to level 2, right. So again just to recap, right, the first strategy is to manage the project portfolio for rater strategy control and the second one is about designing the way of working that can help you to achieve the company's missions and objectives. So after level one, hopefully people have moved on to level 2. 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 to 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. Yeah, So what happens at what companies? Well, not companies. Systems reach level 2 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 release cycle or something, and you can set a date for big release, maybe not just out of a Sprint, but something like big and impactful. OK, so we know who gets to set that date.
What happens if we're midway through the release and we discover that there is, 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 it's 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's consensus and what not. 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 of, you know, half assed them. So this is what you need to do to get to Level 3. So at Level 3, 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 4 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 3. They have so-called teams, air quotes, but those are not teams that 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 all need to make it a three 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 the fairing 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 you're 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 the 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 1st defer more of the commitments because they have ramifications across the company. Every commitment you make, effects, marketing and customer support and finance is going to 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 2, but typically what's still happening is that they don't actually contribute significantly and that's what we want to 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 stopped before or you don't really ingrain it, it needs to become second nature. Then you won't be sustainable at your next level. Thanks for overview of the Level 3 strategies, right? So I'm sure there are plenty of things that people should learn from the book, right? 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? 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 role, 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, fixed that in ascending order and then turn your attention to the strategies from this level. I think that's a pretty good way to summarize how we can get started, right? So of course you need to understand the system first, right? Not just optimizing at the team level. 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 systems fitness. And it is accurate. It's not garbage in, garbage out, and it didn't get funched 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. 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, 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, 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's 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 is 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 usually is, but I don't know what it's going to be in your case.
Or what's another metric. Escape defects, Escape 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 going to 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 going to 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 a metric. So that's why again, this model, it assesses fitness. And by the way, also as 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. OK, 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. 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. So, GAIL, thank you so much for sharing about your model and also delivering better results. The book, right.
So for people later on, we'll put it in the show notes, right, some of the links that they can check out. I have one last question that I would like to ask you before we end the call. Right. So this question is called the three technical leadership system. 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 3 technical leadership system. OK, so one of them that will come as no surprise because we've talked about this
regularly. Work with your colleagues across the system, so not just send 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 #2 is really people
before process. There's a quote from Deming that says that a bad system will beat a good person every time, meaning you can have the most wonderful I CS and managers and whatnot, but if the system is broken, they will not perform at their best. They will struggle, They cause mental issues, 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 are 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. Right. So I think that's really important. Yeah. Sometimes we unconsciously pick a word and 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, Yale, for people who would like to follow you or maybe ask you something online, is there a place where they can reach out? 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 or listen there is 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 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, whatever 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 worthy URL. It's called Heard on podcast.deliverbetterresultsbook.com. Right. Yeah. We'll put 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 learn a lot, You know some of the concepts right And I hope listeners here also learn as well. It's been a pleasure. Thank you. Thank you for listening to this episode and for staying right until the end. If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit
from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better. You can also find the full show notes of this conversation on the episode page at Techly journal dot dev website, including the full transcript, interesting quotes, and links to the resources mentioned from the
conversation. And lastly, make sure to subscribe to the show's mailing list on Techly journal dot dev to get notified for any future episodes. Stay tuned for the next Techly Journal episode, and until then, goodbye.