We’ve made planes and cars and medical devices, but now we’re learning how to make new things more affordably. We can make a smart phone in America, we just can’t afford to yet.

The bottleneck after Manufacturing was originally going to be software, but programming computers is getting cheap. AI is going to make software development cost next to nothing. What’s the bottleneck after that?

Engineering. We don’t Engineer in this country anymore. Anyone who works in consumer electronics knows this -- we’ve become “Architect Astronauts”. From a recent interview with

Palmer Luckey:

“American companies have been hollowed out. ... We’re not teaching engineers how to be engineers anymore. ... We’re not teaching designers how to actually design things to be manufactured. ... We’re teaching them how to be high-level design shops that put together a design package, that gets sent to the real engineers in China—and they actually figure out how to do the work. ... People are turning into architecture astronauts. ... They pick components, and they put them in a nominal layout.”

He’s absolutely right. I’ve been there. The problem is deeper than “We don’t make things here anymore.” It’s that, plus “We don’t know what and how to make here anymore.” By the way--if you want the secret to great companies, it’s this. Their Engineers are actually Engineers.

We sold our engineering souls and gave up obsessing over details like thermal expansion to focus on stakeholder alignment. We traded cyclic loading analysis for topology optimization. We swapped DFM for “they’ll figure it out.”

So here we are. I wrote about how we would get out of the manufacturing bottleneck four years ago, it started happening, and now we’re on to our next bottleneck. How do we engineer in the United States again?

I think I have the answer. This is the main goal of my work. Have Engineers engineer.

building something by yourself is riskier than building it with others, but i also think building something with others limits how great your thing can be

i’m really talking about companies, but i think it’s true in every domain. it boils down to: you sacrifice vision for security. two cofounders will never share the same exact vision, at best, they overlap a lot

the way i think about this: imagine two normal distributions that represent the likelihood of success in an endeavor. a tall short tailed curve (cofounding) and a short fat tailed curve (solo founding) that picks up most of the worst and best outcomes

if you have cofounders you’re more likely to succeed because you have more brain power and net work produced. but it will more likely be average because you have to convince others of a slightly worse but more agreeable version of your vision

if you do it alone, you’re more likely to fail and the average outcome is slightly worse. but, if you want the really exceptional outcomes, it’s the only way to do it — to execute on an undiluted vision

this is why investors like to see cofounders: they aren’t actually betting on home runs (despite what they say), they’re trying to minimize the chances they lose their money

anyways, this isn’t to say exceptional things can’t be cofounded, i’m saying it requires the founders to be sharing an exacted vision which is so so so rare. it requires lightning striking the same place twice

What happened? Let’s start with the evidence: sans Elon (who is leaving), the Valley hasn’t invented anything new in twenty years. Go ahead — think of something. I’ll wait. Airbnb? Is ‘Hotels but worse’ your contention? Apple Silicon started with ARM, which was founded in the UK. Kalshi is legalized gambling.

AI — okay, now we’re talking. Let’s talk about LLMs. Let’s talk about the own goal scored under the guise of “safety” that opened the door for Chinese labs to surpass us in the one thing that was actually invented in the last twenty years. Kimi K3 is now as good as Silicon Valley’s offerings. At the current rate, Chinese labs will pass the frontier labs by the end of the year.

My point is that this could have been avoided if the people who built these technologies hadn’t been living in the Silicon Valley bubble. If they had held real jobs at some point and had truly understood what they were building in the context of the real world, we wouldn’t be discussing a Chinese open-weight model right now.

I don’t think the answer is to jettison Marc Andreessen into space, despite the aerodynamic profile he shares with Starship. I think a correction could fix this. My fear, though, is that Silicon Valley will successfully lobby legislators to regulate open-weight models out of the American economy, preventing builders from getting the best tools (and also avoiding the correction).

This is why I’m writing this and why I’m frustrated. It used to be that I could ignore the Valley, but its silliness is now affecting me. I may now have to build my products using Chinese models. This is not the “future” I wanted.

I’m likely to raise my first round soon. In addition to not using models minted in San Francisco, I may have to look elsewhere for capital because I do not want to be sandbagged by the culture that led us here. I do not think it was simply the founders who shot their companies in the foot; I think the problem went higher than that.

Is this hurting my company’s chances of success? Maybe. But I can throw a rock from my apartment here in Seattle and hit both an incubator and a VC firm. And we don’t have the stupid billboards.

I want the Valley to succeed. I hope it will. Every great thing has had its stumbles. But it’s not a given.

I wasn’t going to write this, but I have heard rumors that another frontier AI model was held back from release because of this. That’s enough.

Most of us have been guilty of fearmongering about AI at one point, so there’s no reason to call anyone specifically out. Ten years ago, when I didn’t understand the technology, even I was doing it.

But some of them continue to do it. This is immoral. Here’s why: if you are sitting on a technology that can enable engineers and scientists to go solve real problems that will affect people’s lives for the better, it’s your moral imperative to make that happen as quickly as possible.

“As possible” is subjective here, but here’s what is objectively immoral: scaring legislators who don’t understand your technology into thinking that you’re bringing about the doom of the species by summoning infinitely intelligent agents we can’t control.

Let’s be very clear. LLMs are glorified autocomplete. That is it. That doesn’t mean they’re not incredibly useful, but they cannot and will not understand. The latest scare tactic is the claim that they’re improving recursively and that this will begin a loop that we can’t control.

Again, they are autocomplete. They will continue to make themselves better at autocomplete. You are making the assumption that we understand intelligence and that intelligence is simply getting better at the arbitrary metrics by which you judge your models (benchmarks).

The one defensible concern, which is being approached incorrectly, is that they’re a threat to cybersecurity. Fine -- stagger the releases to large companies you trust and assume they’re all good actors (that’s an assumption I don’t share). I’m willing to play along if you can stop scaring the government into thinking you’re bringing about the apocalypse.

But here’s the really important thing you’re missing -- our six-month lead in AI becomes a three-month lead because other countries are not going to play by the same rules. Your hamstringing of Americans puts us three months behind the lead. Is that more or less of a risk than the cybersecurity risk? This brings me to the most ridiculous risk that gets bundled in with all of this: “But they’re solving engineering! They’re intelligent! What’s next?“

They have not solved engineering. They have solved software development, which is not engineering. Many jobs were and are autocomplete, and their disappearance is fine -- elevating these people to roles they should have instead will also be a net benefit to humanity. Jobs aren’t going away. The fake ones are.

Additionally -- if you really believe the recursive self-improvement doom spiral, consider that we have not, and never have, understood consciousness. The best theory we have happens to be the craziest one, and if you believe that, well, I guess you can stop reading now. This argument was true decades ago when we invented and deployed computers. Imagine if we had held computers back because of this fearmongering -- where would we be today?

Because you do not understand consciousness, because you are building machines you have no evidence are conscious, you are simply scaring people for free marketing, whether you know it or not.

Why is this immoral? Because engineers and scientists are trying to actually build something with these tools. We are going to colonize planets and eradicate drudgery jobs no one wants to do. We’re going to solve world hunger and the housing crisis and a million other things. But instead you slow us down with the fearmongering.

I almost didn’t include this, but I want to call this out because the solution here isn’t for you just to realize you’re behaving immorally -- it’s to understand the dimensionality of incompetence that caused it in the first place so that you can fix it in the future. Do not take this personally -- we all have crosses to bear; now it is your turn.

The problem, fundamentally, is very simple. You have not had real jobs. Again, not an indictment, but it’s the only explanation I can think of for why you think the hammers and screwdrivers you’re calling “intelligence” are going to get up and start walking around and building nuclear weapons. I want to believe it isn’t actual malevolence.

Get a real job. Go cut metal. Build some furniture for a living. Learn plumbing. Do anything useful on the clock and see what real work looks like so you can understand what you’re really building. Learning the difference between a tool and a person will serve you really well.

The biggest negative side effect of the status race in our country has been our hyper-focus on making our children college-educated and employed in prestigious jobs. We forgot one important factor in that pursuit -- forcing them to have hard jobs in the interim that no one else wants to do so that they can learn something about the real world.

It pains me to think how many of the employees at these companies have never set foot inside a factory or do not understand the difference between drywall and particle board.

Your tools are not the solution to or the cause of humanity’s problems. Drop the hubris and stop scaring regulators so we can get back to work solving problems and bringing about the future. Or we can let China do it. Your call.

My favorite story arc from the show was when Don took out a full-page advertisement in the New York Times to publish a letter where he crisply tells everyone he and his firm will no longer market cigarettes for tobacco companies.

A reason I loved this throughline was because it re-packaged the moral of the story from Odysseus and the Sirens in a modern way. Don was sealing his fate -- he decided he wouldn’t work with Tobacco companies again, and that letter was going to make that a certainty. This was his binding himself to the mast.

-

Despite investment offers, WORC is still self-funded. I’ve written about why in the company’s manifesto. Originally, it was because I saw dilution as an existential risk to the company. That reason is now changing.

For most developers, AI is a 10x or 100x multiplier. But for engineers like myself, it’s closer to 1,000x within my domain of expertise. It’s not because I’m smarter than the others (I don’t think I am), it’s because I have a narrow focus and passion for what I’m doing multiplied by the decades of experience.

Why does this matter in this discussion of funding? I do not see raising capital as a money risk, I see it as an actual production risk. I recently took a meeting where I presented to someone a couple months into the job. They brought an associate who was on their second day. This was a colossal waste of my time. I have spent ten years thinking about the problem I’m solving. I had to boil it down into ten minutes for an MBA and someone who didn’t know where the bathrooms were.

In one of my favorite scenes from Halt and Catch Fire, the founders of Mutiny are pitching their product to two VCs who they assumed were partners. At one point, a GP walked in and asked the associates to get them coffee. Life imitates art.

This isn’t a complaint -- it’s an observation. Founders didn’t have the choice twelve months ago. Software products are features. Features are lines of code. Engineers write lines of code. Engineers need money, so Founders needed VCs.

Today, a meeting with a VC costs me an hour. How many lines of code is that if I’m actually 1,000x where I was twelve months ago? How many features? How many equivalent engineers ten years ago? The calculus doesn’t work anymore.

-

This isn’t me tying myself to the mast -- it’s me saying out loud that I think the mechanism that supported founders in the past is outdated and the right path forward is to carve a new one. I don’t think investors will lag forever. I think they will catch up eventually.

Again -- no mast. I’m saying this because I want to raise the flag to other founders.

Another way to look at this -- everything was elevated up a notch. Hardware companies are now moving and behaving like software companies were twenty years ago. They’re finally raising the money they deserve. Software has elevated to a new level with the current toolsets available to it and doesn’t need the money in the same way.

Now, this is all theory. I may be out of business by the end of the summer, but, we’ll see. One thing is for certain -- I will not pivot. I never understood pivoting. Do you not care about what you’re building?

-

Back to Engineering Software. I mentioned this last time, but we currently have a competition problem in our space. Instead of working together against the incumbents, we’re squabbling over tiny market shares and $50k ARR. Embarrassing.

Why fight with each other? Why make 100 versions of the same CAD product? The incumbents are laughing all the way to the bank from their 95% market share. Meanwhile, we fight each other to survive.

-

There are whispers of an engineering software consortium. A cohort. They don’t know what to call it yet. It would be a unification towards a shared goal -- dethroning the incumbents and bringing about the future of abundance held back by the CAD cartel monopolizing the engineering software market.

By working together instead of against each other, their products and features could neatly fit together. Instead of competing for clients, they could be making introductions. Instead of raising money from VCs, they could be leveraging strategic investors and companies sick of paying 100x more than what they’re getting is worth.

In the end, it may be that the answer to the question of “what company replaces the incumbent” wasn’t the right question.

-

I gave a talk a couple weeks ago at the first Kinetic conference in SF. It was about engineering software. Here’s the last slide from the deck:

I was the only person who got to see it, but the reactions from some of the audience were great. At least five people were totally confused. Most of the other slides made sense, but you had to really be paying attention to get what I was trying to say here:

I see engineering software as this room. The incumbents have built outdated tools that suited us forty years ago (the outdated furniture), but technology has evolved since the initial tools made sense. CAD, spreadsheets, code, all of it. Outdated furnishings.

The capsule sitting there doesn’t belong. Plug any of the recent technological developments from the last ten years into the analogy and it makes sense.

Lucas at Loombotic had another interpretation which I actually liked more than mine: Aliens built the room and what they thought it should be like. They (software developers) built what we (mechanical engineers) thought we wanted. It was close, but it never felt right. It’s because they could only go off of observations, not experience.

-

Why am I talking about outdated technology? We still don’t use MBD, we use drawings. We still use mouse and keyboard, despite never being the right tool for us. We still use Excel and it was made for finance.

Carl Bass said it best in our recent interview: he doesn’t see CAD as Computer Aided Design -- he sees it as Computer Documented Design. It doesn’t feel like it’s really aiding us. I totally agree.

What does the future look like if we can change that? My bet is that the future of abundance becomes a reality hundreds of times faster. Cured diseases, vacationing on the moon and colonizing planets.

What happens when engineers spend their time engineering instead of navigating tools?

-

The number of CAD companies at this point has entered the hundreds. It could be in the thousands by the end of the year. I can’t imagine what Nick at Plasticity and Istvan at Shapr3D are feeling right now. Each has experienced blatant copies at this point (what seem to be byte for byte copies in some cases). They’re even shamelessly copying their marketing materials (including their music). It’s not just a copy of the software, it’s a copy of their marketing. I’ve never seen anything like it.

Warning: you can’t beat these founders. You are going to lose. End of discussion. These are people who think only about what they’re building. They are not doing it for money. You can’t really compete with people like this.

I bring this up because we need to stop competing with each other. We can’t compete with the incumbents and drag them into the right product decisions if we’re squabbling. We need to find a way to work together. I haven’t figured out how to do it yet, but I am working on it.

CAD already made the mistake of abstracting us away from pen and paper. Consider that the first stabs at CAD in 1963 at MIT (Sketchpad, Ivan Sutherland) retained the pen as the main interface. We forget this, but our first attempts at making computers for engineers started with us giving them tools that looked identical to what they were already using.

We only got away from this paradigm because the industry coalesced around a standard set of inputs, the keyboard and mouse, a couple decades later.

Assume we already have strayed away from the light (we have) -- why would we go even further away using code as the intermediary interface to three dimensional geometry?

I understand that CAD as code brings some benefits like utilizing GitHub style diffing and file management. I think that is valuable. I also think it’s incredibly valuable to force the incumbent CAD companies into boiling their feature histories into intermediary code representations as a way to create interoperability. I think they will go out of business sooner than this will ever happen.

This brings me to a major failing of CAD as code -- it is not universal unless every CAD application utilizes the same underlying kernel. The BREP spit out by Catia will not match the BREP spit out by Inventor despite having the exact same set of code instructions. That should equal parts terrify you and bring a sense of wonder that anything in the world manages to get built.

Essentially, the kernel can be thought of as the compiler. Most of the compilers in CAD applications (FreeCAD is not really CAD, do not @ me) have different compilers.

If you insist on CAD as code and want it to be useful, you need to:

1. Work with an international standards organization to force incumbents into adoption

2. Develop an MLPerf style test to compare results between CAD kernels to highlight performance and differences in the results or force all companies into one CAD kernel (this will never happen)

FreeCAD has been toiling away at CAD for, what, two decades? More? It’s still unusable for complex work. Plasticity is only three years old and is nearly on par with most advanced industrial design surfacing tools available. So, what happened?

Plasticity is a dictatorial company that makes good decisions motivated by markets. FreeCAD is a side project made by software engineers for a market they don’t understand.

Open Source doesn’t really build meaningful applications. Blender is the exception to this rule (but I’m not sure, surfaces are for art kids). What can we learn here? Open source excels at developing power lines, but it shouldn’t be allowed anywhere near designing the user experience (phones, TVs, etc.)

What is Open Source for then? How do we dethrone incumbents with this knowledge?

Here is how not to do it: waste time building infrastructure that already exists. If you’re building your own BREP kernel at this point, you’re totally missing the mark. Use OCC if you don’t want to spend the money, otherwise, get Parasolid, suck up the profit loss and move on. Stand on the shoulders of giants, do not try to build your own giants.

Zoo gets a bye here because I think their infrastructure is the product. Competition is good, so they should keep doing what they’re doing. I think Amdahl’s law is going to kill their core thesis that BREPs can be faster, but even if they fail in making a faster kernel, Siemens having actual competition raises everyone else up in engineering software.

Here are the two main takeaways I want you to walk away with:

1. If you are developing your own CAD kernel in 2026, you have totally missed the mark and are doomed for failure.

2. If your engineering software company is developing an application layer product to be open source, you are also missing the mark.

With that said, I don’t think the frontier AI companies understand how little impact their tools will have on the real world. If we get AGI tomorrow, do your bolts get made faster? No.

Most of these companies do not understand how painful the real world is. There is no GitHub or Stack Overflow for Engineering and Manufacturing. This is by design. The incumbent software platforms do not want interoperability. It is how they make money -- through locking users and their data behind moats. Systems of Record? It’s the Inglourious Basterds meme when I hear you say this -- you just told me you haven’t had a job outside of B2B SaaS.

Not only do the incumbents not want you to have it, they will actively fight against you trying to get it. Ask any CEO in the CAD or manufacturing software space.

The problem for the people pursuing the future is that you need this data to train models. Even worse, LLMs will not be enough. I’m not an LLM doomer, but I do subscribe to the Yann LeCun school of thought. You can throw around infinite text data and giga-scale compute and get most of a SWE out of the other side, but most of other jobs is not text.

The theory Marcohard is betting on is that removing people is the only problem to be solved here. This is incorrect. People were never the only bottleneck in real corporations -- software, hierarchy and horizontal integration were. They’re only getting rid of two of the four.

I do think that xAI actually knows this, but they are being quiet about their real plan to not give away the secret sauce.

So anyways, the tsunami is coming. It will destroy most of the engineering and manufacturing software ecosystem. The good news is that it will leave open beachheads. WORC is betting on this. If you want to be a part of it, let’s chat about our Series A.

I see a world in which millions of Engineers around the planet work together. They should be able to share ideas and build things together without worrying about licensing or interoperability. These Engineers should not be forced to live in silos or hierarchies formed around vestiges like educational tracks and company structures.

The future I see lets RF Engineers share their analyses and documentation with Mechanical Engineers. These things should directly drive decisions that the Software Engineering team makes. This isn’t really just “sharing” — it’s working together. So let me reframe: I see a future in which Engineers can actually work together.

If this does not sound like a big deal, consider that we aren’t really doing it right now. The world around you is shaped by painful abstractions around work, and it’s not in service of the work. Imagine what the world could look like if Engineers focused on Engineering and working with other Engineers.

Do not believe the snake oil salesmen. The future is not requirements-driven or AI-only-driven. It’s driven by people. People make decisions using tools, but those tools end up forcing Engineers to make decisions they don’t want to make. If you do not believe me, consider the last time you were stuck staring at a computer screen at 1 AM, wishing you were at home with your family but your CAD package couldn’t figure out how to link a profile tolerance to a hidden line in a drawing.

This example tells you exactly what is wrong with Engineering right now. The Engineer didn’t choose the CAD package, the profile tolerance, the need for the drawing, or the requirements. But they could.

Consider whether the code written for the computers of the time to get man to the moon was the best way to do it. How much time could have been saved with modern tools? What would that impact have been?

This is the problem I need to solve.

How am I going to fix it?

WORC will focus on:

• Developing people who are focused on being the best at their craft. I have not left anything out of this statement.

• Creating products that reduce clerical overhead and increase allowable analytical complexity for Engineers.

• Thriving on constructive disagreement to define truth and how it will impact the product and the Engineer.

To support this, I’ve:

• Saved as much money as I could to try to skip funding until Series A. This is to retain as much control of the company as possible to ensure I’m making the right decisions for Engineers.

• Structured the company to reduce hierarchical overhead in exchange for communication overhead. Truth dies in hierarchy.

Why does this need to be done?

Engineers are not a commodity or resource — they are the actual product. Products are the reflection of the people who make them. A majority of Engineers’ time is spent on documentation and communication toil. Low-impact, clerical work that sucks their time away from the art of Engineering. If this is true, then by proxy, the future will be better if I focus on making their tools better and enabling Engineers to focus on the things that make them better.

Now what?

When the product launches in a couple weeks, you may be underwhelmed. That’s okay. I will be too. I want it to be better. It will be better. But have patience and use it anyway. You using it will help me make it better. There’s a feedback button. Use it.

It will not be paywalled. It will be free to use and share. The only thing you will pay for is features that are already free but that I can’t afford to pay for in the limit. My goal is to keep the base product free so that users from students all the way to Engineers doing state-of-the-art work get full access to the same thing. What will the world look like when this is true?

I called this “Our Engineering Manifesto,” but there is no “Our” yet. There will be. If you’re hyper-focused on being the best at what you do and want to surround yourself with people who share that goal, reach out. We are hiring anyone with this drive. I can teach you how to code, but you have to want to be the best. I can’t teach you that.

This manifesto is Part One of what WORC will eventually become. I will write more about that once we’re ready for it.

Again, I didn’t set out to build this company, but I need to. That doesn’t mean I won’t take it seriously. It’s the most serious thing I’ve ever worked on. I think the art of Engineering is a beautiful thing and spending one’s time perfecting it is a great thing to do.

it’s not surprising. the last “wow” moment i had was with the vive headset back in 2016. it was surreal. i came back after hours at work to keep playing with it. it was like a new world opened up to me

my phone did feel that way at first, but now it feels like a chore. i pick it up out of habit, not excitement. and here’s the thing — the companies selling these products know this

what are we doing here?

laptops are no better. if you ignore the one company actually trying here, it’s like time has frozen, and in reality, things actually got worse

what happened? why did we stop caring?

i think it’s simple — we stopped looking at technology as the thing that excites us, the thing that drives us, and the thing we want. today, your phone is no different from your toilet. it’s a need. it’s infrastructure. plumbing. you don’t want to live without it, but it’s definitely not bringing you joy

that isn’t to say these things aren’t important. just that we should consider our phones more like light bulbs than wonder-devices

once you do that, the companies and their structures that make these products make way more sense. they're creating infrastructure for the world rather than changing it

i’m only speaking about physical products here, not software. AI is a revolutionary software technology and if you disagree with that you haven’t used it correctly. the quickest way to see this is to test drive a tesla with FSD

I have nothing but respect for these companies and hope to position myself as a spectator with admiration and some insights that could be useful to them; but I do not plan on pulling any punches.

The Problem: there is only one laptop OEM. If you want to purchase a reliable and performant laptop there is only one choice. If I had to boil the root cause of the problem into one sentence it would be: OEMs aren’t focusing on narrow enough product lines to enable the requisite capital to be deployed on development and testing.

I won’t go into how owning the technical stack from transistor to operating system is almost required. I will leave that for another time. I want to focus on hardware only here.

Consider a company that has $700 Million a year to spend on product development for laptops. For example, HP has 7 product lines in this segment. This means that each product line has 1/7th or 15% of that total budget, roughly $100 Million.

This means that as a user, when you walk into a store and purchase one of these laptops you know that roughly $100 million was deployed to make that product great. That sounds like a lot of money, but consider how many engineers and managers it takes to create something as complex as a laptop. Consider the international flights back and forth for the multiple builds between facilities. And we haven’t talked about the raw cost of materials, modules and equipment required to perform testing for all of this design work.

Consider the current quality leader (reliability, performance, battery life) in the consumer laptop market: they have two product lines (compared to HP’s seven). If they were spending $700 Million on development, this means their total spending per product line is $350 Million, roughly 3.5x their competitor.

All other things being equal — engineer quality, core competencies, time from handoff to mass production — you have 3.5x more capital to develop a better product. This is the direct effect of focus.

Focus is the first cause of “The Problem”, the second cause is a lack of testing. Testing is the most important part of developing a great portable product. There is no replacement for repeatedly dropping your product, spraying it with salt water and applying a litany of substances to it to check for material incompatibility and corrosion. The lack of capital (caused by lack of focus) means less testing overall takes place, which results in less reliable products. This is a problem because portable products have far more ways to fail than non-portable products do.

Paradoxically, the winner in the Laptop market isn’t the winner in the desktop market, and it’s because Focus and Testing aren’t as important in desktops where users can’t drop their computers or take them outside into the elements that destroy machines.

An example: the Framework laptop uses POGO connectors to join the input devices (keyboard and trackpad) to their motherboard. This is a problem - fretting corrosion is caused by small alternating movements (keyboard typing) relative to a contact surface (connections at the POGO connectors) and exacerbated by oxidizing elements within the atmosphere, which are more aggressive because the device can be outside of an air conditioned climate.

To catch this design flaw would take an incredibly exhaustive (to the point of near lunacy) testing regime to catch that at the ten millionth key press some number of units were failing post reliability testing checks on keyboard connectivity.

This is enabled by an incredible amount of capital and pedigree. The pedigree you can get around by hiring the right people, but you can’t get around the fact it’s incredibly expensive to run these tests non-stop for years on end.

This is why there is really only one laptop manufacturer if you want reliability and performance. How do you get around this? Focus and capital.

Subscribe now

I need a software analogy to have my criticism of GD&T make sense, so bear with the following train of thought.

Computers were once programmed using zeros and ones. Programmers relied on physical switches, plugboards or punch cards to input instructions. This was eventually abstracted away with assembly language.

This evolved into low level languages like Fortran and C. Higher level languages like Java made this easier, and finally we received the highest level languages like Python which enabled more people to be able to write software.

I think GD&T is a low level language forced on multiple disciplines that don’t need to know it. This is at the heart of my issue with GD&T. It’s zeros and ones, not Python. Engineers think in tolerance analyses. Machinists and programmers think in surfaces and distances. Quality control thinks in terms of points in a coordinate system. In the middle of these departments stands a half century old standard.

What we need is an abstraction away from the standard that can be compiled into GD&T as required. At its highest level, the supplement should boil down to form and relation. In other words, “How much can this surface be away from its nominal definition” and “How much should the theoretical position of these surfaces be away from another relative position”.

My proposal is this: make GD&T the low level version of dimensioning and tolerancing that is compiled from and supplemented by the equivalent of a Python (high level language). This optionality makes it so that quality control gets what they want, the machinists get what they need and engineers can ensure everyone is going after the right goal posts.

Let’s call this abstraction GR — Geometric Relations. What would this look like? Let’s look at an example.

An engineer determines a bearing center needs to be within 2 thou radially of another bearing center within a part. This 2 thou is derived from a spreadsheet or some analytical tool. The engineer then defines the two surfaces locating this bearing as “critical” somehow within the tool of their choice (CAD, tolerance monitoring software, drawing software, etc.)

Here’s what this looks like in traditional GD&T:

Why is it this complicated? You could skip datums A and B, but QC or the machinists are going to ask for it eventually although they don’t need it.

We need a simplified solution that enables these teams to make their own decisions and end up at the same requirements.

What I propose is this:

[1] defines the cylindrical surface as datum 1. This creates a way to locate a series of surfaces (an axis in this case). This axis is a position. We reference this position for another axis.

It doesn’t matter what the datuming scheme of the part is, it doesn’t matter if it’s MMC or LMC, and it doesn’t matter whether the engineer and programmer agree on the best way to tolerance this relation.

The most experienced GD&T users will be quick to say “well, you can just do that”, but they’re negating the fifteen other reference frames that may have been generated prior to this relationship, and how they interact with this particular relation definition. Additionally - they’re neglecting the fact that the “proper” GD&T way to do this is even more complicated than what I provided, and requires generating a composite control frame.

It’s not lost on me that this essentially boils down to a simplistic way of making everything a surface and positional tolerance. I think that’s a feature (pardon the pun), not a bug.

At the end of the day, this relationship is defined abstractly away from GD&T. The engineer proceeds to designing the rest of their assembly and parts, meanwhile, maintaining key relationships with their parts as they will typically do.

When it comes time for documentation: do they use a drawing? Maybe not. Maybe they send a STEP file and the relations in MBD. Maybe the relations are “compiled” into GD&T and are in MBD or a drawing. Maybe it’s a secondary file in a JSON format that references specific surfaces that the CAD exporter took note of.

In the end - these relations are loosely defined, and that’s the point. Its ambiguity is its strength. It enables engineers to loosely define things for their tolerance analyses, and back into GD&T when specificity is actually required, which in many cases isn’t.

Just like optional types in Python or Javascript.

This isn’t perfect - there are many holes to patch up here (what if I want to reference multiple surfaces? etcetera). But I hope it’s enough to start a conversation about a supplement.

There’s an important note to make here - Cessnas are for private pilots and F-35s are terrible for that same customer. But the world needs F-35s (engineers in organizations which tend to be at startups or enterprise incubators).

What’s particularly difficult in engineering is that there is a tendency towards obfuscation as a defense mechanism. It isn’t just Academia - this paper showed that the more complicated an explanation for something is, the higher likelihood it is bullshit. We all subconsciously know this, but we are conditioned to be afraid to speak up and call out bullshit in public because it disproportionately requires more from the caller than the defender. This is where the Cessna engineer thrives.

Beware the confident and quick speaker. The best way to dismantle this flavor of nonsense is to hang on assertions and question them. You’ll notice their assertions or your disagreement are quickly disregarded.

The biggest problem with the Cessna engineer is that they are self-fulfilling prophecies. The lack of curiosity and attention to detail (or attention to the wrong details) create an endless personal development misdirection loop. Even more nefarious is the fact that at many organizations these distractions are the point of the job. There is no philosophy of our art, self reflection or self-criticism.

Look around your organization. It’s easy to spot the engineers that know five times as many tools to produce ten times as much.

For those in the physical engineering disciplines who don’t know what an API is (Application Programming Interface), it’s a way to provide some input (drawings) into a black box (manufacturing) and get an output (parts). In the world of software engineering, you can think of them as publicly callable functions that you can’t see into.

My assertion here is simple - drawings are a Manufacturing API. Engineers need a Machinist to cut metal into something, and the drawing is the API for that. The Machinists need a way to communicate back to Engineering that their ideas are bad, and bleeding on the drawing is the official API for doing that too (angry phone calls and cursing as a backup if the API malfunctions).

For an API, you don’t know what happens inside of the black box; you only know that your requests are fulfilled and when they aren’t you have to figure out what in your input is broken. This is a lot like manufacturing parts - if your parts come back incorrect it’s likely something went wrong in your input. Even when the manufacturing floor makes a mistake, it’s usually still your fault because a tolerance or feature was not correctly specified for quality control.

The power of thinking of drawings as an API is multifold:

Firstly, it’s a gentle reminder that drawings are a tool, and not the goal. Bad engineering organizations will hyper-focus on creating good drawings as opposed to creating good parts. This is bad.

Secondly, it frees the engineer to understand that it’s one tool in a toolbox of many. If you can get away with a STEP file and an email, then just do that. If you really need eight sheets of a drawing to explain your fifteen-datum scheme for a critical part, then do that. However, I do recommend looking into another profession if you’re relying on fifteen datums.

Thirdly, and most interesting to me, is that it frees us to think of new ways to advance our art forward - we embraced CAD decades ago and assumed drawings had to look as they always did. What is the next evolution? Does it involve GD&T? Does it evolve GD&T?

You can see this already playing out - I don’t really make drawings anymore outside of the office - SendCutSend, Protolabs and my CNC software takes STEP files as input without a need for drawings. It is exciting to think about what startups lurk in the shadows waiting to spring out of the idea that drawings may not be needed.

A final note on the black box analogy that I know will annoy some Engineers: I want to be clear that I understand there are cases where Engineers do want to control manufacturing process, and I would say that those cases are outside of the scope of the Drawing API (although you can specify process details within the drawing).

Philosophically, I know that it’s essential that Engineers deeply understand manufacturing processes and constantly seek DFM feedback, but Engineers should not be overextending themselves into a dictatorial relationship with Manufacturing. They have big hammers for use on both parts and wandering engineers.

So, there it is - Drawings are the Manufacturing API. What is the next one?

As a Machinist, part of your job consists of getting a part handoff from an Engineer (Jira, email, over-priced ERP system, etcetera).

This should be (but rarely is) enough to do the job. The handoff usually consists of a STEP file (3D geometry) and a drawing. If your engineer is really good, you don’t actually need the drawing because they will know the reasonable (three sigma RSS) tolerances of your machines and processes and design their assemblies such that they don’t need a ten micron profile tolerance on a spline surface.

So then, if your engineers are really good and your data pipeline is too, what purpose do drawings serve?

MBD Isn’t Real

Before continuing, I want to explain that I understand MBD does solve some of the challenges listed below, but MBD is not real because it is paywalled even inside of paid for CAD (paper/pen does not require licensing) and for that reason is not reliably usable.

If you do not believe this point, I challenge you to purchase a single seat of the base version of any CAD package, send a model containing MBD to a contractor, and have them redline it and send it back to you with feedback.

What are Drawings For, Then?

Before presenting what I really think drawings are for, let’s look at what they’re useful for outside of the “main use”:

1. Material Specification - STEP files don’t tell you what the part is made out of

2. Finish Specification - same as #1

3. Notes - outside of material, there are a million call outs you may want to include in a drawing to convey important information about the part

4. Taps/Thread Sizes/etc. - MBD can do these, but, again, it’s unusable

5. Redlining - it’s still the preferred method for engineers and machinists to communicate with each other outside of CAD

6. Tolerances - STEP files do not contain tolerances

7. Raw Material - overall dimensions with +/- tolerances on the part will be included so that the portion of the shop that cuts the raw material down prior to machining will use it to provide the billet to the machinist

8. Interoperability - you don’t need a computer to read paper. PDFs are now openable with any modern computer

This is a longwinded way of saying “They’re an API”.

What are Drawings Really For?

They’re really just contracts. If you can solve the use cases above (which MBD purports to do) then the drawing becomes the contract between the engineer and the machinist. I know many engineering houses where parts are submitted via Jira tickets and they will contain nothing more than a STEP file and a material call out in the ticket.

Most importantly, in cases where the part is made out of house, it becomes the legal contract between the customer and the vendor. If your drawing says you need a hole in your part to be 1/4” +/- .005”, and the hole comes back as a 1/4” + .01” for a thousand parts, you are not culpable when you don’t pay the vendor (secondary agreements aside).

In terms of liability, they can and will end up in court as evidence.

When you look at drawings through the lens of “these are the terms of our handshake”, they start to make more sense. It is through that lens that you can see why it will be a very long time (decades) before we see MBD replace drawings.

I realized eventually in my career that there were tasks required of my job that made me a worse engineer. It took some time to realize this counter-intuitive fact.

I want to explain what things you do that can make you a bad engineer, and how to avoid or mitigate them.

What Qualifies Something as Part of The Job vs. Engineering Skill?

There are two criteria for defining a skill for engineering - transferability and whether the skill helps you make The Product. There is a philosophical question of why “The Product” is different for each company which isn’t in scope for this article.

In general, skills that are a nuance of a particular organization are not engineering. They do not transfer. They may look like engineering, they may quack and have feathers like engineering, but they are not engineering.

Learning a niche software that has custom functionality that you will never use outside of that organization is not an engineering skill. However, if using the tools taught you a nuanced and relevant analysis that you can carry on to tasks outside of that company, you’re developing an engineering skill.

Assumptions

Comments on “broken” or “bad” cultures or organizations

are purely in the sense of their engineering ability for this article. Whether or not the organization is morally “good” or worthwhile is another topic.

What are the traits of a “Broken” engineering organization?

A broken organization:

1. Pushes decision making upwards hierarchically in the organizational structure

2. Encourages or rewards design by committee

3. Treats documentation as a tool for decision making and not for enabling other engineers to make decisions

4. Has artifacts become proxy for the work

5. Does not put effort into growing the technical skills of its engineers

6. Abstracts products into tasks that aren’t performed and owned by a single individual

These do not require proof - it’s given that the opposite would grow engineers and make your organization more effective in an engineering sense.

If you Work for a Broken Organization, You’re Likely to Break

but if you work for a great organization, you’re more likely to become great. Neither are given, but this is true more often than not. For the rest of this article, this is called the “Abyss Principle”.

This means if you are doing Stupid Things™, you will get very good at Stupid Things™. Getting good at and doing Stupid Things™ makes you a worse engineer because:

1. You spend less time getting better at doing and increasing your skill in engineering

2. You’re constantly increasing your tolerance for Stupid Things™

3. In some cases the decision making in doing Stupid Things™ is in opposition of good decision making in engineering, training you to be bad

4. Skill entropy outweighs your skill development and you worsen

Jobs are a Series of Tasks

You aren’t paid to write email, you’re paid to write email where you understand how and why the part failed the supplier outbound quality checks, and make the decision as to whether or not the failure is okay. Writing email is one of thirty tasks required in that sentence — writing email, checking drawings, running your tolerance analysis, checking yield stress against allowables, etc. Email is a sub-task of a larger task (getting your part delivered), because tasks can contain tasks.

Every role can be thought of this way - from a machinist to the CEO. Responsibility, scope, and the tasks will vary, but we are just task machines with egos.

Broken organizations focus on Stupid Things™

as a way of creating their products. All organizations do Stupid Things™ at times as a necessary evil, but at some point the percentage of these tasks relative to your other tasks pushes you into the broken organization column.

Skill Entropy

Every day you clock out, you lose a percentage of your skill. This is “Use it or Lose it”. If you spend a decade not performing the tasks required of a technical role, you will either lose the ability to perform those tasks, or performing them will be slow enough to be as though you never knew how to do them in the first place.

This means that living in total orthogonality on the Task Vector Chart means you’re actively becoming worse. The only way to counter this is to do technical work.

The Task Vector Chart

My belief is that all tasks can be charted in a way to tell you if what you’re doing is a Stupid Thing™ or not. Here’s how:

Make a chart where the X axis is engineering skill, and the Y axis represents the non-technical and engineering irrelevant portion of the skill required for a task. In reality, a task is a high-dimensional vector where each task vector projects a single vector into many skill components — see the email example above.

This chart plots vectors that represent the task (interference check) in question and what portion of it is making you a better or worse engineer. Any vectors between 0 and 89 degrees contribute to you becoming a better engineer, and any vectors between 91 and 180 degrees contribute to you becoming a worse engineer per the Abyss Principle.

Positive Directionality

Good tasks require engineering skill and discipline and chart high on the X axis. In this example, this is an almost purely engineering skill related task (analyzing a part that requires high stiffness yet isn’t brittle and requires a commonly available alloy). This requires mechanics of solids, understanding of analysis tools (FEA or software engineering), CAD, physics, mathematics, etc, all the way to completion.

Some tasks are not particularly technical, but still chart positive on the engineering skill axis. For example - an RFQ is just a document, but buried in it are some of the most important skills an engineer needs to make The Product.

Managing vendors is critical. Bargaining with, motivating and managing your vendors is essential to making something, especially if it is new. So, despite not being outwardly appearing technical, this skill is critical to your engineering development and is one you should relish.

Let this example serve as a reminder to not become spoiled when considering tasks on the chart. One can’t just point at the chart and say “that’s not technical”. There is a wide gradient of gray area.

Orthogonality

Tasks that do not make you a better engineer, but don’t pull you into bad decision making territory are at 90 degrees.

I chose expense reports specifically because they are required of the business, but are not of the engineer. They will eventually be automated away, like many things have for engineers (making drawing copies, etc).

The surprising thing is how much of our work lives in this area. Things that would seem like engineering work (a majority of our day in some organizations) are actually close to orthogonal and are not contributing to your engineering skill development.

Negative Directionality

Worse than engineering skill orthogonality are tasks that make you a worse engineer.

Writing a ten page document that neatly, clearly and concisely outlines your recommendation to choose Aluminum 6061-T6 over 5052-H32 sounds technical, and it is to some degree, but the amount of time spent preparing that documentation outweighs the benefit. Even worse, if you’re creating a ten-page document on a decision that should be relatively menial compared to the rest of your workload, it’s likely you’re pushing decision making higher up the hierarchy and this is a Stupid Thing™.

Most engineering tasks of the modern world live in the semi-orthogonal or negative directionality purgatory. It is one of the greatest challenges of engineers of the past few (and next few) decades until we can trick LLMs into doing our busy work for us.

Note that writing good (and not wasteful) documentation would be slightly X positive (not negative or orthogonal) because writing documentation about a thing makes you understand it better. If that’s all you do, it’s a problem, but if you’re documenting things so that another engineer can do their job well, you’re contributing to the art and this is a net skill positive.

What do you do if The Job is Negative Directionality?

Hire and Grow Junior Engineers

Part of being a junior engineer is doing the work that the seniors don’t want to do — this is how they learn the basics. This has the secondary effect of forcing a senior engineer to think through tasks to ensure they’re really encouraging the juniors, and not just pushing busy work. It acts as a lighter form of the next recommendation:

Have Mechanisms to Remove Stupid Things™ (Unlikely)

I’m writing this despite it being borderline impossible to implement in an organization unless you have a dictatorial type rule over it (which you probably don’t). Stupid Things™ (aka Process) tend to have a Stockholm Syndrome component to them. Over time, people will feel comfortable with and protective of Stupid Things™ and they will fight against their removal.

It’s likely pointless to fight the organization you’re in.

Automate (you probably can’t)

Most engineering tasks can’t be automated. If you’re a Civil PE, you can’t stamp something you didn’t review. It’s that simple.

I implore you to find the things you can automate, but they will be difficult to find.

Quit (Not a quick solution)

The usual best path. You can’t fix broken organizations from the bottom up.

Find a good engineering organization. There are ways to check for this in the interviews. I’ll write something about this soon.

I Can’t Quit?

Most of the time you can’t just quit, but while you’re looking for a new job, I recommend pursuing your skills outside of work. The good news is that I’ve found entropy to be a small fraction of the knowledge I gain in a single hour of post-office engineering. A couple hours a week will keep you sharp.

Summary

This matters. Stay sharp. Don’t fall into the trap of gladly being a high performer at a Stupid Things™ organization because you will develop bad habits, worsen your skills and ultimately make yourself toothless for when the time comes that you need to operate outside of it.

You can be a high performer, but it will take conscientious effort to not diminish your abilities. Take the time to recognize Stupid Things™ and how you can counteract them.