0:00:32 - (A): Podcast introduction 

0:01:07 - (Matt): Dave, you sent me a text recently, and you said that you were involved in some kind of LEGO League. And now I'm really curious because everybody loves Legos, and you were coaching your kids in LEGO stuff, and it got you thinking about engineering. What can you tell me about this?

0:01:24 - (Dave): This year, starting this fall, I didn't even quite realize how much of a thing this was. I'd heard of it before, but hadn't really ever gotten to dig into it. There's an organization called First LEGO League. This is the chance for kids to build a robot out of Legos. There's a kit you buy called Spike Prime. You actually program the robot so kids are learning in a visual programming editor called Scratch Editor. Then you program the robot to do things like drive forward, to spin this motor, to spin this other motor. And all of these things combined means that you're able to actually move a robot around on this field.

0:02:01 - (Dave): And every year there are different challenges, things that you try to do with your robot, and then you go head to head against a whole bunch of other teams, and then whoever, whoever robot does the best wins the robot Challenge. The robot challenge is only 25% of the total score. But the first LEGO League is really an attempt to help kids do real engineering at a very young age. This particular league goes a little bit down to, I think, third grade, and it goes up through eighth grade.

0:02:28 - (Dave): This year, I've been coaching a team, and we've got a third grader, a fourth grader, a fifth grader, and a sixth grader. They're on the younger side, and this is their first year. I've been coaching and letting the kids do this. The most important part is helping with the philosophy, because another 25% of the score is what your strategy for building the robot was and picking which missions you're trying to accomplish.

0:02:52 - (Dave): And that particular strategy is really important.

0:02:55 - (Matt): Yep. This is totally tracking from a conversation that we had before that, you know, you learned some things in college about what good engineering looks like. What can you tell me about that?

0:03:08 - (Dave): I've talked about this before. Back in fifth grade, I watched this robot design contest at mit and I thought, oh, my goodness, I want to go there. I got really lucky, had teachers that had kids that had gone to mit. I went to a public school in Missouri. Right. This is not like, I didn't come to some affluent school or anything like that. They were like, maybe you can do it. So I tried applied and I got in, and then I got to go to MIT and do this robot design contest. One of the guys who helped develop this class, his name was Woody Flowers.

0:03:33 - (Dave): Woody Flowers, before he passed away, actually developed the first LEGO League, because what he saw was just how much engineering was done. And he realized, you know what? We could scaffold this in a way where if the kids don't have to machine metal in a machine shop, maybe we could be doing real engineering at a much younger age. And so, first LEGO League, you get to do some legit engineering starting in, like, third grade. And it's amazing to see how great this is. While I was doing this robot class at mit, I noticed that a lot of the people there were picking very different ways to engineer the robot than I was.

0:04:09 - (Dave): And I noticed right from then, very big difference. So at mit, I've talked about this before, that academically at mit, I was average on my very best days. That's a very hard school, and there's a lot of kids who had much more preparation than I did. So academically, I was average. Average there only on my best days. But when it came to real engineering, I thought I had a different way to do things, and they made sense to me. What I noticed was a lot of folks who were engineering their robots were picking complicated ways to solve simple problems.

0:04:40 - (Dave): So, for instance, we've got an open field, and you can drive a robot around, and you get a controller that wasn't programmed or anything. You get a little controller, and you can control it and drive the robot around. Several people were building these crawlers that crawled along a wall. Very complicated. They were very brittle in how they worked. When they failed, they failed really badly. There was no kind of smooth mode of failure.

0:05:01 - (Dave): I noticed right away. I was just wondering, why are so many people trying to solve these problems in such complicated ways? Because I was always going after the simplest, most robust things. When it came time for real design, my robot was outstanding, and it worked every time. I got to spend the last week of the class optimizing all these little tiny things about it because they all made the difference. Everybody else was trying to get their overly complicated solutions to work.

0:05:31 - (Matt): Were these people enamored with the tech? And doesn't that get into this idea of, you have a very complicated solution that has a lot of bells and whistles, but it maybe is not robust enough in its simplicity to actually work as it ought to? Right.

0:05:46 - (Dave): While coaching the kids, I realized that we as engineers really have two choices for how we solve problems. Both of these choices are valid at different times. I'm not saying one is better than the other. But they're good for different things. One way you can solve a problem is the way that seems the most fun and interesting to you. Another way you can solve it is by doing the thing that you think is the simplest and most reliable and most robust.

0:06:14 - (Dave): And it turns out that second one can feel very boring. It can be kind of uninteresting. But let's be clear, it's focused on an outcome. Sometimes as engineers, when we need to build something for other people, we need to be focused on the outcomes. Sometimes we're building something for us. If I want to go learn a new technology, I will often pick what I think is the most fun and interesting way to learn it. A sample thing I'm going to do with it. I might pick one that seems really fun and interesting to me. I'm not trying to do some whatever thing with it, but I get to really pick fun and interesting. For highly creative individuals, you need to have these times where you're doing things in the most interesting way possible.

0:06:55 - (Matt): Keep the interest going, what keeps you engaged.

0:06:58 - (Dave): And so I get what. This is a very interesting way to solve these problems. It's literally the most interesting way to you. But real engineering, if we're doing something for other people, we should probably be solving it in the simplest, most reliable, and, dare I say, most boring way possible. Right. Because there's a thing I noticed, too. Whether we are focused on what we want to do or what we can do for others, this orientation really changes. When it's good to apply which one. I explicitly told them these differences. Sometimes we're playing, right? As adults, even we play.

0:07:37 - (Dave): And it's great if you have a job that every once in a while you get to do some real play. This is really important for a highly creative field. But sometimes you need to accomplish something for others. And it actually takes a bit of humility to put someone else first over what you want to do, what's best, what you think is going to work best and most reliably for them. And these things might look a little more boring.

0:08:02 - (Dave): On the surface, they may not be the most interesting way. We started with the philosophy this year while coaching LEGO League, that we want to do things in the simplest, most robust way possible. This was our first year. You have access to all these different motors. Yes. You can drive around with a couple of motors, and you can have other motors that do different things. People build these giant LEGO contraptions that spin a worm gear, Right. So they spin around and a little cylindrical gear or a spiral gear spins and it causes a little thing to move up or move down, and you go up and you do this thing, and it ends up being a lot of work to do something very simple.

0:08:39 - (Dave): And what we figured out this year was rather than going through and making a special attachment for every one of the missions we want to do, we figured out we could just use an inclined plane and run into things, because so many things, you needed to push down on them and to build a little thing that goes over and pushes down in the right spot. It's also kind of brittle. So we figured out we can just ram into things with an inclined plane. Not really ram, right. You do it carefully and slowly and reliably because the best engineering is reliable.

0:09:10 - (Dave): And so we ended up getting a lot done, and it's been very interesting. The kids got to have a scrimmage last weekend, and they got to present their design philosophy. They got to run their robot against 23 other teams. And keep in mind, these teams go all the way up to seventh and eighth graders, and most of them are way older than the age of this team. And most everybody else was doing some really interesting solutions.

0:09:35 - (Dave): And our kids at this age got second place by doing less. By knowing less and doing less, they did better. This is the secret sauce behind startups. When you don't know any better, you have to be relentlessly focused on the simplest thing. You don't be like, oh, best practice is we have this basic robot. These attachments attach this way. We engineer one for every single one. You can do it that way, and who knows, maybe we end up that way.

0:10:04 - (Dave): But it was interesting to see how much this philosophy starting with, well, we're new. We don't know what we don't know, so let's just relentlessly and reliably keep it simple. And it had such an interesting impact. So they got second place overall in the robot contest out of 23 teams. The other thing they judge you on is your robot design philosophy. Every year there's a different. This year, it's an underwater theme. And so you also have to do an innovation project on a real problem that people exploring the oceans are facing and come up with a solution for it. They also grade you 25% on how the team treats each other, because in the real world, that one is a secret sauce too. The team was like, 25% on that. I'm like, actually, guys, that's probably underrepresented 80% on how we work together and how we trust each other in the end on what the results turn out to be for the innovation project.

0:10:54 - (Dave): One of the things I said that I told them was, kids, we can't know. We can guess what problems might be underwater. We can read on the Internet, we can find out about these things and we can guess what the problems are. But the truth, the reality is always something you wouldn't expect. And I said, what's the only way we can solve things for people? That's to talk to people. So we ended up getting to talk to two folks.

0:11:21 - (Dave): Originally, the kids wanted to focus on aquanauts, people who live underwater. And it turns out there's no information on them because no one does that anymore because it's so dangerous. Between pressure and oxygen and power. That's not something people really do. Now that robotics have been improving, you can send a robot down and you have a fiber cable that's connecting this up, doing perfect communications.

0:11:47 - (Dave): With that delay, maybe you're talking like eight kilometers down. What's the light delay on that? It's nothing, right? That's near instantaneous communication. It's almost like you're there. It turns out there's no information on aquanauts because that's just not how it's explored anymore. We talk to people. They go out on these boats with lots of people and they send this robot down and it's connected up through a cable.

0:12:07 - (Dave): We found out this cable has problems. The kids came up with thinking from other domains, where else does this problem exist? How else is it solved? They took an existing solution from the human body on how you protect a very high speed data cable and applied it to that. And the judges got so excited with it. But it all came down to this. Just this relentlessly focused on the reality of what people need by getting the product out there, seeing how well it works, but being focused on that.

0:12:38 - (Dave): And I tried to convince the kids and the judging, because how do you describe really well and accurately in a way that's memorable, this notion of simple and robust and reliable. And I came up with a phrase then I wanted to see if the kids would try it out, just to see how it played, because it was a scrimmage or whatever. They were like, if we say that, it sounds like we're not having fun. So they chose not to say it's their presentation. That's cool, right? That's cool. They went through the whole presentation. It went really well. Some of the judges got really, really excited.

0:13:06 - (Dave): One of them was actually an expert. They worked at Verizon and were telling us all about how this isn't a Problem just underwater. This exists right on land. There are tens of thousands of miles of these cables that, when they get cut, things can go down for weeks at a time. Really key ones get cut. One of the team members decided to throw my phrase out. That phrase is boring is best. Boring is best. When it comes to engineering, boring is best if we want to solve this the best way possible for people, not necessarily what's most interesting to ourselves.

0:13:38 - (Dave): It's oftentimes probably going to feel really simple and boring, and it's going to take a lot of iterations to get to boring. And so they made these prototype parts to do these things, and then over time, they got to show how they got simpler and simpler and simpler every single time. They kept at it. They had this clear picture of how simplicity works over time, how you actually move from complexity into simplicity when you're relentlessly focused on system philosophy. The judges were very excited by this phrase.

0:14:05 - (Matt): Yeah, marketing in action, right? Marketing matters, you know, how you phrase a thing and how people can sort of understand what you're up to. Well, that. That must have been really fun to see that play out.

0:14:17 - (Dave): That's not even marketing. That's education. Right? The thing that somebody's going to attach to and remember as a phrase. So that was fun to see that all play out. The kids actually won the whole thing. And again, this is scrimmage. But for them to be able to see and find a problem simple enough, small enough, that maybe they could tackle, but to stay relentlessly focused on this simple, boring solution. None of our attachments are active.

0:14:42 - (Dave): None have an extra motor that gets activated. There's no extra IR sensors. There's no distance sensors. There's no pressure sensors. These are all sensors you can use. We don't use any of them at all. At some point when we get more comfortable, maybe we will. But it's been shocking how the kids have just gone in when we're like, okay, we think the best strategy is to work on this mission, to watch them go in and play.

0:15:06 - (Dave): Because what they do is they walk up these missions and they start flicking around with them, and they're just playing. And then they grab a little Lego piece and start interacting with it. And then the things that they figured out are so simple, and because of this, they're more reliable, they execute more often. You've got these giant contraptions to do one little thing that these people have made, and they spent so much time on the engineering that they haven't gotten to spend as much time solving the problem.

0:15:35 - (Dave): That's been the neat thing to see. Really clear. For the best engineers, boring is best.

0:15:45 - (Matt): Imagine that. You probably have examples of this and probably listeners do too. We've been in the startup space and prior to me coming on board at Font Awesome, I've had experience in the tech startup space in marketing. I'm remembering one particular consultancy I worked for where at a point where they had to make some important business decisions because they were stuck in founder's itis. And the.

0:16:10 - (Matt): The founder of the company was a total genius. But often we would get in meetings with the guy and this was sort of the ongoing joke is like he would over complicate things so much. And I don't think it was an ego thing or anything. I'm not badmouthing the guy, but it makes me think that all of these things are so interconnected. If you have someone that's like, I have this amazing solution and all this knowledge, let's go build something that's going to blow minds. But if you're just impressing yourself and your peers, you might be completely missing the mark.

0:16:44 - (Matt): I see all these things threading together. We've had conversations about if you have a co founder, somebody that balances you out.

0:16:52 - (Dave): That's right.

0:16:52 - (Matt): Be able to say what is it we're really trying to do here, guys? Because I know that we're all geniuses, we can make amazing stuff and lots of cool bells and whistles. But is that actually what the customer needs? Needs.

0:17:03 - (Dave): That's right. And that relentless focus on what is going to work best for somebody else. Right. This requires empathy. This requires insight. It also, more than anything though, requires not guessing. It requires talking to people. It requires building a thing and then seeing what people think. Because here's the real secret. No matter how smart you are, no matter how much of an expert you are, we're still wrong about half of everything. We think.

0:17:35 - (Dave): We just don't know which half it is. Until we put this thing out into reality with other people to use, we won't know which half it is. But then we find out which half we were right about. This is how we really learn and iterate it. The next time we iterate, we keep the good half and we scrap the bad half because of the 8020 rule. You can get 80% done in 20% of the time and then that remaining 20% takes 80% of the time.

0:18:03 - (Dave): Here's the magic trick. What if we never do the final 20% because that means in a fifth the time we can actually get something out there? And find out which part was the best. Keep that. Now with the remaining part again, we can get through 80% of that now. And wouldn't you know it? Let's look at this. We were right about that. Puts us at 40% of the way towards a good solution. We could spend five times that amount of time and only get 10% more towards a good solution.

0:18:36 - (Dave): What if we instead say, let's live at 40 and take the remaining 60 and get 80% of that done? What is that? It's 48% now, half of that. Now we get to add another 24%. So in 40% of the time, we're at 4 plus 40 is 64%. So in 40% of the Time, we're already well over that half. If we keep doing this, it means that we move much faster towards what excellence is. When you've made something really good that you're proud of, we now have that as our bar.

0:19:11 - (Dave): And it feels bad to release something below that bar. But strangely enough, unintuitively, it's really important we don't ever release anything at that bar because it turns out we're wrong about half of what that is, and we need to build 80%, get that out and iterate from there. You get to the best stuff faster if you're willing to be wrong, if you're willing to believe and understand that you're wrong about half of everything.

0:19:41 - (Dave): You just don't know which half it is yet. This is why boring is best. Keeping it as simple as possible right now, without the bells and whistles. Let's stay relentlessly focused on these basic things that we know if we get around to it, and we're like, okay, we were right about that core part. But all this other stuff over here that we thought, we get to spend all this time building these great features that no one used or cared about.

0:20:01 - (Dave): That's a waste of time. Instead, if you have a partially fleshed out, you can then iterate on that. And this is actually important because sometimes this process can lead down the path of mediocrity the whole time. What that means is that you're not talking to people enough. You're not weighing enough of what excellence actually is. Sometimes you can listen to customers too much. There's a balance here which may never lead you to something truly different than what anyone could have ever asked for ahead of time. So it's our jobs to interpret what people are asking for and figure out what we might be able to do with that, not to give them what they ask for, but to understand the meaning and the desire behind what they're trying to do and to build something specifically for that.

0:20:38 - (Dave): And the way that we do that best is by, well, only shipping. When we're embarrassed a little bit, we should always be a little bit embarrassed. This is one of YC's great mantras. If you're not embarrassed by what you release, you waited too long. Right. Those first interactions that you've with customers, it's okay that they're not going to be perfect. There's this idea that you only get one chance to make a first impression.

0:21:03 - (Dave): Wow, that sounds really important. It's not the first impression that matters most. What matters is the 50th iteration, because you've been willing to be wrong. And then somebody suddenly walks onto it the first time. That's their new first impression, Right?

0:21:20 - (Matt): Yep. So we over index on the early adopters and we under index on how far we can get, right?

0:21:28 - (Dave): That's right. Because that's another one of the truths here, is that people always overestimate how far technology can go in a year and underestimate where it can go in a decade. If you go back 10 years to where the open web was and what was possible, it's amazing how much that's moved along in the last 10 years.

0:21:43 - (Matt): It's funny, what starts to come to mind here is that it seems like there's a whole philosophy here. I'm seeing all these threads where even the way that we work using ShapeUp, that's really just baked into that whole process. We're betting on what is it that we can get done, what is the most robust, simplest solution. You iterate and you iterate and you test, go back and add to it if you need to. But if you have this really big idea that's really flashy and you spend all this time on it, you end up throwing so much of it away.

0:22:19 - (Matt): It's been interesting for me, even though I'm not building software, observing how these projects go. Yeah, as an outsider, just seeing how you guys parse the work out in its simplest form. Like the. Probably the best projects we do are the ones that are really simple. Sometimes we shoot too far ahead and then we have to do a little damage control and clean up. But the ones that are the simplest, those are the ones that stick around, that you can build off of. It's really interesting to watch.

0:22:49 - (Dave): It's very interesting in engineering figuring out the right amount to bite off. Right. What's the right amount of this that we know that we can complete? What's my shiny utopia that I never get to or the thing that I can actually ship? We have a comparison in our heads of how good we can make it. Right. And when we ship, 80%. That feels bad. But the customer's comparison is from what they already have.

0:23:16 - (Dave): And 80%. Right. That's a giant jump from where they are now. And so the most customer centric, customer focused thing you can do is actually ship when you're still embarrassed. It's weird. It's unintuitive.

0:23:30 - (A): Podcast conclustion