What It Takes to Deliver Better Results

Transcript

Shane Hastie: Hey, folks. It's Shane Hastie here. Before we start today's podcast, I wanted to tell you about QCon London 2024, our flagship international software development conference that takes place in the heart of London next April eight to 10. Learn about senior practitioners experiences and explore their points of view on emerging trends and best practices across topics like software architecture, generative AI, platform engineering, observability and secure software supply chains. Discover what your peers have learned, explore the techniques they are using and learn about the pitfalls to avoid. Learn more@qconlondon.com. We hope to see you there.

Good Day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down again with Gil Broza. Gil, it's been a while since we last spoke.

Introduction [01:01]

Gil Broza: Yes.

Shane Hastie: Thanks for taking the time to talk to us today.

Gil Broza: It's always a pleasure. We go back.

Shane Hastie: It's probably a decade.

Gil Broza: Probably even longer, right? Some of the early conferences.

Shane Hastie: Wow, time has moved. There's a lot of water under these bridges. You and I know each other, but I suspect that a lot of our audience haven't come across you before. Let's dig in. Who's Gil?

Gil Broza: Who's Gil? Former dev, former R&D manager.  For the past 18, 19 years. I've specialized in helping leaders deliver better results by upgrading their agile ways of working. I have the independent practice for the past 15 years. I'm based in Toronto. I've worked with over about 100 clients, and my focus with clients is on upgrading the entire system of value delivery specifically by putting people first, like before process and being intentional and explicit about choices, what I refer to as mindset.

Shane Hastie: Let's dig into that. What do we mean when we say put people first? I want to be cynical and say it's become hackneyed. Everybody says we put people first.

What does putting people first actually mean? [02:07]

Gil Broza: Anybody here who's listening and thinking, well, does my company do that? Does my leadership do that? The place to look is their decision-making. If their decision-making, whether it's done individually or in groups or by consensus or what have you, if their decision-making starts by considering the wellbeing, opinions, effects, ramifications when it comes to people, not just that team, but also management, stakeholders, customers, of course, then you would know that they put people first.

Now when we say putting people first, it's like, ahead of what, right? It's ahead of product and then it's ahead of process. And what that means is that if we treat people well, we engage them, we empower them, we give them some autonomy, we give them the tools to make the right decisions, they will take care of the product by customizing the process that product and that group of people needs. That's really what we mean. We're not trying to be touchy-feely. We're not trying to create a democracy. We're not trying to totally invert the pyramid and we're not doing away with the hierarchy.

But when it comes to decision making, the wellbeing of people and what they have to contribute comes before a standardized process that solves everything.

Shane Hastie: We're sitting in a time in our industry where there have been massive layoffs.

Gil Broza: Oh yes.

Shane Hastie: Some of the organizations that are involved with this are ones that purport to put people first.

The contrast in how different organisations have approached layoffs [03:39]

Gil Broza: Yes. I'm not privy to the details there. All I can go on is what people have posted online, but I have seen quite a variation among companies in terms of the notice they give people, what people are allowed to take with them, how they break the news, the severance that they get, the help they get with placement. And I have seen some companies that are reportedly putting people first actually acting this way. It's the same with psychological safety.

Psychological safety doesn't mean you will never lose your job. It should mean, and it often does mean, you won't lose your job for speaking up for the benefit of the company, right? You won't lose your job because you care and therefore maybe you argue a certain unpopular point, right? But it could be that some businesses are not in a position to continue employing everybody. And whether that is a mistake by senior management or an absolute necessity, I can't speak to that. It does seem like in more organizations than we hoped the downsizing trigger was pulled a little bit fast, but I don't know, I'm not inside.

Shane Hastie: If it's not touchy-feely, what is it?

Transparency, empathy and safety [04:51]

Gil Broza: What is it? You have empathy and you have, again, the safety to speak up and do your work without fear of failure. It has to do with actually considering people's contribution to decision-making. It has to do with creating conditions where people who ought to be collaborating and would benefit from collaborating with others actually have the opportunity to do that. It goes to transparency, explaining why certain decisions got made, and maybe I asked you for your input, but we made a different decision. At least I have the grace to say, well, okay, here is why we made that decision so you don't feel like I'm just asking for your input because I want to look nice or something of that nature. It has to do with how we engage, how we come across, what we say and don't say, what we do and don't do.

And again, it's a lot of the come from, it's how we show up, right? The big term we have for this is servant leadership. I know a lot of people are allergic to that term, but the concept of a leader being here to enable their people, their teams to really be their best. That's a solid concept, however you call it. It does involve the person actually leading as well, right? A leader is not a doormat and a leader is not a dictator. Sometimes people do find that it's a little bit difficult to be in that position, especially if their superiors are not like that. But I can say having been in the tech industry for three decades, that it has definitely shifted toward that direction or it's so not there yet. But the shift has been happening.

Shane Hastie: It's sort of a segue into your new book, Deliver Better Results, How to Unlock Your Organization's Potential. Tell me a bit about the book.

Overview of Gil’s new book [06:38]

Gil Broza: Okay. It started by looking for a way that senior leaders, and I know we have some of them listening to this like C-level and VPs, busy people who need to fix their house, deliver better results and all that and kind of do it now. I was looking for a way for these busy people to get a pretty decent read on how well are we doing and from that to understand here's what we need to do to level up. And it's not that the industry is not trying, right? We have the surveys and the assessments and lots of metrics and dashboards and whatnot, and without even going into some of the pitfalls of metrics, nobody has a complete set of them that can give you a totally accurate read. It's like if I went to the doctor and I said, hey, give me a good read on my health.

What could the doctor do? Do a couple of blood tests, maybe an MRI, but they're not going to scan my whole body and look into everything I eat and of course do this over a long enough period of time. That's just not practical. We do need something that is simpler and more immediately available and not subject to garbage and garbage out and hopefully not terribly subjective. That's what I was looking for. And when I was doing that, I also realized that this assessment of fitness for purpose that I came up with actually correlated to sequential and incremental strategies that will actually allow you to level up. It's not just, well, here's a read on your state. Now you need a consultant. No, it's here's a read on your state and because your state is one, two, three, four, five, something like that, here's what you need to do now at the very strategic level without imposing on you, I don't know, Kanban or scrum or SAFe or DevOps or what have you. Yes, of course we'll take good ideas from them along the way, but it's not like you have to go this way and do exactly that.

Shane Hastie: In the book, you talk a lot about systems and systems thinking. When we talk about the organization system, what do we actually mean?

Systems thinking [08:46]

Gil Broza: We have the entire organization. That is a system, but it's not what I talk about in the book, right? The entire company, organization, nonprofit, whatever you work in, and then there are the teams, right? A lot of literature in our space is team specific. Sometimes you have multiple of those teams and they work together and you might call it scaled, but there is a construct between those two orders of magnitude, and that's what I refer to in the book as the value delivery system.

That's the entire set of people whose contributions, even if all they contribute is the occasional decision or inputs that somehow changes its direction. All of these people, including their management and how they work in order to produce results. They convert inputs like requirements and roadmaps and whatnot into output, deliverables, product releases and so on. That is a system meaning what?

Meaning that even though it has parts like engineering, product, content and so on, the results of it have to do with the interaction of the parts, not just what the parts did. When you're looking at software development, let's say in a tech product company, of course it's important what engineering does, but what engineering does is also based on what product suggested and what design suggested and some things that product didn't do and design didn't do, and some of what engineering does affects what the other groups do. And that goes into your delivery and your content and even your tech support and all of this. Now, I'm sure every listener knows this stuff already.

The problem I'm seeing in the industry is that we don't manage with that sensitivity. We manage locally, right? We manage engineering separately and we manage product separately. And there's tons of amazing suggestions and advice and resources and tools to help each of them, but somehow they don't quite act as if these people are in a system.

And one thing that sometimes gets in the way is how we actually talk about things. And so we have this concept of the value stream. The value stream is a system, but the word itself, stream, has basically two implications that I'm aware of. One is that work keeps coming in. That's the good interpretation. The other one is the implications that work kind of flows downstream sequentially like it did at Waterfall, but we know that that's not entirely true. And you can make a decision, again, in product that reverberates everywhere. You can make a decision in delivery that reverberates everywhere. And so managers, leaders in a system should be making choices that take the system into consideration. Sometimes all that means is talk to your colleagues, seriously. But what it also means that that's what the book is about is if you want to make things better, you have to make system-wide changes, not just localized changes.

Shane Hastie: I want to dig into that sometimes it means just talk to your colleagues. How do we frame those conversations when we are thinking, so I'm the engineering manager, I want to do this. I've got this idea, I need to optimize something in my team. How do I have that conversation across product, across design, across support?

Framing conversations across the organisation [11:59]

Gil Broza: The first thing you can do is simply think what effects your choices might have. For instance, let's say you're engineering manager, like you say. You want to write more unit tests because you want better quality or you want to improve your code review or pull a request procedure or something of that nature. It sounds local, but think through the consequences it could have. For instance, you write more unit tests, sounds good, right? But it could affect some of your cost of change later if those unit tests are actually not that great, and even if they are great, you might be overusing those unit tests and delaying other more important things. You'd say, well, suppose we improve quality. Okay, what would we see as a result? Well, we might see as a result that we move faster than product actually needs us to.

And maybe products say, well, that's wonderful, but in customer service, they're not going to be ready for us. Then you can look at what you're suggesting here and then have conversations with your colleagues with the product lead or the support lead or someone and then say, well, we're thinking of changing this and that. How is this going to affect you? What do we need from you in order to make this work? Now, what I've been talking about so far is generally we want to make some change. The book is very specific about which changes make sense and in which sequence. For instance, if your system, short for value delivery system, if your system is at a level two of fitness, writing a whole bunch of unit tests is not what you need to do right now. It's premature. And yes, I had a lot of clients for many years where I would teach them how to write those unit tests and make sure they did it right and whatnot, but it didn't always stick as well because the system fitness was just too low.

It was basically just trying to make ends meet. And writing those tests in a way prevented us from having the bandwidth to do the more important things. And so what I suggested in the book is, again, given your fitness level, here are some things to do and they apply across the system. For instance, when you're at level two, one thing to do is to stabilize the system to create a good balance between inputs and outputs, between supply and demand. Again, demand with what comes out your roadmap or portfolio and supplies what you deliver. And level two systems tend to be a little bit erratic in that. And so the strategy at level two is to stabilize things.

How do we do that? Plenty of excellent ideas and Kanban and Agile and Lean, but don't do them locally. For instance, you can apply web limits. On your board once something hits development all the way through deployment, you can do web limits and they're not a bad idea. But what you actually need to do is apply web limits across the system so product doesn't overwhelm engineering. Engineering can limit the whip all they want, but if product has huge expectations and they keep overwhelming engineering, in the aggregate, it's not going to be good because you're going to be paying for it through reprioritization and escalations.

Shane Hastie: Let's dig into some of those levels. You talk about fitness levels. What does that delivery system at Level one look like?

Exploring the fitness levels [15:15]

Gil Broza: First, let's make sure we're clear on what the delivery system includes, right? Again, it's everybody who contributes. The analogy I give is like the credit role for a movie. Everybody who contributes something, including decisions, including tracking, including oversight. A level one system is simply unable to contribute adequately to achieving the company's mission and objectives. People work, they have some successes, but no matter how hard they work, and no matter how much we reprioritize and escalate and this and that, they cannot succeed.

Fortunately, that does not describe too many companies. I mean, I've seen a few of course, but it doesn't describe most. And what you would have to do at a level one is get your portfolio management in order. You might call it roadmap instead, that's fine. Really manage it strategically and for capacity, but also design your way of working your team, structure your processes so that they actually fit what you're trying to accomplish. And that you kind of need to do it enough. There's a threshold for each strategy for it to kind of stick.

Once you reach the threshold on both, you will be at level two. And at level two, your problem is different. When you're a level two system, you do actually deliver things that satisfy the organization's mission and objectives. It's just not effective and efficient enough, but at least it's not considered broken. And now you need to do other things, and so on it goes until you hit level five.

Shane Hastie: What would level five look like?

Gil Broza: That's nirvana. No, seriously. Level five, the system does what the company needs from it, which means both regular delivery, but also adaptation when necessary, okay? Timeliness is necessary, including when some things go a little bit different. It means that when there are big things to do, major outcomes to accomplish, let's say you're replatforming or integrating an acquisition, things go relatively smoothly. We're not looking for perfection.

This whole fitness for purpose concept is relative. It's relative to what this particular company needs given its business model, landscape, people, whatnot. Level five, it does what you need it to do. Now, it doesn't mean that if you pop the hood, you don't see that there's a lot of talking and a lot of process and people making this decision and maybe questioning it or whatnot, but it performs what the company needs it to perform. The way I define fitness for purpose in the book is, like I said, helps the company achieve its mission and objectives, but there's also what aspects it has.

And there are really six. There are not dimensions, and some of them build on others. Fitness for purpose means that you have good enough throughput, you achieve good enough outcomes. There's timeliness, there's adaptation, there's consistency in achieving all of this. And there is cost efficiency in achieving all of that, including the consistency.

All of these fitness aspects are kind of outward looking from the system towards the organization. It's what the organization cares about, it's what senior stakeholders would care about. They care that you're adaptive and timely and consistent and cost-efficient. They don't care if you do scrum, they don't care if your teams are seven people. They need to know that you perform. What does that mean? Those six things. And I found a good way in the book to do this without metrics.

Shane Hastie: Without metrics.

Gil Broza: Without metrics.

Shane Hastie: But surely we want the numbers.

Avoiding metrics mistakes [18:40]

Gil Broza: Right. There is a number there, but it's simple, indiscrete, right? It goes between six and 18 and it maps to the five fitness levels, and that's it. And this is actually also intentional because I've been in this industry long enough to know what people do about industry standards and what the elite level does and what the big five do and this and that. And fitness is a relative concept. Not everybody needs to be Google, right? That's one thing. The other is when our numbers are very specific and we try to be too accurate and too precise, we run into trouble and people start gaming things. And they get attached to goals and a whole bunch of other things that have side effects. Again, system, you measure something in one place, you will get to knock on effects someplace else. And the thing is this, you can measure your fitness based on the assessment tool that I include in the book.

It takes 10 minutes. Let's say that you're really being generous with yourself and you're rating yourself higher than you should be. The whole point of doing the fitness assessment is to know which strategies to apply now. If it maps to, I don't know, it says that you're a level four. Level four, you do these three things, but if you're really a level two and you were just super generous with yourself, you should not be implementing the level four strategies. They would just do you harm. Basically, they're premature. Honesty or impartiality to an extent are kind of built in.

Shane Hastie: If I'm a technical leader in an organization, I'm a dev lead, I'm an architect, how does this help me?

Why understanding system fitness matters [20:13]

Gil Broza: The first thing it would help you with is this context setting of how everything you do affects the system you're in. Even just bringing the system concept into our consciousness, because it's not something that people have talked about much, that's the first thing. The next thing is the ability to see in what ways are we doing things that are not contributing to our fitness for purpose?

What elements are we missing from lower levels? It gives you the idea of what you need to do next. Now, a dev leader or an architect is not going to be able to pull all of this off on their own. But here's the thing. When you want to level up a system, nobody does that alone, even if you're a CTO, because there are many, many people involved in this. You do need this coalition of leaders who kind of look after the way of working of the system so that it's more fit.

An architect or a dev lead can be part of this group, or at least to bring this to the attention of their director, for instance, or their VP and say, Hey, here's what I'm seeing here. Here's how we are creating problems for ourselves. Here's what we're missing, and maybe kickstart something that way. But ultimately, no matter what, this needs a coalition of leaders.

Shane Hastie: Wonderful. Well, thank you so much for taking the time to talk to us today.

Gil Broza: It's been a pleasure. Thank you for having me again.

Mentioned:

• Book: Deliver Better Results
• Gil Broza on LinkedIn