Ep.18: Getting to the Root
Remember, you can always listen here or follow us on Apple Podcasts or Spotify. Either way, thanks for supporting us.
About this episode. Root cause analysis isn’t just a box to check—it’s the difference between fixing symptoms and solving real problems. In this episode, Zach and Hui unpack why so many organizations stop short of the true root causes, settling for easy answers like “lack of training” or “rogue employee.” They explore how curiosity, context, and critical thinking can transform investigations from blame games into learning opportunities.
From the five whys to fishbone diagrams, they share practical methods for digging deeper and highlight why cultural and systemic factors often lurk beneath the surface of compliance failures. Along the way, they connect lessons from NASA’s Challenger disaster and Deepwater Horizon to everyday compliance challenges, showing how disciplined analysis and data-driven insights can prevent repeat mistakes and build stronger, smarter programs.
Who? Zach Coseglia + Hui Chen, CDE Advisors
Full Transcript:
ZACH: Welcome back to The Better Way? Podcast brought to you by CDE Advisors. Culture. Data. Ethics. This is a curiosity podcast for those who ask, “There has to be a better way, right? There just has to be.” I'm Zach Coseglia and I am joined as always by Hui Chen. Hi, Hui.
HUI: Hi, Zach. How are you?
ZACH: I'm good. Welcome back.
HUI: How is everyone out there? I hope you're all doing well.
ZACH: Indeed, and we have a fun topic today. It is just you and I, but today we're going to be talking about a topic that actually has come up quite a bit in our client work over the course of the past year, and that topic is Root Cause Analysis.
HUI: Yes, this is a topic very near and dear to my heart because I truly believe that is the way to better ways. Because I think in compliance we often deal with things when they go wrong—the violations, the control failures, the bad decisions. But to really build better ways, we need to understand why things went wrong. And that's how we turn missteps and near misses into lasting improvements.
ZACH: Absolutely. I love that. And what a wonderful way to tie the topic into the heart of our podcast; seeking better ways. Well done.
HUI: It is always about that.
ZACH: So let's talk a little bit more about why they are important way. Why is doing a root cause analysis so important?
HUI: To me, the 1st place I'd start is to really be able to prevent the same mistake from happening again. And when I was at the DOJ, that was always the heart of the prosecutor's interest in the compliance program. Is, you had all these things that happened that led you to sitting in front of federal prosecutors, being investigated. How do we know if we sign some kind of leniency agreement with you, whether it's non prosecution or deferred prosecution…how do we know this won't happen again, right? So to really prevent the same thing from happening again, you really have to understand why it happened and how it happened.
ZACH: Absolutely. It's also very much part and parcel of the conversation that we have all the time and that we've had on the podcast about measuring effectiveness and understanding and testing outcomes—because at the end of the day when you're doing a root cause analysis, you're sort of working backwards to figure out what worked and what didn't. How did those controls that we have in place actually perform under pressure? Did they work or did they not? And typically, if you're doing a root cause analysis, the answer is going to be somewhere along the way: they didn't quite work the way we hoped they would.
HUI: Exactly. And I think another reason why it's important is, root cause analysis gets you to the causes by definition.
ZACH: The root, one might say: the root.
HUI: That's right. And so you're not really just fixing symptoms, you're really looking at what caused the symptoms to arise in the 1st place. So you know when you're looking at an employee who's violated your policy, you don't just stop at, “oh, you know, this is an employee disregarding the policy.” That's the symptom. But what causes them to disregard the policy? That's the cause that you want to understand so that you can prevent other employees from disregarding the policy.
ZACH: Yeah, I think that that's such an important point and it feels kind of obvious because we are talking about a root cause analysis. We are trying to get to the root of it and to really understand what caused it. But I think part of the reason why we were so interested in having this conversation is because so many of the root cause analyses that we see actually stop at the contributing causes. They actually stop at some of those symptoms. It often winds up being about, well, the training didn't . . . we need to do more training, or we don't have a policy, or we don't have a system to support that particular process. And all of that is information that we should be collecting and understanding and acting on, but it very rarely is the root cause. So really understanding the difference between, as you said, symptoms and causes, the difference between root causes and contributory causes, I think is critical to doing a root cause analysis well.
HUI: And even when you're talking about identifying possible semi root causes like training and policy and stuff, that's already going deeper than what many people do. What I saw at DOJ and we continue to see in our practice is simply blaming, it's a rogue employee. Right? I mean, I had that said to me at DOJ so many times. Well, but this was just a rogue employee or three rogue employees or 25 rogue employees. But my question is . . .
ZACH: Yes. 400 rogue employees—made bad choices.
HUI: Exactly. But our question, you know sitting at the DOJ and again sitting at any investigative table I would say is: why did this employee go rogue in this way in your company at this time?
ZACH: That's right.
HUI: That's what we want to know. Because if you're just telling me you can have a rogue employee, what's to prevent me from thinking right now as we speak, there are 25 other rogue employees sitting in your company doing exactly the same thing and we just have to deal with it when it comes to surface. That's what we don't want.
ZACH: That's right. It reminds me of a discussion that we often have around context. I think we have said here in this space before context is everything and in a way what we're getting at when we're doing a root cause analysis, especially in that case where we have maybe otherwise stopped at “rogue employee” or “misconduct by a person”…what that root cause analysis is really helping us do is to understand the context around that rogue employee's decision making to help us understand the context around that individual's misconduct, so that we can see whether there are weaknesses in the context that we need to address so that we don't have another rogue employee in the future. Or to help us understand that this actually isn't a rogue employee or isolated misconduct, this is actually something more systemic that requires more systemic change to prevent in the future.
HUI: I also like this approach because it shifts the tone of the investigation or the exercise from blaming to learning. So this is not about blaming in the rogue employee. This is about what can we learn from this to make us a better organization.
ZACH: Yeah, I love that. I think that there's a little bit of wishful thinking though in saying that.
HUI: Of course, I do wishful thinking.
ZACH: Indeed, because, you know, I think that part of what compliance continues to work to overcome is being perceived as the police, is being perceived as an enforcement function—being perceived as a reactive function as opposed to a true strategic partner. And so yes, of course, I think, if done right, it does put the focus on learning over blaming. But if you have a culture that looks at compliance as the enforcers, it will be hard to overcome the fear that folks may have that that root cause analysis is really about apportioning blame rather than preventing future misconduct.
HUI: Agree, agree. My wish in that wishful thinking is truly that organizations would focus not just on the employee involved in the wrongdoing, but on the organization itself and what it has enabled or contributed to the situation. That's my wish.
ZACH: Yeah. And that's a wonderful segue into this discussion of where a root cause analysis fits into the compliance lifecycle. Let's start with the investigative context, cause that's the most obvious, that's sort of where we've alluded to already. But it does go beyond that, right?
HUI: Absolutely. I mean, I think root cause analysis can be used when you're monitoring, for example, has identified anomalies or trends when you're trying to dig into why is this happening--whenever you're asking that question or whenever you should be asking that question, why is this happening? That’s where you need to be applying root cause analysis.
ZACH: So, one place where you definitely do that is when something has gone wrong. But I'm also really curious and interested in this idea of instead of a post-mortem, a pre-mortem, thinking about how something could potentially go wrong. Maybe it's a new business strategy, maybe it's, we're opening up in a new market, maybe it is we're expanding our business. And part of positioning compliance as a strategic partner as opposed to just the enforcers or the policy makers is having a voice in those things and seeing how compliance is actually tied into all of those business strategies. So I'm really curious about the idea of, in those moments, doing a pre-mortem to say, all right, what do we know that could potentially go wrong? How could this go off the rails—and in fact, using the library of post investigative root cause analyses to help us understand how what has gone wrong might inform our efforts to prevent something from happening in the future.
HUI: Agreed. I also think it can be applied to just questions you want answers to, right? So it doesn't have to be something wrong or something that could go wrong. A company runs, you know, an employee engagement survey, very low participant rate. Why? That's the kind of thing that you can actually use root cause analysis to dig into in understanding a question like that.
ZACH: Yeah. It's like we often see folks talk about their speak up channels and maybe they don't have a lot of reports coming in to their speak up channel. And what we often hear—really—is people say, well, we just don't have a lot of misconduct
HUI: Yes.
ZACH: And we often say, well, you know, what you don't have is a lot of reports, but how do you know that you don't have a lot of misconduct? Why are people not reporting things? Is it in fact because there's nothing to report? Or are there other reasons that may be shaping those behaviors?
HUI: What we often hear are assumptions.
ZACH: Assumptions, yes.
HUI: Completely untested assumptions. And in some cases we've seen it used very oddly. I remember working with an organization where I saw the reporting rate go up quite noticeably in one market and down in another market. And when I asked them why do you think that is, they attributed it to the same cause, which is we ran a campaign. But why would you run the same campaign which causes one market to increase its reporting, another market to decrease? I'm not saying that's impossible, but that's my next why question, right? So how could it be that the same campaign run in two markets would have the opposite effect? It wasn't tested. It wasn't explored. It was just sort of assumed because you can almost see when we were asking the question, well, why did it go up here and go down there? It's almost as if they hadn't really thought about that. And then they just came up with the next thing they can think of. Oh, it's because we just ran a campaign.
ZACH: We use data to test our assumptions. We don't make decisions based on assumptions. We make decisions based on data. And yes, it's infuriating actually at times, to see the brazenness of assumptions that people sometimes make. And yeah, and so key to our mission is filling in those gaps with data.
HUI: Yes. I find it so I find it so interesting that in a field that is often dominated by people with legal training that there is so little interest in having evidence back up assumptions that are made. Which is an entirely not legalistic approach. This is where I wish there is more legalistic approach, which is not something that I wish often for the compliance industry. But here I would like to see people always, always back up their assumptions with evidence, and data is one form of evidence.
ZACH: Absolutely. So before we get into a little more of the nitty-gritty about doing a root cause analysis, I thought it would be fun, interesting to use a couple of real-life examples to bring this whole conversation about root cause and the difference between root and contributing causes to life. So the first that came to mind immediately when we talked about doing this episode was the Challenger space shuttle disaster. I saw a documentary about this just in the last couple of years.
I think it was a Netflix documentary, and you know, the initial assumption, the initial assessment by NASA and its contractors was, you know, this O-ring erosion that had happened on previous shuttle flights. It was known about, but it was treated as a sort of acceptable risk rather than a systemic design flaw. But as they dug deeper, and because of the gravity of that situation, a significant amount of effort obviously was put in to digging into the root causes of that disaster, what ultimately came to light, what ultimately rose to the surface was organizational and cultural challenges. The normalization by management of deviance from protocol and the failure to heed engineering warnings in the interests of accomplishing this bigger feat. And you know, you've heard me say it. I've said it on this podcast before. But if you ask enough questions as part of a root cause analysis, you're probably going to wind up finding yourself staring some form of cultural issue in the face. And that was precisely what happened with the Challenger disaster back in 1986.
HUI: It is not surprising because when you look at these spectacular failures that movies have been made and books have been written on, you often find that it's never ever one single thing that caused it. It's a whole host of contributing factors, all somehow aligned in that perfect storm so that the spectacular disaster results.
ZACH: Yeah. The other one that came to mind, also tragic and spectacular, was the Deepwater Horizon oil spill back in, I think, 2010. You know, again, the initial root cause analysis, the initial sort of source of the failure was to blame the equipment. I mean it was very much what we were talking about in compliance, blame the person—here was blame the equipment, a blowout preventer or something that didn't operate as intended. But again, as we dug deeper, where we found ourselves was looking at decision making environments, cost cutting pressures, failures of risk management, all of which led to design flaws and misinterpretation of information that led to this spectacular failure. That one to me felt very much like what we see in compliance.
HUI: Yes, I actually had the privilege of working on the tail end of the monitorship of Deepwater Horizon. And you know, as a result sort of got myself to better understand sort of some of the things that could happen in terms of really safety. I've often referenced how compliance can learn a lot from safety. And absolutely we are talking about an environment. It's not just pieces of equipment, it was an environment that enabled a whole host of factors to unfortunately collide into something like that. And as we're talking about this, I was also thinking about as you know I've referenced before and some of you know my father was an airline pilot and he was deep into aviation safety and you know, during his days. And I remember one of the worst airline disasters was KLM's collision in Canary Islands. I can't remember what year, it was some time ago.
What was really spectacular about that was not only the number of deaths involved, it was a jumbo jet. So hundreds of people were on board. Two airplanes collided because the KLM pilot was in a hurry to take off because his crew was about to time out during a delay. And the guy who was the captain was the head of KLM flight safety. It's not like he didn't know, but you start diving into this and you see all the impact on the human being on a very well qualified human being who understands all the risks, but you look at all the factors that cause that split second decision that, I'm going to take off now. And the cultural aspect, the human factor analysis really come into play.
ZACH: Yeah. Well, let's bring it into the world of compliance now and bring it back to the world of compliance and let's talk about how to do a root cause analysis. There's different methods. The method that I guess sort of subscribe to or use most frequently and again, there's no rocket science to this, but that method is five whys. Sometimes it's four whys, sometimes it's six whys, but asking more why questions, which again is a theme that we talk about a lot here. But you know, you might start by saying this was an individual error. This was individual misconduct. That's fine. That's not your cause, root or contributory. That's your finding. That's the finding of the investigation.
HUI: Exactly, yes.
ZACH: So then ask why. And so I'll use an example that recently came up in a real life context. So the root cause analysis was individual misconduct and we said, well wait a second, that's your finding. Let's ask some more questions. So when we asked why to the individual misconduct question, the answer that we got was well, they were in a rush. And I was like, okay, well, that's interesting. That's new. Why were they in a rush? Because they are working 125%. They've got a job and a quarter. They've got more things to do than they have time in the day for. And I was like, okay, well, that also is very interesting. Why is that? Well, because the team is understaffed. Okay, why is the team understaffed? Because a number of people on the team have left recently because they've been overworked. Okay, again, very interesting. We're getting deeper. You ask another why question and another question. And then you start hearing things like people were prioritizing their commercial interests and their bonuses and their incentives over meeting this particular compliance requirement. And suddenly we have all of this information that we didn't have before that's telling us something about, again, the context in which that mistake was made—and we have actionable things that we can remediate. You know, we can look at the incentive structure, we can look at the resourcing of the team, we can look at what people prioritize. We can understand the culture that this thing happened in and try to not allow the conditions to exist in the future so that these things are prevented. And it's just so much more interesting, so much richer and so much more actionable than just “we had someone who made a mistake or someone who did something wrong, someone who engaged in misconduct.” So the 1st and the method that I tend to use is the five whys. Ask yourself those consecutive why questions back-to-back to try to get to a place where you say this is really what we need to address.
HUI: And what I love about that is if you hadn't asked all those why and hadn't gotten all those insights and you stopped at this was an employee who, because he didn't have time or she didn't have time, had chosen to ignore the policy, you wouldn't have addressed all the other issues that your whys have unearthed. And what's likely going to happen is you're going to have another one three months later. You're going to have another departure from the team, and it would just keep happening.
ZACH: Yes, that's right. I mean, a big reason for our why going back many years is constantly hearing folks in an investigative context say that the same thing keeps happening over and over again. I mean, that's why we sought out better ways. That's why we created this sort of data-driven, human-centered, evidence-based approach to compliance. And it's the same thing with the root cause analysis. It's like, let's prevent these things from happening in the future.
HUI: So, you know, I love my medical analogies, right? I feel like that if we are not asking these whys, it's like you're a physician treating someone who says I have a headache and you say here's the Tylenol, Aspirin, take it. Go away, right? Without further examination, your patient could be having a headache because she has a brain tumor, because she has an aneurysm brewing, because there is blood pressure issues. You're not treating those more severe underlying causes. You're just treating the symptom of headache, which can go away for a few hours with some medication. But the causes, if you're not addressing them, not only will contribute to continuing display of symptoms. But can be something way more severe than what the symptoms are displaying.
ZACH: Absolutely. And I think that what that underscores in the context of the discussion we're having is not only the importance of asking those why questions in the context of doing a better root cause analysis, it's actually asking those questions during the investigation. You use the investigative process to get information to help you better understand what's happening and why. And if you don't ask the right questions during the investigation, you're going to have a harder time doing a meaningful root cause analysis.
HUI: Exactly, because you wouldn't be able to answer some of those whys that you were asking.
ZACH: Exactly, yes. So that's one method, the five whys. Hui, tell me about another method that you've seen or that you've used or that you're familiar with.
HUI: Another very common method is known as fishbone because it's diagrammed as a fishbone where the head of the fish is the problem and the bones of the fish are the contributing factors. And I think for a lot of people this may be very helpful because it's a much more organized way. It's almost providing you a checklist of things that you should be looking at. And all these things are things that relate to the system, the context as we've been talking about. So, you're not looking at just a misconduct or an incident. You're looking at commonly at least five categories of system related components that you're examining, people, processes, technology, environment, and culture.
So, some examples, you know something happens an employee (people) disregards a policy. Does it have to do with their skills and the trainings they received? Does it have to do with how they received or understood the communications relating to the policy? What is their motivation? Does it have anything to do with the way they're incentivized? How about staffing? You referenced all of those. How about the way management is guiding and supporting these employees?
So that's some of the people questions. You can also look at processes. Does the workflow impact on how decisions are made? Are there potential points where this decision could have been made better or disaster averted? Is there room for better consistency and standardization in how things are done? Is there bottleneck for approval? Is the procedure outdated, which we often do see? Are processes overly burdensome so that people just decide that it's easier to deal with the consequences of being caught than going through this burdensome process? We've seen that a lot.
In the process of technology, again, this comes up all the time. Is there better technology and tools that we could use that would make the decision easier, better? Is there a lack of integration of technologies and systems and data? You know, does someone have to use, you know, six different systems to onboard a vendor causing them to say, you know what? Either I'm going to skip one or I'm just not going do any of those because it's too much.
ZACH: I'll say the answer to that one is probably usually, yes. That is a flaw. Please, for those listening, change your vendor processes so that it is not so painful for us.
HUI: Yes. User interface issues. We often look at systems and it's a system that is not user-friendly. Users don't really know what the meaning of words that they're supposed to follow are. Access issues, people's ability to access information and systems. So that's a whole bucket of technology issues.
The environment, physical workspace, remote work issues, market conditions, the tools available, and competitor behavior. These all goes into sort of the more general environment bucket and culture, of course, our favorite. What is the organization culture when it comes to accountability, fear of failure, silos, communication gaps, resistance to change, all of these are potential culture issues that contribute to things. So that's another . . . So this fishbone with the categories is another way that people commonly do root cause analysis.
ZACH: What I like about the Fishbone method is, aside from the fact that it gives you the opportunity to draw a fun little fish as part of your process, is that it really leans into the complexity of it all, because as you said, it's often not just one thing. It's often many things, and this really facilitates a discussion about the many things that could potentially be driving the misconduct. It reminds me a lot, actually, of the four-Is method from cultural psychology that we sometimes use when assessing culture. It sort of leans to complexity in a way that gives you a wonderful framework for making sense of it all
HUI: Yes.
ZACH: So, let's talk about what you do once you've done the root cause analysis, remediation. The actioning of it all. And one of the things that I'm really interested in on this topic is, again, in the context of not making assumptions and being curious is: let's say you do the fishbone analysis and you do identify the one of the contributing causes is a training failure. What I have sometimes seen is folks say we need to do more training or this person needs to be trained or this person received training in fact and there isn't a gap at all, and it's the person who didn't get the message that's at fault. And what I'd like to see is folks saying, well, “maybe our training didn't work.” Maybe our training was somehow flawed. Maybe we need to look at the way in which we're educating people about the requirements so that this doesn't happen again in the future—and that I don't see enough of. I see a lot of, as you said, it gives us the opportunity to not focus on blame, and yet what I sometimes see is again the willingness or the ease of blaming the person rather than doing the introspective work that's necessary to, in fact, find a better way and realize that your training, your system, your process, your policy actually was itself flawed.
HUI: Yeah, I think that goes into two elements that we've talked about. You know, one is the blame mindset, and the other is the untested assumption—because a lot of times when I hear about training failure. it turns out to be an untested assumption. Because what you have is an employee in the moment of being interviewed says, “oh well, but I didn't know about that.” And that question was not pursued during the interview. So you have basically investigator coming back to say, well, that person says that she didn't know, but here I have the training record, so clearly she's not telling the truth.
ZACH: Yeah.
HUI: That's oftentimes the conclusion. What I would have liked to see is when the person says I didn't know, you say, “Didn't you get training on that? Do you recall getting training on that?” Well, if the person says I do not recall, this would be the moment when you bring out your training records and say, “Well, but I have a record here that you attended this. Tell me what you remember from this training. Tell me if you remember attending this. Tell me what you remember from this?” You are now doing a root cause analysis, not just of the person's behavior, but also getting potential improvement insights for your training.
ZACH: Absolutely. What else should folks take away when it comes to remediation?
HUI: What you're looking for are system fixes that change conditions and behaviors. That's what your focus needs to be. I'm not saying you don't blame the individual if they are at fault. They do have to be held accountable for their actions. But you as someone conducting the root cause analysis are looking at the individual and the system. So don't ever forget that that's the other 50% or more of what you're looking for. That's the focus. And I think once you've done that, you've identified those conditions and behaviors that need changing and you have identified things that you can do to your systems and processes that can bring improvement. The next thing is really make sure that you do identify owners and hold those owners accountable for implementing those fixes.
ZACH: Absolutely. So to sum it up for folks, we want to focus on system fixes to change the conditions and behaviors. I think another way of putting it that came to my mind as you were talking was you're not going to mostly solve this problem by firing someone. You're going to maybe fire someone or warn someone or discipline someone, but then also do a few other things that are going to make sure that this thing doesn't happen again with someone else. So system fixes that change conditions and behaviors. You're going to, as you said, embed follow through, make sure that owners are assigned, that there are deadlines, that you're tracking that stuff, and then finally feeding that stuff back into other program components so that the risk assessment becomes better, the training program becomes better, that the monitoring program is informed and is therefore looking at similar behaviors in the future.
The other thing that I want to add here that I think is really important is having a consistent and sufficiently robust catalog of root causes for you to assign—so you do the root cause analysis and then you say, okay, this was root cause 1, this was root cause 2, this was root cause 3, and having really good language to describe those things. That is both reflective of this broader point that we're talking about, which is getting beyond the contributory and making sure that we're getting to the actual roots, but it's also about data collection and setting you up for successful trending and data analysis in the future. If at the end of every investigation you assign, and this is something we see a lot, if you assign “individual misconduct” as the root cause, you are creating zero helpful data for your program in the future. But if you have this wonderfully robust catalog of matters that are telling you about control failures and system gaps and policy misunderstandings and cultural shortcomings, you're going to be able to do a sort of post hoc trend analysis around your root cause program that is going to make the entire program better and going to empower your stakeholders with more information about the state of things that enables them to make better, more informed decisions. So, to me, a huge part of this is root cause analysis is a means to a very important data end. So let's do it right and let's collect the data in a smart way so that we can use it in the future.
HUI: That is so critical because understanding the root causes of one set of problems is very different from understanding the trends that it's telling you from 100 instances.
ZACH: Absolutely. And the perfect example is what you said at the outset, sort of jokingly. But you know, if you have one person who engaged in individual misconduct, okay, if you have 10 people who engaged in individual misconduct of the same sort, okay, if you have 25, well, okay, but you don't see it unless you look at it and so.
HUI: Exactly.
ZACH: Being able to do that sort of backward-looking analysis it's importance can't be overstated.
HUI: And I think if you're thinking about what kind of categories might be useful in your trying to collect and document this data, you know, starting with the fishbone categories may not be a bad idea, if you have no other places to start, you can certainly start with people, processes, technology, environment and culture. But it's very, very important that when you put people down as a category, that's a separate core category from the individuals who are involved in the center of the issue. You're talking about and looking at people systems.
ZACH: Yeah, I mean, I actually think that as you were walking through the fishbone methodology, the more detailed information that you provided under people, process, technology, environment and culture are a wonderful starting point for the language that you could use in creating the categories. Starting with people, process, technology, environment, culture is great, but then being able to break it out under culture of: culture-leadership accountability; culture-fear of failure; culture-a siloed organization; culture-lack of effective communication; culture-resistance to change, etc. Like, that is a wonderful approach to creating language for your root cause analysis.
HUI: The other couple of things that I would love for people to take away from, one is certainly just the theme of our podcast. This is about curiosity. It is all about having a curious mindset that wants to understand what happened? Why? How? Why now? Why this place? Why this method? Is wanting to understand all those questions driven by that curiosity. I think the other thing is, together with building that mindset, you need to build capacity. And the capacity here doesn't mean, you know, having to go and get a certification or a degree. It really is being trained in disciplined critical thinking, which we're going to address on another episode of, The Better Way?
ZACH: Indeed, yes.
HUI: But it really is thinking about causes and effects in a much more critical and disciplined way.
ZACH: Yeah, I love that. And you know, not to beat a dead horse, but for me, I guess my closing message is think about how asking those questions can translate into data that you can use in the future, not in isolation, exclusively. But as part of a broader trend analysis. Every single one of those why questions you ask, anytime you ask a question and you get information in return, you are positioning yourself to have valuable data that can ultimately improve the program and tell a whole host of stories that you need and your stakeholders are thirsty for when it comes to compliance and risk.
HUI: Yes, but it does take a lot of discipline to make sure that you get the information, and you document it in a way that you can then use that data.
ZACH: Indeed. Well, this is great, Hui. I really enjoyed this conversation. Again, as we said at the outset, it's something that has very much been a topic of interest to folks that we've talked to over the course of the past year. And I'm looking forward to the conversation that we have coming up in the future about discipline…
HUI: Critical . . .
ZACH: Critical thinking.
HUI: There we go, yes.
ZACH: And thank you all for tuning in to The Better Way? Podcast. For more information about this or anything else that’s happening with CDE Advisors, visit our website at www.CDEAdvisors.com, where you can also check out the Better Way blog. And please like and subscribe to this series on Apply or Spotify. And, finally, if you have thoughts about what we talked about today, the work we do here at CDE, or just have ideas for Better Ways we should explore, please don’t hesitate to reach out—we’d love to hear from you. Thanks again for listening.