Subscribe
Share
Share
Embed
How do we begin creating the future we want, today? Design This Day takes you on a journey to our future world. Futurist Devin Liddell sits down with visionary leaders from some of the biggest names in tech and innovation. Each episode features a brilliant mind who is building the opportunities of the future before most people even know they exist. What will living in microgravity in space look like in the future? Can driverless vehicles go off-roading? What unexpected roles will robots play in our future workplaces and homes? We explore the role that design plays in shaping our future – with the big thinkers and doers who are creating tomorrow, today.
Design This Day is an original podcast brought to you by Teague.
About the Host: Futurist Devin Liddell
Devin Liddell is the Principal Futurist at Teague. With over two decades of experience in innovation and design strategy, Devin has worked with industry giants like Boeing, Intel, and Nike, helping organizations anticipate changes across both near and far-term horizons to create their preferred futures. Devin is a frequent contributor to Fast Company.
Get in Touch:
Have a complex problem that needs solving? Have a great guest or topic idea? We want to hear from you. Visit us at teague.com or send us an email at hello@teague.com
Emily Vetterick:
Have you ever been in a hallway and you accidentally are walking towards the same kind of trajectory as another person? And so you both take two steps to the left, and then you both take two steps to the right, and you kind of do this dance. Proteus needed to design for that problem and that interaction. And so our designers needed to figure out how to signal intent because, from a customer lens, an employee just wants to know where Proteus is trying to go. And so that was a big part of the design problem. It has to be a very intuitive design framework that allows somebody who has never seen this robot before to understand how to be in the same aisle way as it.
Devin Liddell:
Welcome to Design This Day, a podcast about the futures we want and the people working right now to make those futures real. I'm your host, Devin Liddell. I'm a futurist at Teague. This year we're celebrating Teague's 100th anniversary, so I'm thinking a lot about the challenges of today and how we're going to solve them over the next 100 years. My guest today is Emily Vetterick, an engineer whose career has spanned a massive diversity of roles at some really big organizations. She's worked at Boeing, Meta, Amazon's Prime Air, and currently serves as the director of product, program, and ops at Amazon Industrial Robotics.
In so many ways, her career is a story of scale and all of the complexities that come from scaling up from a prototype to a fleet. And at Amazon, she's working with the world's largest fleet of robots, tallying over one million. So today we'll get to hear about how Amazon thinks about orchestrating its mobile robots at fulfillment centers and creating the complex systems that keep orders going out the door. She's led by one design principle in particular: hearing from her customer directly and then integrating what she learns into the systems. And that lesson came to her at the beginning of her career at Boeing.
Emily Vetterick:
So I was a production engineer, and I was assigned the 767 aircraft joints. So when you bring the wings together to the body of the aircraft. It's an amazing process. It also involves a lot of overhead crane movement, so it was usually done on third shift. It wasn't expected that I go watch these, but how could I not? So I often showed up at 2:00 AM, the eager engineer that I was, just to watch what was going on so I could really understand the process. And over time, the mechanics kind of turned me from an observer to including me a bit more, so I got to wear headphones, listen to everything they were doing. Sometimes they used a little bit more aggressive language that they toned down when they heard I was on the call. But it was really interesting to watch what they were optimizing for, lining up seat tracks, lining up wing joints, lining up everything they have to think about.
But what was really great is as they started to trust me, they would unload about all the things that were problematic. And it was actually really great because this was an older program designed in the '60s or '70s, and there were a lot of assumptions that had just changed over time. And the mechanics just wanted somebody to listen and be like, "Oh, interesting. If we made this tweak in the engineering, we could actually make the rework number go down," so higher quality, or make it a little bit faster in the build process. And so we started generating this list that became part of a much bigger engineering effort, and we took out hundreds of hours of the build process. It was a really great partnership.
Devin Liddell:
That's amazing.
Emily Vetterick:
And I could talk about stories from nearly every job I've ever had where we had some assumption. The assumption changed over time, or something changed in the customer's operation, and then we needed to adapt the engineering. That's the important part about bringing your customer in.
Devin Liddell:
What I love about this story is that it underlines the trust required to gather useful customer feedback. By spending time with these mechanics in their environment, Emily got to see how these processes could improve. I think this is a lesson designers learn again and again over their careers. Design starts with listening to and observing the real human at the center of any product, service, or experience. So then, from your roles at Boeing, you then shifted over to Amazon Prime Air. Tell me a little bit about how that actually even happened. I'm also just curious, what was it about the opportunity at Amazon that was a real hook for you?
Emily Vetterick:
Yeah, I really enjoyed my time at Boeing. Working on aircrafts is a pretty magical experience. We joke that people do the airplane salute when they work on aircraft, where anytime you hear an airplane, you look up at the sky and you try to identify what it is. I still do that today. But Amazon's interesting because of the pace and scale. So Boeing creates about an aircraft every decade, a new aircraft, at least on the commercial side. Some of them take as long as 15 years, and this is a transformative process, but I wanted to have a little bit more speed of technology. I wanted something that was measured, maybe more in weeks or months versus years. And so when Amazon called with an opportunity at Prime Air, I was pretty excited. I joined at that interesting stage between deep science R&D and switching over to production scale.
It's my favorite place to live in the process. Some people love it, some people hate it. No matter the product, no matter the company, no matter the team, this transition is hard. Because on the R&D space, you have these visionaries that are trying to push the boundaries of science, and they always have one more idea or two more ideas, and getting the pencil to get put down so you can transition to all the other work that needs to be done is hard. And then on the other end, you want to scale a production system, a manufacturing system, a supply chain; you start delivering to customers, and you have to iterate quickly to make sure that you're really dialing it in. People love this as well, but that's also really hard. So I kind of love being in the middle, and that's exactly where Prime Air was when I joined in 2020.
Devin Liddell:
The messy middle is that space between development and actually releasing the project to the customer base and scaling. Not everyone loves this stage, but Emily thrives in it. Emily told me as soon as she got to Prime Air, she saw a demonstration that showed her how differently Amazon thinks about its customers' experience and how they scale.
Emily Vetterick:
My very first day on the job, first day at Amazon, coming from a decade of working in traditional aerospace. As with any first job, you're touring the office, seeing where the cafeteria is, meeting people on the team. If you work on cool hardware, you get to see the testing facilities and all the different lab spaces. And as we got to what was the indoor flight cage, there was a drone about to take off. So obviously we stopped and watched and it was my first time watching the drone operate. It took off, it went to its coordinate, it descended a little bit, and then it dropped the package, and I was flabbergasted that it dropped the package because, coming from traditional aerospace, the way aircraft operate are they take off, they go to their destination, and they land. And so this was really my first lesson in how Amazon does design.
They don't start with how do we design this product. So in this case, they don't start with how does traditional aerospace say a drone should operate. They start from what the customer wants, which is a reliable, ultra fast, safe delivery system that is consistently delivering 30 minutes or less. And when you think about it from that lens, then it really optimizes the problem space differently. And so it's actually quite an elegant solution for the drone to not land. It simplifies it from a customer perspective, from a safety perspective, and an engineering perspective. They're thinking about it from the customer's lens, and they're also thinking about it not from a one-product perspective or a one drone or a one customer perspective, but from the Amazon level of scale.
Devin Liddell:
So how did you approach the scaling of these drones?
Emily Vetterick:
Yeah. So if you think about the customer journey, they really interact with one drone at a time, and that's the customer journey you want. So think about it. That busy mom like I am maybe forgets to buy a birthday present, your two-year-old's napping, you can't leave the house, you order Prime Air, it arrives within 30 minutes, you're a hero, and that problem is very complex on its own, but the operator side of it is where the scale gets interesting. So if you flip to the fulfillment center side of this, they don't just have one drone flying to one customer. They have dozens taking off and landing about the same time. Some are flying north, some are flying south. And if you think about this from more of a traditional aerospace model, like a pilot's perspective, you ask any pilot, they're going to tell you they have a primary flight path and then they have alternatives, and they're constantly thinking about scenarios that could happen and how they would adjust the aircraft to maneuver those safely.
And an autonomous drone actually has to do the same thing. And with a single drone, that math is pretty simple, but when you start to scale, it's a pretty complex algorithm. Imagine in this dozens of drones taking off scenario that you suddenly have a lot of wind. And so some drones are going to arrive back faster because you've got nice tailwind. Some need to reoptimize their flight pattern because they're flying into the wind and have to conserve batteries. And then maybe you have some that are getting pulled for maintenance. They had a sensor issue, so they're getting swapped out, and there's this cascade effect right at the fulfillment center airport, for lack of a better word. And so this becomes quite a complex algorithm. And somebody at some point dubbed this the beehive ballet, and it's a really nice visual because it kind of immediately evokes what this looks like at scale, which is what we were having a hard time describing to people, and it's this perfect choreography to changing conditions that it just very elegantly articulated. But the beehive ballet was how drones got more complex.
Devin Liddell:
In these lessons about the complexities of scaling and the enduring value of hearing directly from customers served Emily in her next role at Amazon. Her current job is in Amazon Industrial Robotics. Here, her customer is the warehouse worker, and he products are the mobile robots they work alongside.
Emily Vetterick:
So a mobile robot to get a visual, it's about six or 10 inches off the ground. It's wheeled. And at Amazon, these robots are designed to move things around. So, like a cart, for example, it rolls underneath the cart, lifts the cart up, and transports the cart. If you rewound the clock to the earlier days of Amazon, when they were in warehousing, so think early 2000s, you'd see something much different than what's in our facilities today. You could imagine it kind of like grocery store aisles, rows and rows and rows and rows of items, and how an employee would work is when a customer would order something, they would walk to where that item was, they would pick it from where it was, and then walk all the way back. So mobile robots kind of flipped to the design paradigm. Instead of employees walking to an item, the mobile robots brought the item to the employee. And so now the employee can work at a more ergonomic station and significantly reduce repetitive motion, and it also significantly speeds up delivery times for customers. So it's really a good customer improvement and employee experience win.
Devin Liddell:
I imagine there were employees who experienced what you described earlier. They experienced the picking process, which involved a big amount of walking. And then there are robots who arrived and sort of have changed that. What did you hear, or what have you heard from warehouse employees about that change?
Emily Vetterick:
Yeah, I'm in facilities a lot. I always prioritize getting out to talk to people who get to work with automation or maintain it, and generally they're excited. They want the robots to be reliable, so that's a high priority in the design phase, and they want them to be intuitive so it doesn't impede them doing their job; it helps them. That's a high design feature as we go through the development process. We're bringing our customer in, which in robotics means the employee, and to really understand how they would use the technology and different interaction features, we need to be mindful of. So that happens very early, before you're even in a concept, usually doing some more discussion or simulation based research that happens early in a prototyping stage, so they can physically see it, work with it, give feedback there. It helps as we start to scale, kind of early testing, so they're getting more of the fleet-level experience, and then we continue to get feedback throughout the life cycle as more maintenance tasks come up just to make sure we're constantly improving the employee experience.
Devin Liddell:
Emily told me about one particular fulfillment center where the scale of Amazon's robotics program is fully realized.
Emily Vetterick:
So this is a fulfillment center in Shreveport, Louisiana. It launched in 2024. It has about 10 times the automation of prior generation buildings. To just give a visual of how big this facility is, it's about 55 football fields big. So it's a very large building, and if I could just give you a visual of if we're walking through, if you start at where inventory is coming into the building, and we were just standing there, you'd see dock doors, you'd see trucks being unloaded by various employees putting those boxes onto a conveyor that go to what we would call a semi-automated workstation. And so in a workstation like that, the task at hand is you're trying to take that inventory that came in from a distributor and make sure it gets loaded into our inventory system so a customer can buy it. And so the semi-automated piece comes in with a lot of the camera and scanning technology because the box you're unloading might have 500 Beanie Babies in it, and scanning them one by one by one is a pretty repetitive motion.
And so the augmentation here is the employee can scan one, and then the system helps it read how many are supposed to be in that package. They do more of a visual inspection, and then they move it into our inventory system. And so that's one type of automation. Conveyors are a type of automation. Scanning technology is a type of automation. If we went to the other side of the building where packages leave, you would see different types of robots.
You would see Cardinal in this case, which is probably what most people think of when they say robot. It's bolted to the floor; it's a six-degree-of-freedom arm that moves things, and Cardinal, we joke, plays Tetris all day, so it's moving boxes into big carts that are then loaded onto trucks, and so that's what Cardinal does. And if we were on this side of the building, you'd also see Proteus, which is a mobile robot that interfaces with those carts and then brings them to staging and Proteus is designed to work alongside employees. So employees are moving carts, Proteus is moving carts, so we can get packages to customers on time.
Devin Liddell:
I love it. We're entering this kind of interesting phase where artificial intelligence is starting to get sort of physical, for lack of a better way to describe it. A lot of people in their homes have experienced artificial intelligence through smart speakers like Alexa and through their digital assistants on their phones, and so forth. We're now kind of heading into an era where we're starting to occupy the same spaces with robots. Looking at Amazon's fulfillment centers and their warehouses, these are sort of amazing test beds for this. How have you approached just sort of the subject of humans and machines interacting successfully together?
Emily Vetterick:
Yeah. Proteus is actually a really good example here. So I actually wasn't on the design team for Proteus, but I work with a lot of designers who were. And the problem Proteus needed to design for is: have you ever been in a hallway and you accidentally are walking towards the same kind of trajectory as another person, and so you both take two steps to the left and then you both take two steps to the right, and you kind of do this dance. Proteus needed to design for that problem and that interaction. And so our designers needed to figure out how to signal intent because, from a customer lens, an employee just wants to know where Proteus is trying to go. And so that was a big part of the design problem when we were thinking about what Proteus needed to look like from a human robot interaction or HRI perspective. And the answer can't be training. And so it has to be a very intuitive design framework that allows somebody who has never seen this robot before to understand how to be in the same aisleway as it.
Devin Liddell:
The solution cannot be training the human. That's what you're saying.
Emily Vetterick:
Correct.
Devin Liddell:
It cannot be about that.
Emily Vetterick:
Correct.
Devin Liddell:
Okay. Got it. Okay.
Emily Vetterick:
Well, some philosophies in robotics, which does not match Amazon's, think that you could just put everybody through training, and it just doesn't work at scale, which is why Amazon is very focused on bringing the customer into the experience early, so it is an intuitive experience.
Devin Liddell:
What have you done, both from a design, but also from a production standpoint and an ops standpoint to help people and machines maneuver the same spaces? And I'm totally guessing here, but are there things that Proteus does from an audio standpoint, or from a display standpoint to signal to people like, "Hey, I'm working here."
Emily Vetterick:
A hundred percent. Proteus actually has eyes, eyes in the sense of what it looks like. And the reason we tapped into that... Well, I'll tell you another story. So I have a three-year-old; his name is Calvin. He's obsessed with cars, and so we often go on walks, and this weekend he was pointing out all the cars that were happy and the cars that were sad, and he meant the headlights and the grill features, of course. But it's a very natural thing for humans, even as young as three, to be wired to read faces and things, even if it's not really intended to be that way. Cars aren't designed to look like they have a face. It's just the features that are there, and from a Proteus perspective, when I talked to the designers who were in the early stages, their design inspiration was a turtle.
Proteus is low to the ground. It has a green shell, which is good for visibility and safety reasons, so people can automatically see that it's there, and it has eyes in the front. So this is important because then it can signal where its intent is to go. It looks to the left when it wants to go to the left. So you know where it's going if you're approaching it, and you also know if it registers that you're there. And the best part is it's very intuitive. You don't need special training. If you've never seen this robot before, you would immediately know how to interface with it. And if for some reason you didn't, it does have the safe autonomous features where it would stop. And so it does have safe onboard features as well from an engineering perspective.
Devin Liddell:
What about the audio? I'm curious about are there audio signals as well?
Emily Vetterick:
There are. I'll tell you another story. A couple of years ago, I was in our Nashville facility, MQY1. This was one of the first facilities to scale Proteus in operations. And I was standing in the aisle with my boss, actually, and we were working on a completely different automation project, deep in conversation, I don't remember what about right now, but I was totally accidentally blocking Proteus. I was stuck right in front of it, and it chirped at me and it was just kind of a polite, "Excuse me." And I very instinctively stepped out of the way. So it worked exactly as designed, which was great, but it did trigger my boss, who had worked on Proteus, to tell me a pretty funny story about early testing. In the early days of Proteus, we tested at the fleet level and the individual level. At the individual level, it tested really well.
It had a pretty eager chirping sound because we wanted to make sure it was loud enough people could hear and understand who it was directed at. But when we started doing fleet testing, apparently the initial design sounded a bit more like, as he put it, a bog full of frogs. So the team dialed it back a bit, and they really did get it right. And this is another good example of how Amazon sets the design envelope early on to make sure that you're getting feedback not just at the individual level but at the intended scale, because we didn't find it until we tested it at scale, and that was an important finding before we launched this into production.
Devin Liddell:
That's amazing. I love it. And just to get into the weeds a little bit about how that was adjusted. So you have an individual Proteus that's sort of chirping, and then you have a fleet of them that, to your point, sounds like a bog of frogs. How do you solve for that? How do you actually adjust the acoustic signature of them?
Emily Vetterick:
Yeah. I mean, that is one knob that you have to dial for, but it's also okay if you're blocking three; should all three chirp at you?
Devin Liddell:
Oh, got it. Okay. Yeah.
Emily Vetterick:
Or if you're blocking it a little bit further away, should it signal you from that perspective? So it's frequency, it's noise, it's how many do it at the same time. It's kind of that entire design space.
Devin Liddell:
Whenever I'm in Southern California, we don't really seem to have them here in the Northwest yet, but there's these mobile robots on the sidewalks in Southern California from SERV and Coco and the like that are just ferrying around burritos and food delivery. And the reason I bring them up is they are also anthropomorphized. They look cute. They're cute. My hypothesis is that one of the reasons they're cute is to keep people from bothering them. You're less likely to be mean to something that just looks kind of adorable. So I'm also just curious to loop back to Proteus: are there other ways in which it's anthropomorphized in a way that's meant to sort of smooth maybe some of the rough edges of humans and machines interacting with one another? And, by the way, this doesn't have to be limited to Proteus. I'm curious, just from across Amazon's robotics fleet, are there ways in which anthropomorphization has been used to make that collaboration better?
Emily Vetterick:
Yeah, I would say in general, I think designers naturally look to find the most optimum way to present the design so it will be accepted no matter what the product is, no matter who the customer is. So I could imagine for a robot that's interfacing with the world, like a sidewalk robot, that becomes really important because that customer space is actually quite a broad portfolio of people. You're going to run into three year olds like my son, Calvin, who's probably going to want to give the robot a hug if I'm honest. Right? And then you probably run into people more like my five-year-old, Clara, who's going to try to open it because she's very mechanically inclined. And then you might run into some people who really don't want it to be in their space. And so I can imagine tapping into something that, from a design perspective, evokes the right interaction would be a high priority.
Devin Liddell:
Correct me if I'm wrong, but from the array that you described earlier, I imagine early robots were, for lack of a better way of describing it, really, really kind of brute force, right? They're not smart. Maybe that's the way to put it. They don't have a lot of intelligence baked into them. Now, at the other end of the spectrum, you've got Proteus that's fully autonomous; it's interacting with humans in very sophisticated ways. So I'm curious: where do you think AI is headed specifically in the context of robotics?
Emily Vetterick:
Yeah, I can give two examples here. One about how we're using it more in the design process and then some about how we're using it in our fleet of robots as well. So we talked about Amazon has the world's largest fleet of mobile robots. And if you think about that from a warehouse perspective, it kind of looks like a highway where all of these robots are moving around each other in coordination. And so we announced DeepFleet last year, which is a bit like a traffic management system for these mobile robots, and it really manages the congestion patterns much better. So we had over a decade worth of data, kind of the old school way of how we were operating these fleets, and the team pretty proactively loaded these into a model, not really sure what to expect, and they found a ton of efficiency. This model took all the data of the past decade, optimized these traffic patterns, and it pretty significantly improved customer delivery times with a software-only change.
So it was a pretty nice customer improvement there again with the robots we already use today, just getting more intelligent through that AI backbone. On the flip side, we're using AI in the design process as well. I have some user researchers on my team, and one of the things we have been talking about for years now is when you're in the early stages of testing research, you really don't want to show somebody a design that pollutes the initial feedback they might give you about what the solution needs to look like.
And so this was always this tension point in early qualitative user research, where we didn't want to show them something that immediately disrupted the perspective they would have given us. So the team experimented with a bit more of an AI processing pattern where we were investigating a very specific problem. We asked the users to draw what they thought the solution should be, and then we were able to use AI in two minutes, put that context back into the model, and then have a very deep, tailored conversation from a user research perspective of what that solution need to look like. So I'm excited for AI on both ends of the spectrum in the R&D space and then the scaling space as well.
Devin Liddell:
Interesting. Okay. Yeah. I mean, it's a fascinating topic in terms of how we're using AI, just even to sort of concept and test, and refine ideas. I think presently the argument I would make is that it's super helpful in terms of helping us step outside of our preconceptions about how things will work. So I wanted to ask you as a follow-up question: is that what was primarily what was happening when it came to people drawing how they thought that workflow should happen and then AI assessing it and refining. Is that what was happening there?
Emily Vetterick:
In this case, we were asking them to draw a piece of hardware because that was how it would interface, or a different user interface for what a UI experience should look like, but it would be tailorable, I think, to a variety of solutions. And the interesting thing for me is how you'd make this a non-stagnant process. So it's exciting. From early research, you could pretty quickly iterate to an answer that's very customized to a participant, again, to just have a more rich dialogue of how they see the problem. It's interesting.
Devin Liddell:
I mean, it's one of the old jokes, it's a dumb joke about designers, how many designers does it take to change a light bulb? And then the punchline is, does it have to be a light bulb? And that's, of course, what AI can be, even in its sort of naivete, what AI can be really good at. Because if you ask AI, and I actually have done this in the past, where you ask AI, "Hey, give me some ideas for a lamp." And what it comes up with, what it produces visually, is oftentimes kind of bonkers. But if you look at it through a designer's lens and go, "Well, it's kind of bonkers, but there's something here that I would've never thought of on my own."
Emily Vetterick:
My team will laugh if they hear this. One of my favorite sayings is, "Design loves constraints." And so one of the most important things we do in the early stages of defining a problem is setting those constraints appropriately because a good designer, a good engineer, is going to optimize right up to those constraint boundaries. And if you don't think about the customer's problem correctly and you get those lines wrong, you're going to end up with the wrong answer. And so, AI, I think, is interesting to your point. It doesn't always answer in quite the right way. Sometimes it ignores the constraint boundaries, and you have to get really good in your prompt about being clear where those boundary conditions are and keeping it in the lines up, but it's not that much different than a good designer as well. The constraint setting is crucial to the design process.
Devin Liddell:
And I love that you brought up prompts, by the way, too, because I think one of the secret benefits of all of this prompting that we're all finding ourselves doing is that prompting is actually an exercise in precision, to your point. You actually have to be really, really precise if you want to get out of it what you want to get out of it, and you have to go through the process of refining or even re-refining the prompt to refine the output. But there's its own goodness in that in just being precise, and we might actually have prompts to thank for that. It actually goes back a little bit, I think, to some ways to the value of even what's now called X. There was a gift in brevity, like all of us learning to be more concise with what we were trying to say.
It's interesting and kind of exciting to hear how Emily is thinking about using AI as a way to deepen testing and R&D and to let the process of even prompting challenge us to specify and refine our own thinking. Now it's time for our lightning round. Teague is celebrating its 100th year anniversary this year. So in honor of that milestone, we've adjusted our lightning round questions a bit. And so I'm curious, what do you think is the most under-hyped technology or under-hyped technological innovation of the last hundred years?
Emily Vetterick:
Yeah, I'm biased on this one. My spouse works on next-generation nuclear reactors. So this is generally a dinner table argument we have. Nuclear energy went out of style for a while. The economics and the grid assumptions changed in a way over the last, I would call it a couple decades, and now we're kind of seeing a resurgence of nuclear energy. We're building a grid that's increasingly dependent on intermittent sources. If you think about wind and solar, the cost curves are really compelling, but they only produce when they can produce. And so this base load that nuclear energy is really good at is starting to be more compelling again.
And now I think the debate we tend to have is fusion versus fission. Personally, I think fusion is a little bit over-hyped, and I think fission is under-hyped. Vision is tried and true. It's very good. We know it's good. A lot of the newer companies are starting to lean into kind of update the designs with more advanced materials, making it more factory-built and more deployable and modernized for the grid assumptions we have today. So with the growing power needs of the world, I'm bullish on fission reactors.
Devin Liddell:
What is a book or show that you've either currently read or currently watching that has influenced how you're thinking about innovation?
Emily Vetterick:
Yeah, there's a lot of good ones, though I'll give you the one that I always come back to after a couple of years, and it's The Goal by Goldratt. So this is a book from the '80s. My first manager actually gave it to me, and it talks about the theory of constraint. So the core premise is it's a manufacturing book, but it's written more in a narrative or a story format of this dad who has this problem at work, but he's on a Boys Scout trip, and he's trying to get the kids to walk together quicker. And so it's a very illustrative theory of constraints book. It talks about how local optimization can make the system worse. It talks about incentivizing the right behavior with metrics, and it talks about how you shouldn't confuse activity for progress. And so a lot of parallels to leadership, a lot of parallels to technology and design. It's a really great read, and it's pretty short. It's like 80 pages. It's quite quick.
Devin Liddell:
Oh, nice. That's built for the modern attention span for sure. Yeah. Emily, thank you so much for being here today. This has been a super, super fun conversation.
Emily Vetterick:
Thank you for having me. This was super fun to do, so I really appreciate it.
Devin Liddell:
That's it for today. Thank you for listening to Design This Day, a podcast by Teague. Subscribe on your favorite podcast app so you don't miss the next episode. And if you have a complex problem that needs solving, we'd love to hear from you. Visit us at teague.com or send us an email at hello@teague.com.