Stop Building in Single File
Systems Thinking

Stop Building in Single File

Ford's Long Beach skunkworks revealed a manufacturing heresy: stop doing things in order. The mental model underneath — sequential vs. parallel process architecture — applies to every business that's ever wondered why everything takes so long.

There's a manufacturing heresy gaining traction right now, and it has nothing to do with robots or AI or any of the things LinkedIn would like you to believe are transforming industry. It's simpler than that. Ford just invited journalists into a skunkworks facility in Long Beach, California, where a team of 350 engineers showed them a car split into three segments on a screen, each segment designed to be built at the same time instead of one after the other. The most radical idea in the room wasn't a battery chemistry or a software platform. It was the suggestion that maybe you don't have to do things in order.

In business, the pattern I see most often isn't a lack of talent or capital or ideas. It's an addiction to sequence. Step one, then step two, then step three. It feels logical, it looks organized on a whiteboard, but it creates a hidden tax on everything you do. Every step waits for the one before it. Then every delay compounds. Eventually every bottleneck becomes the entire organization's bottleneck. I think most companies are running sequential architectures without ever making a conscious decision to do so, and the cost is staggering.

The Assembly Line Trap

Henry Ford's original assembly line was a masterpiece of sequential thinking. One car body moved through every station in order, each worker adding their piece before passing it to the next. For 1913, this was revolutionary. The problem is that most organizations in 2026 are still running some version of this model, not just in manufacturing but in how they develop products, make decisions, close deals, and ship work.

Sequential architecture has a seductive logic. It's easy to understand, easy to manage, easy to draw on a slide. But it carries a structural flaw that gets worse as complexity increases: your total cycle time is the sum of every step. If you have twenty steps and each takes a day, you're looking at twenty days, and that's before anything goes wrong. When something does go wrong at step seven, steps eight through twenty sit idle. The line stops.

What Ford is doing in Long Beach is splitting that line apart. Instead of one body rolling through every station, they're building the front, the cabin, and the rear of the vehicle on separate parallel lines, then merging them in a final assembly step. The result, according to Ford's own numbers, is 20% fewer parts, 50% fewer cooling hoses and connections, and assembly that's 15% faster than their previous process at the Louisville plant. Tesla has been working on something similar with their "unboxed" process, designing vehicles to be assembled in parallel modules rather than sequentially on a single line.

Where This Actually Matters

The manufacturing story is interesting, but the mental model underneath it is what I think is much more important. Sequential vs. parallel process architecture isn't a factory concept. It's an organizational design choice that shows up everywhere.

I've seen sales organizations where every deal has to pass through the same six approval gates in order, creating a bottleneck at gate three that nobody can explain except that it's always been gate three. I've worked with companies where the marketing team waits for the product team to finish the spec, then the design team waits for marketing to finish the brief, then engineering waits for design to finish the mockups, and by the time anything ships the market is about to move again.

The fix isn't that complicated. Just look at your process and ask: which of these steps actually depend on the one before them, and which ones are sitting in line out of habit?

Most of the time, the answer is uncomfortable. A surprising number of steps are sequential because that's how someone set it up years ago, not because there's a genuine dependency. The approval that has to happen before the vendor gets called. The strategy document that has to be finalized before anyone builds a prototype. The budget sign-off that has to clear before the hiring req gets posted. Half of these gates exist because someone once got burned and added a checkpoint, and nobody ever asked whether the checkpoint was worth the wait.

The Merge Problem

Now, parallel architecture isn't free. Ford's Long Beach facility exists specifically because parallel manufacturing creates a coordination problem that sequential manufacturing doesn't have. When you build three sections of a car at the same time, they all have to fit together perfectly at the merge point. That requires tighter tolerances, better communication between teams, and a shared standard that everyone builds to.

This is the part most people skip when they get excited about parallel work. Going parallel without solving the merge problem just creates three messes instead of one. Your autonomous squads are only as good as your integration point planning. Poor planning and you get speed in the middle and chaos at the end.

Ford solved this by putting everyone in the same building, using megacasting to reduce the number of parts that have to align, and running rapid prototyping cycles where they can test fit in days instead of weeks. The principle translates directly: if you're going to run parallel, you need to invest heavily in the interface between the parallel streams. Shared standards, clear integration points, frequent check-ins at the merge. The coordination cost is real, but it's almost always cheaper than the tax of time when working sequentially.

Going Deeper

The deeper insight from Ford's approach isn't about speed. It's about optionality. When you run sequential, a change at step three means redoing steps four through twenty. When you run parallel, a change in one stream only affects that stream, as long as the interface contract holds. You can iterate faster because the blast radius of any change is smaller.

I think this is why the best business operators I know, the ones who consistently ship faster or adapt quicker, have an instinct for decomposition. They look at any project and immediately start asking what can run at the same time. Not because parallel is always better, but because the act of asking forces you to understand your real dependencies versus your assumed ones.

Ford's Long Beach facility is interesting not because it's new technology. Parallel manufacturing has existed in some form for decades. It's interesting because a 122-year-old company looked at its most fundamental process, the one that put them on the map, and asked whether it still made sense. Was the sequence a conscious choice or just an inheritance? That's a question worth stealing.

Keep building,

-- JW