The robotics industry has a fundamental design flaw that most founders don't recognize until it's too late: hardware and software teams operate as separate worlds, each blind to what the other actually needs. Sebastian Thrun, the engineer who built Waymo and is widely recognized as the godfather of self-driving cars, shared this insight and six others from two decades of experience building moonshot projects at a recent robotics conference.

Thrun's career trajectory is remarkable. In 2005, he built Stanley, a robot that won the DARPA Grand Challenge by traversing 132 miles through the Mojave Desert in under 10 hours. That victory caught the attention of Google co-founder Larry Page, leading Thrun to become a co-founder of Google X and eventually lead the secret self-driving car project that became Waymo. Beyond this, he has published over 380 academic papers, launched Udacity as a co-founder, and became a National Academy of Engineering member at age 39.

But success in robotics, Thrun emphasizes, comes through a very different path than most founders expect. The stakes are fundamentally different from software. "If an LLM hallucinates, you say 'that's wrong.' Then you shrug and move on," Thrun explained. "You have a device that weighs a tonne travelling at 60 miles per hour in downtown San Francisco. What could possibly go wrong?"

Thrun

Why Do Robotics Founders Move So Slowly Compared to Software Builders?

One of Thrun's most revealing observations comes from a question he asks fellow founders: "Given what you know today, how fast could you rebuild your business?" The most common answer is roughly five times faster than they actually built it. This gap reveals a hard truth about robotics development.

"If you are building a business you never built before, there are certain things you just can't know. You can only learn through trial and error," Thrun stated. "With a five-day workweek, this means that one day of the week you make good decisions, and four days of the week you effectively make bad decisions. You hire the wrong person. Or you have the wrong go-to-market, the wrong product, the wrong pricing".

Thrun's own experience with Google Glass illustrates this principle. The team at Google X had no clear answer when asked what they were building or what its purpose was. "When people asked, 'What is this?' I said, 'It's a computer on your nose,' recalls Thrun. "They'd say, 'What is it for?' and we'd say, 'We don't know'". The lesson is uncomfortable but essential: learning through mistakes is unavoidable when building something genuinely new.

How Can Robotics Teams Bridge the Hardware-Software Divide?

The most critical structural problem Thrun identifies is one that starts in universities and compounds throughout entire careers. "My biggest gripe with the field is that we distinguish the world into hardware and software people," he explained. "You're either a mechanical engineer who loves building mechatronics, or you're a software person. Most of us are unable to bridge this divide".

This specialization creates predictable failures. Hardware-led teams take great pride in how a robot looks, feels, and moves, but struggle with the software and business model needed for commercial viability. Software-led teams build elegant systems but often in isolation, depending on hardware partners who don't yet have businesses of their own. Either approach leaves something crucial missing.

Thrun traces this pattern back to the 2005 DARPA Grand Challenge itself. Of 196 competing teams, 195 were hardware teams that ripped apart existing vehicles and rebuilt them from scratch. But the challenge was entirely solvable with a standard rental car. The real difficulty was making the car smart, yet most teams were too focused on their specialty to see that.

To address this gap, Thrun offers a direct solution: "If I had a magic wand, I would force every software person to spend one year just building hardware, and every hardware person to spend a year just doing software," he said. "I started doing lots of hardware, even though I'm really bad at it. It's the only way to get the sense that the truth is somewhere in the middle".

Thrun

Key Lessons for Robotics Founders from Two Decades of Moonshots

• Building in robotics is an uphill battle by design: The founders who succeed move through mistakes rather than around them. Reliability and safety standards in robotics are categorically higher than in software because the physical world has real consequences.
• The hardware-software divide is the industry's most overlooked problem: Teams that bridge both worlds, understanding mechanical engineering and software equally, build stronger businesses than specialists in either discipline.
• Know what motivates you beyond financial reward: Financial incentives fade as motivation. Founders who stay energized through the long middle are driven by something deeper, and getting clarity on that early makes the difference.
• Be arrogant about the goal, humble about the path: Hold your destination firmly, but stay genuinely open about how you get there. Ego is what fractures companies from the inside.
• Genuinely befriend the regulators: Regulators want safety and innovation too. Bring them along early, and they'll want you to win.
• Even the savviest builders can't predict what's coming next: Stay humble about future breakthroughs, as the next major innovation will likely blindside everyone.

Thrun remains optimistic about robotics' future. "Many in the industry are anticipating a 'ChatGPT moment for robotics,' where mass adoption proliferates," he noted. However, he's clear-eyed that general-purpose robotics has a longer road before breaking into the mainstream.

For founders building the next generation of robotics companies, Thrun's message is both humbling and practical: the path forward requires embracing mistakes as learning opportunities, bridging the gap between hardware and software expertise, and staying grounded about what you don't yet know. The companies that succeed won't be those that avoid failure, but those that move through it fastest.