I’ve got a double-header post today, how exciting. I had two separate ideas, neither of which felt like enough content for one month, so here we are. This one isn’t about paleontology or evolution or even nature at all, just something I’ve been thinking about for awhile.

When I started my first job out of college, at a semiconductor test company as a junior mechanical design engineer, I slowly became aware of a class difference between the employees whose cubicles were located upstairs and those who sat downstairs. Upstairs was Design Engineering, that lofty pursuit of elegant parsimony and perfect constraint, while downstairs was everyone else–Sales, Manufacturing, Supply Chain, IT, etc. Upstairs, you could spend 95 percent of your time on your computer, building out whole architectures and machines and features by yourself in an abstract, academic bubble with little input from others or from reality; downstairs, if it didn’t work, you had to fix it. As the adage goes, “shit rolls downhill”–or, in the case of technology companies, downstairs; Upstairs People design the system and shove it down the stairs, where the Downstairs People are forced to pick up the pieces and make a functioning product out of the mess. This upstairs/downstairs dichotomy isn’t restricted to hardware companies; in software, there are equally divisive caste strata between Devs, the Brahmin of software, who work on features, Quality Assurance, who work on tests, Site Reliability / Support, who keep the product running, and IT, the Untouchables of software, sometimes derisively called “I Tried” (as in “I tried to be a real software engineer”), who keep the other engineers’ computers running.

Since I was a privileged Upstairs Person (a Mechanical Design Engineer) in my first job, I was wary of becoming a Downstairs Person (a Manufacturing Engineer–mitigated a bit by the prefix Senior) when an opportunity at a different company arose. As I found out, the Upstairs/Downstairs dichotomy was in full effect at the new job, with Upstairs People enjoying privileges like machining requests fulfilled in two days (rather than two weeks), a fancy espresso machine and pour-over coffee setup (rather than a Keurig), and air conditioning (I didn’t realize it was a privilege til it was gone).

(Aside: the correlation between more abstraction and higher status in engineering (software engineers are paid more than electrical engineers who are paid more than mechanical engineers who are paid more than manufacturing engineers) is also present in scientific research: psychologists wish they were biologists who wish they were chemists who wish they were physicists who wish they were mathematicians. But all of them look down their noses at engineers. Here’s an illustrative joke: A mathematician, a physicist, and an engineer are testing the hypothesis that all odd numbers greater than one are prime. The mathematician goes, “Three is prime, five is prime, seven is prime, nine isn’t prime, so the hypothesis must be false.” The physicist says, “Three is prime, five is prime, seven is prime, nine isn’t prime, but eleven and thirteen are prime, so nine could be experimental error.” And the engineer says, “Three is prime, five is prime, seven is prime, nine is prime, eleven is prime….” This joke was brought to you by mathematicians.)

Anyway, at first I thought of my new Downstairs position as just a way to get my foot in the door at this more competitive new company, and thought I’d naturally transition back Upstairs, where I belonged, as soon as I got the chance. I spent the first couple of months as a Downstairs Person seeking out as much relevant design work as I could, trying to impress various Upstairs engineers and engineering managers, and planning to apply to become one of them when a position opened up. However, as I got more involved in manufacturing and operations work, and as I talked to experienced and successful Downstairs People, I realized–Upstairs is overrated. There is a lot more to the downstairs life–more diverse problems to tackle, quicker feedback that leads to faster learning, and wider scope. And it’s more satisfying to see real results all the time instead of mostly just theoretical ones, followed by a moment of truth at the very end of the project.

It’s interesting to note that the people who were hiring me for this new Downstairs position shared the same concerns: they made sure that I understood that this role was a Downstairs one, that I wouldn’t be designing the actual product but only the associated tooling and fixtures, and that I was okay with this. They stressed this multiple times, seemingly afraid that I would quit shortly after joining when I found out I’d fallen from on high. And these were Downstairs People themselves, who’d sadly bought in to the caste mentality.

Feet on the ground

I don’t know if this is applicable to non-tech companies or to academia, but in tech companies it’s crucial to have people with a lot of pull to have their feet firmly on the ground. That is, managers, executives, and high-level individual contributors shouldn’t distance themselves from the nuts-and-bolts, day-to-day workings of the company, but rather try hard to understand what the everyday problems are and what life for the plebs is like. Often, you don’t know what’s wrong with a design until you see someone struggling to build or use it, and the resulting guilt is very motivating to do better in the future. Also, the limiting factor to success is often something super dumb and mundane–for example, a project timeline slipping because we didn’t have enough buckets to run a critical experiment, or because someone dropped a precision tool on the ground and the lead time to replace it is long. Low-level Downstairs People are hyper-aware of these issues, but often don’t have the resources to fix them, or the communication line to someone who could. Bringing Upstairs People into the thick of things not only allows silly problems to get resolved quickly, but it also sets the stage for super-agile prototyping and design iteration. This is both a recipe for success as a company, and a great method for learning and improving as a designer.

Diversity of tasks

As a design engineer, you’re mostly solving the same types of problems over and over–for mechanical engineers, that’s optimizing the shape and material of things for strength, controlled movement, lightness, and cost, among other considerations. The details and constraints will obviously vary from project to project, but the core process is the same. I used to say that my job was “making sure things are the right shape so they don’t break”.

As a manufacturing engineer, there are opportunities to wear many different hats: optimizing a process or workflow to achieve high yield and safety (operations hat), doing experiments to test design or process prototypes (scientist hat), troubleshooting and root-causing field failures and coordinating how to fix them (quality hat), designing tools and fixtures to enable and improve manufacturing or other tasks (design engineer hat), building stuff and figuring out best practices for building it (manufacturing hat), training technicians and ramping factories (production hat), etc. You could choose to specialize in any of these areas, but being exposed to all of them provides a much more well-rounded perspective on how companies actually run.

So…

Turns out Elon agrees with me–on a tour of the new Starbase facility in Boca Chica, he said (and this was one of the very first things that he said),

"I think generally, manufacturing is underrated and design is overrated. People generally think that there's this Eureka moment of, like, you come up with this idea and that's it, now it's good. But...there's literally a thousand percent, maybe ten thousand percent more work that goes into the production system than the thing itself. So, say like, how much effort that we put into, say, designing Raptor versus designing the manufacturing system, it's ten to a hundred times more effort to design the manufacturing system than the engine. Especially with Raptor. Basically, the amount of effort that goes into the design rounds down to zero, relative to the amount that goes into the manufacturing system. If this was not true, then, great, I'd like a thousand Raptors, please. Oh, you can't make them? Oh, okay.

"This is just very fundamentally underappreciated. If people have not been in manufacturing, especially manufacturing of something that's relatively new, then they don't understand, and they think design is the hard part and production is like a copier or something. This is completely false. I can't emphasize enough--I'm trying to correct the misperception that design is the hard part. It is not the hard part...What is super hard about Raptor is how do we make a Raptor where the cost per ton of thrust is under a thousand dollars."

Maybe this is why the page image is a raptor? *waves hands*

So if manufacturing is so valuable, why is it underrated? The main reason is probably just that it’s easier for people to appreciate your work if you point at a thing and say “I designed that” than if you say “I did a lot of coordinating, experimenting, sourcing, and designing relevant equipment in order to get this built”. It just seems less sexy. Another reason might be that they don’t generally teach the latter stuff in school, and if you went to college for mechanical engineering and are considering a manufacturing job that would only use your knowledge of beam bending once in a blue moon, you might feel like you’d be underutilized or overqualified for that position. It’s a hard sell. And it’s bad for everyone that the brightest candidates gravitate toward Upstairs roles, where they’re underutilized in actuality.

And lest you get the wrong impression, I haven’t just switched tribes. I’m not saying that design isn’t important–it’s completely necessary. But designing with one eye on assembly and production (or in the case of software, architecture and deployment) produces significantly better outcomes than siloing. And I’m not saying that the pay differences between different types of engineering should be equalized either–pay is largely dictated by market forces, as it should be. But I do think that manufacturing positions are definitely underappreciated by other parts of the company and by the public, and probably undercompensated as well, and tying their prestige and pay more closely with their real-world importance would be beneficial (both for company productivity in general and for me personally, of course).

How can we mitigate this?

Well, if you’re an executive or a manager, you can try to highlight the work that the manufacturing and operations teams are doing. That’s actually something my current company, despite the persistence of the Upstairs/Downstairs dichotomy, has made efforts to do: in our weekly company-wide lectures / interviews / presentations, there’s been tours of the manufacturing and production areas and shout-outs to particular operations personnel for specific acts of heroism. However, since the dichotomy persists, clearly doing just this isn’t enough to eliminate it.

I’m still a pretty inexperienced manufacturing engineer, so take any solutions I propose with a grain of salt. But if I were in charge of company organization, I’d first try to lease a building with only one floor, and make sure all the areas of the building had the same amenities–that’s a no-brainer. I’d also probably try to collapse the design and manufacturing teams together, and list all the roles on the hiring website as “Mechanical Engineer” (no “design”, no “manufacturing” in the title) but be very clear during interviews that spending time on both would be required.

I’ve been super privileged to have an amazing boss at this new company who understands all this deeply. He used to be an Upstairs design engineer once upon a time, and chose to make his career Downstairs. One thing he said that was really memorable was, after a milestone in a design project I’d been working on: “I just want to make sure you’re okay with projects like this. I don’t want people to pigeonhole you into being just a designer.”

“Just a designer”! This is someone who gets it.