“There is the greatest practical benefit in making a few failures early in life”
– Thomas Huxley [1890]
Thomas Huxley (the grandfather of Aldous Huxley, the author of “The Brave New Word”) was pulled out of school when he was 10 years old, due to financial family problems, and therefore was entirely self-taught. That didn’t stop him from becoming an intellectual of the last century, whose ideas about scientific education have shaped modern educational systems in the UK and USA.
So this Huxley dude was smart…but what’s all this about failure?
Obviously, no one ever sets out on any new venture to fail. We all dream of connecting with success in all of our projects. But there are times when we do not achieve our initial goals. What happens then? What and how do we learn from our failures?
This came up in a recent discussion, and I realized I was a perfect candidate to share my experiences on this topic. Why? Well, I have participated in projects that have experienced both setbacks and successes, early on in the process and not in just one professional field, but two! Both in my day job as a NASA engineer and in my side gig as a comic book artist and creator.
Recently, I got the opportunity to take over a project to build and test a new experimental rig for Vertical Take Off and Landing vehicles (VTOL). By the time I arrived on the scene, the specs had been written, contracts had been awarded, various components were built by separate contractors, and overall system integration was on its way at an off-site facility. “Sub-System Fit and Function” tests were all scheduled to be performed before the test rig was going to be delivered to us, and we were going to do final assembly, perform Dynamic Spin testing, and get ready for experimental testing.
We took delivery in a few months and got down to business: installing motors, hooking up power and cooling water, wiring up instrumentation systems, repeating some of the static function testing to ensure that nothing got damaged in transport, performing in-place calibrations, and developing procedures to safely test in our facility.
The day of the first spin-up, we had representatives from all the organizations that were “shareholders” in our project onsite. We spun-up and performed RPM dwells at discrete percentages of full-scale RPM up to 100 percent – then had to shut down because we hit bearing temperature limits. The cooling oil got too hot, too fast. Stop.
Spurred by failure “to launch” and the fear of total project failure, we started looking for an engineering solution to our problem. I found out a couple of things:
- Receiving an integrated system with an “Operation and Maintenance Manual” is great, but no matter how much effort you put into studying the manual, until you receive the system and start working on it yourself, you will never be an expert.
- No matter how good the manual is, it will never cover all the possible questions that will come up when you will need to fix the system on your own. It is simply impossible for anyone to write a totally complete “brain download.” There will always be engineering judgments and assumptions and technical details that will not be fully documented.
The month that followed was scary. It proved to be an awesome opportunity for me to learn about bearings, lubrication systems, thermal transfer, and control systems, while constantly looking over my shoulder at the ever-shrinking schedule and budget. By upgrading the lubrication pump and pump motor to increase the flow, redesigning plumbing to allow for the increased flow, and raising the initial lubrication oil temperature to decrease the viscosity of the cooling oil, we not only solved our heating issue and moved on to the next phase of testing, we also took ownership of the lubrication system and became the experts. We now wrote our own sections in the “Operation and Maintenance Manual.”
I became a better engineer and learned a lot of valuable leadership lessons through this activity. I would love to say that after we spun-up again and successfully achieved full RPM without heating problems, we have never encountered another issue and smoothly performed all of our testings from there. In truth, this was just the first issue that we encountered on our path to fully checking out the rig. But this first initial “issue” was what taught us how to work as a team, how to trust each other, and ultimately resulted in a successful project.
So I would have to agree with Mr. Huxley. Having “challenges” early on in our project taught us how to approach all of the subsequent “challenges” as a team, and made us develop expertise for the overall system. By the time we made it to the final phase of real testing, we were confident in our knowledge of the system and in our ability to solve problems.
Interestingly enough, I believe Mr. Huxley’s quote applies to many areas of human endeavors. In my case, it also applied to my comic book “career” – but, regretfully, in reverse.
I was a 19-year-old engineering college student when I sent in comic book samples to a fledging Midwestern comic book company. In a few weeks, I was contacted by the publisher with some amazing news: they LOVED my artwork. In fact, they loved it so much, they were willing to let me create my own character, write, draw, and edit my own story, AND they were going to pay me an advance of $2,000 for the privilege of working with me, and split the profits 50/50 upon publication. 1986…$2,000…oh, yeah!
I created a character called Moonstruck (an insane assassin with a tragic past and a thirst for vengeance…this was the 1980s!), and wrote and drew a 32-page origin story. It was published and sold 10,000 copies nation-wide.
I was written up in the local newspaper, got invited to conventions, and even received fan mail. Looking back, I have no idea why any of that happened. Maybe folks saw youthful exuberance in my work and they were kind enough to encourage it, or maybe they were just being kind. I don’t know. What I do know is that I didn’t feel the pressure to get better and, as a result, my development as a comic book creator stagnated. I remember turning down internship opportunities because I thought I was a STAR.
What I thought would be a meteoric rise to a career in comics, turned out to be a small blip in the annals of independent black and white comic book publishing. In 2017, when I mention that I did a comic book called “Moonstruck,” the question that I hear most often is: “Is that a 1980s movie with Nicolas Cage?”
So what did I learn from all this?
Nothing new. Ancient Greeks talked about “hubris” more than 2,000 years ago and I personally experienced that. Interestingly enough, this experience in the comic book arena, in turn, made me look differently at my progress in the engineering field. Every time I reached a milestone, instead of resting on my laurels, I always asked what I could have done smarter, more elegantly. Not surprisingly, there was always something that could have been improved upon.
Everyone reading this has had successes and failures in their careers, and everyone will have their own answers to how they dealt (and will deal) with situations of achievement. I think the most important thing is to always look ahead, be honest with yourself, and never became complacent.
Here’s some more career advice from this NASA engineer.
Be the first to post a comment.