Innovation everywhere

Welcome to Definitely Maybe Agile, the podcast with Peter Maddison and Dave Sharrock to discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts, Peter Maddison and Dave Sharrock. So how are you today, Dave?

Very, very good. It's been I'm just laughing. That's a great way to start the morning, isn't it? Um, what are we talking about?

We are talking about innovation as a department. The right way to do innovation. Okay, let's put it that way then. Yes. And I and I and I think this came to mind. Uh we were talking about this uh last week um before our call, and I think it might have come up because you might have run into an innovation department at an organization or something along those lines.

Well, I I think I mean this this stems back uh to the whole innovators' dilemma and the and the idea that you can't innovate in the same group of people or department or organization that is optimizing for delivery effectively and doing the delivery side. Fair comment, right? I mean, those two cultural mindsets and and incentives are completely different, right? But that doesn't mean we should push innovation out as a department. I think there's an awful lot more to innovation than just hiving it off and giving its own uh building department uh VP, whatever it might be.

Yeah, I've seen that uh the danger before, and I've been in organizations where the creation of the department um has been taken as alleviating everybody else in the organization from ever needing to do anything with relation to innovation because that's somebody else's job now.

I I mean I'm just thinking of the number of organizations I've seen which have hived off uh the CICD pipeline, for example. Continuous integration, continuous delivery is done over there in that team, or test automation is done over there in that team. Exactly the same challenges are uh kind of experienced there because now it's not my problem, it's somebody else's problem.

So yeah, and the and the and this comes to one of the areas of this is that we're in this together, we're all trying to deliver to a solution. And so when we have this complexity, we have to work together towards these. So it's not a it's not something that's only done over there, it's something that we do together and we we solve problems together. We don't uh make it somebody else's problem.

Well, I I think there's another piece to that, which is in the past, and uh I'm being somewhat general here, but in the past, innovation was a small portion of what we did as an organization. A lot of what we did as an organization was just execute extremely well. And the focus on execution was driven through efficiency, and that we kind of as we get more and more efficient and impactful, we want to stabilize that as an operational kind of way of working. And so innovation becomes something that a 10 or 20 percent of the organization is focused on. But I think today innovation is every organization I talk to is hungry for innovation, they recognize the need to innovate, and you can't take a 10 or 20 percent and just kind of keep scaling that department up. We need to take that thinking in that 10 or 20 percent of the organization and make it how we think as an entire organization. It's a it's a cultural shift, if you like, more than a scaling of what innovation was in many organizations five or ten years ago.

Exactly. And it's it's not just about and it's not just about that product innovation, which is where it often gets landed, it's about process innovation too. It's about how do we how do we do the work, not just about the product that we produce as well.

I mean, uh and even how do we execute on our strategy, because I always think of Dell. Dell was they weren't product innovators, they were process innovators. They figured out how to get computers into your and my hands, and I'm sure both of us have used many Dell machines in the past. They got a Dell machine into our hand without all of the hoops and bells and whistles that a lot of other organizations and and uh retail structures put in place. So innovation is not tied purely to the physical product or the service, but is tied to business processes, tied to delivery processes, tied to all of these different elements that allow us to explore our domain and execute on the other.

Another reason that I've I've seen that uh you end up with the innovation happens over there type uh mode of operating, uh, is because uh they there's a recognization recognizing in the organization that uh the uh failure is bad and that they so people don't feel comfortable with failing, and so they so the organization does is well we we don't want to tackle that because that's difficult to tackle. So we're going to create another group over here who doesn't have some of the constraints that the rest of the organization has, and then they've got more freedom to operate and they can start to experiment and learn.

And we can live with them tripping up over their shoelaces and and somehow it's going to be different over there. I I think you that idea of that psychological safety of making mistakes and learning from them is it's a foundational block in any learning organization. And part of the challenge is a lot of organizations they want to be and they state that they are learning organizations, but when we look at the execution to deliver, our goal is to execute to deliver with the minimum variance possible. And so in that context, we don't handle mistakes well. And and I think this is what Toyota did it remarkably well with. But it's really difficult to get that that psychology of this is how we're going to do stuff, versus the the sort of not bringing in uh holding people accountable to doing exactly what our execution process is.

Trevor Burrus, Jr. And uh another piece that uh that I see, especially in larger organizations, is the the lack of visibility into the impact of their actions. So there's no feedback loops to be able to learn from. So and even when there is, there's a I'd I'll give you an example, um, a certificate expiring. I see this all over the place, like certificates expire. And uh the problem is that it's a two-year certificate or a one-year certificate. So potentially by the time it expires, again, nobody's the person who is there doesn't know about it. So what ends up happening is that every two years certificates expire and the whole system goes offline. Um repeatedly every two years. Yeah, like clockwork, in fact. Almost exactly. Like clockwork comes offline. You could set your watch fire if it's well, I mean Literally.

I think that this is the part of that is the um when we're moving fast, we have a tendency of of solving the immediate problem, but not shoring it up so it's solved in perpetuity. I mean, this is the argument in not an argument against test automation, but is why test automation isn't everywhere. I can fix something, and I don't necessarily think how do I make sure that never is occurs as an issue or a problem in the future. What what process can I put in place? What code can I put in? What tool can I use that means that this thing that that happened like clockwork two years after the last time it happened doesn't ever occur again. And that actually takes time. It's not that people don't have the skills to do that or the intent to do it, but they can't do that if they're immediately pulled off to the next certificate that is expiring or whatever other problem is.

Exactly. They have to be given time to respond and build that in, and so that the learning can occur. So not only the learning can occur, because they might have learned what it is that they need to do and they've learned what piece, but so that the action of actually doing the innovation, the remediation, the setting things up to be able to do things differently can actually occur as well.

It's the classic Slack, right? We need Slack in the system, and we're in a world where efficiency is king. Where do you get the slack in the system? Right, exactly.

So so if we were to wrap this up for our listeners today, how would you wrap this up?

I I think we started with innovation has to get out of that 10 to 20 percent innovation department headspace. So I think that's one of the first things is recognizing we have to think of innovation as a culture across the organization, as a mindset that we all bring to the table at some point, rather than something that we hive off and it's on the 14th floor or it's in this particular group or whatever it might be. I also really liked the point that you made about uh innovation sort of being everywhere, it's not just product innovation, it's process innovation. Even when you hit process, there's a business process, there's our delivery process. So innovation is everywhere. We're learning, and there's an opportunity for us to innovate in many, many corners of the organization. Again, why we need the mindset. Um the third sort of point would be around the learning organization, I think, in the psychological sector and just providing I mean part of that is Slack and allowing people to be thoughtful about what they find and be able to remediate that correctly so that it doesn't recur. It's it's a problem that is no longer a problem rather than a problem that is solved but is going to become a problem again in the future. But a lot of that has does tie into that psychological safety, that comfort with tripping up our own shoe over our own shoelaces.

Yeah, build building into the organization that it's okay to fail, that uh that we'll support you if you do, and that we and making it safe to do so, and that psychological safety is critical for that.

But I I'd even I I kind of think that okay to fail, it's expected that you will fail. There's a different okay to fail is yeah, that's okay, but expected is yeah, why aren't we failing enough?

That's exactly. Well, this is uh this is a great one from the the concept of SRE and error budgets. The the idea that you you're the intent of an error budget is that you use it. That uh if you're not consuming your error budget, you are not innovating and going as fast as you can. So you should be using up your error.

That's a great I think that's a great way to sort of thought for us to end on is error budgets, learning budgets. How are we using awesome?

Well, thank you very much as always, Dave. Really enjoy these conversations. Uh if anybody wants to get hold of us, they can at uh feedback at definitely maybeagile.com. And I look forward to next time. Thanks. Excellent. Thanks again, Peter. Talk to you soon. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.