GA 228 | How to Apply Lean to Architecture and Engineering with Kurt Neubek

This grew out of Deming an engineer, an American engineer teaching Japanese, and it's come full circle. So this is not hard for architects and engineers to grasp.

Last week we explored how banks and mortgage departments are successfully leveraging Lean Thinking, so it only makes sense to continue down that value stream and learn how Architects and engineers are also using Lean Thinking to improve the way their work is done and to help us understand this side of the Lean movement. I'm excited to welcome Kurt Neubeck to the show, and as it turns out, Kurt went through Gemba Academy's Black Belt program, which allowed me to get to know him. Well. Now, as you'll hear, Kurt is pretty passionate about this topic, and I really enjoyed hearing yet another example of how Lean Thinking principles apply outside of a traditional manufacturing environment. Show notes for this episode, which will include links to everything Kurt and I discuss, can be found over@gembapodcast.com just so for episode 228. You can also check out GEMBA Academy's Lean Learning system over@gembacademy.com with a fully functional trial. Finally, want to give a quick plug for the AME Conference that's going to be in San Diego this year from October 29th through November 1st. We're going to be hosting our cocktail party again on that Tuesday night, and we'd love to see you all there. To learn more, including how to save 10% during registration, go to gembacademy.com ame Again, that's gembaacademy.com ame ame. Okay, enough for me. Let's get to the show. Welcome to the show, Kurt. How's it going?

Oh, great. Thanks, Ron. It's a pleasure to be here.

Yeah, yeah, yeah. Well, it's good to talk to you again. You went through our Black Belt program. When was that? It was a little while ago, wasn't it?

Yeah, it was. I started quite a while ago and it took time since because you're working full time and just chipping away at it here and there. Yeah, it took me a while to get through it, but yeah, it was great.

Yeah, yeah, yeah. Well, fun having you and it's fun to have you back on the podcast here and, and talk about an area of Lean that we haven't really explored a whole lot in design, construction, all that kind of stuff. So I'm really excited to dig into this. But Kurt, let's kind of begin at the start here and have you tell us a little bit about your background, how you first came to learn about all this Continuous improvement stuff. And then what you're up to these days.

All right, so Kurt Newbeck. And I'm an architect by day with a firm called Page or Page Sutherland. Page is a long name, but we go by Page. And I've been here for 23 years. But how I got here, starting from the beginning, my dad's an architect. When I was a kid growing up and I saw from him, I would ask him things like, dad, how do you know how big to make that? Is there some book you look up, he said, no, no, you just like, you make a mock up. Look, you sit down and you decide, is this too high, is this too low? So he's doing, I learned mock ups just quickly from him and then also doing things around the shop. The idea of before you build something regularly, you set up a jig, you know, set up essentially make the tool to make everything the same and have a template that everything is the same for consistency. So I learned some of those things very early on as a kid. And then in high school. I was in work my way through school, making pizza in undergrad and in high school and they're just making pizza. It's all about speed and trying to do it right and just learn to be very, very efficient and streamlined. And there was a guy there who used the phrase flawless maximum celeri, which is celerity is the swiftness of movement. So flawless maximum, so in other words, go as fast as you can without making a mistake. So it was a great kind of maxim for us to all strive for. So that was in Collins and then in architecture school. We're trained in what's called programming, and it's not computer programming. That phrase was invented before computer programming existed. And it has to do with when you decide what the functions or activities are going to be in, in the building. And it's also about defining the requirements. So that's called architectural programming or pre design analysis. And so there it's about creating flowcharts and bubble diagrams and designing the flow of what should happen before you design the building around it. So there's a lot of overlap with lean. Then in the early 80s and late 80s and early 90s, I worked for a firm called Caldwell Row at Scott or CRS CRSarine. And they specialized, they wrote a book called Problem Seeking and I had the opportunity to specialize in that. And we'll talk more about or tell you more about the problem seeking in a bit. But that's where I really learned pre design analysis and got some overlap with Learned about quality movements and Deming Duran and some of the things that were happening then. And then I got recruited to the firm I'm with now, Paige, to do that problem seeking and bring that specialty to this firm. So about. Because defining the problem is so critical to come up with a good solution. So for the last 30 years or so, I've mostly been running meetings with people and helping clients analyze their problems and helping them make informed decisions. And then along the way, I just was interested in Lean, and I decided to go to GEMB Academy and go through that whole program, do the black belt. And it's been great. I just love the ability to do it when I had the time to do it, do it a blitz some evening were in a hotel room or late at night at home or in the weekends. And so it was a great way for me to. To keep up and learn things at my pace.

Yeah, I guess I got to send you a check now, you know.

All sincere.

Yeah. Thank you for that. Appreciate it, Kurt. All right, well, I want to dive into that problem seeking methodology here in a bit, but before then, Kurt, I wanted to see if you had a quote or two that you'd like to share with the folks.

Yeah, well, on that spirit or the theme of the problem seeking, there's a. An American philosopher and psychologist named John Dewey who said a problem well defined is half solved. And so you just can't. If you're really going to try to solve someone's problem, you just really, really have to understand what the problem is and the root cause and all those things, but everything around it. So not only the quantitative, but the qualitative aspects of what the problem is you're trying to solve.

So that's a good one. That's a good one.

Another one that I like is I've seen this attributed to Peter Drucker, but I think other people may have said it. And it's a definition of a leader. My favorite definition of a leader is one who has followers. And I just love that because, you know, someone can be appointed a leader, but if no one is going to follow them, then they're clearly not a leader. So if I think leadership is about, if you have the right qualities that people start following you, then you know you're on the right track to be a good leader.

Yeah, that's awesome. Very good. All right, well, let's jump in, Kurt, with. And start with. With. With problem seeking, I guess. You know, what is it and how is it similar or related to. To Lean?

Yeah. So the Anecdote is. So this architecture firm, cutter roll. It's got, it's. This was in the 60s. They, they three guys or four or five guys. I think the firm was up four or five people at the time. And they won. They were, they were. And they had a project in Oklahoma. So they drove up to Oklahoma and they had meetings with the client to understand everything. And then they came back and they realized they didn't have all the information they needed. So they got in the car, drove all the way back up to Oklahoma, had some more meetings, came back and they realized, oh, there's still some stuff we should have discussed with the client. So that's when they came up with this idea. No, we're going to do a concept they called squatters. We're going to go up there and get squatters rights in a conference room. We're going to take over a room and we're going to meet with them and have enough meetings, keep meeting with them until we really understand the whole problem and we can work through the solution with them together. So they, you know, they didn't call it going to Gemba. Yeah. But it was about going there and being with the client. So part out of that came, while they were doing that, they also learned that they needed to really understand separate what's the problem we're trying to solve. So one of those guys, a guy named Willie Pena, who recently passed away at age 99, wrote this book called Problem Seeking. And it started out as a little booklet, but they decided came upon this process. It's really applying the scientific method to design. And so they start with this five. Five steps or five phases. You start with goals, establish what are the goals we're trying to achieve. And again, you're going to recognize there's so much overlap with a 3 and practical problem solving and domic and all these things. We start out with the goal or the target condition you're trying to shoot for. And also when we're designing buildings, there are all these other subcategories that we ask to make sure we're being comprehensive. We talk about what are the functional go goals for the functions, the activities, the things that we want in there. Quantitative aspects, also form. You may have heard in architecture they talk about form follows function. So you've got to talk about form. And they separate that. The goals for the form, what do they want to look like, the image, things like that. And lots of things that we design. We the world. Design is not just architecture. There is a form aspect of it. The Aesthetics, you got to talk with the client about the goals for the aesthetics. And then budget and schedule too are important to talk about those from the very beginning. That was one of key learning that they had to talk about from the very beginning. So those are goals and then you get to the facts. Let's establish what do we know. Let's everyone get documented in one place. What are all the things we know or projections that will apply to or impact the design of the solution. So the two steps so far, goals and facts. Then you get into concepts and concepts are strategies or, or programmatic concept, conceptual ideas for how might we achieve the goals in light of the facts. So these are essentially general strategies. So that might say with a building, you might say, well, these people should stay together, these people should stay apart. We want continuous flow here, we want separated flow there. What are the adjacencies, the relationships? And so you're talking conceptually, how might we solve this? And you have to overtly, while you're in this pre design phase, overtly yourself to not come up with the solution. And that's. It's hard to teach people initially, but once you get into it and especially seeing the diagrams and even how do you create a diagram that captures the requirement without prejudicing the solution? So there are ways we learn and we teach people how to do that. So that's the third step is concepts. Then the fourth one is what's called the needs. How do we quantify all those things we just talked about? Where is this going now? How do we quantify it? So in a building that is generally a space, list, area or scope, schedule and budget, conceptually, what's the scope of what we're trying to do and what's the schedule that we think it'll take to achieve that? What's the budget we think it'll take to achieve that? It's important to do these things before it's designed because then what happens? On almost every project, everyone, everyone has greater goals or aspirations than they want to pay for. So this project, this process is very much about getting all the ide on the table. In concept. We sort through them and prioritize which ones, the ones we want the most, which ones are least important. And then you say, well, when we get to what is the budget we're trying to fit to, then you can prioritize and say, right, these are the things we can afford to do today and design enough flexibility to get the rest of them later. So that's the fourth step. The final one is Called state the problem. That's where you summarize everything you've done into very concise statements about base. And writing the problem statements is not obvious. What you're trying to do is capture what I call the apparent contradiction. Because you don't have a problem statement that says something like, well, you have to design this building within budget because, well, where's the problem there? Where's the inherent contradiction? What makes it a challenge? That's the other phrase that some people call, some people frankly are turned off by the idea or the phrase of a problem that's so negative. Why do you talk about that? Well, because the reason we call it problem seeking is that in architecture, in many aspects of the world, we say here's a design solution which implies you're solving some problem. So your design is what problem are you trying to solve with that? So that's why we're saying let's seek out the problem that's supposed to be solved that way. In other words, if you ask the question very clearly, then you'll know for sure whether it's a good answer to the question. So that last step, stating the problem, is about summarizing it in a way that, that highlights the apparent contradictions or the really challenging part of what's gonna really drive and shape the design solution.

Okay, so I've been taking notes, I wanna recap, see if I got it. First one was talking about setting high level the goals of the, of the initiative. Second one is we wanna get the facts. Third one is concepts, so strategy or ideas for how we might achieve the goals. And we must not come up with the solution.

That's right.

In this third step, fourth step is the need, scope, schedule, budget. And fifth step was state the problem, capture the apparent contradiction.

That's right. Well said. And I should also give credit. I mentioned that the lead author of this was named Willie Pena, but there were other co authors along the way. And the book is actually in its fifth printing, in its fifth edition now. It's available on the Amazon today. When I was in school in the 80s, it was required reading for the architectural registration exam. I don't know if it is anymore, but it used to be that everybody knew about that book and now it's. So it's available. It's not an easy read because it's even subtitled An Architectural Programming Primer. So it's really just, it lays it all out. But it's kind of like reading a book about brain surgery. It's not going to make you a brain Surgeon. So we're not worried. The people who wrote it, sometimes people say, well, how can you give that away? Or you know, publish it publicly? Isn't that giving away some trade secret? And because of that, because it's not going to make a brain surgeon? No, they believed, and I think it was the right decision to. No, it's better to just get this idea out and share it among the community.

Can you talk a little bit more about the third and fourth step? Because to me, I guess those are the ones that I struggled with the most. When you were explaining it, I was kind of, I wanted to say, like, why wouldn't you do the needs and all that before coming up with the concept or strategies for how to achieve the goals?

Yeah, sure. So, and by the way, we use this, even though it started for buildings, this process applies to doing anything, planning anything. In fact, I've given presentations called Planning and Managing Anything that highlight all the ways you can use this. I mean, you design it, use it for designing a building or a campus or a whole city, or planning a wedding, planning a meeting. It applies at all different scales. So the concepts part, someone once said about this whole approach that those of you who do this programming, you design the building by the numbers, without drawings or without knowing what it's going to look like, you still really are designing the whole building. You know how many square feet it is, you know how many rooms they are, you know which rooms are going to be next to each other, you know the ceiling height, you know the requirements, you know what equipment is going to go in there. We know all those things, but we just haven't applied it in three dimensions or the aesthetics or because there are so many other creative ways you can design the building to meet those requirements. So back to your question now. So the needs are the summary, because you have to state, for example, if one of the concepts is. And in fact the book talks about 24 recurring concepts because as I mentioned, every project there are more needs or more wish lists than you have budget. So one of the concepts might be early on in discussion. Someone might say, well, we need a room for this and a room for that and we need a room for this other thing. And then when you add it all up and it's too expensive, then you start talking about, well, what if we make some of those multi purpose, can we combine those functions into a multipurpose room?

Or what do we really need? Right, sure.

Well, that's the first step. Exactly. First step is prioritize, cut out anything we don't need. And then if it's still over, then you start looking at more creative ways to do multi purpose rooms, for example, or get swing space or let's not build that today, but let's make it so we can expand it in the future. And these concepts or this strategy applies to lots of different things. This is probably 20 some years ago now when the software industry first came up with the phrase software architect. And it's a phrase they use in software now and have ever since then. The people who are at AT&T Bell Labs, someone was designated, okay, you're the software architect. You're the architect of the system. Back when, when AT and T Bell Labs was the phone company before the break, all that stuff. So those people started saying, well, gosh, all right, we better find out. What does that mean? What do we think Software architect means the architect of the system. So they said, let's learn from some other architects. Architects. And they found the firm I was with and they found me and they said, teach us how to apply this to telephone switch gear design. So I did. So I taught them how to the system. And then they said, yeah, well we think this applies and this applies, but we think we can skip some of that stuff. And I said, no, no, no, no, no, it's a system. So then I went to Naperville, Illinois with them and spent several weeks design using this process to design some changes to the telephone switching system. Some of them were simple software changes, some of them were software and hardware new products. And I talked to them years later when it was bought out by Lucent, they said that is still the foundation of the way we apply changes to the system. Now they use architect as a verb. People in the software industry often say we architect that now. So, so that's further about how this applies now. So I said all that to get back to your question Rod about. So why is concepts now? Some of this is iterative because you may, when you come up with certain concepts and then you say, look, what does the scope, schedule, budget look like now? Are we within budget now? And if it's not, then you may go back and start changing some of the concepts.

Okay?

It's even possible to change some goals because you might say, look, we just can't. We can't achieve that goal because there are threads that tie across these. For every goal that you state, there should be some facts about it. There should be some concepts about how to implement that goal. And it has some effect on scope, schedule and budget. Because sometimes people have goals that are motherhood and apple pie goals. And everyone nods and we put it up there. But then the reality of, okay, but what does that mean to this building? Does that mean we want to do this or that or this other thing? And people say, well, no, not really. So then, all right, let's take that goal out. Because otherwise the designers are going to latch onto that and they may take it in a direction that you don't want. Even though the process is somewhat left to right, once you kind of get it all drafted, then there is more iteration to fine tune it.

Yeah, yeah, yeah, no, I got it, I got it. That makes a lot of sense. Okay, last question on problem seeking. And then I want to ask you about a conference that you recently spoke at. But can you give an example of an apparent contradiction? I don't even know if that's a good question.

Yeah. Oh, yeah, let me think of one. So let's say we're designing just a building. And so under one of the budget goals might be to build this building. Or let's say the scheduled goal is to build a building by, let's say it's a school. It has to open by August. Okay. And we know that conventional building techniques, you can't open. We can't possibly design and build it by then. So you can't get there from here. Well, there's a challenge. So one of the problem statements would be that because the building has to open in August, and because conventional construction will take too long, then the design needs to explore alternative delivery methods. So there's an apparent contradiction. We have to open by August. But you. We can't get there from here. So there's a problem. So what does that mean? What kind of general directions does that set us in? Well, that says we need to look at something else. Modular construction, prefab, tilt wall, something that's going to dramatically shorten the normal construction time in order to get this thing open. And it's important to have those discussions from the very beginning, because if you didn't identify that from the very beginning, then not only would the owner not be aware, you could talk through the owner. Look, this is. You're going to have to find some other way to do this. So you need to be open to these other approaches. And the owner would say, absolutely, whatever it takes to be open by August. So there's one example, but there may be others in any of those categories of function, form, economy, and time. You try to find what's the real design problem in there.

Now, I know you're architects, so you're on the front end of this whole process. But I'm sure you've been around, you know, the, the construction side of it and, and, and watching this, these things go up. You know, we're redoing our, our refreshing if you will, our SMED course, our quick changeover course. And you know, so we obviously we've got lots of manufacturing examples. Internal, external and you know, get your tools and everything before the machine stops. Right. What about, where are you seeing perhaps lean thinking principles being, being, being put into place on the construction end of it in particular something like smed. Like what the concept of internal do things are external tasks, do them before the air quote machine stops. Right. Or you know, but just to speed up the whole construction process.

Oh yeah, absolutely. So the construction industry overall has, has already identified there are various reports out there that show productivity in the United States in all these various sectors and, and construction is the only one that lags significantly behind the rest of the other industries. So the construction industry has taken this seriously. How do we fix that? And so they've adopted lean. I'll say they, there is a group called the lean Construction Institute, LCI and they have been, they formed 10 years ago already. And so a lot of contractors around the country have, have been trained in how to do lean and LCI took essentially the lean that you and I know and adapted it to construction. So they have certain construction specific terms and training that they do. So an example is one of the, one of the things that they do that is very big for contractors is what's called pull planning. So when you're doing the schedule, you want to start with, you know, start with the end. But it's more than that. What they call LCI has what they call the Last Planner system. I think that's LCI registered trademark. But it has to do with getting the right people they call Last Planner because whoever's going to be the last person involved, you don't just have one person who sits in a room by himself or his or herself coming up with a schedule for the whole construction team and all these other subcontractors and everything. No, instead what Last Planner is you get the people involved who are going to be doing the work, or at least the supervisor of the people who are going to be doing the work work and get them involved to say all right. And it's pull planning. So you start at the end, say all right, if we're going to open by this date, what do you need to have in place for you to do your work. Well, the painters have to. If we're going to paint well, we have to have the gypboard up and we have to have the electrical roughed in, but no trim yet. Okay, so then, all right, how long is it going to take you to paint once you have that? So you're identifying what are the inputs that you need and what will be the output of your step. So this. And then how long will that take? So you start working through. And again, that can be iterative because often you come up with, especially people who are new to the scheduling, they build in contingency for themselves and then there's contingency built in at every step and the things take too long. So contractors are working with their subcontractors much more collaboratively or trade partners. In fact, that's the phrase that the industry is using now is to recognize all those various trades. You're partners in how we deliver this. And the general contractors are also doing things like they'll video for them to help train their trade partners. They'll do things like set up video cameras on site. And just. I've been through some training with some contractors too to see how they're teaching Lean. And one of the examples they showed was they were built. Someone was building a hospital. And so there were all these bathrooms all along the wall. There were. Let's say there were 20 bathrooms along one wall. And I set up the video camera to watch them do this and then they did a sped up version to show them. Look how many times in the course of the day you went all the way back to this side of the building, get some supplies, then you carry them over to where you were and then you forgot something so you went back. So would it be helpful if we gave you a cart? Let's set up a cart so you can do all the thing. Let's set up kits of things so you have. You ended up kidding and get all the pieces you need so that you can just march down the way. And we're not going to charge anymore for this. In fact, we want you to be more efficient if you make more money doing this. That's great.

Yeah, Sounds familiar.

Yeah, exactly. In fact, there's another story I wanted to tell you about the problem seeking. If I can go back to that for a minute. There was a really interesting story that in the. I think it was the early 80s that Willie Pena and a couple other my buddies, Kevin, Kelly, Lewis May. I think Kevin Williams was involved guys who were doing the same kind of work that we're talking about. They were invited by Toyota to go to California to work on a project that was codenamed the Lexus project. This is before the Lexus car existed. And they invited these people doing problem seeking to help them sink through. How do we approach this? They weren't overtly designing the car and they weren't designing a building either. It had much more to do with help us understand your process and the way Americans make decisions. So I thought that connection to Toyota was very interesting how because there is a lot over and there was some famous letter that they had mounted on the wall, blown up and mounted on the wall from Toyota saying, thank you you for your great insights. We learn more from you than you could imagine, or something like that.

Yeah, well, that's what you got to love about Toyota. They're willing to learn from anyone, right? Yeah. Super humble. Well, hey, listen, let's go ahead and transition to the reflection section. I got a couple of questions I'm really curious to ask. Earlier you touched on that in one of your talks that you did talk to these architects about respect for people and what that means. So I am curious to hear what do you say to them? Like, how do you explain respect for people to a group of architects?

Yeah, so. Well, first of all, for me, the respect for people is about putting yourself in someone else's shoes and fully understanding their perspective. So that just as an example, when we're working with nurses, we'll go together, we observe them for full shift. We'll just stay or walk around and observe them and really try to understand what they're doing. Because as you know, if you ask them, especially when you're doing value stream mapping, when you ask people the process, there can be three answers. There's the way we actually do it, there's the way we're supposed to be doing it, and then there's the way we would prefer to do it in the future or the better, improved, streamlined way. And so it's hard for people to set. If you just ask people, how do you do it? You never really know which of those answers you're going to get, so you have to tease them out. But if we go and actually watch how they're doing it, then, well, I mean, it's basically Gota Gemba, so there's no surprise to you. But we learn things and they learn things. And so the architects and the engineers can get a much greater appreciation for not only what they do, but a greater sensitivity and empathy for the things that they're going through because nurses, just as an extra example, are extremely resilient people. They don't complain much. They will take whatever situation they're in, they'll make the best of it. So frankly, they're not really good planners because of that, because they're so resilient. We'll say, wouldn't it be better if you did this? Wouldn't this be an improvement to your process or to the environment? They'll say, some of them will say, oh that would be fabulous. Others will say it doesn't really matter because whatever you give us, we'll figure it, we'll work around it.

Well, it's kind of like if Paul Akers has one, well, just fix what bugs you. And you're like, nothing bugs us. You know, everything bugs us. So nothing bugs us. Right?

Yeah.

Yeah.

Well, so that is one of the things that I conclude with the architects is tell them about how do you start? Look for where's the value? Ask ourselves, where's the value? Look for the forms of waste, ask the five ways, try to find the root cause and then start testing some countermeasures. And also going back to the the easier, better, faster, cheaper, in that order. First, just focus first on how do we make your lives easier? And I find with architects and engineers who often work late, they're pulling an all nighter sometimes or always working crazy hours that I would like if. Let's just improve things enough so you all can go home at a reasonable hour and you can make your kids baseball game and you get things like that because as you and others in your podcast have said, that really gets, that's something that, that people really do care about and, and it shows that we care about them too because we do. We really want them to have a good fulfilling life and don't want them to miss out on those important points. Points because of a deadline as, because our process has kept them from that. So let's improve the processes to do that.

Yeah, well, it's respect for people and also, you know, some guys working at 3am how good at work are they really doing? You know, so.

Yeah, right.

Okay. Hey, so last question. Where do you see this whole lean movement of ours going over the next five to 10 years? And maybe I'm especially curious to hear where you think it's headed in your industry.

I think it's still in its infancy in architecture and engineering, in construction. As I said, to a degree it's really growing in construction because one of the things I've seen seeing Just now. I mean, I know half a dozen contractors who have been doing projects in a lean way. In fact, I was in a meeting just yesterday with some people. It was a lean construction institute, sort of a local chapter meeting. And one of the guys who's an engineer said his drive right now is to help spread lean because he was on a project where everyone understood the lean processes. They had the right vocabulary, they knew how to cut through the waste and talk to each other and get to things. Now he's on a project that isn't that way, and it's so incredibly frustrating to him. And some of that is driven by the building type. If you have a private owner, let's say healthcare, where the owners already get. They get lean, and they encourage people on the team who understand lean and speak that language and can add value and all that. But then if you go to a different building type where they're much more bottom line driven, or it's for a government agency where they have to pick the lowest bidder they can. I can't be as selective about people about getting teams that know how to do these things, or maybe they can, but they haven't yet. So that's frustrating for people. So because of that, I'm seeing crossover from contractors who first learn this on healthcare projects, now they're using it on other projects. One of the firms, that good firm that we've been working with, took us on a tour of high rise housing that they just finished and they were talking about all the ways that they built lean into that and how that's been just been such a great success for them in so many ways. So that's one of the reasons why, again in that talk we were just talking about, I'm trying to spread that word to architects and engineers. So back to your question. I think it's going to be mushrooming from here because it's the sort of thing that it's not that difficult for architects and engineers once they speak the vocabulary. And I'm trying to convey to people, it's really not that full. I mean, yes, there's some foreign words in there. There's a few Japanese words you need to use. You need to learn when you're around other lean speakers or lean trained folks, but. But not so much that this is gonna radically change the way you work. This will improve the way you work.

Yeah, yeah, Good stuff, good stuff. All right. Well, hey, Kurt, it's been great, man. You gotta introduce me some of these LCI fellows, man, or gals or whoever. It is. I. I don't know. I don't have a connection with that group. And I think it'll be fun to get them on the podcast here and, and learn more about some of the work that they're doing. So if any of them's listening, hit me up, man. Or you can, you can, you can connect us. Kurt.

I will. I will do that.

Yeah, that'd be fun. All right, well, hey, let's. Let's wrap things up, maybe share some final words of wisdom and then tell people how they can best connect with you.

Kurt. Okay, so, yeah, final words of wisdom, I suppose, on that problem seeking aspect. Again, make sure in any. Anytime you're coming up with a countermeasure, make sure you really fully understand the problem you're trying to solve, both quantitatively and qualitatively. Because there are qualitative aspects when you're defining a requirement. There are also unstated requirements. You can ask the client what's important to you, but there are also things that are important to them that they didn't state. And you have to ferret out what I usually call in a category of expectations. They expect you to know that already, but you have to ferret that out. You have to dig for those two. So that's. I guess that's one thing I would leave people with. When you are in that, in the section of wherever you are, in your problem solving methodology, whatever you're calling it, make sure you're fully understanding all those requirements, because otherwise your countermeasures are less likely to work. If you really understand what the countermeasures are supposed to do, you're more likely to hit the nail on the head the first time.

Yeah.

So, yeah, how to reach me? So, Kurt Newbeck. It's my full name. K U R T N E U B E K. And so on LinkedIn, I'm K. Newbeck. And then also at, at my company, at Paige Sutherland, page is. My email is knewbeckagenc P A G E T H I N K like think Ahead page, think dot com.

Okay.

Yeah. So those are the two easiest ways to reach me.

Yeah. And we'll link everything up on the Show Notes page, which is gimbapodcast.com this will be episode 228. So, yeah, go check out Kurt and connect with them. And yeah, it was great chatting with you again. I miss our old coaching calls and all that kind of stuff. So, you know.

Yeah, thanks.

I'm glad to see you still using everything and doing a great job. So keep up the great work and I'll be sure we'll talk again in the future.

Good. Look forward to it. Ron, thanks so much.

Thank you. Bye Bye. Thanks for listening to the Gemba Academy Podcast. Now we invite you to take a no strings attached, fully functional Test drive of Gembaacademy.com gain immediate access to more than a thousand Lean and Six Sigma learning resources, all free of charge at Gembaacademy.com.