What came up again and again was the need to work hard. This is, of course, both essential and obvious as table stakes. Certainly, it was requisite in successfully deploying hundreds of millions of dollars of hardware over the past decade. What’s funny though, is that it’s also curiously unclear as to what “work hard” means.

In my experience working closely with dozens of teams over the last decade, I have found that too often the idea of “work hard” is interpreted solely to mean “work long hours over a long period of time.” Certainly, the time we’re at work is going to be part of it, but is it really the whole story? I doubt it.

There were periods as a bush pilot growing up, and again as a launch engineer during a campaign, that I worked seven days a week, averaging 17 hours a day, for literal months on end. No breaks, no days off. More than a handful of times, I’ve been at work manning critical systems for over 24 hours without respite. As such, I’ve had a lot of time to think about the outcomes from those efforts and my take is more nuanced.

Many factors like working on the right things, minimizing thrash, and having clear deliverables must all weigh in. Otherwise, we’re no better than Boxer the horse walking in circles, doing a lot of work, but not getting much really done. Still, the idea persists that the simple secret is just to be there. I wanted to find a new way to poke at it.

A Physical Definition of Work

To get some clarity, I decided to think about the physics definition of Work.

In its simplest form:

Where F is force and S is the distance that force is applied over.

This makes intuitive sense. Applying a force to go some distance passes the gut check for defining Work1. But there are some interesting things to note here. First is that depending on the frame of reference, pushing a box across the room and then pushing it back would mean no distance was covered, and thus no Work was done2. Others would argue you did twice the work (going there and back) but I like the former frame of reference because we all know intuitively that just because energy was expended, that doesn’t mean Work was done!3 They have same units, but Work is different because we must make progress for it to count. In this case, that’s our distance covered.

This all makes good sense, but it’s also a bit too simplistic of a take. We rarely move in straight lines, and neither do our projects. To get a better view, let’s add a critical term.

Work That Moves Us Along a Winding Path

In order to model those projects that tend to follow more of an up-and-down, twist-and-turn path to their completion, a better definition of work looks like this:

Note that now we’re working with an integral, which let’s us have a more organic shape to the distance covered, and that we’ve added a cosine term.

What the heck is that all about?

Don’t worry, it’s not a big deal. We can think of that cosine as an honesty term. Without it, we’re saying that all effort (e.g. force applied) moves us father down our intended path. But that isn’t the case, is it? We all know that we might spend a lot of effort on things that take us absolutely nowhere. For an honest definition of Work, we must only count the force that moves us along the path to our goal!4

Sometimes wasted effort is goofy stuff like the previous footnote about the guy who sent emails all night instead of building his prototype, but that’s rare in high performing teams. In these latter cases, the issue can often be attributed to thrash. Here, I am defining thrash as that lost time moving between efforts in your day-to-day or being unclear where to go next.5

Common causes of thrash for hardware teams include:

• Effort of Starting New Tasks

• Effort of Task Switching

• Working Towards Unclear Deliverables

Minimizing thrash is about maximizing lean process. Woah, easy there! I sense your revulsion and desperate jump for the little red ‘x’ in the upper corner of your browser tab. Stick with me! Too much unnecessary process has rightfully gotten a bad rap, but too little also kills companies through indecision.6

I think the answer (as with most things) is the Middle Way. An ebb and flow of effort at the right times, directed properly down the right path (cosine(theta) = 1). To illustrate that, let’s look at how an Olympian trains.

How Olympic Marathoners Train

We always say building hardware is a marathon, right? I build teams with the Olympians of their discipline. The Eliud Kipchoge of thermofluids, the Haile Gebrselassie of structural design, the Catherine Ndereba of deployment. We all plan to have the absolute best in our fields to help bring the vision of the company to life. Now, imagine assembling that team and then telling them to run a full marathon every single day.7

We agree that would be insane, right?

We know that’s not how training works and yet, that’s how we must interpret the common advice of “work hard, all the time” for hardware engineers the world over, even though we’re also squishy humans trying our best to perform optimally while warding off diminishing returns (or worse, injury and burnout). In my view, that’s poor management.

I believe the secret to engaging strong teams lies with good planning, sane milestones, and an aggressive (yet achievable) schedule co-developed with the stakeholders8. That represents, in my experience, the aforementioned Middle Way. Like any plan, it can change, but it’s important to have one because otherwise you enter a mode of pure reactivity, waiting for things to happen to you and responding rather than proactively moving forward. Within that schedule exist times to push, and also exist times to recover and assess the result. Update the plan, move forward again.

Now, depending on which side of the table you’re on, you’re either agreeing with me or praying for (and investing in) the arrival of tireless AI robots9.

Just like in our physical definition of work, the key is strong, hard, unyielding effort at the right times. Riding the wave of build up to the crest of an event and then going into active recovery on the other side. Never yielding wholly in output or thrashing uselessly on things that tire without providing progress, and also not keeping the pedal to the metal 24/7.

The magic, for us as founders, is to craft programs that understand the pushes and then maintain the team’s energy for when the hard times really come.

Everyone thinks the quote comes from Gene Kranz, the steely-eyed NASA flight director, but it’s actually an invention of (and tag line for) the 90’s movie Apollo 13.

From Wikipedia:

In preparation for the movie, the script writers, Al Reinert and Bill Broyles, came down to Clear Lake to interview [FIDO Flight Controller Jerry Bostick] on "What are the people in Mission Control really like?" One of their questions was "Weren't there times when everybody, or at least a few people, just panicked?" My answer was "No, when bad things happened, we just calmly laid out all the options, and failure was not one of them." ... I immediately sensed that Bill Broyles wanted to leave and assumed that he was bored with the interview. Only months later did I learn that when they got in their car to leave, he started screaming, "That's it! That's the tag line for the whole movie, Failure is not an option."

Though Kranz did employ the phrase for the title of his memoir, it came out after the movie, so it’s fair to say his character played by Ed Harris inspired the choice. It’s a great line, I don’t blame him. I bet it moved a lot of books. This is important to note because 1) the line is not etched into the bedrock of aerospace history, it came from Hollywood and 2) I see those words inspire lazy thinking that’s, ironically, killing our ability to succeed.

Let me explain.

Failure is *absolutely* an option.

First of all, failure is not only an option, but also the most likely option. It is the entropically favorable outcomes, no less, which means it’s damn near the default state. Our job as design and test engineers is to play the Second Law to a draw — maybe increase a little entropy universally so that it stays low locally. Put another way, we must figure out the ways things will fail and then make hardware, code, and processes which obviate those modes.

Understanding the ways we can fail is step one in this process. Risk and hazard mitigation are a *huge* part of the design phase of engineering. It’s an entire section of my design review template1 and the associated process, which digs deeper each iteration. Running FMEA’s, quantifying hazards, and looking at failure modes are all part of understanding how a system works and creating redundancies to prevent mission loss.

Sometimes we need to fail

This column is about avoiding pithy turns-of-phrase, but at the risk of undermining myself (with a Silicon Valley truism, no less) it’s important to fail fast and fail forward. We’re making assumptions in design and doing our best to anticipate real world conditions. It’s too big of a job to design something and stick it right into service. Component tests, system activations, and qualification testing are ways that we can find unplanned dynamics. I see a lot of tests get skipped because they’re “expensive” or too hard. I assure you it is more expensive and much harder to have your thing fail publicly instead.

Failure can also be psychologically important for a team. I remember Flight 3 of Falcon 9, which was the COTS demo for NASA. I had just joined the company, and the Dragon capsule was having some challenges executing commands. The mission represented a huge milestone, as it would be the first commercial vehicle to dock with the ISS. I went out for drinks with some of the seasoned vets during the time when it was unclear whether Dragon would be allowed to approach. They were worried, but they’d also each worked on Falcon 1 which was marked by constant failure. They spoke about how it was good that some of the green engineers (aka, me and others starting at the same time) got to see that everything didn’t just magically work. Dragon recovered and docked, but I never forgot the lesson or the way it bonded us as we set out on the huge task of building the west coast launch site at Vandy where failure stalked us constantly.

Planning is boring but essential

Failure is like a grizzly bear. We shouldn’t fear it, but we damn well better respect it. A good design process, a robust test program, and process that includes all contingencies is crucial to success. We must avoid magical thinking such as “We can do it we’re XXX we always get it done!” That’s dangerous, and it demonstrates a lack of understanding of why a team succeeds. Things don’t “always get done” because some VP said so out loud, they get done because some dummy like me goes outside and works all night to make it so.

If you watch Apollo 13 (which you should, because it’s great) you’ll see the attitude of both the flight team in Houston and the astronauts on board isn’t actually “failure is not an option.” They watched the explosion. They are watching the oxygen drop on board. They all know what’s likely. But they keep making decisions that choosing anything besides failure. They look at every piece, part, and process on hand and assemble them in ways that beat back the obvious outcome.

Failure is always an option; we must work constantly to make it the least likely one.

Subscribe now

I am excited to write all of these, and most are already in some state of partial completion. But still I found myself paralyzed wondering which one would best capture the constructively contrarian spirit I want to cultivate here at Anti-Hype.

I decided it’s this: We gotta stop saying space is hard.

We Already Know Space is Hard.

Yes, space is a challenging environment to work in. Sometimes it’s cold, and sometimes it's hot, too depending on your position with respect to the sun. Sometimes that changes a lot in a matter of hours, or even instantly across the exposure boundary of whatever thing you have floating around in orbit. Worse, it's a near-perfect vacuum and there isn't a lot of gravity, depending on where you set up shop. As you get further from earth, micrometeorites and radiation will eat you up. If they don’t then landing on another planet or even our neighboring heavenly body probably will.

But we already know all that! Hell, we've been flying up there for over 70 years at this point! Every American company launching a rocket, or a satellite, or even heading back to the moon has seven decades of publicly available, taxpayer-backed science, research, mission data, and precedence to pull from. I mean, worst case how many times did you watch Apollo 13 growing up?

Now, maybe *your* company didn't take any of that seriously, do the boring research, invest that slow effort, or even engineer your systems with proper process in place, but I’ll be damned if that isn’t a different problem altogether! That’s not space, that’s just a lack of discipline — it’s hubris!

You thought you were going to waltz on to the scene as a wunderkind and shake things up? You thought 70 years of missions in the bag meant we had the logistical and engineering wrinkles so ironed out they simply no longer had to be accounted for? Woof, big “gifted child” energy there.

No, friend, that’s not how this works. A mission to space is one of those few things in life that’s purely binary and every stage, every action, every moment is a new casting of lots. Mission success or mission failure, that’s it. Failure is always an option2, and usually the entropically favorable one at that.

We all know people and companies like this. Since my last company had just about every major New Space company as a client, I got to see it dozens of times from players old and new. Some were more memorable than others, like when a well-known CEO thought his launch pad would cost $2M, take 8 weeks to build, and require just two people to build and operate it.3

Or when I overheard a pitch to global investors by a different CEO that the mission was simple, solved, and the next round of cash was for the next shiny thing because you’ll be hockey-sticking your way to orbit any day now. Can’t forget about the time those same guys thought it would be ok for the first flight or two to just hit the ocean. That’s fine, I guess; it was their call.

But when that call gets made, the outcome must be owned! After the shit (often predictably) hits the fan sideways, one really shouldn’t be able to just tweet "space is hard" and move on to commit the same sins of poor process again, and again. Instead, the focus should be on the real, tangile things in front of us that are indeed quite challenging.

The Other Challenges

Raising money is hard.

Raising money is really tough, especially these days. I know that in order to stand out, it is easier to tell investors what they want to hear and sell them the hype. But the bill eventually comes due, even if you were lucky enough to enjoy a few fun months skipping the IPO process and SPAC'ing before you had a real product. These shenanigans make it harder for other hardware founders in the future. Quit salting the earth.

Hitting technical milestones is hard.

Once you raise a little money, now you have to hit technical milestones. This is hard because engineering is decidedly distinct from physics, and generally it’s a huge pain in the ass to get the two to line up while also respecting your timeline and budget. However, the answer to these difficulties is not to underfund development and cut schedules in half as a form of motivation. It definitely isn’t cutting down your qualification program until only a cynical series of check boxes remains, nor is it throwing out proper procedure in an attempt to ‘cut bureaucracy’ and go faster.

Managing people is hard.

Worse, than meeting technical milestones is managing the people who do the engineering. Yes, I am talking about managing engineers, a phrase that is enough to cause former PM’s to break out in hives, throw their iPhone in the ocean, and join a commune beyond the reaches of Microsoft Project. It would have helped if you’d trained actual managers, instead of just promoting the loudest, most opinionated engineers, but too late for that now, I guess, it’s time for mission!

Making money in space is damn hard.

Cool, you made it to space! Now the trouble really begins because the further you get from earth — the place where dyed pieces of cotton paper overcome their non-intrinsic value by being blessed as fiat currency — the less chance any business model is going to work. As venture dollars wane (and with the IPO markets essentially closed) all revenue roads near the space industry run directly through NASA and the DOD, sooner or later.

Right now, the companies racing to return humans to the Moon, as well as to replace the ISS with a commercial alternative, are struggling to find real, established, paying customers. That’s not to say the mission or the science of both aren’t important, because they are. Rather, it’s just to say that behind closed doors everyone is whispering their worry that the only LOI’s they’ve managed to sign are with a bunch of other shaky startups who also need two or three miracles each in order to survive.

The whole thing ends up looking like the Spiderman pointing meme.

Firing an entire company should be hard.

Then the hard times really hit, because without money coming in from investors of customers, the layoffs begin. It would be cool if you didn’t do it over Zoom, or email, and it would be especially cool if you didn’t hose everyone out of their livelihoods before taking a golden parachute for yourself.

Hardware Matters & Space is the Standard Bearer

The reason this matters is because hardware is key to unlocking a sustainable future on this planet, and learning more about the universe around us. Machines are fundamental to how we make energy, grow food with modern agriculture, and save lives with modern medicine. Hardware is the foundation from which we support a growing world while working to improve outcomes for everyone.

And the reason I am picking on the space industry is because, for better or worse, it is the standard bearer for how hardware projects are developed. Everyone from energy startups to the gundo boys look to the modern space industry as standard for how hardware is developed and deployed.4

So, if we want to spin in circles burning investor dollars and customer goodwill all while steadily eroding public trust before letting that virus spread to energy, defense, and every other hardware-heavy industry while the earth burns around us, then I have good news: we’re on the right track! We have the right mindset and we must do nothing more than let the process play out. It’s only natural in that scenario that “space is hard” or whatever shrugging non-mea-culpa applies to the industry in question is as close to accountability as anyone will get.

The real consequence is that if we build enough failed, sloppy projects we will forget how to build anything of consequence. We deserve better, and we must demand better both of our others and of ourselves if we want the future humanity truly deserves.

Share

Subscribe now

I have been building hardware for over ten years. Fresh out of graduate school I was hired as a launch pad engineer for SpaceX, where I helped design, build, and launch in the early days of the Falcon program. After that, I transitioned to leading the design and build of their rocket landing barges out in Florida and Louisiana. Then, I moved home to Alaska and started The Launch Company which bootstrapped hardware to space on rockets and satellites, while also designing dozens of launch site systems along the way.

I sold that company and about a year ago, I left. I started a sabbatical (which I am still technically in the middle of) and spent a lot of time writing. I write on The Next 30 Trips, a newsletter where I explore our relationship with work and our search for actualization, and I also wrote (and am forever revising) a memoir called The First 30 Trips which examines what happens when a demanding career becomes our sole center and how to recover life afterward.

I Have Some Thoughts

So, in short, things were good! I played with my kids and I went on long bike rides or skis through the woods depending on the season. I putzed around with old motorcycles and I noodled on who we build big things for, and why. This led me to think about startups, and more specifically the world of hardware. I admit, I didn’t mind. I love thinking about hardware development. I even started doing some consulting through my one-person engineering shop Laylu and advising a handful of startups.

As I got back in the saddle, I reflected on what worked, and what didn’t, during the journey of bootstrapping in-space fueling fittings and test equipment in the demanding New Space industry. I thought, too, about what worked and what didn’t for the larger venture-backed companies that were our clients. Companies like Astra, Relativity Space, Firefly, SpaceX, and many more. Some flamed out (quite literally) and others rose to the challenge. I realized that I’d seen a huge swath of a very complex, competitive industry and I have opinions, dammit!

No, more than that, I’d realized that I’d enjoyed a behind-the-scenes tour of dozens of very painful lessons in developing and literally launching hardware. From that, I have been synthesizing some of the things I think worked, and those that didn’t. These are lessons I will be holding close as I worked on my own Next Big Thing (which is currently TBD). I wanted to write them somewhere, and they just didn’t fit in my other newsletter nor solely as LinkedIn posts.

And so, Anti-Hype Hardware was born.

Things to Explore

In general, posts will fall into one of two buckets:

• Exploring the State of the Hardware Art

  • Building hardware is a pain in the ass! Why do it? Shouldn’t we all be out pumping fintech companies or jumping on the AI bullshit train? Yeah, maybe we should but if you’re here then you probably have the same screw loose as I do. You like switches, buttons, and watching things light up. You like holding something you built in your hands, then deploying it to do a job. You recognize that the biggest needs on earth all revolve around hardware.

  • But hype is killing hardware. We need an honest exploration of what’s working and what isn’t to develop a set of practices that lead us to the zero-carbon, spacefaring, equitable future we all deserve.

  • Most posts will fall into this category and the vast majority will be free! However, I reserve the right to paywall some especially juicy ones.

• The Bootstrapper’s Guide to Hardware

  • I am a huge believer in bootstrapping companies. Some people think it’s not possible to bootstrap hardware, but my experience disagrees. Even if you don’t bootstrap forever, doing so at the outset helps whittle away a lot of bullshit.

  • To that end, I am developing a series of posts that will encompass a step-by-step actionable guide to bootstrapping your own hardware company through the early days using only the tools you already have on your computer.

  • These posts will be for paying subscribers only, though I will try to share out some nuggets here and there.

That’s the thesis, as of now. It’ll be fun, and maybe we will all learn something together. I hope you’ll come along for the ride!

Subscribe now

Share