Ep. 152: Why Your Productivity Push Might Be Backfiring

In this thought-provoking episode of Definitely Maybe Agile, Peter Maddison and David Sharrock dive into the complex relationship between quality, productivity, and organizational culture. They explore how external market pressures and a focus on short-term productivity can undermine long-term success. The hosts discuss the importance of building quality into processes, the challenges of cultural change, and the enduring relevance of Deming's principles in today's business world. This conversation offers valuable insights for leaders and teams striving to balance market demands with sustainable, quality-focused practices.

This week´s takeaways:

• Quality is cultural, not mechanical. Sustainable improvement comes from fostering a culture of quality rather than simply implementing mechanical processes.
• Building quality in is more effective than inspecting for quality at the end. Organizations that integrate quality throughout their development process tend to perform better than those relying on final quality checks.
• Cultural change is slow to build but quick to lose. While it takes time and effort to cultivate a quality-focused culture, it can be rapidly undermined by leadership changes, mergers, or short-term thinking.

Don’t miss out on this deep dive into aligning leadership and processes to create an environment where quality and innovation can truly thrive.

Chapters

• 0:04 Building Quality in Agile Organizations
• 7:44 Cultural Impact on Organizational Quality

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you today? Excellent Peter, how are you doing? I'm doing good, it's good. It's a good start to the week. We've got a new conversation underway.

Dave: 0:21

It's fun new conversation underway. It's fun. This actually feels like a little bit of a Friday evening rant that we're going to be starting on. So, as we were prepping for this, we were sort of beginning to circle around the challenge of trying to build in things like developer experience and to create space for organizations to innovate, let's say, or build quality into what they're up to and what the challenges are.

Peter: 0:51

Yeah, and we started. As we're into this, we're talking about organization and that ability and the value of some of these things. Why we want to measure experience versus productivity? Because we know that that thrives the organization's ability to perform. But the organization naturally has aspects of things like the external market which influence it in ways and cause it to behave unnaturally as a consequence of that. Hence the Friday evening discussion of abuse.

Dave: 1:20

Yes, yeah, well, I mean. And so we spend a lot of time talking about, say, innovation or great engineering practices, configuring an organization to be, say, customer centric and really thoughtful about how they go about delivering things, and yet that's often in conflict with how the external market is viewing that company.

Peter: 1:43

Yes, exactly Because, for public companies, they have a quarterly reporting schedule and they are asked to predict what their results are going to be. So they've got to predict the future and then, if they see that future coming at them, they start to do whatever they need to do to make sure that the external market gets what it is they said they were going to have three months ago. Which means you end up in this situation where people will jump through hoops to ensure that they hit a particular number or target and often result in things which can be just fundamentally disruptive or to the organization, in fact quite damaging to the organization in some cases.

Dave: 2:22

I think we can, whether you're looking at the external market and quarterly results, but also there's a huge focus on productivity right now and organizations trying to get their productivity numbers up.

Dave: 2:34

And whenever we look at these things. What I find fascinating is there's a paradigm shift when we're looking at organizations and trying to help them go through that. I think we have a very specific view of how to go about improving productivity or outcomes from an organization, whereas many organizations view it in a different way and fundamentally it's tied to Deming. It goes way back right. It's tied to Deming. It's tied to understanding that productivity, that that performance, that outcomes, quality comes from really getting a focus on quality at the outset, which will lead to all of these other things over time having that culture of quality where it isn't good enough to be just good enough.

Peter: 3:19

It's got to be. It's got to be of quality. It's got to be something you're proud to ship. It's got to be something that does proud to ship. It's got to be something that does what it needs to do. Seth Godin had a good quote there. The other side of that is you're not aiming perfectionism here, because that also puts you down a path where, hey, you're not going to ship something until it's absolutely perfect, but it's got to be better than just good enough. It's got to be of quality, something that we can put our name behind.

Dave: 3:46

Well, I think you know we're just coming off the back of a couple of weeks of the Olympics, so this dates up conversation for sure.

Dave: 3:52

But if you think about you know, the reason many of us are drawn to watching the Olympics is seeing people who aren't perfectionists but are focused on quality, are focused on becoming the best that they are able to be and then competing on a world stage to sort of see who's the best of everybody, who's kind of competing at that level.

Dave: 4:13

But there you're absolutely looking at people who understand the difference between mediocrity and perfectionist, that understand the ability to you know what it means to be, to focus on the quality of what it is you're doing, whether it's in preparation, whether it's in delivery, whether it's in nutrition or warmups and warm downs, all of those things that all kind of stitched together to deliver the outcome. And and I think that's something that sometimes we get into a position as a company competing in the marketplace where we think good enough means it's almost like you can take your foot off the accelerator or you can take your foot off the pedal and just do, you know, just good enough, and that will maintain our position as a trusted brand or a trusted product, whatever that might be yeah, and and I liked one of the things that you had noted down here around it it's cultural, not mechanical.

Peter: 5:05

And so some of the reactions you see within the organization when you say, well, okay, well, we only need a thousand people to get this done so we can get rid of 500. And that means we can go do this, but that means you're changing the cultural dynamics of the organization, the process of doing that, which is horrendously damaging to your ability to get a quality product. You might still be able to operate, but you're going to really damage your sort of the culture of the organization in the process of that, because you're purely looking at how many people do I need to pull how many levers, versus looking at how do I create the right culture in this organization that is guided around building a quality product that we put into market.

Dave: 5:52

This is interesting because it goes back to that paradigm, that mindset of in order to improve productivity, I need to remove a number of people from the organization. That will reduce my costs. Therefore, if I maintain the same outcomes, my productivity obviously goes up relative to the number of people I have, for example. So we begin focusing on this as a and this we often talk about. It is sort of the, the fungible assets perspective of people on the in the organization, in the organization and what I. I read a blog post recently by chris chapman around this and he was talking about how the paradigm shift is understanding that building quality in and again, not the perfectionism, quality, not the we can't ship anything until it's, you know, totally on top of it but building quality in in such a way that we're always striving to do as well, if not better, than we've done before, and we're looking to continuously tweak and fine tune what we're looking for. That's where the productivity growth comes from.

Dave: 6:52

That's where the deeper presence in the market comes from because these products are revered by people who use them, because they're continually getting better and better and stronger and stronger.

Peter: 7:03

Yeah, and I think the organizations that create that are ones that are proud of the things that they produce. So you're creating the culture where we want to see, we want the next thing to be better. We're going to produce another thing that's just a little better than the last and we're going to continue to improve because we know that we can and that we're working towards that. And that's such a key underlying piece how the organization adapts, how the organization learns. Understanding that, understanding what's stopping you being able to get those things, is a key piece that we can start to help organizations improve.

Dave: 7:44

Now what about? I mean, when you lose that attention to detail or attention to quality, how hard is it to recover from that, or any thoughts on that side of it?

Peter: 7:56

I think it's. I mean's because we're talking about a cultural element, so it is very hard to recover. I remember years ago a CTO who would always go on about quality is everybody's problem, which is wonderful and fantastic and put it on a cat poster on your wall and it feels good. But that alone isn't going to change the situation of, like, how do things get done within the organization? How do we look at the work that we're doing? How are we aligned to that work? Do we feel that the work that we're doing is valuable and that we can contribute to it? Autonomy, mastery, purpose right, it's drive. Like, how do we it's these pieces all tie?

Dave: 8:35

into it.

Peter: 8:36

So you've got to think about it a little more fundamentally. How long is it going to take? It's how long is a piece of string and how much damage has been done to the organization at that point or where the organization is at.

Dave: 8:52

So I don't think there's a cut and dried answer to that, other than it takes a long time I think there's one bit that I would add to that is, the larger the organization, it's like that the whole oil tanker turning around it's longer and longer to make that shift. The one of the headaches and this is something to kind of think about as we're looking at it, because culture is really difficult to shift and change when you're trying to to raise it and shore it up and change it sort of in a certain direction. But the interesting thing about culture is also it's a little bit like a sawtooth. It's really difficult to get up to a point but you can lose that culture almost instantaneously. So it's just one of these things that is, you're continually trying to move it in the right direction, things that is, you're continually trying to to move it in the right direction, but one you know, not single experience, but it's very, very quick to kind of lose where it is and it can be a merger and

Dave: 9:46

acquisition or acquisition bringing two cultures together. It can be. Uh, we've all seen it. When there's a change of leadership in a part of the organization, they bring a different mindset in and immediately you lose um a lot of the culture that they bring a different mindset in and immediately you lose a lot of the culture that's taken years to build up beforehand. So there's that sort of sawtooth piece to it which makes it incredibly difficult, because you can lose it very, very rapidly but it takes a long time to build back up, as you say that.

Peter: 10:10

It reminds me about the conversation around trust. Right, if you have the bathtub of trust, every positive conversation adds a little drop of water into the bathtub, but all it takes is pulling the plug out and all the water's gone, and that takes takes very little to break that trust and but once you do, getting it back's a long, painstaking uh can I ask what?

Dave: 10:33

what do you think that uh organizations can do? What is the? You know, we're having a bit of a like that friday evening philosophical conversation yes but how do we take this away and say, okay, what is it that we can? We can actually work on uh.

Peter: 10:47

Well, I think one aspect of it comes to being willing to admit that there is that problem, that you can see that it's there and starting to look at like what are the opportunities to improve. I think one of the pieces is very powerful, of course, is going and asking the people who are working in the system like what's working, what's not working? How could you improve from here? Where do you see the problems? And then investing in what people see as the biggest problems and starting to fix those and tackle them and dig into what's underlying this and finding different ways to do that. And that can be in a myriad of different ways depending on what the problems are.

Peter: 11:28

I mean, if people say that, well, my leadership doesn't give me the ability to go and do the work I need to do to succeed, then have a conversation around like how can we enable the leaders to free that up? What's causing that? What are the underlying reasons for that? Where's that coming from? And making sure that there's good, healthy conversation occurring around that on an ongoing basis too. The other key part here is it's not one and done. It has to occur, and action has to occur too to go along with that, to support things that people are recommending.

Dave: 12:04

I think I mean, as I'm asking that question, I was thinking about where I would start with that or what's in my mind, and I feel like just beginning to understand it's a paradigm shift. About thinking about how an organization or a system works is one side of it, and again, I'm just going to reference that Chris Chapman blog post. I will definitely put it in the notes where he started talking about that. But then the other one is is we often talk about building quality in during the process of building whatever product or service that we're delivering, versus completing that product or service and then testing for quality at the end?

Dave: 12:44

But there's a fundamental mindset shift around that, whether it's to do with you know, have we outsourced QA or are we expecting a lot of defects to come in through a live? Are we expecting a lot of defects to come in through a live? We push things live and then basically expect our users to do the testing.

Peter: 13:02

Or are we?

Dave: 13:02

taking care of it as we build that process out itself and how we're tracking that. And already that conversation is beginning to challenge how we get work done and what you know. If it's simple things like what can delay something going live, which invariably I mean, I've worked in so many organizations where a quality problem won't necessarily delay something going live, because a deadline has to be met with a list of features that we can point to, even though we may not have quite got those features working the way we want to. So there's some real. It really unpacks a lot of how we think about the product if we start looking at that. Just single statement.

Peter: 13:44

It does. It does indeed and I know exactly what you're alluding to there and I've experienced it many times too. Where it's the okay? We know, operationally, this product is not ready to be put in front of a customer. We don't have a mechanism where we can only put it in front of a few customers or use that for testing purposes. All we can do is release the whole thing. This should not go live. And executive XYZ comes in at whatever level and says, no, it has to go live, we're back to the stock market, so we've got to hit that share number, we've got to hit this, and this is critical to that and it gets pushed into production. Everything breaks, and this is critical to that and it gets pushed into production.

Dave: 14:24

Everything breaks. Yeah, and that's what I mean about that paradigm shift. It really is a different way, like organizations that follow through on that just move in a different way. They make trade-off decisions in a different way. They structure their organizations different.

Peter: 14:38

Yeah, and some of that comes from, of course I mean, putting my DevOps hat on and not doing things in massive releases and doing things in small incremental changes into the production environment, so you're not in a situation where you're waiting for everything to be ready. Now, of course, deployment is separated from release and some things are going to be very, very large and require a lot of small changes to get to the point that it's fully ready to go, and in large, complex systems there's a lot of different pieces that need to be done. But that whole concept and how we go about doing that changing that from the sort of traditional it's one big batch for the big batch is safer, I mean, just that type of mindset is huge.

Dave: 15:20

As you're describing that all I can think of right now and I've got to but is Boeing Star, is it Starliner? Yeah, where the helium link leak that are causing the fact that it's still up there two months and it hasn't come back down to Earth. But every time I see an article about that, they talk about the fact that it took off with helium leaks that they felt they could work around the fact that it took off with helium leaks that they felt they could work around, and there's these little sentences that come out.

Dave: 15:45

I have no idea I've not looked into the whole thing to find out exactly what's there whether you know like validate all of the the points there, but it that even just the language that's used in reporting? It feels like, oh, this isn't a big, you know, it's the inspect for quality rather than build quality and mindset of it, which is just mind boggling when you look at the sort of risks associated with it.

Dave: 16:10

You know the cost of those programs. But, again, it's something that you hear in the language how they structure, how they make decisions about what's going on.

Peter: 16:19

Yeah, it's when decisions get made on a cost basis when it should be an engineering decision, especially when it's something that it's critical that the quality is built in because it's going to save people's lives. That's where there's this disconnect it's using the wrong type of decision criteria to make the decision. So how would you sum this up?

Dave: 16:42

Summarizing it yeah, sum this up. Okay, so let's not let Friday become Saturday morning. What is it you're thinking of? Two or three things that jump out.

Peter: 16:51

I really liked how we tied everything down into the quality. It's the quality, how the organization looks at quality and how they. I think that sort of that pride piece of understanding that it has to be baked into the system, as Deming has always said, putting it into the system so that we can. We've got more confidence and that we trust the people that we're doing. And again, trust comes up here. Right, it's like do we trust our organization to do the right thing? And this, in turn, is if we, if we put large quality gates at the end of processes, we always are going to end up in these situations that, uh, the risk is going to get overridden and we're going to not have the outcomes that we're looking for.

Dave: 17:36

I'm just going to add one thing to this, which is I find it fascinating that we're nearly 100 years later on and we're revisiting. This is like the returning of flares. We're revisiting this idea of Deming and total quality management and just understanding how quality impacts productivity and outcomes and what we're delivering. And yeah, it's still a problem, a paradigm that we've not fully bought into in many, many places.

Peter: 18:03

Yes, yeah, indeed, ok. Well, thank you very much, dave. Enjoyed the conversation, as always, and if anybody wants to reach us, they can at feedback, at definitely maybe agile dot com. And don't forget hit subscribe so you can get the latest episodes on a somewhat weekly basis Until next time. Thanks again. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.