[Mary] Hi there. Welcome to Safety Labs. There are a lot of safety and safety-related books out there. There's a body of research and an active discussion happening within the profession about how to improve workplace safety.
Today's guest felt that a lot of those books offer excellent insights, but don't always explain how to put their ideas into practice. So he wrote his own book to do just that. We'll talk about how he developed his ideas and how they fit into the larger world of occupational health and safety. Jake Mazulewicz has served as a firefighter, an EMT, and a military paratrooper. He's been the human performance lead of a 3,600-person business group in a large electric power utility. He's advised executives and field teams, helped analyze over 300 incidents, and led a North American team of human performance specialists for three years. Since 2015, Jake has led workshops, keynotes, or event reviews for organizations such as ASSP, Energy Safety Canada, US Department of Energy National Laboratories, and hundreds of client teams. Jake specializes in translating ideas from HOP and HRO into practical actions you can apply immediately. He joins me to discuss his book, "Seven Practical Steps: How to Build Reliability, Safety, and Trust in Technical Teams." Jake joins us from Richmond, Virginia. Welcome.
[Jake] Hi, Mary. It's great to be here. Thanks so much for having me on the podcast. Yeah, this is going to be a good one — I'm excited.
[Mary] So, before the book's main content even starts, you talk about a few techniques to make sure the lessons from the book stick. I don't think I've ever seen that kind of introduction before. Can you describe a couple of those techniques, and maybe why you decided to include them?
[Jake] Sure. My background is teaching and learning — my PhD is in education, so I've always been fascinated by how people teach and learn, and what they retain and what they don't. I've taught thousands of contact hours of classroom material, I used to be an adjunct college professor, did a lot of adult training, and I've sat through tons of presentations, some not very good, some good. I'll almost always walk away with an insight, a practice, a great idea — usually four, five, six, eight, ten of them, too many for me to retain just one. And I'll think, these are great ideas, but how do I keep them alive? How do I operationalize them, make them part of my regular daily practice? That's both a personal question for me and something most of my students and the people in my keynotes and workshops walk away wondering too.
So I always try to put things on one page or two pages — keeps things concise. The three things I put down — let me see if I can do them from memory. One is recall after twenty-four, thirty-six, forty-eight hours. After you finish reading a book, around twenty-four hours later, get a blank piece of paper, don't look at your notes, and take five minutes to write down everything you can remember. At first it'll seem hard — "I don't remember anything" — but you'll catch one word or phrase and then the floodgates open. It's important to recall from memory first, then look back at your notes and see what you remembered versus what you didn't, and notice the pattern. That's one suggestion.
Another is basically the same idea, but instead of writing it down, talk to a friend — for people who are less on the writing side, more extroverted. Twenty-four hours after you read the book, go have lunch with a friend and say, "Can I take ten minutes and tell you some of the things about this book I read?" It's not just for them, it's for you, because the more you speak it, the more you'll remember it.
The third tactic — I've got my calendar up on my second screen right now, and it's filled with repeating reminders: here's an insight, here's a practice, remember to do this, or just here's a great quote. I set them to repeat at odd intervals — seven days, three and a half months, whatever — so that when it comes up again, I think, "Man, I'd forgotten that," and it keeps popping up relentlessly until I decide I've got it down. Those are three things I put right at the beginning of the book to help with all the great ideas you get out of it.
[Mary] Yeah, I would think those would be fantastic. We all know the experience of going to a conference, getting really inspired by a speaker, and then a month or three months later thinking, I don't remember what they said, I'm not doing anything different because of it — so what was the point? So, safety pros, take note of a few of those, regardless of what you're learning. At the beginning of the book, you've got a really interesting phrase — you describe accidents as a consolidation of subtleties. What do you mean by that?
[Jake] Yeah, that was a neat phrase — I've only heard one person use it, but it stuck with me. It was my old advisor in graduate school, a very wise guy who got up every morning and read three newspapers. He said that almost any big problem we're trying to solve — as individuals, families, a nation, a company, neighborhoods — there's almost never one key solution, one secret ingredient. We see that a lot in Hollywood movies, just find the magic key. But real life isn't like that. It's more like Harry Potter having to go find seven horcruxes — you have to find several things and put them together.
A good example I like to give is losing weight and getting fit. You come out of the holidays thinking, I want to lose weight and get fit. If you just do one thing — join a gym — does that actually work by itself? Probably not. I can say that from experience. But if you try to do several small things together that reinforce each other — drink more water, park further away and walk, try intermittent fasting for a week or two — when you do several things together that resonate with each other, that's what he meant by a consolidation of subtleties. Losing weight, getting fit, getting out of credit card debt, building a nest egg for retirement, being a good parent, and being safe and reliable at work — none of those have one secret. What's the secret to parenting? I've asked dozens of people and heard dozens of answers. There is no one secret, but there are several things that the best, most reliable, safest teams do together. That's what I've tried to put in the book — my consolidation of subtleties is these seven steps. That's a foundational concept of the book — describing both the issue and the response or solution.
[Mary] For most accidents or incidents, there's the term root cause analysis out there.
[Jake] Yeah, and I've done RCAs and helped with RCAs. For really mechanical things — when one particular piece of a device breaks — you can sometimes find a root cause: it was this, the vibration happened because this went out of whack because somebody used the wrong grease six months ago. Fix the grease, problem solved — that's a root cause, and we need those. I don't want to minimize that. But for most of the errors or incidents I get called to look into, they're misunderstandings, miscommunications, human-based errors. There's no root cause for that — instead, you've got a consolidation of subtleties. Several things came together to make an incident happen.
[Mary] Okay, let's get into some of the steps — I won't always name them as the correct step, but I do know step one is good.
[Jake] Step one is based on the idea that an error is a signal. You describe two approaches to errors — the control-based approach and the learning-based approach. What's the difference, and why does it matter?
[Mary] I wish I could say I came up with this idea, but I've read about it and heard about it in so many different places. It's an archetype that's out there. I picked the names control-based and learning-based, but other people have made similar distinctions — between the old view and new view of safety, that's Sidney Dekker, or Safety I versus Safety II, that's Erik Hollnagel. There's definitely elements of that in here, but I picked these names because they were clear to me.
[Jake] The control-based approach: leaders who take this approach basically want to eliminate errors. Every error is a failure, and they want to eliminate it — full stop. Imagine working at a car factory building blue cars, and suddenly a blue car with a yellow hood rolls off the line. Something's wrong — that's a defect, a failure. In a car factory, or something very mechanistic like that, that's a real problem. But for almost any team where human judgment is involved — think of a medical team doing a surgery that has complications — there's usually no one thing that goes wrong, so there's no one secret to make sure things go right. Trying to apply a very mechanistic, control-based approach to everything is where the problem starts.
What I've found is the more adaptive a situation gets — meaning the more human decision-making and expert judgment is involved — the more you move away from a control-based approach and toward a learning-based one. Humans are constantly learning, adapting, changing, and making mistakes. Most of those mistakes are insignificant, or we actually learn from them — we need to make the mistakes. My thesis is that maybe a hundred years ago, the control-based approach fit better, when people were doing very simple, repetitive labor in factories or on farms. Now it's so much more problem-solving — the goalposts keep moving, as the saying goes, "they keep moving my cheese." So we've got to keep adapting, and a learning-based approach to errors is much more effective for that.
That said, it's not binary — you don't have to choose one and abandon the other. Everybody I know, every leader I respect, uses both control-based and learning-based approaches. There's always a blend, but everyone has a default — nobody does exactly fifty-fifty. Some people default to control and say, "Well, I guess we could have learned something from that too." Others — the ones I tend to like working with — default to learning, and say, "We could use this as a change in a rule, or put up a barrier here, but mostly it's learning."
[Mary] One of the things you mentioned — it's not exactly a thought experiment, but it starts a little abstract — you encourage readers to separate the error from the results of the error. And you say the error itself is not the cause of harm. Tell me more about that concept.
[Jake] It goes back to the idea of active and latent errors. An active error: imagine an electrician going into a substation, reading off a switching order, flipping a switch, and then hearing a big bang as the lights go off. You get immediate feedback that what you just did was wrong — that's an active error, because the feedback is immediate.
A latent error would be something like an electrician installing an underground transformer — one of those green boxes you see in yards — and doing all the wiring correctly, but forgetting to connect the lightning arrestor or grounding. It looks like everything's in the right place, but the first time lightning hits it, it's going to fry the transformer instead of going safely through the grounding wire. You might not discover that for days, weeks, months, or even years — the error's been baked in there the whole time. So in a latent error, the error and the consequence are separated by a long stretch of time. In an active error, they're right after each other — it's obvious you made a mistake.
Latent errors, where the error and the consequence are separated by time, are a lot harder to detect. You make an error in an Excel spreadsheet for payroll, it works out mathematically, the spreadsheet doesn't flag it, but it's wrong — and you run payroll on that for the next several months. Some people are happy, some are sad, but that's an error. That's why I say try to separate the error from the consequences of the error. The people who make the errors don't control the consequences.
[Mary] So maybe that's an initial approach — if there's a consequence, an accident, something, you don't initially assume there was an obvious, immediate error. You think, this could be a latent error, let's work backwards.
[Jake] Yeah. Some people are at higher risk of making latent errors — accountants, designers working in AutoCAD, people writing contracts, people writing computer code. It's fairly easy to make a latent error and bake it into a larger system, where it stays and compounds. One person writes an Excel spreadsheet for budget or payroll, dozens of people use it, and the mistake compounds. So one reason to separate the error from the consequences is, if you're in a job where those two are naturally going to be separated, you have to take precautions to make latent errors active — to detect them, because they're not going to be easy to find. Active errors will jump out at you — when the lights go on, you know you're going to need a Snickers bar because you just did something bad. But a latent error, you don't know you made it, and nature isn't going to tell you. So if your job involves latent errors, you've got to actively look for them, test for them, get people to double- and triple-check, run simulations, that kind of thing.
[Mary] Why is the concept of expanding successes, instead of trying to eliminate failure, important for safety practitioners?
[Jake] I always try to give credit there — that was popularized, not invented, by a guy named Erik Hollnagel, a professor out in Norway, who wrote some really good, thoughtful books, one called "Safety-I and Safety-II." Probably a lot of your listeners have explored it. He talks about Safety-I as a more old-school, twentieth-century idea — minimizing things that go wrong, minimizing accidents — and if we get to zero accidents, incidents, or SIFs, we're doing great. What he pointed out is that as we do that, we also get less and less data to learn from, so maybe we need a different metric: don't just minimize things that go wrong, try to maximize things that go right.
He popularized that idea, but I've also seen it in a different place — a guy named David Cooperrider, writing in the 1980s, came up with a concept called appreciative inquiry. He said when you're looking at an organization and trying to help it perform better, you can either look at what they're doing wrong and try to fix it, or look at what they're doing right and try to expand it. In theory, both might work. But have you ever gone into an organization or team and said, "Tell me what's not going well, tell me what you're screwing up at"? How does that conversation go? Most people don't want to talk about that — they're not even that aware of it, and it's like pulling teeth. That's what Cooperrider found. If you ask instead, "What do you all rock at doing?" people will love to tell you about that. You can usually infer from the pattern of what they do well what they might not do so well, but people are much more motivated to share and gush about what's going well, and they want to expand it, rather than spend time in the painful swamp of minimizing the stuff they don't want to talk about anyway. In theory, both approaches might work, but in practice, starting the conversation with appreciative inquiry tends to work better.
[Mary] That makes sense — people would open up and then be more receptive to discussing what's not going as well, once they know you fully appreciate the things that are.
[Jake] That's why I say start there. When I teach event reviews or do event reviews myself, I again want to give credit to Hollnagel. One of the first questions I'll ask in an event review — say a team was installing a bulk feeder splice for an electric utility and it shorted or blew when it wasn't supposed to — instead of starting by asking what went wrong, I advocate starting the investigation, or event review, by asking: how does this job usually get done? How does it usually get done right, safely, efficiently, reliably — ninety-nine percent of the time it gets done right, what we're talking about today is the exception, but how does it usually get done right? That's what Hollnagel suggests, and it completely shifts the vibe of the conversation — you put the frontline experts in the role of experts, and they'll tell you a lot more. What they'll usually tell you is, it ain't as easy as you think to get those things right most of the time. So instead of asking why it failed this time, the real question is more like, why do they succeed as often as they do? If you start the conversation by asking what went right, over time most people will naturally get around to, "that's not what happened on Tuesday," and then into what went wrong.
[Mary] Absolutely. Questions are powerful, and the book mentions the power of this question: if ten similarly experienced and trained individuals were in the same situation, would they make the same choice? That's a yes-no question — what does the answer tell us about the nature of the problem?
[Jake] That's called the substitution test. I want to give credit for it too, though I don't know the original source — I believe I got it from the US Department of Energy manuals. They're public domain, and they've been out since around 2009. A lot of people in the electric utility business have looked at those, given the natural connection to the Department of Energy, and they're free to use. I was actually honored to be one of the co-authors on the revised set, which will hopefully come out at some point — there were twenty, twenty-five guest authors, and I was one, so I helped edit that new version. But I believe that's where the substitution test came from.
It's such a simple tool to use. I've literally used it to end arguments when people in the room had decades more experience than I did. I'm facing down a lineman with twenty years of experience — I've never been a lineman, so there's no way I can argue what's right or what a lineman would do. I don't know. But if I'm doubting what he's saying, how do you compete with that? You use the substitution test.
The example I give: we had a guy climbing a pole in a very rural area where we couldn't get the truck back there for a lift, so he had to climb it. It was an old pole, around forty years old based on the tag, and when he got to the top, it cracked at the base and started falling over — it was rotted below ground level, where you couldn't see it. He got a minor injury, but it was muddy that day, so it wasn't too bad. The big question was — taking a control-based approach, leaders would say, that lineman shouldn't have done that, he should have tested it, should have, should have, should have — and we were in a bit of an argument, to put it politely.
So what I did was ask: if we had ten other linemen — not perfect linemen, because those don't exist, just normal, regular people who try their best, from different places — and ten of them looked at that same pole, how many of those ten would have made the same decision and climbed it? You can frame it as binary, yes or no, or as a number — I tend to use a number from one to ten. If the answer is essentially none — the only person who would have made that decision is the guy who did it — then you might have an individual problem. You might have someone who's untrained, reckless, or not doing what everybody else does, and you might need to change that person or their training. But if the answer is two, three, or more people probably would have done the same thing, then you don't have an individual problem — you have a culture problem, a training problem, a budget problem, a staffing problem, some kind of organizational issue. Punishing, shaming, or sending that lineman back to training is going to do nothing, because three or four other people are already on the road to making the same decision. You need to change systems, training, policies — whatever it is. Does that make sense?
[Mary] Yeah, absolutely — it's a very good way to depersonalize things and just talk about the issue, not feelings.
[Jake] Exactly.
[Mary] Speaking of organizational change, you write about planning for gradual change, which I think is a bit of an underrated idea in a culture that's obsessed with results. What does planning for gradual change look like in the workplace?
[Jake] I get this question, or a similar one, a lot — how can I get this adopted in my organization, get my team to do this? I did some research years ago on change management — how organizations and teams change — and got a lot of theory and fancy charts with colors, but not much I could actually put into practice. Until I found the innovation curve. It's a bell curve — I think it's somewhere in the book here. It basically says an organization has roughly five different groups of people. The major mistake people make — if you're an influencer, an innovator, a CEO — is trying to change everybody all at once: writing a memo saying, "Starting Monday, we're all going to use a spotter when backing in." Trying to change everybody at once almost always fails, especially when you're trying to undo or change existing behaviors. If it's something brand new — like a phone number nobody's heard of before — you can roll that out with a memo, because nobody has to unlearn anything. But when you have to unlearn or change existing behavior, that's where the innovation curve comes in.
The guy who came up with it in the 1960s said the innovators are the people who read my books, take my workshops, listen to my keynotes, and say, "Jake, we need more of this." Great — so we'll do a workshop together to get you more information, and then I'll ask you to imagine the four or five people you know who wish they had been in this workshop, or would have liked to be. People can usually name four or five people like that, even if they're in different parts of the organization. Those are your early adopters — you take them to lunch, give them a copy of the book, share a debrief with them, talk through your ideas and see if they resonate. If they say, "You know what, we do need this," then you ask them: who are the five, six, ten people you think would get into this? They'll give you a whole different group, and now you're moving through the first half of the bell curve — maybe thirty percent of the whole organization.
If you get enough innovators and early adopters, and each person talks to several more people, the early middle talks to the late middle — "Hey, I know you don't usually go to workshops, but this one's actually pretty good, want the handout?" — you've gone most of the way through the bell curve. At the end you have what they call the laggards — I call them the CAVEs, Citizens Against Virtually Everything. No matter what the innovation is, they say no, don't want it, forget it. But by the time everyone else has gotten on board, you take the laggards out for coffee and say, "I know you don't like this, or me, or really anyone, but when you do this, it's a favor to me." Most of them will go along with it until they retire. That's the best model I've seen for getting change through an organization in a smart way — don't try to influence everybody, just influence these people, who influence these people, and so on.
[Mary] I think that's a common mistake when someone's really enthusiastic about a new idea — we assume other people think the way we do, that they'll feel the same way once they hear it.
[Jake] You find a couple of people who are crazy enough to want to geek out on the stuff with you, and that's where you start.
[Mary] Excellent. You talk about psychological safety — some people might call it a buzzword, overused or misunderstood. It comes up a lot. What are some common myths about psychological safety?
[Jake] That's a good one. I wrote a few of those in the book — let me see if I can remember them. One common myth is that psychological safety means nobody ever gets upset, you can never say anything that offends somebody. That's wrong — psychological safety is deeper than that, not superficial. I've had conversations with people where — here's one of the questions I've used for psychological safety many times — I'll say, "Hey, Billy, may I have permission to give you feedback?" Notice how I said that. I'm looking him in the eye, not saying, "Hey, come here, let me tell you something." That doesn't show respect or deference, and it doesn't give Billy any choice. But when I say, "May I have permission to give you some feedback," or, to soften it a bit, "Can I share something I noticed in the meeting we were just in? You might or might not have noticed it" — I'm putting him in charge. He can say yes or no.
Most people, honestly, when I frame it that way, don't say no — almost nobody does, because they want to know what I've seen. About a third will say, "Not right now," and come back to me later. When I give feedback, sometimes it's brutally honest, but it's always done from a place of respect. I've had people tell me afterward, "Jake, it is so hard to get honest feedback, and no, you didn't hurt my feelings," even though I told them they were doing a couple of things really wrong — because I also told them how I thought they could do it better, if they wanted to.
So one of the big myths is that nobody ever gets hurt or upset — that's a fantasy. You're always responsible for three things: what you say, what you do, and your intentions. You should never, ever have the intention to hurt somebody, to cut them down, to put them in their place, to teach them a lesson — that's condescending and arrogant. But if you come into a conversation out of respect, with something you genuinely think will be good for the other person, then even if it stings a little, you're being psychologically safe, because you're trying to do the right thing and they've given you permission.
[Mary] As you were talking, I was thinking respect is really about not assuming bad intention. If you go up to someone and say, "Hey, you screwed this up," maybe you're not assuming bad intention, but you might be assuming stupidity or inexperience. Whereas if you frame it as, "I have information to share, and I suspect you'll be interested because I know you have good intentions, that you want to learn and get better" — and you only offer that to people you know are likely to receive it well.
[Jake] We all know people who would never listen to any feedback we'd give, who'd never say yes. You might try them once or twice, but generally not. I have a new acronym for them now — I call them CAVEs in my mind, and it helps. An old mentor of mine told me, a long time ago, to treat everybody you meet as if they're fighting a heroic battle. I've loved that, and I try to live it — from janitors to CEOs. You'd think really rich, well-off people have it easy, but some of them have problems I couldn't have imagined. So whatever station someone's in, if I assume they're acting in good faith, I try to treat them as if they're fighting a heroic battle and ask, what can I do to help?
[Mary] Another thing you mention in the book is after-action reviews, and you talk about five core questions. Can you describe what they are, and then we can talk about how an event review might differ from an after-action review?
[Jake] That's a great one. Pop quiz, five questions, no pressure. I actually keynoted this just yesterday to a group online. I recommend doing most after-action reviews for jobs that go well — the eighty or ninety percent that go well. The questions are: number one, what did we set out to do in this job? Number two, what did we actually do in this job? Number three, why did it turn out the way that it did? Number four, what are we going to do the same way next time we do a job like this? And number five, what are we going to do differently next time we do a job like this? Those are the five classic after-action review questions — I learned them decades ago, and I'll alter and adjust them as needed. An after-action review is a semi-structured discussion — not just "talk about whatever you want," but also not "only these five questions, don't deviate." You start with those questions and deviate as needed.
[Mary] And how does that differ from an event review?
[Jake] The big difference is that after-action reviews were actually invented by the US Army, back in the late 1970s, early 1980s, as a way to debrief force-on-force events, the mock battles. This was before everything was recorded with telemetry, video cameras, drones — you'd go fight the mock battle, come back, and hopefully learn something. They realized some people were learning a lot, others not much, but the people who learned good stuff kept it locked up in their own heads — what else were they going to do with it? So the Army created a process that was simple enough for pretty much everybody to use, versatile and quick, because there's never enough time to do it right but always enough time to do it over — bad philosophy, but that's how it started, and that's where those five questions came from.
The big difference between an after-action review and an event review is that after-action reviews were designed primarily to debrief jobs that go well. The event review, as I define it, is designed for incidents, accidents, unwanted events — especially ones involving miscommunications, misunderstandings, and errors. You'd never do an event review for a job that goes really well, but you can do an after-action review for an incident — in fact, of the six steps of an event review, step one is to lead an after-action review. That's how you start. For many small incidents — like a guy doing grinding work whose grinding wheel separated and flew apart because it was the wrong wheel, got stuck in a wall, but nobody got hurt — you don't need the full event review process for that, just step one: do an after-action review, write up the answers, you're done. But if it's more complex — multiple errors, multiple shifts, half a dozen people — you'll want the full event review.
[Mary] You mentioned something called classic defenses. What are classic defenses, and how are they helpful?
[Jake] I call them classic because some of them have been around for years or decades. I love telling the story of the oldest human performance tool or defense I know of, which was institutionalized in aviation in 1937, and aviation's been using it in pretty much its original form ever since. Show me something else that hasn't really changed or evolved in over eighty years, and I'll show you something that's probably a pretty good practice — it's the checklist, the pilot's checklist. Classic defenses can be very old, simple to do, require very little or no budget, very little or no training. The handbook I wrote — this is the first book I wrote, I wish somebody had written it for me fifteen years ago — has several of these classic defenses: checklists, three-step communication, things you don't need any organizational change to do. You almost don't need to ask your boss, you just start doing it — three-step communication, for example, has essentially zero risk, and if it works, you do more of it.
They're individual and team techniques — one or two people can do them, communication techniques need two people, decision-making techniques can be solo. They're simple, easy to use, and often have dramatically good effects. You just don't want to build your entire human performance or HOP program out of them, because they get people focused purely on end-user behavior, and if something does go wrong, all you'll focus on is whether they were using the tools perfectly every time — and if not, it becomes the worker's fault, and people drop them. I joke that classic defenses are like budgeting with a credit card — you use one sometimes, sure, but if that's a hundred percent of your purchases, it's going to catch up with you. That's using human performance defenses by themselves.
[Mary] What's wrong with just telling people to have more situational awareness?
[Jake] I love situational awareness — it also kind of freaked me out when I first heard of it. I thought, that seems really cool, what is it? I asked people, and they'd say, "Well, you've got to pay attention." Okay, great, but what is it, specifically? I talked to human performance experts, twenty-year lineman veterans who'd lived with situational awareness and were alive with all their fingers and toes because of it, pilots, military folks, even the vice president of my company, my boss's boss — and even he, being honest, admitted, "Keep your head on a swivel, but honestly, I don't know much more than that." He said it's kind of hard to describe, and he was right. Situational awareness, out of all the classic tools, defenses, and concepts, is the most abstract, the most misunderstood, the most intangible. You can't see it, hold it in your hand, or see it on a videotape.
I love playing this game in workshops — for a room full of tough field people who don't like sitting most of the day — and I'll ask, "Do you have situational awareness right now, in that chair?" Suddenly the confidence wavers: "Well, I thought I did, but I'm not so sure now." How do you know if you have situational awareness? On a blue-sky day like today, do you, Mary, have situational awareness? If you think you do because we're talking about it — my follow-up question would be, prove it.
[Mary] Prove it — exactly. It's not something you can measure or quantify, which is what makes it so hard.
[Jake] Right. A lot of people say situational awareness is important, and it is — there's a study out of aviation that found something like seventy percent of aviation incidents involve a lack or loss of situational awareness. So if we could figure out how to actually, practically operationalize it, that would be a game changer. I tried a few things, looked at a couple of the prevailing theories, and they didn't quite fit — a couple of reasons I include in the book. Then I got an insight watching a particular video that involves counting basketball passes — an old video, kind of fun, won't ruin it for you. What I realized was situational awareness isn't one thing, it's two things, and our brains can't do both at the same time: scan, like radar, and focus, like a laser. You can't be a floodlight and a laser at the same time, but you can shift back and forth.
What I came up with was scan, focus, and communicate. What would happen with a two-person team if they weren't both scanning or both focusing — if one person scanned like radar while the other focused like a laser, and they communicated with each other? What I saw was that's exactly what the best teams, the most reliable and safest teams, already do — they just don't call it that. Backing up a truck, the spotter is in scanning mode, communicating with hand signals, while the driver focuses on the spotter. The person operating a crane focuses on that one load, making sure it goes exactly where it needs to, while another person off to the side watches everything else, communicating via earpiece or hand signals. Paramedic teams — one person looks at the patient, the other looks around to make sure, say, the person with the gun doesn't come back. That's how the best teams tend to operate. That's the scan-and-focus model of situational awareness, which I've been teaching for about ten years now. I'm not sure I'm the one who invented it — one gentleman, Captain Richard Madden, a maritime transport and safety expert, liked the model so much he wrote his own article about it, describing two incidents — a fatality on a ship and a bad near-miss — and said if they'd been using the scan-and-focus model, neither would have happened. He's trying to bring it into maritime safety, but I think it's useful for pretty much any high-hazard industry.
[Mary] Speaking of situational awareness feeling abstract, I've always found the idea of building resilience to be similarly abstract — important, but hard to picture. Can you give some examples of practical steps an organization could take to build resilience?
[Jake] Resilience was another one of those concepts where I thought, that's cool, what is it? It's complicated. So I did what I do — listened to a lot of people, presentations, read several books, mostly academic articles. There's a lot of academic material on it, which is neat — I like playing with ideas — but at a certain point the firefighter, EMT, and paratrooper in me kicks in, and I hear the voice asking, is this going to make a difference, what action do I take? An old mentor once told me it's way easier to act yourself into a new way of thinking than to think yourself into a new way of acting. I've tried both, but I think it's much easier to find something to do that changes the way you think.
So, what do you do for resilience? I put nine methods into the book — I don't claim they're the only nine, and they're not all mutually exclusive, they relate to each other. One example is using failsafes. Think of the undo function in Microsoft Word or Excel — who hasn't gone, "okay, I need to undo this very carefully"? I'll ask in workshops, how many errors does the undo function prevent? Some people say thousands, millions. Others, usually the introverts, say none. Think about it: the undo function doesn't prevent you from deleting ten thousand lines of code, or the last two chapters of that novel you've been working on for a year — it doesn't prevent the error. It separates the error from the consequence, like we talked about earlier, and reduces the consequence. It allows you to undo the error.
So for things where it's impractical or impossible to eliminate or reduce the error, we can separate the error from the consequence and try to reduce the consequence. My favorite quote from the world of high reliability organizations, HROs, is that they don't try to eliminate all errors — instead, they try to make it so that errors don't disable you. That's resilience in a nutshell. People are going to make errors — pilots, people managing million-dollar contracts, everybody. The successful teams use all these techniques — classic defenses, system improvement, psychological safety — but they also build in resilience, so when errors happen, because they will, you can easily come back from them, learn from them, and the cost is minimal. Failsafes are a great way to do that. Airbags are another example — you don't even see them in your car until after an accident. They don't prevent the accident, they prevent you from being disabled by it.
There's a lot of other interesting research on resilience too — practicing resilience, compartmentalizing, pre-deciding and contingency planning, and also working with what I call quiet professionals — people who take the right amount of responsibility, want things to go right, but are absolutely prepared for things to go wrong. I love working with people like that.
[Mary] There are a few questions I ask most of my guests. One is more general — we're moving on from the book a bit here. Where would you focus training, or research if you prefer, for the next generation of safety professionals?
[Jake] Wow — if I had a magic wand. That's a good question. Right now, I still think many organizations are taking a primarily mechanistic, control-based approach to errors and to operations in general — "I want this team to run like a well-oiled machine." That's somebody telling you up front they're thinking in mechanistic, control-based terms, and if the machine breaks down, they're going to find which part — meaning which human — is malfunctioning, and replace them. I'd love to see more focus, research, and training on the learning-based approach, on the soft skills that are super practical — after-action reviews, event reviews, psychological safety — and research on how that actually builds business results over a long period of time. That's where the business case comes in, because the control-based approach gives you something easy to point to — "one person sliced their finger with an X-Acto knife on Tuesday, we banned all X-Acto knives, look at the control" — but you don't see the long-term results, like people leaving or saying they don't trust the organization anymore. It's a lot harder to see the long-term results of the learning-based approach, so that's what I'd like to see more research on.
[Mary] If you could go back in time to the beginning of your safety career, what's a piece of advice you'd give yourself?
[Jake] That's another good one — there's so many to choose from, we'd need more than one interview for this. I want to say "read more books," but I'm going to say instead, talk to more of the field guys and women earlier. That's what I wish I'd done. Reading the books, which I did, made a huge impact, but I also wish I'd focused on spending as much time as possible with the field folks, learning how they put in a bulk feeder splice — not that I'll ever do one myself — but to really see the difficulty, complexity, and nuance of that work. Pick two or three other jobs and go watch the work as actually done, not just spend time in the work as imagined.
[Mary] How can our listeners learn more about the topics in our discussion today, besides the book?
[Jake] Lots to get into there, and I've really enjoyed doing this. The book is out, and just yesterday I got word the audiobook is out too, if that's your thing. There's an electronic copy on Amazon, which fits nicely on your phone, but if you want the hard copy, that's only on my website, reliableorg.com. This is my main job, my full-time work — giving workshops and presentations, mostly half-day or full-day workshops for small groups, and more and more keynotes too. My website has a catalog of everything I do, called "Workshops and Presentations from JMA Human Reliability Strategies" — I just call it the catalog. It's a bunch of one-sheets summarizing what I offer, useful if you're looking for a keynote presenter, plus an intro and some quotes. All of that's available on the website. I'm on LinkedIn, the only social media I'm on — you can contact me there. I present a fair bit throughout the year; I'm doing several private events in a row right now, but stay in touch with me on LinkedIn, check out my website, and get the book on Amazon. And if you get the book, I'd love it if you wrote a review.
[Mary] Well, that's the end of today's show. Thank you, Jake, for joining me.
[Jake] Thank you for having me on — it's been a pleasure. You've asked some wonderful questions. Thanks so much for reading my book — I hope it's useful to you and all your listeners too.
[Mary] My thanks to all of our listeners. If you enjoyed this or any other episode, we'd sure appreciate it if you shared it with a colleague or friend who might also enjoy it. Thank you to the Safety Labs team, my colleagues and my friends. Bye for now. This podcast is created by Safety Products Global, the world's leading manufacturer of safety knives. Through our trusted brands, Klever, Slice, and PHC, we empower companies to prevent injuries by providing safer cutting tools for every material and application. Until next time, stay safe.
