GA 319 | The Danger of Expertise with Audie Penn

If you put a solution on the table, typically what that does is everyone aligns to it and says, well, this guy's the expert. He has the answer for us. They're done thinking, and it may or may not be correct. And so I always tell them, I want you to come with your opinion, but I don't want you to lead with it.

Today I'm excited to welcome Audie Penn to the show. Now, Adi is an executive consultant for Faro Partners, and we connected over LinkedIn, and after nice dialogue back and forth, I asked Adi if he wanted to come onto the podcast to share a little bit of his story. And that's exactly what happened. And so, as you'll hear, Adi has a lot of experience in many different industries. And so what we ended up doing was just kind of really taking a journey through his career and talking about how he was first exposed to Lean. And then we kind of. We got into some specifics, and he shared some really fun stories of how Lean has been able to help him and the teams that he's led solve some particular. Some very specific situations. So we just, we honed in on a few examples back from a paint department and then. And then a concrete making business, and we just talked about some different scenarios and how Lean was able to help those teams move forward. And so, yeah, really good conversation, a lot of fun, and I think you're going to enjoy it. So show notes for this episode can be found over@gembapodcast.com just look for episode 319. Again, gembapodcast.com and look for episode three. 19, 19. Okay, enough for me. Let's get to the show. Adi, welcome to the. To the podcast. How are you?

I'm doing well today. Thank you for asking.

All right, well, hey, where are you calling in from?

I'm just outside of Chicago, about an hour west.

Okay. What I grew up in, when I grew up, my wife grew up in. In the Chicago suburbs, and I actually lived in Libertyville, Illinois, up there for a while and worked at Motorola. So, yeah, know the. Know the area well.

Well, we're out in Sandwich, which is a little bit out in the western suburbs. They're famous for their fair.

Nice, Nice. Yeah, I grew up in Greenville, Ohio, and we're famous for the great Darke County Fair, which they claim is the. Used to. Used to be. I don't know, maybe it still is the largest county fair in the country. So, you know, it's a pretty big deal growing up in Greenville, Ohio. All right, well, hey, thanks for coming On Adi, as you know, we kind of like to begin all of our episodes with our guests sharing a quote. So do you have one?

Yes. And it comes right from one of my favorite mentors, Shigeo Shingo. He is quoted as saying there are four purposes of improvement. Easier, better, faster, and cheaper. These four goals appear in the order of their priority. And I think that's very important.

Yeah, yeah. Because oftentimes it a lot of people will flip it around, right?

Yes.

Yeah, yeah. So good stuff. Good stuff.

Yeah.

Mr. Shingo got some good wisdom. All right, well, hey, Adi, why don't we jump in, Tell us a little bit about your background, Tell us how you first got exposed to all this. All this continuous improvement stuff, and then tell us what you're up to these days.

Sure. My first exposure to Lean came in the mid-90s. I was working for Han under George Koenigsecker, of all people, and he was bringing Japanese sensei into the Han factories at that time to teach us all how to conduct kaizen and to learn more about it. So I'm grateful for that experience and what I learned there. But it started in, I think it was 95, 94, 95. And it's just built from that point forward.

So I guess let's just talk about your career a little bit and tell us how Lean has played a role in it.

Sure. So from that initial exposure, I was young enough at the time. This is the way I share this with people. I was young enough at the time not to know any different. And so my assumption at that point was simply, well, this is the way it's done. Everybody must do it this way. And as I moved then from organization to organization, the first thing that I would always start with would be a value stream map of whatever area of responsibility I had been given. But I also learned through those movements, from organization to organization, that my assumption that everyone did this was not true. And so out of that realization, I began really, what I would say is my journey of teaching and sharing that knowledge. So through food manufacturing, heavy equipment manufacturing, and finally with building materials in recent focus with some of my clients, what I've learned over that time is lean goes anywhere and everywhere. It's conceptually sound and philosophically it can go anywhere. You just have to carry it in and look for the ways to apply it within these different industries.

So, I mean, how have you personally used it, maybe in your early career and even up to present day? I mean, obviously we talk about a lot about tools and whatnot, but what have you seen, what have you learned as it relates to the way Lean can help an organization?

If I start with that lowest tactical level, there is no problem that we can't solve. So if we're allowed clarity about what processes are supposed to produce and we tap into the skill and knowledge of that local process team, I have seen teams over overcome problems that quite frankly had existed in those departments, in those processes for the better part of 20 years.

Can you give us an example? I mean, you don't have to use names or companies or anything like that.

Certainly there was a, there was a paint system with one of the heavy equipment manufacturers that I worked with that had struggled for 20 years. And I was invited to take over that department. And bringing Lean into the department, we actually overcame a number of what I would say just were simple fundamental errors in the way the department was viewed. And we actually defined, okay, how was the department designed and how is it that we need to operate this process to optimize the purpose that it was designed, designed for. And after six months, we completely turned that department around. We reduced the operating budget by over 60%. We went from a two shift operation to a single operation. At the same time increased productivity and output by 40%. And there's a phrase that I use when I speak, and it's. We never believed it could, it was possible.

Give us an example of a defect that you were seeing and, and then how you approached how you approach that defect, that problem.

Sure. Well, one of the simple defects would be film thickness on paint, on paint surfaces. So we identified the proper thickness that we expected and we actually simulated what paint usage should be and compared that to our actual usage and realized, okay, there's a root cause here that we're not sure of what it is. And as we started our experimentation, we discovered that we had inconsistencies in application and we rewrote the standards and we trained the team in the booth to apply, and we started to check those films. And as we began to bring those films into tolerance or into our target area, we started to, to see the usage line up with what we had estimated or assumed should be happening.

So was it like kind of like a Kaizen event approach or was it more of a. So like in four days you solve the problem or like talk us through it?

Well, in every Kaizen, you have to understand what your gap is, right? The difference between what you actually have and what you intend or what you expect. And at that point, you invite that local process team in to begin sharing their experiences and to Identify. Identify potential. Potential solutions or potential problems that could related to this. So a standard Kaizen event. We did get to that. Once we identified where we thought the gap was, it required us to define standard work and to evaluate how well the painters were applying and to see where the gaps were in their performance. So was it done in five days? No. But was it done over the same overarching project approach? Absolutely. We had to understand what the problem was and then begin to challenge or invite those operators to share their knowledge and to help us understand where the problem might be.

So seeking root causes obviously is an art. So what's your preferred approach to kind of get after a particular situation to seek out some, as you rightly explain, potential root causes? Right. Because we don't really ever know until we do some experimentation. What's your favorite approach?

I think what I enjoy most about locating a root cause is really that initial conversation where we're seeking the right problem statement. Because my consistent experience in this conversation is there are as many perspectives of the problem statement as there are team members participating in the conversation. And so until we can create that shared vision about what that problem is, and what I mean by that is when everyone in the group points at that problem statement and says, yes, if you make that problem go away, you will make my life easier, that's the first step to realizing we've finally gotten to the real problem. Now let's start to evaluate where that root cause is. For me, it's that discovery moment through that challenging conversation that is the most fun because it's so rewarding. When everyone's aligned and working toward the same outcome, it really picks up momentum.

Yeah. Deeply understanding the problem is obviously critical. So, like, when you. When let's say that we do have a good problem segment you mentioned, you know, film thickness or it could be any defect related to anything. Right. Let's just say that the team does feel like, yeah, they've got some data, they got some evidence that, listen, we've got this problem. We've got facts here. There's no emotion, there's no opinion. This is facts. These are numbers. It's a control chart. It's whatever it is. So let's say we get to that juncture and then we're all standing around, we're like, okay, yeah, we've got this problem. Here's the facts, here's the data that says this is our problem, and now we're going to get after it. Are you like, more like a 5Y guy or fishbone or what do you think at that point? Because I often find that's a, that, you know, a lot of people struggle in this area.

I actually use multiple tools depending on the complexity of the problem, the familiarity with the process of the team participating. So it can be all over the board. 5 why, certainly. But I, I really do enjoy that fishbone as well. The other one that I think surfaces a lot of clarity is simply a process map where we begin to dive into much greater detail about a task where we believe the root cause could reside. And so out of that conversation we start to see the differences of approach and opinion about that in individual task. And a lot can surface when people start to realize, well, Tom over there has his way of doing it and John has his way of doing it and I have my own. And all three of us are doing this differently. That could be the source of some variation that we're seeing in the process.

Oh, I love that. I love that. I was actually coaching call yesterday with one of our green belts and they were kind of just having a lot of anxiety about kind of about how long it's going to take to solve the problem and this and that and, and I share the true story of when I worked at, at Nokia, we were, you know, cell phone company and we were, I worked in the, at that time and with our supply chain and so I worked with a lot of our suppliers and we had a supplier literally across the street from our, from our facility who was sending us these parts, you know, these, these little plastic parts that clipped into the, on the inside of the phone. You know, you stack these parts up to make the phone and one of them. We were having all kinds of dimensional problems and I mean, we were scrapping incredible amounts of this part. And it was just simple little, very actually pretty inexpensive part. But it was creating, you know, incredible amount of problems, right? I mean, because, you know, you all have all the parts to make a phone. So anyhow, long story short, I went over there and, and to your point, we walked to Gemba. I was sketching a process map as we were going. Then we came back and we kind of honed in on this particular measurement system over there and come to find out they had never done a gage R and R. So they had no idea really what they were measuring. So we did a proper gauge R and R on this machine. Come to find out, they had like number, distinct categories, was like one. So they had no, they couldn't even tell between good and bad, let alone, you know, really give us, you know, definition as Far as the actual size of the part. And again, long story short, we found that a new way to. To program this machine. It was actually looking. We programmed it to look at these circles that were cut out in the part instead of this little part that stood up on the part it was. The camera was having a hard time kind of finding its bearings, so the engineer was able to reprogram it in literally 10 minutes. And we redid another gage R and R. It took about 20 minutes because this machine measured parts super fast, right? And boom, we nailed it. And so at that, just in, like, literally in a few hours. But it all started with a process map and kind of asking questions about, you know, potential weaknesses right. In their system. And we really honed in on this one measurement system. So I love that example where you talk about process maps because, you know, fishbones are great and I've used them, but sometimes they can get a little bit. Yeah, you know, it's just like all these just opinions just floating around. And sometimes I just feel it's better to just go to the Gemba, right, And just get out there and start walking around, start talking to people. And it's amazing how quickly you can stumble upon opportunities for improvement.

Absolutely, absolutely. And I think those maps are quick to lead you to the right area, at which point the fishbone or the five Whys might actually have much more impact. I gotta get close enough to the problem to apply those tools and increase their efficiency. So. Yeah, I'm with you.

Yep, Perfect. Perfect. So, you know, for folks who are. Maybe they're, I don't know, just getting kind of started with lean, or maybe they've been at it for a little while and just kind of going through the motions. What are some of the. Some key tips, some key ideas that you like to educate others on in order to, you know, maybe better understand what lean can do for us or just. Just get more out of the system itself.

Sure. That's a great question. I will often begin with new project team leaders. And so we're still going to stay in that tactical level. The Lean alliance would call it the bronze level. But I always try to raise awareness about the negative impact of our expertise. And So I spent 30 years in fabrication manufacturing, so I have expertise in that space burn to shape, robotic welding, CNC machining. That's where I'm comfortable. And the danger is I can immediately come up with a solution. That's not what lean is about. And what I warn experts about is you need to leave your expertise at the door. And you need to allow the process to bring everyone together. Because if you put a solution on the table, typically what that does is everyone aligns to it and says, well, this guy's the expert. He has the answer for us. They're done thinking, and it may or may not be correct. And so I always tell them, I want you to come with your opinion, but I don't want you to lead with it. I want you to ask enough questions that you actually begin to learn what are the perspectives, the knowledge, the ideas that the team has. And I want you to be. Be able to compare what they think to what you think. And that will create another layer of questions that allow us to close the gap as we move toward that shared vision. But you'll never understand what they know or they think. If you immediately lead with your solution, you'll shut down the conversation and you'll. You'll actually jump over a phase that is so critical that we talked about earlier, that you may not find the right root cause, you may not find the right solution. Solution.

You know, I was having a interesting conversation with my colleague Steve Kane the other day, and we were, you know, we were. We were talking about the whole idea of, you know, scientific thinking and kind of this Toyota Kata way of moving through. Through, you know, life really, not just work, but just, you know, kind of outlining, you know, where we want to. Where do we want to go next and, you know, what obstacles are in our way and how we might go about clearing those obstacles and so forth. And Steve was, you know, sometimes one of us will kind of play the contrarian a conversation, and we always pretty much agree, but sometimes we just like to stress the conversation by just taking a contrary view. And Steve did it this day, and he said, you know, basically what you just said was that, you know, don't lead with, you know, the leader shouldn't, or the coach, in that case shouldn't. Shouldn't bias the conversation with his or her opinion of what should be done. But then Steve said, well, what if you're in a particular situation and the coach or the leader clearly knows that you know which direction you should go and the team is just completely clueless, for lack of a better word, like, where is. Is there ever a balance of where the coach can give hints? Or do they. Do they realize that we could. I could. I could say this, and then we could work on the implementation process, you know, and be moving forward, or the team could fumble about for the next month, like, where is that balance? Right? You know, between, you know, having that expertise and pretty being very confident that you could help this team, but you're also afraid of giving them the answer. You know what I'm saying?

I do, I do. And I think it's a great question because as, as a coach, when we go into these situations, and again, I'm going to encourage project team leads. Always have your own ideas when you go into these conversations. But to Steve's point, at some point you realize this group doesn't understand. And I don't want to assume that. I want to prove that through the conversation. Right. So I'm going to challenge them to share with me. And as their frustration grows and I see the level of knowledge that they have about the process that they're working in, at some point it makes sense to begin to lead them toward that solution. But there's also a balance between just telling them and educating them about why that solution makes sense. Yeah. So that's the opportunity that shows itself again when you refrain from leading with your solution, but you continue to explore and ask those questions to understand what does this team know about what we're working on?

Hey, so going back to your earlier career, the paint thing, it's funny the that that supplier that I was telling you about with Nokia, they also painted parts, you know, so, boy, we had a lot of fun, you know, optimizing paint processes. And that's tricky. You know, that's a tricky, tricky business, especially when you're kind of mass producing parts. You'd think it'd be easy once you dialed in a process, but, boy, there's a lot of potential variation in those processes. Talk, maybe share an example or share a story of, of a situation to where you were about to test some potential countermeasures. Say you identified or you felt pretty confident that you honed in on a root cause or two, and now you. Now it's time to implement some countermeasures. Can you talk a little bit about that? About that process? Like, how would you go about that?

Yeah, if I understand the question correctly, where my mind goes immediately is if we have a solution that the team has actually suggested.

Yep. They have an idea of what we might be able to do. Yeah.

Yes.

I'm sure if it's going to work or not, but.

Exactly. Exactly. So the one situation that shows up in my mind actually happened at a cement manufacturing plant where I was coaching a continuous improvement manager and we were having problems at the top of a silo with blinded screens and moving material. And the team actually came up With a proposed solution that the engineer said that is exactly the opposite of what I was taught in my engineering class.

Okay.

And I challenge the continuous improvement manager. Well, this is either a solution that will work or an opportunity to educate the team and share what this engineer knows. So let's do a temporary. We welded up a temporary pipe, we put it in place. Engineer said this will never work. And we put it in place temporarily. And it worked beautifully. And the engineer was shocked and actually was. Was stepping back saying this is not supposed to work. He was actually frustrated that the solution that the team came up with, it broke through the teaching that he was engineering school. But in the end we adopted it. And I share that story, but because even the experts are wrong sometimes and we have to experiment with these ideas to truly understand or educate out of the failure. Well, let's talk about why this didn't work. And now everyone on that team has. Has a new level of common understanding about the work that they do that they can build on from there.

Curious. How, how. How did you guys. How did the team. How to continuous improvement manager and that, that story. How did they interact with that engineer? Because obviously they could have been like, ha, told you so or you're not so smart after all. Whereas that could really rock that engineer. I mean, you know, they could have potentially devastated them. You know, like dedicated how many years of their life getting this education. And in one fell swoop they maybe they feel like it was all a lie. Like, how did you approach that? What was that like?

Well, we, we actually kept the conversation relatively private. So it was, it was me as the coach, it was the continuous improvement manager, and it was the engineer that discussed this, I would say offline. So he was never really exposed to the broader team, which, which could have led to some ridicule. And so we had to talk about it a little bit. You know, he shook his head and said this will never work and it won't last. And I think that was nearly five years ago and that solution is still in place today. But it's just, it was a learning experience for him.

Yeah, yeah. Well, yeah, and it's, you know, I think that's one of the best things I ever heard. I think it was Mike Rother who talked about we should, you know, people or organizations would be much better served, you know, stop arguing about who's right and who's wrong. You know, instead, if you want to debate anything, debate what experiment we're going to run next. Right. And then, you know, debate that, you know, and Then. But don't debate too long. Pick one, you know, and then. And then implement the experiment and see what you learn. Right. And I feel like that's so. It's so easy to say that, but it's so hard for people to wrap their mind around because everybody wants to be right, you know, they all want to think they know the right answer. What's the stock market going to do today or tomorrow? Nobody knows, you know.

Your comments, though, take me to one of my favorite books, the fifth Discipline.

Yes.

In that book talks about there's two ideas. I think they're in the same chapter. They're very, very close together. The first one is this idea of advocacy and inquiry where a leader will advocate for a solution, but yet share the reasons why he or she thinks this is the answer. That's the advocacy half. The inquiry half is where that leader then turns and invites what others think, with the requirement that you must also share the information, the knowledge, the data that you use for the position that you've taken. Now, I think before that, there's a conversation about the difference between discussion and dialogue, which I think we often we miss. And his. It was a beautiful explanation. He shared. Discussion has a similar root in percussion or concussion. And there's this idea of conflict and winning associated with a discussion. But on the other hand, you've got dialogue where it's shared learning from conversation. And the difference between the two is there's no desire to win as an individual in a dialogue. There is learning that's shared and we all win together when we learn together. And I think that points me right back to leadership and what they value. Because if a leader values individuals winning over others in the team, we all lose. If a leader values learning together and shows up that way in conversation, conversation, that leader can create a culture of dialogue where advocacy and inquiry then makes sense and is a welcome conversation.

I love that. I love that. The difference between discussion and dialogue. Discussion. Someone's typically trying to win dialogue, is trying to figure out the one best way right. To move forward.

Absolutely.

Beautiful. Beautiful. Hey, so, last question. So I know you work a lot with different companies and your daily work. So what are you seeing out there that I don't know, might be you find missing, you know, or folks that just aren't doing as it relates to this whole lean movement of ours?

Yeah, that's a great question and I appreciate it because what I find missing most often, and it starts in the conversations where the executives that I work with are complaining about sustainability. One comment that I that I frequently make to teams is you're already doing lean for the most part. It's common sense. It really is. What we're missing is the complete cycle, which includes that management system piece, which is the sustainability mechanism where we go back and we evaluate this is the PDCA conversation. What's important, does everyone understand their role in it? How are we doing against that today? And if we're not achieving that, what are we going to do about it? And so if there's no management system, if there's no disciplined governance of processes where these conversations are going on continuously, the language that I often use is regularly and frequently, then our performance will drift. And I always share with teams. The frequency of your meeting is absolutely correlated to the time it takes to recover. And so we want that frequency close enough that we recognize we're not on the rails anymore and we've got to respond to right the ship, get back on the rails, so to speak, that's missing so often. And I think the reason for that is because we're human and we get bored in those disciplined executions. And so when a, when a conversation becomes real rote and routine, it loses its interest and we forget about it, we step away from it. But it's that conversation, it's that focus that keeps the level of importance for the team on whatever it is we've deemed we're supposed to be creating. And so the solving problems piece, I think everyone has done, whether you consider yourself a lean practitioner, not even in the old school days, the problem was the supervisor solved all the problems in lean. We ask, we asked those flourishing communities to participate in solving the problems but we don't know what's important.

Yeah, absolutely. Good stuff. Well, Adi, I really enjoyed the conversation and we were talking before we hit record which direction it was going to go, but I thought it was good just just jumping in and, and talking about some real life stories and hearing how you've gone about things. So I appreciate you taking time to come on. Why don't we wrap things up with you telling folks how they can best connect with you, whether your website, social media, whatever it might be.

Absolutely. The primary website that I would point people to is the Faro Partners website. That's www.faro.partners. there's no comm on that one. You can also find me as an individual@audipen.com or you can look me up on LinkedIn. I've got a, I've got a lot of connections out there and I'm always willing to make another one. But one rule for me is if you want to connect with me, we have to have a conversation because that's what relationship is all about. So if you send me a request, you can expect for me to send you an email and say, hey, tell me a little bit about you so I can learn about who you are and we can start a conversation that way.

Like it? I like it. All right, and we'll, we'll link to all that in our show notes. So this will be found over@gembapodcast.com and just look for episode 319. So Adi, yeah, again, thank you for coming on. I know we're right in the middle here of the craziness with the coronavirus and all that, so hopefully you stay tuned, safe and keep up the good work and let us know if there's anything we can do to support you.

Thank you, Ron. I appreciate your time as well and it was a pleasure to meet you. Okay.

All right, take care. Thanks for listening. Whether you've been on the continuous improvement journey for many years or perhaps you're just getting started, GEMBA Academy is here to support you. And while we're best known for our more than 1500 lean and 6 Sigma teaching and virtual tour videos, we also have a team of experienced Lean and Six Sigma practitioners available for one on one coaching, as well as a variety of Lean and Six Sigma certification options. To learn more and to schedule a demo, head on over to gembaacademy.com.