GA 410 | Are You Winning or Losing? with Max Krug and Pavel Kuviarzin
26 Nov 2025 · 38 min
Ron talks with Max Krug and Pavel Kuviarzin about continuous improvement fundamentals: finding bottlenecks, using visual management to spot problems, and sustaining changes through coaching and behavior shifts. They walk through real examples like laser-cutting delays and high robot retry rates.
Chapters
Sustainability to me is you gotta get the behavior changed. So it's easy to go in and make, you know, process improvements and, you know, see a quick win. But the key is to be able to sustain that long term. And to sustain it long term, you gotta change the behaviors.
Today I'm excited to welcome Max Krug and Pavel Kouvierzin back to the show. Now, Max and Pavel were on originally in episode 405, and in that episode we got all in to theory of constraints and Gantt charts and all kinds of good stuff, root cause analysis a little bit, and had a lot of fun talking about the different camps out there. You know, we got the Lean camp, the Six Sigma camp, the TOC camp. And sometimes these camps fight with each other. I don't know. For some reason they do that. So we had a lot of fun in 405, but unfortunately we had some other things that we wanted to get to and we ran out of time. So I asked them to come back on so we could sort of finish the original thoughts that we had. So today what we do is we talk a little bit more about root cause analysis and problem solving, but then we really jump into a nice discussion on visual management and sort of like how to use visual management to identify whether or not you're winning or losing or whether or not things are operating normally or abnormally, that sort of thing. So that was really good discussion. And then we talked about kind of the hardest part of continuous improvement, and that's making sure that things don't fall back apart after we've made them better. So we sort of wrap things up by having a nice discussion on. On sustainment, on getting stability and then sustainment and then keep making things a little bit better. Right. So really good, really good episode. I really like talking to Max and Pavel. They're both super smart guys. Yeah. So this is episode 4 10, 4, 1 0. So all the show notes can be found over@gembapodcast.com Episode 4 10. Okay, enough for me. Let's get to the show. Havel and Max, welcome back to the show. How are you guys?
Great. How are you doing? Ron, thanks for having us back a second time.
Thanks for having us, Ron. And we're doing good.
Yeah, yeah.
Awesome. Awesome. Well, we had a lot of fun in our last discussion. We thought we. Let's keep. We. I know we had some things that we wanted to talk about and we didn't get to them all, so I wanted to have you guys back on. So I appreciate you guys carving some time Out. But just to follow our protocol, we do, as you guys know, like to begin with a quote. So what do you guys got?
So from Edward Deming, one of my favorite quotes where he said, it's not enough to do your best. You must know what to do and then do your best.
Yeah, that's a good one. I like it.
And I have a Deming quote too. So we both pick Deming this time. So I like. A bad system will beat a good person every time.
Man, ain't that the truth. Very good, Very good. All right, guys. Well, hey, so you guys were last on. Let's see, episode four. 05. So we, we spent a lot of time, I think we called that one elevating constraints. And we spent a lot of time talking about TOC and Gantt charts and good stuff. Drum, buffer, rope. And we got into some root cause analysis. But, but maybe before, what I want to do is maybe we'll use that root cause analysis as a sort of a jumping off point into episode one, this episode. But just, just in case folks didn't Hear that episode 405, I'd encourage everybody to go back and listen to 405 because it was some good stuff. But tell us just quickly about your background and the work that you guys do.
Okay, so my background, this is Max. My education in industrial engineering. So I spent most of my career in manufacturing, a little bit in distribution. I started Future State engineering back in 2005 as a consulting group and then started Future State Engineering rebranding about two years ago. And really we're focused on helping companies become high performing organizations. And we use all different techniques to do that. And we talked about the camps last time. We're not dedicated to a certain camp. We use what's the best method to help the company move forward.
Yeah. Yes. And Ron, my background is coming from operations. For the past 15 years I've been holding operations management positions. I started my own consulting three years ago. And two years ago I started working with Max's team. And we were helping mostly manufacturers, but we did work with distribution and construction companies to achieve breakthrough results. And it's correct. Like Buck said, even though we're coming from the TOC theory of constraint mindset, we apply different methodologies. Whether it's lean, Six Sigma, it's the right time. So we applying the right tools. I don't know if you remember, it's important to know which tools to apply at the right time. So like my quote from Deming, you must know what to do first and Then do your best. Because lots of companies, they think they're doing best. They're working on their department. And many times in their department, they're working. And then many times they have a silo approach. So they're doing really good for their department. They're really doing good with the processes within the department. But many times the problem is they don't have the system thinking. So they're. Even though they're doing really good for the specific process, it's not helping the system to produce more.
Yeah, got it, got it. All right, well, like I said, we, I think we, we finished up episode 405 with really talking about root cause analysis. And then we got into the. Those camps that you guys are talking about, the lean folks versus the Six Sigma folks versus the TOC folks. And so some really good discussion there. But I thought maybe we could use some. The opportunity to maybe dive a little bit deeper into root cause analysis and getting in maybe some problem solving discussion. And I'm really more interested in not necessarily hearing the theory behind it, but maybe some stories of, of what you guys have seen out there out in the, out in the wild, so to speak, you know, of how you've seen root cause analysis work and just problem solving in general.
Okay, so we have a lot of examples of it not working. Yeah. And then helping companies get it to work. So a lot of what we see is that again, there's a process to doing problem solving and people don't follow the process. They skip steps. They, you know, they do them out of sequence and then they don't get the results and they don't understand why it doesn't work. And give you a quick example. So we were contracted to come to a company to do training for problem solving. Pavel and I went in and started working through the process. So we use pdca. So I don't care what methodology you use, follow the process and we start looking at some problems. So part of our training is we do applications. We train and we take a problem. We work through the methodology with them on their problem. So they get the hands on experience in an environment that they're aware of. We start doing the problem solving. They had a big problem with the first operation, which is a laser cutting operation. And it's interesting because the plant manager was like, well, we need to get this laser machine up and running. It's like, we're like, well, this is a bottleneck. They're like, what are you talking about? And when we started to dig more into it, the plant manager Was the one that justified buying this equipment. And so we got this new piece of equipment that's not running. So get the machine running. So there was sort of a side story behind what we were working on. But when we started to go into the area and look at the laser machines, like why isn't it running? It wasn't actually that process. It was the next process. The shakeout process to unload the machine was the bottleneck. And so when we started to shine the light on what's the real issue, it sort of changed the whole focus of our problem solving. And then it's interesting to us just having a different set of eyes and getting them to look at a different perspective, how it changes their mindset. Yeah.
So it was fascinating because they were so determined that the big problem is the laser. The laser operations invested so much money and time and now they put those two big laser machines and somehow still the system is not producing more than what they expected to get out of this lasering system. And the plant manager is adamant for us to help him to. To get the system up to speed so that we can produce more parts. So we going with the teams, we're doing the PDCA methodology. We're going with the teams, we assess the problems. We're going on the floor, we're looking. Okay. So at times the lasering operation is idle and they're extremely not satisfied with. Or the plant manager is not satisfied with the laser operation being idle because the operators that is moving the parts is not able to keep up with the laser machine because it's so, so fast cutting the machine. But then we're looking a little bit further down, further downstream and we see that they have the shakeout, Then they have the frame after the shake of the frame. And there is a mountain of inventory in front of shakeout. A mountain of inventory. But nobody's looking at this mountain of inventory and they don't think it's a problem. So we start asking questions. So if we can laser more parts, do you think it's going to help the system? Do you think you're going to produce more parts or you're just going to create a bigger mountain of the front of the shakeout and somehow the light bulb starting to kind of getting brighter and brightening. It's like aha. Lights up. Maybe the lasering is not the constraint. Maybe the laser operation is not a constraint. But we need to focus on the shakeout.
Yeah. Being able to identify, just getting people to. To ask the question, like what problem are you trying to solve. Right. So, okay, laser or what this good look like, you know, down. That's another way of going about it, I suppose, is, hey, if we're successful here, what will we see? You know, how will we know if we're. If we've won? Right. How do you guys help people identify that? What problem are you trying to solve? I mean, obviously from a TOC perspective, we're looking for the constraints and all the rest of it, but let's just say we've identified it. Yeah, that. Or maybe it's not even a throughput issue. It's just a problem in general. Like, how do you help folks identify what problem are you trying to solve?
So typically we start out with looking at the undesirable effects that they're dealing with. And so if we go into an area and we start making observations and talking to the people, what we like to do is let people complain about their job. So they start telling us like, oh, this guy, you know, if that guy would pay attention, we would have these problems. And it's like, and this machine's never reliable. And so they just start complaining about all the issues that they're dealing with. Because a lot of people are good at identifying the symptoms, but they're not good at getting to the problem statement. So to your point, Ron, we start asking questions, we start letting people, you know, venture. Talk about the problems that they're dealing with, the frustrations, and then we take that information and start collecting that and say, okay, these are the frustrations. Now let's try to boil that down into a problem statement. And a lot of times companies don't do that. And then they end up dealing, you know, working on the symptoms instead of getting a good problem statement defined. That's basically encompassing the scope of what they're dealing with.
Yeah, yeah. Do you guys see people trying to include countermeasures or potential solutions in their problem statement? I've seen that. Do you guys see that?
Yes. Yes. And that's one of the, that's what we always say. It depends at what time of the PDCA cycle you are at. You can't implement solutions right away. And many times when companies experience effects of problems starting with they, they know the solution right away.
Yeah.
And they creating a solution. And that's a big problem because you're not really diving into the root cause. You just keep, like Max mentioned, you keep focusing on fixing the effects of problems, but the root cause never disappears. So it either does nothing or solves a little effect, but there will be Other effects that don't start popping out.
So, so that reminded me, Ron, you said that we did training last week on problem solving. And so when we were having the teams define their problem statement, the one team kept putting causes. They have a statement and it causes this to happen. I said, you can't have cause and effect in your problem statement. So I go reword it. So they were having trouble. Every time they reworded it, they put causes this to happen. It's like, no, what's the clear problem statement you're trying to solve? So they were trying to. They almost started to get the first five why statement in their problem statement. And they were struggling with it.
It's hard, especially when you have ideas, right? And I tell people, hey, it's fin trying to have ideas of what you think some root causes might be or what some potential countermeasures might be. That's fantastic. Let's put them in our back pocket and keep them there for a bit and let's focus on the problem statement. You know, I'm curious to hear you guys thoughts on quantifying the problem with facts, with data. I always use the analogy of you're going into a courtroom and you're the lawyer, you know, and you can't just go up and say, hey, the jury, hey, he did it. And it was okay, great, tell us more. Well, no, no, I'm just telling you he did it. Well, where's your evidence? I'm just telling you, you gotta believe me, he did it. You know, so in fact is if you don't have any evidence, right, that he did it, then you're gonna lose in court. And it's the same thing in problem solving. So often we come into these things when you say that's a bad process. Okay, okay, well, tell me more. You know, and you come to find out they can't actually quantify the badness. If you process, are you guys seeing the same thing? If so, how do you overcome that?
Yeah, so it's funny you mentioned that because I use that in a training. It's like crime scene investigation. So I go imagine yourself going in front of a judge and you were in an accident and you say, oh, some guy hit me. Well, where do you. You know, it's someplace in Buffalo, right? You got to have the details.
Right?
So you got to have the details of what happened and gathered as many facts as possible. So a lot of times companies don't gather those facts. So part of our process, the second step in the process that we have is Defining the problem statement. The first step is assessing the current situation, gathering as much facts and details about what happened as possible. Of course we want to go when it's happening, but if we can't go when it's happening, as soon as possible after the event, gather as many facts as possible. And we're looking for quantity here, not quality, because we never know what facts might be relevant and which ones aren't. So we have a process of going like crime scene investigation and gathering as much data as possible about what happened. And that helps us start to get enough information to develop our problem statement.
Yes. And just another example from a client we're dealing with. So they have a problem with. So they say it's an operation with forge hammers and I have a problem with a lot of downtime due to machine breakdowns. So we started diving into the process, getting to the root cause and call, and we need data to answer the five why questions. And we got stuck on the one question where, because I don't have data, every time they do a rebuild of the machine, they don't take any data or any information as potential root causes of why the hammer is not square. So we get to the, we got to the position that when the hammer is not square, it causes breakdowns. But why it's not square, we don't know. So we need data. And with all the preventive maintenance they did, they have nothing in the records that is going to help us. So now we need to do a rebuild to get the data. But guess what this client is now doing. Every time they have a preventive maintenance or anything, they're starting to collect data because now they know how critical data is and how much is going to help them in the future. So it's fascinating how our clients are changing their perspective, changing their mindset and being more proactive versus reactive.
And so on the squareness issue, they're like, well, you know, one of the problems might be it's not wearing, you know, equally. So when it's hammering, the wear is uneven and it creates to become out of square. And so we talked about measuring the where blocks when we take the rebuild, but the problem is we have no measurements of the blocks that they put in. So now we don't have a starting point and we only have the ending point. So to your point that we talked last time, it's going to be guesses and we're going to take the guesses and we're going to try to validate based on the guesses what's the reality. And it's an iterative process and I think people get impatient with that process because it's iterative. It's like, okay, we think this. Nope, the data doesn't support that. Okay, let's change our theory. Let me think this. And sometimes that could take weeks. And people get impatient and they're like, just solve the problem. We're trying to solve the problem.
Yeah, exactly. Well, we've got to experiment and learn. Right, Experiment and learn and just keep repeating that, you know, that process. So, yeah, really good stuff. No, the. I want to transition now, guys, and we could talk about root cause analysis and problem solving all day, but.
Right.
I'm really interested to hear your thoughts on the importance of a visual management and maybe how you guys are using it, why you're using it, and maybe some tips and maybe even some traps of visual management gone wrong. What do you think?
Okay. Yeah. So we're huge components of visual management. The main purpose to us for visual management is what you mentioned earlier. What does good look like? We tell our people that we work with, if we can't see the problem, we can't fix it. Visual management's there to help us understand what normal looks like. What does good look like? But more importantly, when we have something that's abnormal that we can see it, we use visual management as a tool to help us understand normal condition and help us see abnormal conditions so we can address the problem. That's our philosophy on visual management. I think a lot of people go overboard on visual management and everything's got to be visual. We step back and say, okay, what does normal look like? And then we need to ask ourselves what information should the process be telling us to understand if it's normal and if we see normal, we can understand abnormal. So the first question that we need to answer is what does normal look like? And then what information do we need from the process to be able to spot abnormal that helps us guide what visual management we need in place, if that makes sense.
Yeah.
Yes. And I would like to add also. So the way we do usually with our clients is we develop a process that we want so the future state how we want to see the process. To what do we want to do then? What we do is what good looks like, like Buck said, and what good looks like. We use visual management to help us to ensure that that's what good looks like. But also visual management helps us to identify when it's abnormal. And the purpose of that to reduce the management window and to be able to Be proactive versus reactive into solving problems. If anything deviated from the process. Because what we notice with our clients is that when you introduce a new process and you started, that's the hardest part. To sustain and to create the good habits. Because there is a lot of bad habits developed. And to create good habits is really hard. Visual management helps us identify those bad habits really quick that they're not doing the good habits and take action. When we take action, people start, understand, okay, we're not doing right. And then they're starting to do the process. They follow the process. They follow the process and eventually it stabilizes and we sustain the process.
Yeah.
So that, that can bring us even to the next point. How do we sustain a process?
Yeah, no, for sure. I want to go into that, but I'm not going to let you off the hook yet on visual management. I'm curious to hear maybe do you guys have some, I don't know, maybe a favorite one or two techniques? You know, I mean, obviously from like a production perspective, are you like hour by hour boards or like what are some of the things that some of the tactical visual management tools that you guys like to see?
Yeah. So hour by hour boards or hour by hour charts on the process and on signals or and on lights. Let's bring it specific locations for things. So a little bit of 5s type concepts. Simple visuals of like normal, like so even like on a gauge. Right. Putting a green.
Yes.
Area where the normal operating range is so we can see what's normal operating range. We're not big on huge Gemba boards where people are putting tons of data. Because a lot of times I see people don't keep the data up to date and then it's not accurate data. And I'm more of like let's build the visual management into the process. So we have one company where we have a procedure for loading one process. Okay. This is what pictures of what normal looks like. And when they're running that product, they should have that picture of what the normal load looks like. And then anybody can come and compare the picture to the actual belt. If it's not the same, then immediately a red flag should be raised and it's not. Visual management isn't a tool to beat the operator with. So we say you're going to use it as a stick to beat the operator. We're not going to do it. It's a tool to help the operator improve and sustain the process. Yes.
So another example, Max mentioned anon lights. So for example, just a quick Quick. With one of our clients, we have an issue with of high retries. So they have a line with robots picking up material, they're bringing it to the laser and for some reason it's not continuing the operation, it drops it back on the conveyor. So it's a retry and the retrace were as high as 50%. We did some problem solving, we did some root cause analysis, we reduced the retrace and then we introduced the visual management. So the anon lights, anything. If the retry rate is over 5%, it flashes yellow. So it's visual management right there tells us it's abnormal. So just a little example.
I like it. Are you guys using or seeing any benefit of SPC in certain situations like control chart or anything like that?
Yeah. So we do a lot with that also. And again, understanding the variables that are controlling the process and that's where we want to. And if we apply the Pareto principle, what Pareto would say is that 20% or 80% of the defects or problems are coming from 20% of the variable. So we don't need to do visual management on every variable.
Right.
And that's why I was saying it's like people can go overboard. We need to do visual management on the variables that are most affecting the process. As long as we can keep 20% of those variables within normal operating range, 80% of our issues go away. The guy that trained me, when he's training me, he says, what is data and information? That's a good question. What is data and information? He said it's the answer to the question we're asking. If we don't ask the right questions, we're not going to get the right data or right feedback. So I see companies gathering huge amounts of data going overboard on visual management. But we really want to step back and say, okay, what question should we be asking? And then let's design the visual management and the data collection tools to answer those questions.
Yeah, I was thinking what questions would I ask? I think I have two questions. Let me get you guys thoughts that I would want answered. Number one, to your point earlier about abnormal versus normal. So are things operating normally? That's question number one. And then, and then number two, which maybe if number one is true, then number two should be yes, but, but I think we should still ask it. Are we winning or are we losing? You know, like right now, three o' clock in the afternoon, we walk out and you go up to any operator, it should be able to say, hey, are you winning? Are you losing right now. And they should know immediately. Right. Not just from their gut, but from some, some visual management, whether it's again, hour by hour, board or. Or some other mechanism, you know, where they're. When they're monitoring their performance against some plan. Right. What do you think?
Yep. Agreed. And that operator needs to know real time. Is he. Is. Are we winning? Right?
Yeah. Yep.
If the process is designed correctly, in normal condition, allows us to win, then he needs immediate feedback. Is it normal condition? If it is, then I'm winning. So I have that real feedback in the process. It's like managers think that the visual management's for them. No, it's not for management. It's for the operator. It's the person functioning doing the process that the visual management's for.
Yes.
And it's critical. They also. It motivates the teammates so that they understand if they're winning or losing.
Yep, exactly. Okay, well, hey guys, let's wrap things up. I'm curious to hear your thoughts on. Okay, we've got a process and it's operating normally where we're actually winning. We're doing well and we made some nice improvements. We've solved some problems. How do we sustain a process? Because you know the second law of thermodynamics, right. This thing called entropy is always out there pulling.
Right.
And it never stops. Right. It's always trying to bring disorder to a system. So how do we battle that? How do we sustain? How do we keep things working normally?
Yeah, so that's a great question. And sustainability to me is you got to get the behavior change. So it's easy to go in and make process improvements and see a quick win. But the key is to be able to sustain that long term. And to sustain it long term, you got to change the behaviors. And what Pavel and I have seen is like people have been doing the things I wouldn't say incorrectly. There's a better way that can be done. And so when we try to put that better process, the best practice in place, people have a six week rule. After about six weeks, the wheels fall off and they go back to old habits. And what happens is there's not enough positive feedback for the operator to sustain that for the long term. And then the behaviors don't change. So after a few weeks they start to drift back a little bit. Drift back a little bit, Drift back a little bit. Then six weeks later they're back doing the old process. And I think we talked about it in the first session. We only have one rule. When we work with our customers, and the one rule is we follow the rules. And I'll give you an example. I set up a replenishment system with the company on raw materials. And I did a Kaizen event where I brought in the supplier, and they're having issues with way too much inventory, the wrong stuff and not enough, the right stuff and disorganized. And so we started getting the replenishment process defined, and we put in visual management and we set up containers. And then the rule was, when the container is empty, we reorder. About a week later, I get a call from the operator. He goes, oh, I got a question for. You can come down. So I go down. He goes, oh, I just finished the job and there's two parts left in this container. So do I reorder? I go, what's our rule? He said, when the bin's empty, we reorder. I said, is the bin empty? No. There's your answer. So it's not only having the visual management to support them, it's the coaching that goes along with it to coach them when they have questions or they start to veer off a little bit and get them back on track. But you got to get the behavior change, and it takes some cases months to get the behavior change. You need that constant feedback of not only the process, visual management, but the coaching, the mentoring and rewarding for the good behavior.
Yes. To get this change in behavior, it's critical also to get the leadership and management involved in the entire process. When the management window is reduced, we have the visual management in place, and it's easy to identify abnormal situations. What's important here is to act when it's abnormal and not just let it happen. So you act, you do the corrective actions in place, and you reinforce the behavior and eventually you change the habits.
Yeah, yeah. You know, one of my kind of passions in life as it relates to continuous improvement is, you know, towards D. I think we may have talked about this on a last episode. I talked about it with somebody recently. Talked to a lot of people. I can't remember who I talked to, but, you know, I'm of the mindset that it's very difficult, difficult really, to, you know, keep something going perfectly sideways. I believe really in life and nature, if you will, it's either getting a little bit better or it's getting a little bit worse, you know, and so I'm also of the. Of the opinion that when you're trying to sustain a process is keep trying to make it a little bit Better. It doesn't have to be a lot better.
Yeah.
But just a little bit better. Positive tension. Right on that. On that process. What do you think?
Yeah. So what I learned from Deming is the process has got to be stable before you can improve it. So our first step is to get it stable. That means people are doing it consistently. Consistent, consistent, consistent. And he had a statement that's been in my brain. If you have a process and it's. He said, even do it consistently, even if it's wrong. Because if you do it consistently, even if it's wrong, you'll understand the cause and effect relationship of what actions are causing what effect. If you have people doing it different all the time, then you have no idea what's the relationship between the cause and effect. So our first goal is to get people doing it consistently in the visual management, and the reinforcement gets us there. Then once we get it consistent, then we can start making those incremental improvements. But making those improvements when the process isn't stable is a recipe for disaster.
Yeah. The last thing I'll say on this, it's almost the inverse of what you're saying is sometimes when you think back to problem solving or root cause and our countermeasure development, sometimes the worst thing that can happen is that you throw a lot of countermeasures, add a problem, and it works because you're like, oh, which one was it? You don't know because you didn't have any. You know, you have no idea what actually fixed it because you were trying so many things at one time, Right?
That's correct.
Yeah.
Yeah. Good stuff. All right, well, hey, guys, this has been fun, man. I'm glad we did a second one. I feel like we covered all the original ideas that we had when we were brainstorming before even the first episode. So thanks again for. For coming on. Maybe, I don't know if you guys maybe each have some final words of wisdom for the. For the folks listening out there. Maybe one way we could go about that is, you know, in our audience, we've got everybody from people brand new to. To lean to, you know, really experienced folks who have been at it for a long time. So maybe one of you can speak to the. To the person just getting started, maybe with some. A practical tip or two. And then the other person can speak to the old guru, the veteran out there who is, you know, also on the journey and always and trying to get better as well. So I'll let you guys decide who speaks to who.
I'll Speak to the experience and follow if you want to speak to the.
Just starting out, go ahead.
So for the experience people, my message is, one of Dr. Goldratt's pillars is never say I know. So don't get in the mindset that you know everything because you don't. You can never stop learning. So always have an open mind and go into it and you know, use that open mind as your advantage and don't get close minded like oh, I know what the solution is. No, there's always learning that can be done. You can never stop growing as a person.
I love it.
Yes. And what I can say for somebody who is starting out is so you're starting out but don't be afraid to challenge the status quo. So once again keep an open mindset but at the same time don't be afraid, challenge the system. Things can be always done better. And listen, learn. But at the same time think of ways how you can do even with not a lot of knowledge. But what can you do? Like think about the solution differently and challenge the status quo.
I like it.
I always tell young people that are starting out, you have a window of opportunity here where you complete ignorance. So use that to your advantage. Ask questions and say no, I don't understand how this works. Explain it to me and you'll be surprised what you get for answers.
For sure. For sure. Awesome. Well guys, what's the best way for folks to connect with you individually and then also with your company? Future State Engineering?
Yes, our website is www.futurestatengineering.com and Pavel and I are both on LinkedIn. So our emails are our first initial, our last name uturestatengineering.com so mine's mcruguturestateengineering.com and LinkedIn is always a good way to connect with us. Yes.
And mine is pico VRs in futurestudyengineering.com I also thought to mention something so we have a workshop, Lessons in Synchronous Flow. So if anybody is interested to learn a little more. It's a free workshop where you can. When it's a different. It's a different methodology of how you can improve throughput. Basically this methodology helps our clients to produce more and it's also using the same resources. So it's called the Dice Game and it's gonna happen on the first of every. On the first Tuesday of every month.
Yeah, you're doing it one time or you do it more than one time.
So we have five sessions set up right now starting in February, the first Tuesday of every month.
Okay, good. Yeah, because I, I don't know, I'm trying to do the math on when this episode's going to come out. It might, may come out after that, so. But I guess it's all on your website.
Yep, we'll get it on the website.
Okay. Okay. Yeah, so we'll drive people to your website and they can go check that out. We're gonna, we're gonna put everything in the links, all the links in the show notes like always. So you can find us over@gembapodcast.com episode 410. Well, hey Max and Pavel, thank you for coming on. This has been fun. I appreciate you guys taking the time.
Yeah, we really appreciate having us on the show, Ron.
Thank you, Ron.
All right, take care, guys. 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 more and to schedule a demo, head on over to gembaacademy.com.
