#61 - Todd Conklin - Why the Best Safety Systems Assume Failure

So there's gonna be managers who listen to this podcast today who can tell you stories of a worker who comes in the office, shuts the door, and says, I really screwed up. It's my fault, my bad. I know better. I should have locked it out. I didn't. I was in a hurry. I mean, they make a million excuses, right? That critical self-blame, we, we as leaders in an organization, we have to be able to move beyond that. And so we have to say, I know it feels this way. I mean, and you recognize that they feel that way. I know you feel this way, but if we stop there, all we've learned is that you screwed up, and that's not very helpful to creating sustainable change. So, we want to understand, you know, how you got into a position where that potential failure was possible.

Welcome to the podcast, everyone. Today, we're sitting with someone the industry calls the godfather of HOP.

Who calls me that?

Well, I do. That's made up. I hope other people do. I'm

sorry, I interrupted the introduction.

Oh, perfect. That made it even better. But yeah, so Todd spent 30 years at an organization that literally built the atomic bomb. As a senior advisor for organizational safety culture, you basically spent 3 decades in a place where the consequences are just extremely, extremely high, and the margin between safe and catastrophe is razor thin. every day compared to other industries and other businesses we've been working with. Todd authored so many books, I think 6 books overall over 20 years, but the one I'm most familiar with—

I think it's like 14.

14?

Yeah, it's crazy.

Man, how do you—

Nah, they just shoot out. It's no big deal.

Yeah. And I think the one that had the most influence on me and so many of the safety leaders I talk to is The 5 Principles of Human Performance. I think It's the one book that I have safety leaders like pick up and show me when they're referencing topics, and it's just extremely powerful. Wow. It's had that much influence.

Thanks. What a sweet thing to hear. Thank you.

But yeah, there are a bunch of amazing things, man, that you've done, but I think everyone who's in this space probably knows you and heard of you, but honestly, super grateful that you found the time to jump on. Thank you for being on.

My pleasure. Yeah, my pleasure. No problem at all there.

Cool. So Todd, I dug into some of the work you did initially, and I know you've been doing podcasts for a long time. And I looked at your, the first podcast that you did. That

was like 12 years ago.

Okay, so that might not be the right one. The one I found on Spotify was March 4th, 2020.

Oh no, I've been doing it for 12 years. I just, the reason I know that is I just had to look it up. I wouldn't have known that yesterday, but yesterday afternoon I had to look it up.

And you're consistent, man. Like, you've been posting consistently, which is awesome.

They started in 2015. I'm trying to find podcast number 1. There it is. And the date on that is January 29th, 2015.

Wild.

And the guest was like—

That's like such force.

Steve de Albuquerque, who at the time was the director of safety at ConocoPhillips globally. You've— it's so unfortunate. I'm so, I'm so sorry somebody asked me that yesterday because I just happen to have all this. I would never know that crap.

Yeah, I literally, like, the episode I went into on Spotify, I picked up something that I really liked that you mentioned. But honestly, like, I'll divert that a little bit before I read what I heard you say. How was that like, man? Like, if you look back, can you remember that conversation? Like, what were you thinking? What got you into—

Oh, probably. So when I was in college, in university, I was a disc jockey. And it was a great— it's actually kind of a good gig to have while you're in university, except it sort of sucked because I had to go to work at 4 in the morning, but I was on a little morning team and every morning, 5 days a week, we would do the morning show, kind of the wake-up show. Mm-hmm. So I had a background in doing radio and podcasting in the olden days before, you know, now was much more like radio than it was like anything else. And so it was pretty fun to do. And I'd been working with the human performance stuff for years, so I knew lots of really interesting people. That's the fun thing. It'll be fun to watch your podcast as well as you progress because you don't ever run out of interesting people.

I mean,

it's funny, I made a promise that I would stop doing podcasts when I ran out of stuff to say. And I think I might be out of stuff to say, but the people I talk to all have Lots of stuff to say. And so it's kind of fun and interesting. And I'm sure we talked about— I'll need to go back and listen to that, actually. I haven't listened to it in all those years, but I'm sure we talked about kind of some of the same stuff that we'll probably talk about today. It's fun how human performance has changed in those 12 years. I mean, we certainly are smarter than we were 12 years ago, but that's good. I mean, I would expect that. I would hope we're getting smarter. If not, I'm not sure what we're doing.

So you do feel like it was still a concept? It was a concept that you've kind of been thinking about even back then in 2015?

Oh,

yeah.

Yeah. Well, so I started thinking about this as a work assignment probably in either the late 1990s or early 2000s. So this has been around a while, these concepts. They were really a big part of the discussion, at least at Los Alamos, we were having around kind of how could we take safety to the next level. And I always kind of think about this, that I don't think of human performance as what's new. I kind of think of human performance as what's next. And I'm curious to see what will follow the human— what human performance will breed. Because all these ideas kind of breed new ideas and new ideas. But we worked really hard at a place like Los Alamos because your introduction was amazing, and thank you for that. The crazy thing about Los Alamos is the work was so critical, at least as related to risk. It was critical for many reasons, but it was pretty high-risk work. And we really worked diligently to understand and to keep the margin between disaster and normal operations as wide as we could. And so, we had to look for ways pretty early that were different than the traditional safety approach that was being used in industry. And it's interesting because Eric Hollenagel has a new book out now where he calls it incremental and decremental safety. Interesting. And it's a really interesting way to look at it because incremental safety is making work better, Incrementally improving. Decremental is removing harm. So we kind of shifted from the classic, we need to manage all risk and mitigate all risk, to we need to make it easier to do work more reliably and safely. So that's what we did. And it's been a super interesting journey because one of the things, Musa, that was— That's very interesting to me is that when we started this discussion, With Tony Mashara and some of the IMPO guys, James Reason, the original Clambake Clan. I mean, all kind of the people, Jens Rasmussen, all those guys were a part of this discussion a long time ago. And when we started this discussion, it's really funny because we started thinking we could manage human error, that this was about management of error. And what we've realized over time is that that's really, that was probably an important thought to have, but that's not what happened. In fact, what we learned is that error is inevitable and it's not a choice. And because error is inevitable, it'll, it's gonna happen and people are gonna screw up. And because it's not a choice, you actually manage systems that can tolerate human error. So, you know, reason said you can't change the human condition. But you can change the conditions around which humans do their work. And that's really been kind of the watchword. I don't know, what do you think?

Yeah, I mean, you know—

What's been interesting to you about all this stuff?

Yeah, I think, like, in my journey in the world of safety, I think I went through a similar journey to what most people go through. You know, I always thought that the life-saving rules and thinking about SIFs and thinking about human error is the way you manage safety, and it was literally built a product around it. But then going through that shift, that aha moment of like, wait, manage the systems around people, you know, don't blame anyone, like blame. And I don't only think about it from a place of safety anymore. It's something that really helped me in my management and leadership. And I think it's just a fundamental leadership framework of like, how do you operate within an organization for people to feel safe, being in a better version of themselves and to multiply them? But you know, when I reflect on your journey though, Yeah. You know, I still talk to organizations now who are still looking at human error as the main thing they're trying to solve.

Right.

And you've gone through that journey a long time ago, and you've been a voice that's helping many people go through that aha moment realization. But—

Yeah, because they won't solve it. So, if we can save them time by saying, you know, you can't assume that error's a choice because it's not. And because error's not a choice, asking people to not make error, Is not a very strong control. I mean, it's not a good barrier. It doesn't really work because of course they'll choose not to make a mistake if given the choice, but most people don't have the choice. I mean, mistakes are really insipid. They kind of sneak in and out. And that's a super interesting world. I mean, that's pretty crazy. One of the things that happened with me is that in the middle of my journey, My boss said, we need you to help us manage a group of software engineers, basically database— What? DBAs and SAs. And I said, but I don't know anything about that work. And my boss said, well, I don't really need anybody who knows about that work. These people know that work. What I need is somebody who can be creative and help manage them. Because at the time, this group, it was a rather large group, Really impressive group. They were eating their leadership. It was really difficult to find leaders who could be effective with that group of people because that's a strong, I mean, that's a strong personality set. So I got that job. I didn't necessarily want that job, but I got that job. It was amazing.

When was that, Todd?

Gosh, I don't know. I'd have to think. It was a while ago for sure. And what's interesting is that I learned more from those Especially the SAs and DBAs, you know, the system administrators and the database administrators. I learned more about systems thinking than I'd ever, I'd ever learned in a million years. I mean, the software people were great. The people who were writing code were great, but they were easy to manage. You just get them a new monitor and kind of don't talk to them. And, you know, remind them to shower every once in a while. Hey, you should probably go home and shower. Yeah, right. But talking to the people who ran those big systems, and these were the system that we were involved in, was a really important, really significant system, very important system. And talking to those guys, and I learned so much about how the system influences the outcome and how you have to build a system that's tolerant, that can tolerate You know, user error, that can tolerate power glitches, that can tolerate technical difficulties, because the more tolerance you build in the system, the more robust the system is. And what's funny is in bringing that back into the high-risk work, it made perfect sense. I mean, and you look at systems, you look at systems that fail and they fail in these brittle places.

Right.

Where there simply was not enough tolerance in that system for that system to actually have variation and recover from that variation in a way that's effective. This plane crash that just happened in New York in the United States is a really interesting one because you have emergency vehicles crossing runways. Well, I mean, say what you will, but when they designed that airport, they put the fire station on one side of a runway. So the fact that the emergency vehicle in an emergency situation is gonna have to cross the runway is not a surprise, but it's incredibly brittle.

I didn't dig into that. Like, I just saw it on the news and I just read like one headline saying the pilot had actually like submitted complaints about that as well.

Yeah. Yeah. Well, because that brittle place is gonna give weak signal indicators, or in this case, a loud signal indicator that that part of the system, the design of the system, was weak. And so, I mean, that's what you think about.

Yeah, it's interesting how you've been put in that situation where you had to manage very technical system developers, particularly database specialists. And fundamentally, within a system that shouldn't fail, you just have to build contingency for failure. You have to think of all these different situations because you understand that at scale, Everyone's gonna make mistakes. When you're in operation, you don't think about it that way.

And what's crazy about that is that safety engineers would do like a failure modes and effect analysis. They would say, okay, how many ways can this fail? And do we have enough mitigating factors in there? But that's not how database administrators or software system administrators really look at it. They actually assumed failure could happen anywhere.

Anywhere. Yeah.

And so they didn't seek ways for the system to fail. What they would do is monitor the system's ability to recover. So it was all about identifying a problem and then how long it took to identify the problem and then fixing the problem or the system identifying the problem and fixing the problems. And I remember when they first introduced the concept of Chaos Monkey to me, because, you know, I didn't know anything about this world. I mean, I'm, I mean, nothing, nothing, nothing. And they were talking about chaos monkeys and I was, anything that has the word monkey in it, I'm kind of interested in naturally because monkeys are super interesting things. I mean, they just are, right? Yeah. And they were talking about putting in the chaos monkeys and they would actually put in failures. They would program in failures and not tell each other and then time how long it took the system to identify the failure, and then what the corrective margins were around that failure, what the recoverability was. And what's crazy about that is those same ideas apply in human systems as well. I mean, I'm not sure we should use chaos monkeys. Well, I mean, I think we don't use enough monkeys anyway. I'm pro-monkey.

Yeah. And it's like, there's so many directions that I want to go, but like just going into this, It's like, it feels lighter and less intense if you just assume things are going to fail and operate that way, you know, versus trying to like overthink and overengineer and overstress simulating failures and working in that direction. And as we were talking, I'm just like thinking—

But you know that what you're saying is very, very controversial, that for the most part in our workplaces, Places that have things like, you know, cardinal rules that you were talking about, right? Right. Lifesaving rules. Those places assume the system is perfect and the person is flawed.

Yeah.

Right? So if they just did what they're supposed to do, if they just followed the rules, they wouldn't be injured or they wouldn't die. That's the whole basis of these lifesaving rules is that the rule reflects the system and the system is perfect, or the system is stable. They wouldn't say perfect, but I would say they're really saying perfect. Whereas in the software side of the house, it's a flip. They assume that the system will fail. That's not a— you could never write a rule that's not going to stop cloud computing from having a failure. They have probably thousands of them a day, right? I mean, lots of things happen all the time. So they assume the system will fail and they put their onus on building that recoverability into that system, which is one of the problems with things like life-saving rules. Life-saving rules sound super sexy, like, oh my God, this is so beautiful. We have 8 things, and if you follow these 8 rules, you'll never get hurt. I mean, this is the perfect, you know, never stand under a suspended load. You know what the rules are. You know, never work without isolation, blah, blah, blah, the 8 rules. Well, the crazy thing about that is that assumption is that the system is perfect, the system is stable, and the people are adding variation. But here's what we know. The people add variation. Yes, that's true. But the world also adds variation, and no system is ever complete enough. to accurately reflect the reality that the system is operating in, in the current state. Then add to that the notion of entropy, that every system is running degraded, and you have a place where you look at life-saving rules and think, hmm, maybe they're not exactly what we think they are, right? Because they're really about controlling behavior. And the belief is, is if I can control the worker's behavior, Then I control the worker's outcome. The problem with that is that it doesn't count normal operational variation that exists every single day, all day long. I mean, that's my favorite story about these, these software guys, and it was really true as long as you didn't talk to 'em and you really did kind of have to remind them to take showers and go home. Hmm. But the one thing they would do is when they ran their beta tests on their software, They would beta test it using something they called the butt test, which I always thought was really funny. And I was like, I never heard of

this.

What's the butt test? I never heard of this. And this guy's name's Justin. He said, I sit on my keyboard and I see what happens because that is a very realistic potential outcome.

Oh,

that's so good. And so, and what he was saying, I mean, he was really kind of, Dramatically creating a metaphor, is that they try to fail their system as hard as they can in every way they can. And then, and it works really well. You can see where like things like chaos monkeys make total sense. I mean, build failure in, and then therefore you're not expecting perfection, you're expecting failure. It, it's like the phrase. So if I say practice makes perfect, what does that make you think, Louisa? Practice makes perfect. You've heard it a million times. You've heard it your whole life.

Yeah. Yeah, just keep practicing, keep practicing, and you'll be okay, you know.

Yeah. So you don't practice, you don't practice to be perfect. You practice because the potential to be imperfect always exists in the system. So you don't practice to make perfection. You practice because of the imperfections that exist in just normal life, in what happens. And that's, that's how, when you look at systems that are really robust and good, They're tolerant. They have tolerance in there for variation. They have tolerance for failure.

It's so interesting how you reflected on the rules and like standard rules within industries. Typically, what I usually see when I work with safety leaders, they don't see them as— and I wanna hear your perspective more there, but I don't see them typically see them as like a one-size-fits-all, but they see them as one piece that follows human performance mindset as well. But they say fundamentally, when we have new people coming to sites, it's for them to be aware of the things that could hurt them.

Why aren't they called 8 life-saving controls or 8 life-saving hazards or 8 life-saving practices?

Risks.

Yeah, risks. Risk would be better. They write them as rules and they put the onus for handling that hazard on the worker. Never ever do this, never ever do that. But in reality, what you'd want to do is take those same 8 things and say, when we do this work, what keeps us safe? Fall protection is the one I would use because it's easy to talk about, right? When we're working at height, what keeps us safe is the presence of a harness. So we never climb without the harness. I mean, but the harness is a control. It's not a way to punish people. It's a way to celebrate the, as David Woods would say, celebrate the graceful extensibility of a system that knows it will fail. That's why systems that know they'll fail are sexy, is because they know they'll fail. And so they build in graceful extensibility. The one you ought to look at, Melissa, because it's super, super interesting to me, is that Kathleen Sutcliffe, do you know that name? No.

No.

Yeah, she was part of the early group of scholars that studied high reliability. So HRO, highly reliable organizations. I actually think they call it highly reliable organizing, but HRO. Sutcliffe is now at a university in the United States called Johns Hopkins, and her and her peer scholars studied medical risk, patient safety. And what they learned is, is that people don't die in hospitals because of exposure to risk. They die in hospitals because of a lack of rescue ability, a failure to rescue.

Wow.

Now, I want you to think about that a little bit. That's super interesting for people who do what we do. Because it's not that they're exposed to the risk. That's pretty normal in a hospital because people go to hospitals because they're sick, right? Some of them are going to die. I mean, hospitals are not great places to hang out, right? Like there's never been a really good club located in a hospital. That's just not how it works. Our hospital at the penthouse level, they have a beautiful bar that rotates. Nobody says that, right? What's interesting is that their research really showed something that we're talking about right now. And the software, the DBAs and States knew this a long, long time ago. They're way ahead of us on this, is that it's not the presence of the risk, it's the lack of the ability to recover. That's where the failure happens. And that's a way, way, way, way, way different way to see the world. But I promise you, systems that are really good at it are good at being a system because they're highly recoverable.

It's like, focus a lot of your energy as an organization, like for someone hearing this or What I'm contextualizing here is spend enough time thinking about how you're going to recover and get really good at how you recover from risks and issues. And that's going to significantly reduce actual serious injuries or fatalities. They might happen, but you have consequences, but you're ready to react and you have— Yeah.

I'm really not sure you can define events. I mean, defense are Kind of in the eye of the beholder. But what it does reduce is things like the consequence. So when you look at fatalities, one of the things I would question about fatalities, and the jury's still out because this is really, really difficult to measure because there's a lot of moral and ethical implications. And ultimately you don't want to do a research project where, you know, where people have to die in order for you to get your data, right? But I will tell you that my gut tells me, and this comes from people like software engineering, that people don't die at work because of the presence of risk. They don't die at work because we failed to prevent the accident. They die at work because we failed to recover. So, and that's kind of what Matthew Holloway's— Hollowell, I can't even talk. That's kind of what he's talking about when he talks about the energy wheel, which has been around a long time. But he says, you know, it's the release of energy that kills people, not the lack of discipline or the lack of following the cardinal rules. I mean, one of the challenges with life-saving rules is the belief that all those rules are followable. I mean, they're just not depending on time and reality. It's not.

Yeah. Yeah. Like the, what we sell more than anything as a company are things like the life-saving rules or sticky The approach we took is actually putting people in like a Call of Duty-like simulation where they're outside, they have a role, and you play through a game and you learn through. Yeah, exactly. And we're trying to get you to a place where you actually can stop work, you're living through a real experience, but you actually see incidents happen that are very dramatic.

And Sticky's just clever. I mean, when all this Sticky stuff started, I remember this vividly. It was a really fun part of hanging out when it started. You know, sticky was not the important thing. So the only reason you identify it's, it's the clever thing. I mean, shit that kills you is clever and it's really memorable. And I mean, it's got that going for it, but it's not the sticky. The sticky identifying what's risky is only half the battle. It's then ensuring that you have the right controls in place. To do that risky work successfully. So, when you look at stop work, which you brought up, I didn't bring up, one of the things sticky helps you understand is that stop work is not really very effective. And the reason it's not very effective is because if you're counting on a worker to stop a job before it kills them, what that really tells you is that every other single control you had in that system failed. And they all failed at the same time. I mean, they all failed. Yeah, we're all in the same time. What sticky helps you understand is that you actually start safe. So it's not stop before you fail, it's start when you're ready, start when you're prepared, start when the right controls are in place, start when you have recoverability. Does that make sense?

Yeah, yeah, yeah. And then just by telling the person like, stop before you fail, you're putting all the weight and all the pressure on that person being like the point of failure and— Well, you know, it's better.

And, and you're expecting them to be psychic. I mean, I promise you, if you knew it was going to fail, you'd have stopped. I

mean, and then you'll blame yourself for not stopping work and like, hey, why didn't you take action before? And didn't you notice this? That's so powerful. And it's like, so how do you embed the two is a very interesting thing. It's like, how do you start putting the weight of teaching on the controls and the systems and the recoverability? How do you make your ROI when you learn? I love it.

Call of Duty game illustrate that. I mean, that's the kicker, right? Is if you're making a cool simulation that people want to do, right? Because say what you will about Call of Duty, but it's pretty dang popular and people like it and lots of people spend lots of hours playing it, right? Well, make that Call of Duty simulation that you make, make it emphasize the values we want to see. So give them extra points for, you know, having the right controls in place. I don't know, I'm making crap up, but I've never really played Call of Duty.

Yeah, yeah, yeah. It's honestly, it's simple changes to focus less on, hey, be aware of this risk that could happen, to, hey, understand how you recover from that, understand how the system led to that, led to that risk, but contextualize things in a bit of a more robust way. Yeah. Yeah. And you know, as you're speaking and just going into the topic of blame, I don't know, like my gut, just hearing you speak, I feel like blame is such an innate human—

Normal.

You know, human normal. That like, do you feel like it's a big part of where people fail? As in blaming and thinking about how people should have been better and the mindset of blame?

Yeah. I mean, I would say organizationally, blame is a problem, but not for the reasons that you think it is. I mean, it's a problem because it's morally crappy. It makes you feel like poop. It makes you treat other employees badly. The worst blame you can do is when you blame yourself, right? So blame's icky and awful and not very helpful, but that's not what worries me. What worries me about blame is what blame does is stop organizations from learning.

Mm-hmm.

Because as soon as you figure out the problem is this person, Fred, Fred screwed up. He didn't follow our rule. He didn't, he didn't follow a life-saving rule. He didn't follow our procedure, whatever. As soon as you find that origin, put quotes around the word origin of the failure, then you no longer have to do any learning because you found the problem. And as soon as you feel like you have the problem, then you stop asking the questions. So the reason blame should be kind of insulting to organizations, especially organizations that want to do either really high-risk work really well, or want to improve, or want to be efficient and effective, or want to make money, or want to succeed, kind of most organizations, the reason blame should be insulting to them is because it stops them from actually getting better.

From learning.

I mean, the, the, the, yeah, it, it does. It stops them from learning. And, and one of the things that's really, important to realize is that the minute an organization stops learning, then it's going backwards. I mean, then it's not learning, which means it's not improving, which means it's not becoming more efficient, which means it's not making more money, which means it's not making an environment where workers feel successful. I mean, it's the opposite of getting better. It's getting worse.

I know, Todd, you've done quite a bit of work with Rhonda, who like where you dig deep into how blame can really backfire. You know, with everything you've done there, what comes to mind as like the deepest learning or what comes out of that story as something for people to learn from?

Well, ultimately, I think there's 2 things. One is that usually the person who's quickest to go to blame is the person who had the event. So there's going to be managers who listen to this podcast today who can tell you stories of a worker who comes in the office, shuts the door, and says, I really screwed up. It's my fault. My bad. I know better. I should have locked it out. I didn't. I was in a hurry. I mean, they make a million excuses, right? That critical self-blame, we as leaders in an organization, we have to be able to move beyond that. And so we have to say, I know it feels this way. I mean, and you recognize that they feel that way. I know you feel this way, but if we stop there, all we've learned is that you screwed up. And that's not very helpful to creating sustainable change. So we want to understand, you know, how you got into a position where that potential failure was possible, how we set you up.

Yeah, that's so true. Honestly, like that, that one move by itself, imagine how you've really helped that person. And we're just so critical on ourselves and the person who was involved in the incident probably just naturally looks at what they did wrong and what they should have done differently.

Well, and we could talk about where that comes from. I mean, it's really a part of human nature. Friedrich Nietzsche studied it, you know, this kind of existential shift. I mean, it's been around a long time. It's hardwired into the human condition. And the interesting thing to me is that every single leader who's listening to you today will have gone through that experience. So we know it happens all the time. And it's oftentimes easier for the employee to take the blame, to take the guilt, because then they remove the guilt from their coworkers. They take their medicine faster and we can get on with whatever's going to happen. I don't have to live in it. If I'm going to get fired, I'll get fired. Or if I'm going to get 10 days off without pay, I'll get 10 days off without pay. Whatever's going to happen, let's just, let's get it out of the way so I know what's going to happen. So I don't have to live with the sword of Damocles hanging over my head waiting for, you know, the shoe to drop.

Yeah, man. Like going back to the, to the particular Ronda situation where someone was criminally prosecuted, that's like an extreme case that I'm sure would just hinder learning completely, right? Like just not everyone with it.

It also completely shuts down communication. But what it really does is it criminalizes error. And if you criminalize error, then you're going to— then error is going to go underground. Any error I make that I don't have to tell you about, I'm not going to tell you about because I got other crap to do. I'm busy. I'm not going to spend a lot of time on stuff that I don't think is important. And if we drive human error underground, then what happens is we don't know where error happens and we don't know where to make the system stronger. more robust and more flexible, right? We don't know where to put the margin, or again, David Woods, my favorite phrase, we don't know where to add the graceful extensibility. You look at that fire truck that hit that plane and you think, wow, could they not have built an underpass for the fire truck? Because they knew it was going to have to cross that runway. Could they not have built a way for that to happen so that both could happen simultaneously? Now, I have the benefit of hindsight. But I can, I can tell you that smart people understand how to make good systems. Remember, the key is that a well-designed system is invisible.

Yeah.

A really good system doesn't point itself out. It just works. I mean, and if you think about, I mean, there's a—

So, which is the paradox here, you know, it's like a very well-designed system is a system that probably leadership doesn't understand the value of as well.

Yeah. And nor do they know it even exists. And so one of the questions you want to ask is what systems are good, right? Because a good system is 99% invisible. I mean, it just works. It works every time. It works every single time. It's brilliantly designed, usually over time with lots of experience and smart people, but it works beautifully. Bad systems are easy to see and they show up all the time.

It's like always design systems in a way where you are accounting for failure, just move away from any blame mindset if that comes about, but then nurturing and learning. Like, I feel like the way you talked about this, where if you're a manager and anyone comes to you with clear facts of here was where I went wrong, like, I'm not gonna just be satisfied here, you know, we're not gonna stop here because let's learn together. And I know you talk so much about like learning teams and how to nurture that culture. What can you share there, Todd? Like,

Well, so I would add one more thing to your list because you made a— like, you should go back and play this because you made a beautiful little list of things to do. And you should capture that because that's what people want to know. I've never thought to do it, so you're doing it without me. I would add one more thing to that. And the only thing I would add to that is that expertise lives at every level of your organization. And so you have experts working for you already. who understand what you do. Those people aren't the problem to be policed. They're not the victims of your rule following. Those experts really are what keeps you operating and running. Because basically we live in a world where we have less than optimal systems being run by highly adaptive pretty brilliant human beings. If you took the brilliant human being out of the less than optimal system, the system would suck. Well, you'd probably be paralyzed. It'd probably stop work. I mean, that would stop work. If you took workers out and you said you couldn't adapt, you couldn't problem solve in real time, then what would happen is the work would go away. Right. The British transit strike's a really good example. So we know that every time the bus drivers in London go on strike, they don't really go on strike because they can't really go on strike. What they do is something called work to rule. And are you familiar with what work to rule is?

Mm-hmm.

What work to rule is, is they say, okay, you won't let us go on strike. What we're going to do is we're going to follow every single one of your rules perfectly. And it shuts the facility completely down.

Wow.

You really don't want workers to follow rules. You want— you don't want rote compliance to rules. You want them to give thinking compliance to rules.

Yeah. I'm gonna throw a curveball on this because we're talking about like, it's so true. Like, the people you work with are brilliant and it's about like removing constraints and really empowering them. And of course, every company is going through this thinking now of, you know, automate things with AI. Agentic AI allows you to set processes. Everyone's struggling to find a job. What's your perspective there, man? Like, how do you, how do you think about how that's going to play out?

2 things. 2 things about that. I think about this a lot too. One is it absolutely will remove people from some jobs without question. Jobs are going to go away because they're going to be automated. No question about it. However, comma, lots of people will have to stay. And automation won't replace those people. It will change how those people do their work. And so part of what we have to understand is the efficiencies, again, put quotes around the word efficiency, but the efficiency gained by making some positions redundant is real. That's going to happen. And I think it's going to be interesting Musa, because it's not going to be the guys who load pallets on trucks. Yeah. Not, at least not for a while, because that's pretty variable and robots can do it, but they don't do it really well. They're efficient.

It's going to take time. Yeah. Yeah.

It's going to take time. Right. But it is going to be, I'm guessing this, I mean, I don't have any data. It is going to be people like lawyers and doctors. Yeah. These knowledge workers, because that knowledge is, is is capturable. And to a great extent, AI's better at doing that kind of analysis than people are. And so I think those jobs will go away. But I'm thinking about how podcasting has changed. Yeah. Like 12 years ago, I would have to spend a couple hours managing levels and getting your voice and my voice so they're similar. All that's done automatically. AI does all that stuff now. All of it. I mean, I don't do anything anymore. Right. It writes the summary, it does the closed captioning, it does everything.

Everything. Everything about like, does the outreach, sends the emails, creates even the campaign marketing assets.

Names it.

It's like ready. Yep. And repeats it every Sunday, does its bulk of activities and names it. So does the thumbnail. It's insane.

It's crazy. It's crazy. What's interesting is that other jobs will mean workers will have to change their roles. Hmm. And so when automation comes in in those jobs, it's not gonna replace the worker. It's gonna mean the worker has to do different things. And that, that's gonna be interesting to watch. Will it be safer? Maybe. I mean, I have to tell you, I'm not the biggest fan of, of self-driving, but I can tell you that my car When it self-drives, it's safer than when I drive. I mean, it is.

Yeah, I mean, the stats show that it's a bit—

No, it is. It's definitely safer than when I drive. And I can tell you that I'm less fatigued and in a better mood on a long journey because I have self-driving. So it's safer, more reliable, and I'm probably happier and healthier.

Yeah, honestly, it's interesting. I think another thing that's interesting is like, the way it starts off in the tech industry, but fundamentally it will kind of move across all industries to a certain extent, right?

Yeah,

totally. And this mindset of like, you have to be empowering the people, it's just like, I think it's going to be an interesting time for leaders to think about how to do this with compassion in the right way. And we're going to make mistakes in places we automate as well, because in some cases automation with the lack of a human who's really good at what they do is still going to give you the result.

No, absolutely. And you're exactly right. And automation will fail. Automation is not perfect. And, but software people understand that failure. And so they go in assuming the failure's there and then looking for ways to recover. And that's a huge difference. But I would encourage you to think about the word empowerment. I mean, not you, well, you, but I think we all have to think about the word empowerment because I, that's why I really like the model, the phrase expertise lives at every level of the organization.

Mm-hmm.

Because it's not so much about empowering the worker, it's about the organization understanding that there is data and information that the organization must go out and actively seek. So last thing, and then I gotta run, but sadly, because I would hang out with you forever.

Yeah, man. I've had a great time, man. Yeah.

But like these speak-up programs, right? The amazing thing about a speak-up program is it's not about the speak, it's about the up. The companies that say, you know, we're aggressively pursuing a speak-up program, we're telling our people to tell us what we need to know. You know, we're demanding that they tell us, they need to speak up, they need to tell us. Well, ultimately, telling the workers to tell you the truth is fine. But the more rich question is, is what have you developed where you can listen to what the workers have to say? Because it's more about you being available as a leader to listen than it is about the worker being available as a worker to speak. What do you think, my friend?

100%, man. Amazing to see you, Todd. Hopefully we'll see you when you're in London, man. Always appreciate you.

I'll be there in a couple weeks.

Yeah, please let me know when you're here.

I'm staying in the Mayfair. Yeah. The April, April, I'll be there April 26th, which is a Sunday, I think.

Amazing. And how long are you here for?

2 days. I wish I could, I, I would love to stay longer.

Yeah. So I'll pitch you, I'll pitch you some fun stuff.

You be creative and think of something fun. 'Cause what I really want is fish and chips.

Done. I got you.

But I think it's, I think it's during flower market, which is kind of a Weird time, but yeah, I'll be there. I'm giving some speech. So, all right, Musa.

Amazing. Todd, take care, Musa. See you soon.