GA 631 | What We Can Learn from Tetris with Michael Parent
7 May 2026 · 30 min
Michael Parent, a Lean Six Sigma consultant, argues that system design beats individual talent. He built a custom Tetris game with reversed controls to show how bad design crushes performance even when people know what they're doing, using it to illustrate Deming's principle: a bad system will beat a good person every time.
Chapters
I think performance is much more a function of the systems that we put around ourselves. And that is something that I try to bring to all my conversations, all, all of the projects that I work on is not how do we find and elevate top performers, but how do we figure out why the top performers are performing? How do we figure out why the bottom performers are performing poorly? And how do we elevate the whole system so that we're performing at a higher level and higher capability than we were doing months past, years past?
Today I am excited to welcome Michael Parent back to the show. Now, Michael was on— it's what we, uh, we named the, the episode here at the beginning— a few hundred episodes ago. So it's been a minute since we, uh, we last chatted, but we had a really fun conversation today, uh, really focused on the whole idea of, of, um, systems design, design thinking, um, and really their, their impact on human performance and results. And, um, Yeah, we just, we had a, we all had a lot of fun. We actually just, we always have a plan going into each interview, but something came up at the beginning related to high school graduations and using AI for the voice to say the kid's name. So we, I asked Michael his opinion of that and we had a really fun, fun chat about that. Then we get into just the whole idea of the impact that systems and design have on just really performance. And really the question was really more about, you know, motivation, talent, smarts. These things are, you know, obviously, you know, play a role in performance, but what about systems and which one is more important? And so really that sort of opens up and is really the framework really for the whole conversation. And we get into— you may be familiar with Deming's Red Bead Experiment. Maybe we'll get Greg or somebody to link up a YouTube video or something like that in case you're not familiar with that experiment, but it's really famous. And well, Michael has done another version of this experiment, but he used the game Tetris, the video game Tetris. And so we explore what that is and why he did it and what problem he was trying to solve. And yeah, just a really fun conversation. Michael's a great guy. I think you're going to enjoy this one. I know I did. So, show notes can be found over at gembapodcast.com. Just look for episode 631. Again, gembapodcast.com and look for episode 631. Okay, enough from me. Let's get to the show. Michael, how are you? Welcome to the show.
Hi, Ron. I'm doing well. How are you?
Yeah, I'm doing great. Doing great. All right. Good to have you back on. We were just chatting that it's been a minute since we've had you back on. I think you were episode 423 was the last time that you were on. We're up to 6/31. So yeah, we've had a few things happen in the world since then.
Yeah, absolutely. Good.
Well, as you know, Michael, we like to begin all of our episodes with our guests sharing a quote. So what do you got?
Yeah, this quote comes from Joseph Weizenbaum, who I don't know if you know him or not. He's not a Lean thinker, but he's the grandfather of artificial intelligence, which that whole phenomenon has happened since the last time we talked. But I was doing a lot of reading about technology, and one of the things he says about technology is, he says, "Technology becomes an indispensable component of any structure once it is so thoroughly integrated with the structure, so enmeshed in various vital substructures, that it can no longer be factored out without fatally impairing the whole structure." Hmm.
Wow, there's a lot in there. What's that mean?
Yeah, what it means to me is, is we really— Weizenbaum was one who was at the precipice of computer science in the 1960s, but he was also one of kind of like cautionary reason. He was very, very aware of the potential of technology and the effects that systems can have on human beings. So I take it as a word of caution. Whatever we do, we need to ensure that we're taking steps not just to have good stewardship of technology now, but to ensure that we're making the right decisions so that future generations may also have the power to choose the technology that works and benefits them.
So, um, we're always many weeks ahead on the podcast, so what I'm I try not to say anything that's going to date the episode, but I recently posted something on LinkedIn. So if you go people right now and look, it's a few months ago. We're fast forwarding when this episode comes out. But I recently posted something on LinkedIn. It was a little poll, and I saw something here in Texas. I think it's the Plano Independent School District is planning to use artificial intelligence, um, like a voice to announce the names of the graduates at their high school graduation for the— it's a huge high school, right?
Yeah.
Um, and well, some people are just like appalled that, you know, it's not gonna be a human saying the name. And some people are like, well, yeah, well, if you saw my name, you'd be glad cuz they're gonna get it right. And, and so I put this poll on LinkedIn. And it's like, what do you think? You know, is this crazy or whatever? And it's honestly, at least right now, as of today, the poll is like around 50-50. Like, yeah, 50 think it's nuts, crazy, dystopian. The other 50 thinks it's no big deal. So like, it's interesting to see what's going on and just sort of the reaction. Like, what do you make of that? Not to put you on the spot, but.
Yeah, you know, I, had my name called when I graduated high school. We didn't have AI. Certainly, I think anybody who's sat through one of those roll calls knows that humans are fallible. They're going to make errors and that the names are invariably going to have some level of error. I don't know if AI in a naive state is going to be able to pronounce all of those names.
Well, now here's the other thing is the kids are able to sort of train it as well.
Yeah, that's— I was thinking if, if you could do something like that. Yeah. Where now you've got this.
Yeah, apparently the kids can like train it to say if they got this bizarre name, like it's going to get it perfect, you know.
I, I think in spades you go with that. Um, and you know, I think that's great. I think that the kids can participate in it and everything. So yeah, what, what I see is certainly a performance improvement. I don't see anything too dystopian. You know, the, the my dystopian narratives in my head are always about when we try to humanize the AI, when we try to give it a cute voice and give it a personality. And, you know, when you go by Wendy's and you think you're talking to somebody and you're actually not talking to somebody, you're talking to a robot. That's where I don't like it, is when that line between what a human is and what a robot is. Yeah, if we're saying, hey, it's going to be an AI voice doing this and everyone knows that, I think there's less chance of dystopia in our futures.
Yeah, well, it's here whether we like it or not. I mean, I guess, you know, if you think about when computers first came out, I'm sure some people were just like, you know, shocked and appalled that— what? You know, like, I use a typewriter.
Yeah, my name's not going to be handwritten, you know?
Yeah, yeah, yeah. Yeah, yeah, yeah, yeah. So anyhow, well, hey, Michael, so sorry for the detour there. It wasn't part of the plan, but I just thought of it when you said that. So, well, tell us a little bit about yourself. If folks don't remember from a couple hundred episodes ago, tell us a little bit about your background and how you first got involved in your line of work.
Yeah, thank you. So right now I am a consultant. I focus on operations management. I'm in facilities all the time, trying to make things run leaner, have less delays, all that sort of good stuff. As for my background, I am a Lean Six Sigma Master Black Belt. I'm heavily involved with ASQ, and I have a number of certifications from American Society for Quality. I went to the University of Michigan. Go Blue! I still live outside of Ann Arbor. Very, very proud of that fact. Before returning to Michigan, I was in various states in the South, working in kind of heavy manufacturing. And then personally, I have a growing family. My— I think last time we talked, Ron, I just had one infant, and now that girl has grown into a very precocious 4.5-year-old girl. I have two other boys, the youngest boy being just a couple months old. So I've been busy on the home front as well.
Fantastic.
Fantastic.
That's great. That's great. I think you remember my, uh, where I grew up, a little, a little bit, uh, to the side of Michigan there, Ohio. So, you know, we just won't, we won't go there, right? We finally got you, you know, like, my gosh, my, so my kids are all, I, you know, I, you know, I've got 7 kids and, and they're all, they've all just diehard Ohio State fans, even though none of them have ever lived in Ohio. They've all grown up in Texas, but, you know, their dad They just follow their dad, right? And, uh, good for you. Well, my younger kids, right, my younger kids like had literally never seen Ohio State beat Michigan. It's like, or they couldn't remember it, right? You know, I was like, well, yeah, it goes in waves like this, kids. That's welcome to college, you know, uh, rivalry.
So it sure does. So, so all of my in-laws, they live in Ohio and have gone to, to the Ohio State University.
Yeah.
And when I, when I was going there, we never won a game. We never beat y'all. And then when they were going there, they never, you know, they're a couple years younger than me and they never won again. So it was kind of—
Yeah, yeah, it just goes in waves like that, I guess. So it's fun though. And I actually have a lot of admiration for Michigan and the school in particular, you know, so much, especially in our lean world. My gosh, you know, like think about all of the influence, Rother and, Who is that? Rich Sheridan, you know, is over there and Menlo Innovations and, and yeah, so just, just a lot of, a lot of great stuff going around that part of the country. So anyhow, well, hey, I'm excited for today's topic. So kind of getting into the whole idea of motivation, talent, smarts, that sort of thing. And but I know that you're big into systems and design. So talk a little bit about your, your thoughts on the whole idea of, you know, some people would say performance is based on talent and smarts and grit and, you know, these things that we've got to do. But what's your take on that as it relates to systems and design?
Yeah, thanks for the question. I think first and foremost, I've always been a Deming guy. I think the people who taught me Lean and Six Sigma liked Deming a whole lot more than they liked TPS. So I always have that bias. Deming is through and through a systems thinker. You know, his famous quote, "A bad system will beat a good person every time." So I kind of see the world through that lens. When I think about the topics of motivation and talent and smarts, I think that is what we like to gravitate towards, but I don't think that's actually how performance happens. I think performance is much more a function of the systems that we put around ourselves. And that is something that I try to bring to all my conversations, all of the projects that I work on is not how do we find and elevate top performers, but how do we figure out why the top performers are performing? How do we figure out why the bottom performers are performing poorly? And how do we elevate the whole system so that we're performing at a higher level and higher capability than we were doing months past, years past.
So let me push back on you a little bit because so you're obviously a very, very well-educated guy, master's degree, you know, all the things like, like without that education, without that background, without your, your brains, if you will, for lack of a better word, do you think you could be as effective at what you're doing today without that?
No, absolutely. And I think that's a function of the systems, right? I think if we take a high-performing nurse in healthcare as an example, and let's say she works at Mass General, and we put her in— or him— put her in a hospital in the backwaters of Oklahoma, I think we would all agree that she's not going to perform to the same level. She doesn't have the same resources. She doesn't have the same support. She doesn't have the same standards or mechanisms that's going to allow her to perform and realize her individual potential. So that's kind of where I see that. And I think education and background and all those sorts of things play into that as well. Is if I didn't have great professors and I didn't have great mentors, my individual talents would not have blossomed the way they have.
So, so talk a little bit more then about just this whole idea of systems bounded performance with the, with the reality of high, high performers. Like, how are you— how do you reconcile these things?
Yeah, so certainly I, I wouldn't deny that high performers exist. I liked watching Simone Biles at the Olympics. I liked watching Michael Phelps years ago. I think high performers— I think one of two things is happening. I think either they're performing highly despite the system and not because of it, and I think what this would ultimately do is signal a system that's overall very weak and dependent on heroics. It doesn't have the mechanisms to elevate all the individuals. So it relies on individual performance to meet goals and, and so on and so forth. It's not, it's not reproducible for everybody. So I think that might be one thing that's going on. The other thing that I think might be going on is that individuals might be reinventing what the system is. And I'll use another sports analogy. There's a guy, Dick Fosbury, a very, very famous high jumper in the mid-20th century, and he created something called the Fosbury Flop. And essentially, before him, right, everybody was jumping over the high jump legs first. And what he did is he changed how he goes over. He goes over back first, and every high jumper then started to model after him. Um, and, and as you look at kind of the high jump records they increase, you know, by meters or half meters at a time. So what's going on here? Are the people actually getting better? Are they— are we really saying that the people in the 1970s had more athletic talent than the people of the 1960s, or that they were more motivated? I don't think so. I think what we're seeing instead is mastery of a new system and a new technique that was invented by Dick Fosbury. Dick Fosbury probably wasn't the best athlete at the 1968 Olympics, but he was the one that was operating in a different system. I think that allowed him to achieve different levels of performance. In my mind, I think it still goes back to systems dictating, at least in a large part, what performance is capable or what humans are capable of.
Yeah, I know that's super interesting just thinking about, yeah, it's a, it's not in a way, perhaps it's also a slippery slope where you sort of like put high performance and systems against each other, right? Like they're not opponents, right?
Sure.
Yeah.
Yeah. I think very much that what we should be doing is trying to identify Dick Fosbury's, not to give them a bigger bonus and put them in the C-suite necessarily, but, you know, what Deming's thought was, was the role of management is to improve systems. The role of management is to elevate performance for the entire operation. So if we can find people who are extreme users of a technology or a process, what we need to do is we need to leverage their expertise and figure out ways to loosen the bounds of the current systems and elevate performance for everybody.
Yeah. So obviously, you've mentioned Deming a few times, and you've even mentioned his famous red bead experiment. And for folks that don't know what I'm talking about, just Google it, and you can find that. So I'm wondering, though, if you can talk a little bit about something that I understand that you came up with, which is a— oh, maybe another version of, of this experiment, but you're actually using Tetris. Now, full disclosure, and I am not a Tetris expert. In fact, I've seen it. I don't know if I've actually played. I just don't play games like that. So first of all, for knuckleheads like me, talk a little bit about Tetris and then explain why you decided to sort of create an experiment using it.
Yeah, this, this is a great audience who is gonna know the Red Bean Experiment greater than they know, uh, Tetris.
Yeah.
Um, so, so Tetris is essentially a game. I think it was, you know, developed it behind the Iron Curtain in the 1980s, and the object of the game is you get these falling blocks.
Yes, the blocks that are falling. Okay. Yeah, yeah, yeah, yeah, yeah.
So I played it. Yeah, there's various shapes, and, and your job is to make lines, full complete lines, probably 20 blocks across, and then they fall away.
They go away.
Yes, exactly. Once a line is constructed, it falls away. You— the blocks fall faster. You run into issues because you make mistake, you make mental errors, and then you can't get that whole line. So it eventually stacks up and you lose when all the blocks go to the top.
Yeah.
So, um, I like the red bead experiment a lot. I've used it a lot. I talk about it a lot. I think it has a couple limitations. One is that in a virtual space, it's nearly impossible to construct. People just won't be able to do it. There's a tactile-ness about using the red beads, using the paddle, and, you know, digging in there and figuring out that you actually can't achieve the level of performance that you're expected to based on kind of how the experiment is set up. The other part of that experiment that I think is a little bit lacking is it seems to be very process-focused. Deming is certainly a process guy. Um, 1980s was, was all about process. And when I have these conversations with people, I think that they limit the scope and applicability of the red bead experiment just to the process. And what I tried to do in this Tetris experiment is focus on design itself. Not necessarily the process, but that the design of the systems, that the design of the interface is actually going to bound the level of performance that you're able to achieve. So if I could just describe what my experiment actually is, if you've ever played Tetris on the computer, if you're not like Ron—
I have played it, full disclosure, but it's been a minute.
The interface is very intuitive, right? As you would suspect, The right arrow moves the block right, the left arrow moves the block left, the down arrow moves it down, and the up arrow spins the block so you can rotate it to get it into the right position. So this, you have full knowledge of the controls and the controls map very intuitively, so you can play the game without any training or anything like that. That is version 1 of my experiment, and you play that for 2 minutes and you see how many lines you can get in 2 minutes. Now the next part of the experiment is using the exact same game, the exact same scoring system, the exact same goal. I'm going to give you a new set of controls where the right arrow is actually going to move it left and the up arrow is going to move it down and the left arrow is going to rotate it, right? So the, the mapping of the controls is not as intuitive as you would like it to be. Now, you still have full knowledge of the controls, you still have full knowledge of the goals, and I would assume after 2 minutes of playing the first one, you're still similarly motivated to achieving your goal. Yet despite the mapping, or despite all of the similarities, the mapping is going to be a very hard limit on what you can achieve. Because you run into just limitations between technology and systems and the human operator.
Okay. So like, what are you taking away from when people are playing this game? Like, what are they learning? What are they discovering? Like, are there any sort of like aha moments or?
Yeah, absolutely. There's several. So hopefully what you should learn, and again, the Red Beta Experiment, you usually have multiple operators. So maybe there's some difference between operators that you could ascribe variation to. But what I like about this is it's just you versus yourself, and the only change is the mapping of the controls. You have perfect knowledge, you have the same motivation, and so on and so forth. But there's a number of key lessons. First of all, the fact that design trumps knowledge, that despite the knowledge of the controls, It doesn't take long to be trained in, in the controls, um, that you cannot achieve the level of performance that you would if those controls were mapped. Again, the goal of Tetris is very straightforward, so there's no questions about what you're trying to accomplish. Secondly, you have issues of cognitive loading effects. This is actually what is binding your performance in this experiment, is that you have to think about the controls. You have to think that the right arrow is actually to move it left, and so on and so forth. So that's going to slow you down. It's going to make you exert more mental effort. You're going to have to translate your intentions into actions. And this takes time, and it's fraught with errors, and it's going to reduce overall performance. The people will also learn that Natural mappings naturally increase performance. It enables flow. Intuitive designs let us focus on goals rather than the mechanics in achieving those goals. So all of these things, hopefully we're not just taking and saying, wow, I'm glad Tetris is mapped the way that it is, but we're taking this and applying it to our current systems and saying, okay, where do I see bad mappings in my existing controls, in my existing interfaces, in my existing systems? Which parts of my operation am I focusing too much on training and knowledge management and not enough on making things intuitive and easy to use? And that's really kind of the last takeaway, is that if we do see areas of poor performance, these should be red flags, not to say that we have user deficiencies or training deficiencies or knowledge deficiencies, that we might actually have underlying design problems.
How often are you seeing what you just described, sort of these design problems within organizations? I mean, I'm sure all your clients are fantastic and all that, but, you know, once in a while we'll bump into even good folks and good companies trying to do the right thing, but things are still not perfect.
Yeah, certainly. I think Every company has these things. That's, I mean, that's the nature of organizations. You see it on varying scales. Certainly lean, you could almost think of it as many micro design changes. That's kind of the idea behind Kaizen. I see it actually quite a bit. I've been doing some work with value engineering and design for manufacturability, where we start to look at why are we getting so many scrap with a particular widget, let's say, that we're trying to bend and break. And then we go and we look at the design and we say, oh, well, this was designed by engineers for function. And as we look at kind of our capabilities in manufacturing, we see that, oh, there's lots of tolerance stacking one after another. Oh, they're, they're doing this and that requires another size change. And requires more handling and more jigs and all these sorts of things. So by starting at the, all the way back with good design, it can lead to manufacturing and performance by focusing on the natural mappings and understanding the capabilities, not just of the operators, but also of the machines as well.
[Speaker] You mentioned value engineering. I remember back in the day, it's in my corporate days, we were working with that, we called it VAVE, Value Analysis, Value Engineering, and like really trying to understand like sort of like the, what's the function of that thing, you know, and then are we set up correctly to do it that way? But it's a really interesting way of thinking. And it's sometimes not even intuitive initially. You're like, you almost fight yourself. But yeah, that's a fantastic framework.
Yeah, value engineering, or value-added engineering, for anyone who hasn't looked into it, is absolutely— it's a very, very fun enterprise to get into. Engineers, design engineers, typically will design things only for function. So as long as it works, they will say mission accomplished. And then what I like to do with the value engineering is look at it in terms of, well, you know, can we do it with less setups? Can we do it with greater tolerances, and then adding the human element into it too is, well, this is designed for function, but is it designed for human interaction? So that's something that we also look into quite a bit.
Good stuff. All right. Well, Michael, this has been a fun conversation. I'm wondering maybe to wrap things up, did you have any sort of final thoughts or final words of wisdom that you'd like to leave with the listeners?
Yeah, certainly. I think just kind of on, on, uh, the topic of that last thing with interactions with humans, the prime movers of technology are always going to be humans, whether we're talking about manufacturing technology or computer interfaces, whatever, whatever it may be. There's always going to be some level of interaction with humans, and I think we need to start thinking about this more intentionally and elevating it as well. So There's a number of human-centered design principles that I'll just kind of rattle off here that I think everyone should, you know, as you walk around your factory floor or start to consider your systems, think about these things in relation to the Tetris experiment, in relation to how humans interact with their interfaces and machines. So these principles are very intuitive things like preferring simplicity to complexity, embracing transparency, exploiting natural connections, using constraints as guides, and anticipating and expecting errors when you're dealing with humans.
Yeah, fantastic.
All right.
Well, hey, Michael, if folks wanted to, to connect with you, what's the best way?
Well, right now I have a Substack. You can find me there. It's called performance systems.substack.com. There I write about just about all kinds of stuff we're talking about: system design, systems thinking, human error, a little bit about technology as well. And of course, I'm on LinkedIn. I'm very active on LinkedIn, and you'll be— I'll be very easy to find if you search for me on LinkedIn.
Got it. Yeah, we'll link everything up in the show notes, so everybody just scroll down on whatever you're listening to and be sure to go connect with Michael. All right. Well, hey, thanks again for coming on, Michael. It's been a lot of fun.
Yeah, it's a pleasure. Thanks for having me, Ron.
All right. Take care. Thanks for joining us today. We know the path to continuous improvement can be challenging to walk alone. That's why Gemba Academy exists, not just to provide training, but to be your partner in problem solving. Whether you're just taking your first steps or leading a global transformation, Our goal is to help you bridge the gap between knowing and doing. Beyond our library of Lean and Six Sigma resources, we're here to coach and guide you through your journey, whether that's through personalized support or joining us for a live training to get that immersive hands-on experience. To learn more, go to gembaacademy.com.
