What is Engineering?

My journey so far

A sky full of stars (Joshua Earle joshuaearle, CC0, via Wikimedia Commons)

When I was a kid I wanted to be a garbage man, then an astronaut, then a physicist, then finally I settled on rocket scientist. What do all these have in common? If we ignore the first one, it’s pretty clear I’ve loved exploring since an early age. Even picking up garbage speaks to a certain kind of exploration. Much of what we’ve learned about social sciences is through looking at what we throw away and what we hoard. I think it’s safe to say I’ve always imagined myself as an explorer in one shape or another, be it of our internal or external worlds. Most of my education was spent training to explore that most external of worlds—outer space—but most of my career has actually been oriented towards our internal worlds. In a way, I have become that garbage man that I initially set out to be.

The 1995 movie Apollo 13 was a turning point for me. I was nine years old and wanted to become an astronaut. After seeing the film, I remember reading the science section of our local newspaper every week looking for stories about NASA. I even saved article clippings. NASA’s new shuttle replacement, the Venture Star, was going to bring us closer than ever to outer space! A science fiction future was around the corner! As the years dragged on, and shuttle launches kept their terribly slow pace and terribly high cost I started to grow disheartened. Why wasn’t NASA making progress? Even at that age I realized there was no way I was going to be an astronaut if there were only a handful of people going to space each year and they were only funded by the government. Things would have to dramatically change before that became a real possibility.

Apollo 13 movie poster (Imagine Entertainment and Universal Pictures)

A couple years after Apollo 13, I learned about the X Prize, a competition challenging non-governmental organizations to launch a reusable crewed spacecraft to beyond the edge of space and repeat the feat within two weeks of the first successful attempt. Through this competition I learned other people were feeling the same way as me about NASA. Why couldn’t we make real progress on exploring outer space? We went to the Moon, now we were stuck in low earth orbit. Even that was only happening a couple times a year. Why was outer space so hard? Why was it so expensive? It would be a while until I found out.

NASA lost much of its glamour in that next decade after I watched Apollo 13 the movie. I still loved space but the commercial sector began to capture most of my attention. I had new heroes, first Burt Rutan, then Elon Musk. Maybe these iconoclasts knew something that NASA and their army of sub-contractors never could figure out (or had more likely forgotten)? Could it be that pure genius and guts were all it took? Was space finally close enough that I could go there in my lifetime? Maybe all it took was a blank sheet design and problem could be solved.

I entered University of Michigan as an aspiring aerospace engineer. I left five years later with a bachelor’s in Aerospace Engineering, a Masters in Space Systems Engineering. Here I started to learn the scope of the problem. There is so much to learn in order to simply understand a small piece of what’s necessary to build something as complicated as a rocket or an airplane. Thermodynamics, Aerodynamics, Mechanics, Chemistry, Electrical Engineering, and Computer Science are just some of the specialties that need to be integrated in order to put together aerospace technology. Each discipline takes an entire career to master. Stitching them together such that each discipline can coordinate with one another and work together as a differentiated whole makes the problems of each individual expertise exponentially more difficult to overcome.

In essence, any sufficiently large multi-discipline project becomes a hyperobject, an object “of such vast temporal and spatial dimensions that [it defeats] traditional ideas about what a thing is in the first place”. To engineer is fundamentally a creative act. When we engineer at the limits of our capabilities, such as in aerospace engineering, biomedicine, or any other high-technology area of expertise we must create and imagine together because the scope of what we attempt to create defeats our individual capacities. When we ride a jet plane, hold a cell phone, or get vaccinated we are only seeing the barest surface of the entire object formed by the people, ideas, places, and tools necessary to provide each of those functions.

Me, with laser glasses

At university, I experienced how difficult it is to create new technologies in two ways: an education in the physics and mathematics used by the engineering disciplines of aerodynamics, control engineering, thermodynamics, and dynamics and structural mechanics. Here I started to grasp how non-intuitive and incomprehensible the base features of reality can be. It is amazing that we have any capacity to control physics at all.

As a team member then project lead for a student engineering group I started to understand how different practicing real engineering is versus learning the analytical tools used when engineering. Real engineering uses specialized fields of analysis just as real engineering uses screwdrivers, lathes, and blast furnaces. Engineering uses many specialized tools, fields of analysis are not the function of engineering itself. In actuality, engineering is similar to politics. Engineering is about uniting and coordinating a team that is both capable and motivated to accomplish a particular task that is beyond the reach of any of their individual capacities. When we train engineers, we are training people into a particular protocol that enable them to unite and coordinate such that together they can manipulate hyperobjects.

MClimber v1 on its way up (Las Cruces New Mexico, October 2006)

For all five years I was at university I worked on a quixotic project. We called ourselves MClimber, and we wanted to win a NASA Centennial Challenge. The Centennial Challenges were set up in response to the success of the first X Prize and seek to galvanize progress and public involvement across many “moonshots” related to space exploration. MClimber was a competitor in the power beaming Centennial Challenge. The purpose was to develop technology needed to one day build a functioning space elevator by building a tether climbing robot that who’s power was beamed from the ground rather than stored on board or transmitted through a cable. MClimber failed, but we learned a lot along the way. The details of our design and the competition are not relevant to this story, but the lessons certainly are. You see, by my nature I have always tried to do things by myself. I’m inclined to approach every challenge as an opportunity for self improvement. A childhood playing Role Playing Games taught me that every challenge is an opportunity for experience, for “leveling up”. This mindset does not work when working on a team (unless one is focused on ‘leveling up’ leadership, which I have never been very interested in).

The Team (Michigan, October 2009)

At this point, I was inspired by how I imagined my engineering role models operate. In my head, people like Kelly Johnson of Skunk Works, Burt Rutan of Scaled Composites, and Elon Musk of SpaceX brought forth their creations by the power of their individual genus. Sure, they had teams but they were calling the shots. They were the artists. Their teams were just tools to help them realize their vision. That is how the real technology disruptors operate and I wanted to be one of them.

When a subsystem on the project needed help, I focused on making that subsystem rather than making the team step up to the challenge. Learning skills is far easier than coordinating people, so I tried to stitch together the functions necessary to succeed at the competition through the bare power of my will. Tools are not teammates, and my available time, and skills would never be sufficient to design, build, and test a technology as complex as a power beaming robot. Engineering by oneself is not a recipe for success. Hyperobjects by definition will not conform to any single individual’s talent.

Exhaustion (November 2009)

When I started working at SpaceX after completing my Master’s degree I started to learn how the sausage is really made.

At SpaceX, I worked closely with the Flight Software team. I was not a software engineer, but rather served a supporting role. At any other company I would be called a systems engineer, but at SpaceX we were all systems engineers, a directive that came straight from the boss man Elon. My title changed a few times in the eight years I was with the company, but purpose of my job did not. I was in charge of defining and describing the processes that made SpaceX flight software safe and reliable enough that the government could trust us to fly missions to the International Space Station.

In this role, I primarily acted as an interface between NASA and SpaceX, working to translate between “SpaceX-ese” and “NASA-ese” so that these two organizations could better understand and dialogue with one another. Neither wants to screw up, but beyond that their motivations and core assumptions were wildly different.

In my experience, NASA works by trusting their processes while SpaceX works by trusting their engineers. The truth is much more complicated than that, yes generalizations are dangerous, but great for making a point. Both use process, both rely on individual responsibility but the difference is in the relation between the two. Does the individual serve the process or does the process serve the individual? Both approaches have pros and cons. Process-first development is slow and expensive when developing new technology, but personnel are less susceptible to burn out. Engineer-first development is faster and cheaper, but finding and retaining the necessary talent to accomplish challenging goals is a real risk. Judging by track records, both approaches may be similarly effective at creating something that achieves the desired goals, but processed based approaches have the advantage that the risks are more legible across the organization (or at least give that appearance).

I feel that something is deeply maladapted about the way we go about working together on collective projects. In a sense, SpaceX and NASA both represent opposing poles on a spectrum of organizational theories. They represent thesis and antithesis to one another. NASA’s engineering is most characterized by their artifacts: their standards, requirements, and processes by which they constrain their engineering. SpaceX’s engineering is most characterized by their people. What then is their synthesis?

I’ve had a hard time creating an “elevator pitch” for what my core interests are ever since I really started being an engineer. I’ve always been most fulfilled as a systems engineer but I’ve always been dissatisfied with the process and toolbox a traditional systems engineering education promotes. One cannot extract systems engineering into its own discipline, for by its nature systems engineering is the very substrate by which an engineering organization coordinates. If I have to pick sides I agree with the SpaceX approach. The proper ordering of process versus individual is that the individual uses processes as tools, not that individual creativity is fundamentally constrained by process. I just don’t believe we have the protocol in place that makes the SpaceX paradigm scale to meet our global challenges. When primacy is placed on the individual it means our collective work must be collaborative, it must be social. It cannot be rigid or tyrannical. This is what it is to engineer, it is to be creative together within our shared social reality.

In the late nineties when I became disillusioned with NASA, I found I was not alone. In fact there were other people who even had a theory as to how to how the status quo could be improved and the gumption to test their ideas. I’m talking about the new space pioneers who found their calling through the X Prize and the later space commercialization efforts exemplified by SpaceX. Similar to that moment I believe there’s an even grander change afoot.

Unlike that moment, diagnosing the root problem here is much less legible. Here’s my attempt. Collectively we are increasingly aware that our orientation towards reality is not optimal. Our beliefs about the nature of reality are in need of a reset. The main fissure is that objective and subjective reality are much closer together than we have been led to believe. Objectivity and subjectivity are not a dualism but rather a spectrum. At their extremes they are paradoxical, but reality is defined by their mixture. We can reframe and resolve many contemporary issues when we realize we are treating some ideas as being more objective than they actually are, and other ideas as much more subjective than is really the case.

We are entering a moment of collective kairos. We are starting to understand all the different symptoms of our cultural malaise. What I found in systems engineering is simply one manifestation of the problem. I believe we may yet find the wisdom to act at the moment of kairos and positively reorient society towards a new equilibrium point. The moment is almost upon us, it is not yet passed so whether we make it or not remains to be seen. The purpose of buildonomy is to participate in this moment, acting within my niche of systems engineering. I believe the full potential for engineering to be both deeply personally rewarding and culturally meaningful is much greater than has yet been realized. It is only when we can collectively and dynamically realize relevance, balancing between the two poles of individual genius and collective process that we will unleash the full potential of the creative collective spirit of transformation that engineering represents.