There are very few people who are so gifted at what they do, they land on a near-perfect solution almost by instinct. The rest of us really ought to embrace that rarity.
I could not tell you how I first came across it, but I enjoyed this TED talk called Trial, error and the God complex. It’s about 18 minutes, so not too long, but here’s a few key points from it:
- The “God complex” as presented is the overwhelming belief that you are infallibly right in your solution to a problem, no matter said problem’s complexity. The trouble is that since our brains first evolved, the world has gotten orders of magnitude more complex—we just can’t fully comprehend many of our problems today. So we can at least accept that complexity and spend our time experimenting instead of aiming to make a perfect solution right off the bat.
- The consumer goods company Unilever makes detergent, and they needed a specially-designed nozzle to spray liquid detergent so it would dry as a powder for packaging. They first approached this with a God complex: they hired an expert to precisely calculate and design the perfect nozzle. But this proved itself too complex a problem to be solved by math.
- Instead, Unilever ended up using trial and error: they made 10 random variations of a nozzle, tried them, kept the best one, and made 10 random variations of that nozzle. Kept the best one, and made 10 more from it. And repeat, and repeat. 45 iterations later they had a nozzle that worked incredibly well for its purpose—though no one can explain exactly why!
I think there are valuable insights here that we can apply to our work developing, testing, and flying UAVs. To be clear, I’m definitely not saying we should design by throwing metaphorical spaghetti at the wall and seeing what flies for more than 13 seconds. We stand on the shoulders of giants and collectively know a heck of a lot about physics and aerodynamics. There’s zero sense in not using it.
The God complex shows up in our engineering in its own way. It often reveals itself in counterproductive design spirals: the comfort zone of repeated analysis and iteration of a design, trying to make it absolutely perfect for its job. But at the same time avoiding the hard and vulnerable part of making that digital design into a real airplane and flying it.
I’ve seen this a lot and, if I’m honest, I’ve probably done it plenty too. We try to find the perfect airfoil, assemble the perfect configuration, hyper-contour the fuselage to reduce drag as much as we can. It’s the hope that if we can just dig a bit deeper, look harder, calculate with more fidelity, we’ll find the exact right answer we need. We’ll finally know we’re right.
This pops up in ways beyond just individual engineering choices: reviewers outside the primary team might finally provide design input well after decisions are made. Or some contributors suggest revisiting a certain design choice, not because the team found a genuine problem with it, but because it could be made “better.” Especially if the feedback is from a different division or company, this pressures the team to revive and retread previous decisions without any genuine new insights. It locks up their time in re-explaining, re-proving, and re-meeting instead of spending that energy on the fresh problems they’re currently wrestling with.
The vast majority of UAV programs just do not have the budget or runway to spare for these re-hashing spirals. The timeline is often literally talked about in terms of months: program kickoff in March, first article fabrication in November, prototype flights in February. If the analytical perfection route slows progress just when it needs to keep up the pace, the team ought to adopt a more trial-and-error based approach on a macro level.
What do I mean by this? Do what must be done for the current program phase to be deemed successful, and wait on extensive refinement until the next phase. If you zoom out to take in a UAV’s full development and operational lifetime, it can often make sense to use the first phase or contract to design your prototype with only as much optimization as is necessary. Snap the chalk line, make and fly the configuration, and roll those learnings into the next iteration.
This iterative perspective doesn’t need to be exclusive to government contracts and programs. It can be just as beneficial to get to a viable product, have it flying and functional, and use that to drum up interest and gain trust. Depending on the use case, you can even get some initial customer feedback to roll into the next version and avoid silly mistakes.
Something will probably need to be changed after the first flight anyways, whether it’s due to a functional issue or because a vendor decided in the middle of fabrication that they don’t want to make a component anymore. Maybe you find some quirk that, though it doesn’t impact a critical function, you ought to address with a design change. Wouldn’t it be real nice if your team didn’t spend a ton of effort on optimizations that end up having to be reworked anyways?
The worst consequence is the bureaucratic one. Many contracts include some sort of demo to close out, whether it’s a flight demo or some other presentation. You may end up not actually fulfilling your contract if you get to the end of the period of performance and don’t have anything physical to show, much less fly, because you spent all your time optimizing and designing. And no matter who your customer is, I would not recommend testing how much they’ll stretch a deadline for you for a factor within your control.
This all takes strong project leadership and careful management of team politics. You need to make sure everyone involved keeps moving at a pace that makes inputs actually actionable when they’re received. You have to be able to firmly push back when someone wants to dredge up old topics just because they can, and tell them that the team will be moving forward with their existing decisions. And you won’t get far without the internal fortitude to admit uncertainty and accept measured risks. Heck, it’s worth it to cultivate this mindset in the entire team, though definitely no small feat.
But my thinking is, it’s better for your bird to end up in the dirt a couple times than your entire program. And that’s the risk that entertaining the God complex can bring.