This fall, I had the opportunity to coach a Lego robotics team in the FIRST Lego League. There are over 32,000 teams in the First Lego League in 88 countries, and over 600 teams in Minnesota alone. Each season, every team in the league receives the same tournament board. Teams design, build, and program their robots to score points on the tournament board. The robots must be designed to operate autonomously. You can read more about it here.

Our team is called the Plaidiators. We’re made up of six homeschoolers between the ages of 11 and 14. We just wrapped up our season last weekend, and I’d like to reflect on the leadership lessons I learned through this experience. Yes, this is all for the kids, and not associated with my day job. However, I learned a few things that directly apply to my profession of leading teams in enterprise technology.

Winning isn’t everything: How > What

The main event at a Lego tournament is the robot performance on the tournament table. The teams have two and a half minutes to score as many points as possible within the constraints of the tournament rules. If Lego robotics were like any other sport, that would be it. The team with the highest score would win.

But that’s not it. While the performance is focal, there are three other areas that are independently judged and scored: research, design, and core values. The tournaments are structured such that you cannot succeed with performance points alone. You need to do well in research, design, and core values too.

The FIRST Lego League has captured the importance of measuring how, not just what. Sometimes in the corporate world, we live in a results-only performance management culture. “I don’t care how you get it done, just get it done.” As technologists, that can be especially true. Sometimes the business doesn’t even want to know how we work.

That might be okay for the business, but not for technology leaders. We need to care deeply how our teams work. “Get it done” isn’t okay. Instead, we need to cultivate learning, experimentation, innovation, thoughtful design, thorough research, mutual respect, and empathy. Not only do we need to encourage these things, we need to go further, like the FIRST Lego League, and make it part of our performance management system, thereby defining what success means.

The technology is weak

The biggest source of team frustration is the poor quality of the robotic components. Lego Mindstorms, after all, are just toys. They are not high-precision, industrial-grade robotics. In contrast, the scoring missions require precision. The team spent countless hours running mission programs that performed with too much variability to be trusted. To make matters worse, we found slight variations between our practice board, and the actual tournament board. Missions that performed reasonably well in practice, failed in the tournament.

As significant as this problem seems, it is solvable. You simply cannot trust the robot to do what you tell it to do all of the time. You need to supplement those instructions with sensory input, so the robot can interpret the environment around it, and recover accordingly. There are numerous techniques and calibrations that can be done, but they are all really hard. Teams that take this approach and master these techniques win.

This lesson fits better with enterprise technology than you may think. Sure, we spend millions of dollars on enterprise-grade technology. What we have certainly cannot be compared to a child’s toy, can it? The truth is, our enterprise technology is just as weak. We develop our technologies with the happy path in-mind. We test it in our own controlled environment to the point we are satisfied, then we put it into production. That’s when it all falls apart.

We put too much faith in the reliability of our technology. It’s just not worthy of that faith. Just like the Lego robot, we need to supplement our technology with redundancy, monitoring, and self-healing capabilities. Just like in Lego robotics, you cannot build that functionality on the morning of the tournament. It needs to be a part of the design planning from product inception. My favorite real-world example of this is Neflix’s Chaos Monkey.

Agile works

When I first thought about the opportunity to be a Lego robotics coach, I was excited to apply Agile development principles to the process and see if it would work with a bunch of middle-schoolers and a pile of Lego bricks. We put up a Kanban board. We estimated the development effort for each mission. We divided up the work into sprints. We managed a backlog. We minimized work-in-progress. We did retrospectives. I hooked up our development computer to large TV, so everyone could see the work.

I cannot say that these methods alone made us wildly successful, but it definitely made the team practices engaging and enjoyable. These principles facilitated learning and collaboration, which is what it is all about.

The kids do the work

As a coach, one of the hardest things for me, was to let the kids do the work. The challenge is quite engaging. I really wanted to put my hands on the keyboard to write the code, and I wanted to dive into the Lego bin to build mechanical attachments.

This was the most tempting when it looked like my team was going down the wrong path. The team made the design choices, not me. I provided guidance, but the team made the decisions, even if they were the wrong ones. Sure, we burned valuable time chasing ideas that I knew would fail, but I needed the team to learn. I believe that learning works best when experiencing the results of your own decisions, not just by listening to what the coach says.

Earlier in the season, I volunteered as a design judge in a tournament in which my team did not compete. This gave me a better sense of how to prepare my team for our upcoming tournament. The judging rubrics required us to look for evidence of over-involvement of coaches. As a coach, it’s tempting to look at successful teams with a cynical look wondering if the other coaches or parents did the sophisticated engineering, or it was really the kids. It’s nice to know that the judges are forcing that accountability.

This lesson translates directly into enterprise technology leadership. Technology leaders become leaders because they were first really good engineers. But if leaders cannot let go, then they become poisonous micro-managers. As technology leaders, it’s good for us to espouse the servant leadership virtues of self-directed teams, empowerment, and delegation during good times, but it’s even more important to practice it when things are going poorly. I understand the temptation to take control when things are going awry, but that’s one of the most important times to demonstrate restraint.

Sometimes, you don’t win

The reason why I’m writing this now is because our season is over. I am competitive and I wish it were not the case, but the Plaidiators didn’t advance beyond the regional tournament round. If we would have succeeded there, we would have competed in a sectional tournament. From there, it goes to state, then world. That’s how you go from 32,000 teams to one champion.

I am proud of our team. We had an even mix of girls and boys. We had some first timers and some experienced members. Everyone worked on everything from design and planning, to coding and mechanics. The team collaborated, respected each other, and laughed a lot. On tournament day, they executed the plan to the best of their ability. They gave it their all. Sometimes, that’s not good enough to move on, and that’s okay. The teams that beat us didn’t cheat. They were just better.

In enterprise technology and in business, sometimes you do your best and still fail. In my career, I’ve worked hard and had great years, and I’ve worked even harder and had terrible years. That’s how it goes. Corporations aren’t defined by one fiscal year any more than a Lego robotics team is defined by one season. We’ll be back next year. We’ve learned a thing or two. We’ll be better for it.

Update: This article is now the first in a series on Lego robotics. Check out part 2 here: https://zachonleadership.com/integrity-and-automation-leadership-lessons-from-lego-robotics-part-2-of-3/