GA 077 | How an Engineering Manager Practices Lean with Rob Connelly

You're listening to episode 77 with Rob Connolly.

Welcome to the Gemba Academy Podcast, the show that's focused on helping individuals and companies achieve breakthrough results using the same continuous improvement principles leveraged by companies such as Toyota Del Monte and the U.S. department of Defense. And now, here's your host, Ron Pereira.

Hey there. This is Ron Pereira with Gemba Academy, and I'd like to welcome you to another edition of the Gemba Academy podcast. As always, thank you so much for taking time out of your day and your week to listen to the show and for watching our Lean and Six Sigwa training videos over@gembaacademy.com I also want to thank everyone for all of their feedback and comments and tweets and Facebook posts and LinkedIn posts for last week's episode with Simon Sinek. I think it was definitely a success. Again, I want to thank Simon for taking time to visit with us. If you haven't listened to that episode, I really encourage you to do that. We, we have it in both audio format, and then we also created kind of a video version of the. Of the interview, and you can get all of that along with all the other resources that Simon provides over@gembaacademy.com Sinek and that's S I N E K so again, gembacademy.com Cynic now, today, I'm excited to welcome Rob Connolly to the show. Now, Rob is a longtime Gemba Academy friend. Rob actually works for a company called Specialty Silicone Fabricators in California. And our own Kevin Meyer and Steve Cain used to be colleagues with Rob and are good friends with Rob. And I actually got to meet Rob, I guess, a few years ago. We actually featured SSF in a gimbalive episode. Rob is an engineering manager there for ssf, and he's a really prolific Lean thinker doing some fantastic work over at ssf. So today, what we're going to do is we're going to kind of explore a day in the life of a lean thinking engineering manager. So Rob's just gonna kind of walk us through the day and kind of walk us through how he attempts to kind of practice Lean with his team and his organization and what he personally does to be a better lean thinker. So it's a little bit different episode than we normally do, but I think it's gonna add a lot of value because it's real. And this is a real lean thinker sharing how he does his work on a daily basis. So show notes for this episode can be found over@gembapodcast.com 77. And that's seven. Seven for 77. So gembapodcast.com 77. Okay, enough from me. Let's get to the show. All right, Rob, well, thank you so much for taking time out of the day to talk to us. Where are you calling in from today?

I'm calling in from the beautiful central coast of California in Paso Robles.

All right, so let's jump right in. So what company do you work for?

I work for a company called Specialty Silicone Fabricators and we are a medical component manufacturer. And we are almost exclusively medical focused, Medically focused. Our components are mostly implant components. Not all of them, but of those implants, most of those are for devices that are life improving and life saving applications. So it's a really fantastic place to work and a great industry to boot. So it's been a thrill.

Yeah. And so as Gemba Academy customers probably know, we actually did a Gemba Academy live episode there. Gosh, it's been a couple years now, I think, Rob, hasn't it? And, and Rob made his video debut. You were on those videos, so that was, that was good. And so you guys have a fantastic lean thinking company. So I'm really, really excited to talk with you today. So, well, let's go and just kind of take one more step back. And Rob, why don't you tell everybody kind of your continuous improvement background, maybe how you first came to learn about lean thinking and, and, and then kind of walk through like what you do for ssf.

Sure, yeah, that sounds great. First off, I've been working for SSF for 10 years. I actually was introduced to lean culture and lean thinking through your partner and my previous boss, Kevin Meyer. Kevin has moved on from our company and is devoting his time now to your organization, which is cool to see. But yeah, primarily my, my learning came from him and then his next in line, the VP of operations, Steve Cain, who also works for Gemba Academy now as well.

Yeah. Okay. Well, Fayden, what do you do, Rob?

I am our manufacturing engineering manager. I've been in this role for about two and a half years. And prior to that I worked as a manufacturing engineer on our floor. And I did that for a number of years as well. That was my background.

Yeah, very good. All right, well, Rob, as you know, we like to start all of our shows with our guests sharing a quotation that possibly inspires them. So do you have one in mind?

Yeah, you know, it's really simple. And it's from David Schwartz. You may have heard it. And that's the idea. Action cures fear. Action cures fear. I love that quote because it kind of embodies my mantra of getting out of your comfort zone. I think it's really important for everyone to understand that there's things that are outside their comfort zone and to look at them and poke at them and prod at them and learn from that and grow and just go beyond that. And I think action cures fear kind of does that.

I love it. I love it. Very good, Very good. All right, well, what we're going to do today, Rob, is we're going to kind of just take a journey through the day in the life of a lean thinking manufacturing engineering manager. And that would be you. And we're just going to kind of walk through how you run your organization and how SSF runs their business with a obviously strong, lean thinking slant. So I'm going to kind of turn it over to you and, and I don't know if you want to is first question I have. Is there any difference in how you approach your, your job on Monday versus say Tuesday, Wednesday, Thursday, Friday, or is it all pretty consistent throughout the week?

You know, it's actually pretty consistent. You know, we have some pretty strong leadership standard work that we follow that I follow on a day to day basis. And there's really very little variation between those days. So on occasion, you know, we have some certain weekly meetings that we, that we have. But aside from those details, you know, everything is pretty standard. And as you may know, our company is very focused on autonomous teams and self directed cultures. And I think we do a really good job at that and we have fantastic communication and we have very good teams and it's been a pleasure. So just to kind of walk you through my daily routine. It really starts, our day really starts with our morning leadership meeting. And we use an action board, a visual board at that group meeting. In that meeting.

What time is that meeting?

It is at 8:15.

Okay. Yeah.

And so that's an opportunity for all the key, you know, key department personnel to come together. It's not necessarily all like leadership or supervision staff. We do have some key technicians and operators that may come to that as well. But it's generally a leadership meeting and at that meeting we focus on, we have a nice visual board. We do start off the meeting with asking some very basic opening rituals. So we ask if we have any wow moments, if there's anything that we need to celebrate as a company.

Give me an example of a wow moment.

If we Delight a customer and we land a big order or if there's a project that was completed, those generally are wow moments. Something that we want to celebrate as a group.

Sure.

Okay, we go through these lists. Are there any wow moments? Are there any customer issues, Are there any visitors, are there any other issues or announcements that we need to cover? Those are. And is there any safety issues? So not necessarily in that order, but we cover those as an opening ritual every day. From there we dive into our visual board which starts out with the metrics of the various production areas and discuss any delays, any problems that we're seeing. We have some standard work around when problems product progresses from one stage to another and moving into shipping and we go over any problems related to those and discuss those as a group. And then from there we walk in to our action board. And it's a little bit hard to maybe visualize on a podcast, but if you can imagine a board that has columns for every day of the month just numbered 1 through 31, we then use that with rows for every department and say if I have an issue with a quality assurance or if I have an issue with an operations team member, I will issue them a sticky. And we just use the two by two post it notes and we post each sticky for every team member if they come up. And these stickies represent problems that we are trying to address as a team. And it's focused on continuous improvement. It's not, it's not a finger pointing activity. This is really about continuous improvement and it takes a special kind of culture and a special approach to make sure that people don't feel like they're being attacked when we find out a problem with another area. If I'm say not getting information that I need from somebody, I need to approach that subject and say, hey, I really need this. What's preventing you from getting it to me? And it's an eye opening experience on many levels. But we use this board to go over open, open action items and open projects that need need addressing.

So how did that go when you very first started this? And that was the first, I don't know, rough conflict thing?

Oh yeah, yeah, it was a little rough, honestly. And we call this board the action board. But it didn't start out as an action board, it started out as an accountability board and it did have that tone of why am I not getting this? I need this quote. Where's this quote? You said you're going to get it to me and I don't have it. So those types of of issues definitely were there and there was definitely a little bit of culture. But as time progressed, I think people realized, wait, this isn't about accountability. This is about making sure that we're focused on improvement and focused on continuing our growth. And honestly, having those dialogues takes practice so that you're not beating each other up about it. It's about discovering those problems and moving on.

Now I know SSF is big into twi and so I'm curious what your exposure has been to say, job relations and do you use any of those techniques in these kind of conversations or these tougher conversations or tougher situations?

We are very focused on TWI as a training mechanism, but we don't use it per se as it relates to our morning leadership meeting in the Action Board.

Okay, fair enough. All right. Now one other thing I wanted to ask you about. The last time I was there and it's been a couple years, you guys video conferenced in other plants. Do you still do that?

Yeah, in fact, that's a good question. So we've kind of danced around different methods to incorporate and to communicate with our other sites. We have three sites total and if we go over the entire action Board as a cross functional company, that's a little too much. Currently, one day a week we conference in with our other sites and we rotate who's reporting. If it's our week to report, our leadership staff have a brief update for the rest of the company and we do that over video conference just to give everybody a flavor for what's going on. We try and tell a story on projects and problems that we're plowing through and focus on learning and just try and get everybody on the same page. From a company standpoint, that's how we incorporate our other sites. We also on a monthly basis go over trends related to certain, you know, quality issues that we're tracking. That's another piece of standard work on that morning meeting that we're incorporating as well. So that's on a monthly basis so that we're keeping very close tabs on the trends of any issues from product quality.

Got it, Got it. Now how long does this whole meeting generally last?

Generally it's about 15, 20 minutes tops. Following that meeting, there may be other spinoff discussions to resolve certain issues, but you know, it's never more than 20 minutes at the top side.

Okay, so it's Wednesday at about 8:20. What's Rob do now?

So Rob heads out and I have about usually 15 to 20 minutes before my team meeting. As an engineering manager I do have a morning meeting with my team and in that meantime I try to do a Gemba walk around our production floor. We have a very open floor plan and that allows me to kind of go around and quiz people and see how they're doing, doing, see what problems they're having and learn and get an update from the operators and technicians that are actually running jobs. So that's what I do in that off time. And then a 45 rolls around, I have my engineering meeting and that's a standing meeting on our production floor as well. And of course we're congregated at our visual board and we have an opportunity where every team member will go around and discuss what you know, primarily what they're learning from yesterday. It should be a reflection meeting, not a meeting where, hey, this is what I'm going to do today. So I really try and encourage them to share with the rest of the team what they learned, what problems that they had the previous day in order for everybody to benefit. So there is a tendency when you put a group together like that that they want kind of give an update and make themselves look good in front of their boss. And I try and discourage that. That meeting is not for me, the leader, it's for the team. And I make sure I refocus their update to have everybody benefit from that. I have my own one on one meetings with my team. So the benefit of the group morning meeting is to share learning with their teammates. We also go over our visual board itself and this is a very simple board. If you can imagine. We have a column for every person and it's roughly organized so that their highest priority projects are on the top. Again, these are with just post it notes and more of a queue of activities down the column. We can kind of give brief updates on those as well. But really the focus is on learning from the previous day.

Have you always done it that way?

No, in fact, it has been an evolution. Traditionally our morning meeting was everybody says, well, this is what I'm doing today and this is what I'm working on and that sort of thing. It doesn't have as much value as sharing learning. And what mistakes did you have? What problems did you see? What issues did you have? That's where the learning happens and I think that's where the most value is.

It's really interesting. I'm just like when I'm doing these interviews, I'm focusing on the interview, but then I'm also thinking in my mind, gosh, Gamba Academy's morning meeting you know, this is what we do. And I'll tell you what we do is we get on a Skype call, we're all spread across the country, and we go off and we rattle on about what we're focused on that day and any help we need. And then we've gone through variations to where we have talked about, you know, kind of wins and opportunities, or losses, if you will, of the previous day or the previous week. But for some reason, we always fall back to, you know, kind of what we're doing. And Kevin and I and Steve, we're like. We just like to hear each other's voice and see each other on the cameras. You know, I think there's value in that, but I think there's always an opportunity. I really like what you're saying here is really keep it focused on, you know, what went well, what challenges you had, you know, from the previous day, because it's probably far more value added than, oh, I'm just going to, you know, call some people or, you know, try to sell some videos. I don't know, you know.

Right, right.

Really interesting perspective.

Yeah, definitely.

All right, well, how long is your meeting last, then? Your engineering meeting?

I cap it at 15 as well. So I really try and respect everybody's schedule and keep it to, you know, 15 minutes. Beyond that, it gets a little. It can, you know, if you. If you're undisciplined with the timekeeping, then it. Time slips away really quickly. And I think that's when there tends to be, you know, little dialogues or discussions between a few people in the. In the team and not necessarily everybody. So I try and focus everybody on, you know, let's. Let's keep it for the entire group. If you guys need a discussion, you know, let's do that. Let's do that afterwards.

Okay. All right. So what now we're up to about what, nine o' clock or so?

This is nine? Yeah, this is nine o'. Clock.

Okay. So far, all you've done is have meetings. So, guys, when are you going to do some work?

I know, right? That's the hardest part. And in fact, you know, in my. In my role, I do have to accept the fact that I don't get to do as much work anymore. Right. It tends to be more leadership and. And more focused on team projects. And that's where it goes into. The majority of My day is spent visiting with teams and having team updates. And that's great.

I know. You said it's great. Let me stop you for a second. Because let's get real, there's some engineer listening to this right now, and you're obviously a hardcore engineer. You love engineering work. When you first started managing people, was it hard?

Oh, it was brutal. And it's still hard. Right. When you start managing, you have to have the discipline to let go a little bit and give your team the reins to actually make progress and to do the actual work. That's the hardest thing about being a manager, is letting go. It. It definitely is my focus. To have autonomous teams is important at the engineering level. It's not just an operations thing. And so I do need to allow my engineers to work autonomously without me interfering. And I just need to give them the background training, the opportunity to. To pursue their ideas. And I need to protect them if they're going to, you know, if I know that they're going to fail or deliver something that the customer is not, you know, not going to be happy with. Right. I have to have those protections in place to kind of block that. But aside from that, I need to, you know, give them the opportunity to learn and to try new things. And so there's definitely a little bit of a dance there. How do you reconcile the two? You know, you want to protect your team and you want to, you want them to do a good job. At the same time, you need to give them the, you know, the, the flexibility and the ability for them to pursue their ideas on their own. So. So there's definitely a balancer. I try and get out of, you know, being too involved with the teams, but at the same time, I need to make sure that they're progressing the way they need to progress.

So, okay, do you have kind of like leaders leader standard work for yourself as far as, like, after the meeting, all the meetings are over and it's, you know, nine to. However long you work throughout the day. Do you have set. Set tasks that you do or how does that work?

You know, I tried to, you know, we're getting into sort of more of the personal productivity. I do try and focus on, you know, the GTD methodology to some level. I try and make sure, you know, I try and get it, you know, to inbox zero and work on my next projects or next actions list. That's the way I try to work. I'm still questioning whether that's the right approach at some times because vmail does tend to be more firefighting and less working on the highest priorities. So there is a little bit of a balance there. But for me, from there, it's Working on those top priority issues that I am responsible for from a management level.

Okay, well, is there anything else within the day that you want to share? Because I do have a few other questions I want to run through, but I don't want to cut you short. If there's anything else that you think you want to talk about.

One aspect of team management that gets interesting is how do you balance out communication for all the teams working in a particular area versus single individual teams? Our company is at the size that we do have focus teams set up. If we're talking about, say, a customer project. Right. These are not operations teams. These are development teams, if you will, with cross functional people. Traditionally, if the company is small enough, all the key players work on all the projects. You have one great technician, you have one great engineer, and you have all these key people that come together and they work through all these development projects and they get it done. But as the company grows, the teams grow and there's more and more people involved when it comes to that level. The project management at the company level becomes more challenging. You want to make sure that everybody's communicating. However, you need the teams focused enough that you're not tying everybody into all of the projects, if that makes sense. You do need to have focused teams. And so there needs to be some level of, like a project overview meeting, if you will, as well as individual project meetings. And the way we've accomplished that is we have a visual board, again on a production floor that is divided up into rectangles that represent the different phases of a development project. And we don't go into detail about each project. We just share if the project is on schedule, on budget, and what phase of the cycle is every project at. So from a, from a. From a company standpoint, you can address the resource and overall scheduling risks at that level and not get into the details. And so that's how we manage it from a company level so that you're not tying everybody into all of the projects, which becomes rather dysfunctional, to be honest.

Yes, yes.

So that's an important technique that we use to manage projects at the company level that I think would be helpful for people.

Okay, well, the other things that I want to talk to you about, Rob, I know you guys are big, and, you know, I've talked about it with Steve Cain and Kevin to some extent on various podcasts and videos and whatnot. But I know you're big into just. We've talked a lot about autonomy here. But also I know you're big on Mastery and purpose. So I'd like you to talk a little bit about mastery and how you attempt to, you know, work the mastery concept into your, into your department and your, your team members.

Yeah, it's a great question, right? Mastery is not easily attained, is it? You know, for me, I look at some, you know, some of our expert engineers, and it's fantastic to see how creative they are. And I believe that, you know, I believe that creativity is sort of the result of years of being a master and years of learning and, and to me, that's like just the pinnacle, right? And in today's world, we're bringing people on quickly and we're moving, we're trying to grow. And bridging the gap between a new engineer and a master is a pretty daunting task. For me, it's really about training and it's about mentorship. And so I have a very strong philosophy that you need both. You need the training to give them the background information, but then you need the mentorship and the freedom to allow them to try new things and to grow. For us, I have a very big training program, a very elaborate series of topics that we cover. And I don't get, I don't get particularly concerned on how formal the actual training is so much as we hit a topic and we hit it often. I have techniques around doing that from a technical standpoint. And I tend to bring everybody together in a group and say, okay, we're going to talk about this process. We go through what I call process mapping. It's not to be confused with value stream mapping, where we're mapping out the process from a technical level. And it doesn't take any preparation. We're just going through what every input to a process is and what every output to a process is in detail. And then how do those relate to potential problems or potential defects in this technique? It requires no preparation. It just gets everybody together and we're going to say, okay, this is our topic today. And we go through that. And by having these discussions, we're able to pull out information from the total experts. And the new newbie guy just off the street will be able to learn from that and grow.

Is it like post it notes and paper kind of thing or how do you.

Strictly whiteboard. Strictly whiteboard. But the trick is to go very meticulously through the process. Through it. This is a manufacturing process, but it could be used for service or whatever, anything. And just detailing out every single input and every single output and then understanding how they relate to.

So what's the purpose? What problem are you solving by doing this?

This is strictly education. Right. So this is understanding in detail how a. How a manufacturing process would work from a technical level. Yeah, got it.

Now, do you document it in any way after it's been up? Do you take a picture of it or how does that work?

Yeah, we definitely take a picture of it. You know, it's. It's nice to think that we have, like this fancy book of knowledge, you know, but honestly, no, it's very informal. Leave it like that. And next time we may bring that out for the next round because we may have multiple rounds and cover it that way. So it does evolve over time, for sure, but it tends to be informal. And I am a fervent believer that if I have some perfect training, it's not going to happen. I need to bring in the training earlier and let it be informal. Let it be a little bit rough around the edges. That's okay, as long as we're. As long as we're doing it. Because primarily from my standpoint, if I don't have these trainings, then these guys are going on for years learning by their own experiences without really pulling in the experts to guide them. And this is one technique that we rely upon to do that.

Yeah, I love it. What about purpose?

Yeah, when you talk about mastery, autonomy, and purpose. Purpose, I would suspect in many cases is the hardest one to fuse into the company's culture, but here it tends to be the easiest. Because we're medical, we know that every part we touch is likely to go into somebody or it affects somebody very directly, that becomes very easy. But sharing the vision and mission of the company at the company level is one thing, but also making sure that your team has a vision, mission statement at the team level as well, and sharing with, working through that as a team so that we're all clear on our purpose is important to me as well.

Yeah, purpose is always the toughest one, but I don't know, I would almost argue it could be the most important. Right?

Oh, yeah.

Why are we here? Right. What's our purpose?

Yeah, definitely.

Got it. Got it. Well, Rob, is there anything else that you want to share about the inner workings of ssf?

You know, really, I can't stress about the, you know, on the autonomy part. I feel strongly that really good autonomous teams, from what I've seen here, you know, Steve has been so successful at rolling these out in our company, and where I see them failing or really thriving, to me it's. It does relate to the Size of the team. And I feel strongly that to have good autonomous teams, they need to be small enough that they can own something themselves. So really, hopefully refocusing your organizational structure so that you have a team focused on a larger portion of the process for one product family. I'm really interested in manufacturing cells and making sure that a team team can see a process from start to finish rather than having a functional organizational structure and having some big huge team, 30, 40, 50 people. It doesn't lend itself to being autonomous. From my perspective, it's important to make sure that teams are organized small enough that they really can interact individually and to own a process themselves. To me, that's really a key factor in good autonomous teams.

Now, I once heard someone, I can't remember who it was, but talked about like a two pizza rule that, you know, if it takes more than two pizzas to feed the team, it's too big. I don't know.

I like it.

You know, I don't know how big the pizzas are, you know, but the engineer is probably size of the pizzas.

Yeah, that's right.

But no, I think so. I mean, if you could wave a magic wand and only have a team size of X, I mean, would you. What is it? Is it like 8 to 12 kind of thing or.

In my eyes, I'm thinking 6 to 8 somewhere around in there. Yeah. When he starts getting above 8, you know, you start 10, 12. That's getting pretty big. And I think leaders tend to emerge out of those, out of those groups. And that's not a bad thing. But I think some of the team members will just kind of turn off at that point. They let the more energetic folks of the group kind of take the reins and make those improvements. Whereas when you're working in a group of five, you really can't get out of it. You're either with it or you're not. That's where I kind of feel really should be. Something less than 8 in my view.

Now, how many engineers work for you, Rob?

14 currently.

So then do you have multiple autonomous teams then or how do you handle?

That's a good question. Well, okay, so I do. So of 14 that is split up into different groups. So we've got a tool room group, we have manufacturing engineering and we have mechanical engineering. So there really is subgroups there that do work together more closely. So it is a little smaller.

You follow your own rules in your teams are probably eight or less, I would guess, right?

Yes, yeah, absolutely. And in fact, I'm proud of Our tool room staff, they do work very independently, and because of our organizational structure, they have to. We don't have a ton of middle management. Right. They've got to work autonomously. That's the way we're structured. And they do an awesome job at communicating and making their own decisions, and it's hard. And so there are things that we struggle with, but ultimately, they're doing an amazing job.

You know, one of the things that, you know, we work hard to practice autonomy here at Gemba Academy, we're far from perfect. But Elaine, who's been with us for almost four years now, or a little over four years, in fact, she told a story on episode 50 of the podcast where we're kind of reflecting on, you know, how we started the company and so forth, and she, you know, she would come to me and she would ask questions and I would. I would. I don't know, what do you think, Elaine? And a lot of times, just because I didn't know, right? Like, I was really. No, what do you think? You know, because I didn't have the answer. But she told us a story about how, you know, there was times when she hated that. She was just like, just tell me what to do and I'll do it. And, you know, and I know from an engineering perspective, it's gotta be tempting for you to just tell them what to do when they ask you a question, but is that a struggle? Or how does that work with your engineers? Do they ask a lot of questions? Maybe in the beginning, when they're, you know, a classically trained engineer, you know.

You know, you'd be surprised. It really, it's. I think it's. It's almost human nature that we tend to, you know, it's. It's so much easier for somebody to just tell us what to do, just tell me what to do and I'll do it. Right. But that doesn't build the problem solving muscle to use that cliche. And it is definitely challenging. Some people are easier than others at working them by themselves. But ultimately, I have to spin it around, and honestly, it's about me being humble more than anything. It's easy for me to assume that I know all the answers, right? I would like to think that. But even with the newest engineers, and they may be a little bit insecure and they may not be familiar with the processes as much and so on, but I have to turn it back and I say, what do you think? This is your project, and you're closest to the project. You're closest to the people I'm up here, I think I have these perceptions right, but I may not have everything right. You're the ones working with the facts. And so I do need to spin it around and say, well, you tell me what you think we ought to do. And so that takes a little bit of time and focus to spin it around like that. But ultimately, if they come up to my office and they say, hey, I'm not really sure what to do, they're going to get the same answer. I'm going to say, what do you think we should do?

Eventually, what I ended up doing with Elaine, she would ask me and I would just pause and she'd say, oh, I don't even know why I asked you, like walk away, you know, laughing or whatever. But yeah, no, it's tough though. And you're right. I think it's humility and easier said than done sometimes, you know, it is.

Yeah, it's all about. It's all about being humble and open minded. And that's a perspective of leadership that I try and fold into everything that I do. Because so often, you know, you have your perception and you think, oh, this is it. I know what's going on. Why didn't we do this in xyz? And we're battling a supervisor on some issue. Really, I had it all wrong and I needed to be more humble and ask questions so that I get fully. So that I can fully understand the issues. So that's the key for me is just being humble and open minded.

I have another question for you. How do you hire engineers? What's your process?

I'll give it away. Right. For any future applicants.

Yeah. Right.

Just to cut to the basics, to really answer that question. Yeah, we have the traditional screening interview and that sort of thing, but ultimately that's just to get the person in the door. Is this person willing? Is this somebody that we want to entertain an on site or not? And our on site interviews are very elaborate. Right. They're long, they're almost a full day. And really it starts with an introductory sort of face to face meeting where we might get to know each other a little better. But really the meat of the matter is in two places. One is I take every engineer on a tour and that tour is for them to learn about us and our processes, but also for me to see their curiosity and how engaged would they be. And the best applicants are the ones that I have to stop and say, okay, we got to move on, we got to move on. You ask enough questions, those are the ones that I know that really shine and the ones that are interacting well with our operators because I take them face to face and I say, okay, you know, Joe, can you work through this applicant? You know, can you describe to this applicant, you know, what you're doing? And the applicant either says, uh huh. Okay, cool. Yeah, well, it was nice to meet you. Okay, that's a turn off. That's a flag right there. If they don't engage the operator and really ask, well, what does this do and what does this do and what does this do and why do you do that? Those are the ones that I know are going to be engaged employees and ultimately going to do a better job. So really, it's our tour and seeing their questions is a big focus. The second piece, which is interesting is we always have our applicants do a presentation. And it's kind of funny, but we say, we'd like you to do a presentation between 10 and 20 minutes. And they get this request ahead of time and they come prepared to give some presentations. And the better applicants there, I look at not only their presentation skills, which is really about communication, but what topic did they choose? It's funny that we've gotten some pretty entertaining topics that.

Oh, you got to share a couple. Oh boy, isn't there one? Steve? It's tipping my tongue. Something about apples or something like that. Is that ring a bell to you? It was a female applicant and she did, and he said she did. Just blew us away with some esoteric topic that I can't even remember what it was, but it was.

I don't know necessarily which story you're talking about, but some of our better employees have come with. They are experts. One of our favorite stories was about one of our engineers, and she's working with us now, and she's a beekeeper.

That's what it was.

She blew us away. That's the one beekeeping presentation. You know, it's just kind of, you know, entertaining and enlightening and it just, you know, made us fall in love, so to speak, with her. And so that, you know, cemented her, you know, her candidacy for working with us.

So was it like a PowerPoint presentation or she just get up?

Yeah, yeah, Generally speaking. But how well do they do that?

Yeah, sure.

But to that point, the choice of the presentation sure is important because I've seen some real doozies that they didn't. They either chose poorly or they just didn't put any kind of preparation into it. And so that really shows.

Yeah. Yeah. Wow. I Love it. Okay, well, goodness, we could talk all day. I'm looking at the clock here. I'm like, goodness, this has been going on for quite a while, but. But that's a good thing. It's really interesting to me at least. Well, let's just kind of jump into a reflection section before we're two hours into this thing.

Sure.

We spend a lot of time within a lean world talking about continuous improvement and respect for people, with continuous improvement being tools, the things that we do. But respect for people can be more difficult to define. So I'm curious, what does respect for people mean to you?

You know, first we hit it briefly. And that is humble leadership. To me, being humble is all about. It's based in respect for each individual as we work with them. So that's a big piece of that. Having an autonomous, self directed culture is also important to that. But I can't help but comment on safety. As a manufacturing company, safety is a big thing. And honestly, I've seen situations where, yeah, we have these safety walks and yeah, we have safety committee this and safety reviews there. But we never really connected the big dots, which is the obvious ones. If you have big issues, ergonomic issues, workers comp issues, we need to connect those dots as well. And that comes from the leadership level, not from, you know, a gemba walk. You know, a Gemba safety walk, necessarily. And so respect for people needs to start with safety. And that's the obvious thing. But you have to be the leader that's not afraid to say, you know what, that process is going to hurt somebody and we need to retire it and move on. And that takes a special level at the leadership level to make sure that we're really having true respect for people.

Yeah. Not to be a downer, but I am so in alignment with what you just said. And it's sad that not many people actually mention that when we talk about respect for people on this podcast, but I'm glad you did. I mean, I was involved in a tragic situation where a young man, he died, he was killed, you know, in a manufacturing environment. And let me tell you, it'll rock your world. You know, when you think about the processes that you're creating literally could kill people if they're, you know, tragedy strikes. And so, yeah, I mean, I totally agree that safety has to come first. And it can't just be a slogan on a poster. Right. You have to really mean it.

Yeah, I mean, you know, yeah, okay, you got, you know, you know, finger poke risks and, you know, trip and Fall risks. Those are. Those are important to deal with. But I don't want to forget about the systemic risks of ergonomics, because, honestly, those are far more debilitating. And if I twist my ankle, all right, fine, I'm in a cast for a little while, but if I got a messed up back for the rest of my life, what's up with that? So really, ergonomics is an important one. I think it's so easily overlooked.

Beautiful. All right, what's the best advice you've ever received?

So I have to quote your partner, Kevin Meyer.

Oh, God, his head's gonna get all.

Big, you know, but, you know, when I first started working here, I asked him, essentially, you know, what's your vision for the production floor? And he responded with a computerless, paperless production floor. And, you know, he was being a little bit facetious. Right. That's a hard ideal to. To live up to a computerless, paperless production floor. But what I think that embodies is his idea that you never want to automate complexity. Don't automate complexity here. I recently graduated in industrial engineering, and I had an IT programming background before I finished school. And I'm like, I can set up a database for this and I can set up a database for that. And that's just not the right approach. If you don't even need the database where you can do it with a visual tool right in the work cell, that's what you need. Don't automate it. Don't automate complexity. So I love that advice, and I'm still sticking to it.

Love it. Yeah. I'm trying to convince. My wife's looking at, well, how we need to get better filing cabinets over here. I'm like, how about we scan all those papers? Or how about we just throw away the stuff that we don't need anymore? Less filing. So it's same principles, really. Do you have a personal productivity habit that others might benefit from?

You know, I mentioned it earlier that the getting things done approach is one approach that I think is helpful in many regards. You got to twist it and tailor it to your needs and your environment. But that's something that does help me. Definitely.

Give me a specific example, though. We'll push you a little bit.

Yeah. So if I really. It's about keeping my inbox as zero. I really try and work on that and then working off my priorities based on a next actions list and a project list.

Do you keep your email open all day long or do you check at a specific time or how does that work?

Well, in reality, I'm not at my desk very often, so there's only a few hours a day at most that I can be at my desk. And so in reality, it's not all day.

Yeah, got it.

And I'm not like a phone addict. I don't sit there and try and chew through email when I'm in the middle of a meeting or something, or.

Lying in bed at 10pm Good for you. Good for you. All right, Rob, is there one thing that surprised you over this past year of practicing or implementing Lean?

There's one little story that popped in my mind. It just happened the other day that we had a shipment of parts and we failed to meet the order quantity for these parts, and it was due to a missed inspection, essentially. Just to make a long story short, we had a special inspection for this situation, and we didn't plan on that. And so the order ran short. We only run the order on, you know, that a customer requests. We don't run over. We don't have a standard overage quantity. And in this case, of course, because we ran short, that required another setup and another run and all this extra work. But the problem was being, was going, you know, we were forced to deal with the problem. Why did we miss this one special inspection and how did that happen? And so it led to problem solving, is that we didn't have this extra, you know, we didn't run anything extra. That's our standard. And I had. I was just talking with one of my newer engineers and he said, well, why don't we run a standard overage on these orders so you wouldn't have had this problem. And it was kind of like, oh, yeah, I gotta, you know, I gotta teach, you know, I gotta teach these concepts. This isn't necessarily intuitive that you don't overproduce. You don't overproduce. Yeah. Because it covers up all these problems. And I was like, oh, yeah. And he told, he's a smart guy, totally with it. And I didn't have to explain it twice. You know, it was, well, you know, if we ran overage, we wouldn't be having this conversation and dealing with the problem. And he got it right. But it's the fact that we got to continuously teach these concepts and educate from the conceptual level on Lean Wastes. And that was kind of like a reminder call, sort of a wake up call that, oh, man, I definitely need to make sure that we're continuing to train because so often these concepts in Lean are not Intuitive, and they're really important, but it takes that constant focus to draw their attention to that.

So what was the root cause of that particular issue, if you don't mind me asking?

Well, I can't. I'm not comfortable getting into those details.

No problem.

But it was a procedural issue.

You figured it out, though, I guess, right?

Well, we're working through the solution right now, but it definitely comes from the procedural requirements that get out on the floor. And I don't need to get into the nitty gritty there. But, yeah, it wasn't a big deal. We have checks and balances on the quality level to make sure stuff like that doesn't get shipped out or anything. There's no way for us to miss something like that in the end. But when we're running product and faced with figuring out the quantity to produce, it didn't happen at that level.

Got it. Got it. All right, Rob, do you have a routine or ritual that you follow when things aren't going well and you need to recharge and refocus?

You know, the best thing that makes me feel most at ease for refocusing is really reviewing my team's projects. So I have a very, you know, a good list of all of our open projects that we're currently working on. Projects and, you know, corrective actions and that sort of thing. And me reconciling that list with my team members really is what puts me at ease. And if I feel like things are getting out of hand, I just make sure that I'm reviewing all of our open issues down the list and reconciling those. And to me, that gives me the breadth of assurance that everything is running smoothly. So for. That's really the main thing that I do.

Okay. Do you have a knowledge or skill area that you feel you need to improve in order to become a better lean thinker?

Yeah. I'm really enthused with Mike Rother's Toyota Kata ideas, and that's something that I'm not proficient at yet, and I feel like I'm getting there. I got the concepts, but putting it into practice is a little bit still out there, and I need to improve that for sure. I love his ideas, and that's really an awesome book. If any of the listeners haven't read it, that's a must read.

Yeah, no, he's been mentioned. I can't tell you how many times. Mike does some amazing work. So huge influence to lean movement.

Yes, definitely.

All right. Well, Rob, goodness, this is a great conversation. I really appreciate you taking time to visit with us. So. So let's go ahead and wrap the show up with you sharing some final words of wisdom, and then why don't you tell folks how they can connect with you on social media or any other way?

Sure, yeah. My closing words of wisdom, I guess, is all about embracing and engaging the idea of embracing the ideas that you're really not comfortable with or those ideas that you just don't understand, or you're not quite at the level that you think you should be, or the things that are nagging you, those projects that are nagging you. To me, it's all about poking at those and embracing the fact that, oh, yeah, this is making me uncomfortable, and here's why. And really engage it and move beyond it. So the idea of having, you know, getting out beyond your comfort zone is something that I've held closely on many levels in my life. You know, I've got many stories athletically and professionally that really embody that, and it's allowed me to grow and to really prosper, I think, in a great extent. So, yeah, embracing and engaging, getting out of your comfort zone. Those are my words of wisdom. As far as how to get in touch with me, probably the simplest, easiest approach is through my blog, which is leanprotoolbox.com we can connect on LinkedIn or Twitter as well. But that's probably the easiest thing to remember is leanprotoolbox.com it's just all spelled.

Out, out, L, E, A, N, P, R, O. And then toolbox.

Yep, you've got it.

Got it. All right, well, very good, very good.

Well, thanks, Ron.

Yeah, thanks for coming on. And next time I'm out California way, maybe we can go hang out at one of those fancy wineries or whatever you guys have over there.

You know, I'll take you to Firestone. You know, that's. That's the brewery of choice around here. All right, I'll skip the wine country, you know.

Okay.

I'm gonna go for a beer.

Let's do it. I love it. All right.

All right.

Okay, Take care.

Thanks a lot, Ron.

Okay, thanks for listening to the Gemba Academy podcast. Now it's time to take a free, no strings attached, fully functional test drive of Gemba Academy's School of Lean and Six Sigma over@Gembaacademy.com Gain immediate access to more than 500 Lean and Six Sigma training videos free of charge at GembaCademy.com.

Sam.