What I Learned About Software Delivery in a Manufacturing Culture

Roughly 10 years ago I was enrolled in a SAFe DevOps certification course where the instructor primed our excitement with an epic triumph of SpaceX's. The story went that during one of the first SpaceX dockings to the ISS, the team on the ground realized the guiding laser for the docking gear was millimeters off. They were able to triage, write the fix, test it, and deploy it to the spacecraft. In space. All in a matter of around twenty minutes.

I've never been able to confirm this story. It doesn't matter. The image stuck. Fast. Autonomous. High-stakes and high-trust. It was very invigorating, as a young engineer, to hear about such achievement, and since then, I have always aspired to build teams who can deliver like that.

Software That Ships on a Vehicle

The company who sponsored my SAFe DevOps certification, General Dynamics Mission Systems, is not a software company. It's a manufacturing operation where software is one component of a much larger system. The teams I worked with supported software, but oftentimes it was a complement to a proprietary hardware system or, in the worst case, deployed onto the hardware from another company. Usually this was a vehicle, sometimes shipped to the other side of the world. Delivery cycles were not measured in sprints. They were measured in months and years because the software could not ship until the physical thing it lived on was ready to move.

The culture of the company embodied this reality. Total Quality Management was a key framework for evaluating success. Documentation was thorough. Testing was rigorous, often pushing solutions to the edge of physical possibilities. If a defect made it downstream, it was extraordinarily expensive to fix, and oftentimes, led to a more serious casualty than "the website is down".

When I first arrived, I thought this was awful. I had been trained on the romantic ideal: lean startup, move fast, iterate, ship MVPs. General Dynamics felt like the opposite of all of that. Slow, heavy, overly cautious. It took me leaving and a few years of management experience to realize how structured engineering discipline protects the producer and consumer when consequences of failure are expensive and physically irreversible.

The Most Over-Engineered SharePoint Site I Ever Replaced

To their credit, the leadership at GD was acutely aware of the tension between manufacturing rigor and software agility. There was a genuine push to adopt faster, more iterative approaches in areas where the stakes of breaking were low, especially when prototyping. It was often the case that between program contracts, teams would spend short cycles contributing to internal tools, knowledge management, and process improvement. These were fair game for experimentation.

Around the time I joined the company, they had completed an acquisition of a highly competent AI startup, and while their program work was delayed, they were asked to modernize how the company handled internal contracting and proposal documents. Their proposal was solid: build an intelligent document repository where teams could quickly assemble the long, esoteric contracts that defense work demands.

The implementation, though, was on another level. Their tool was a web app: a React frontend with Redux for state management. The web app connected to a node.js middleware via websockets, which did pub/sub message exchange with a RabbitMQ instance, which in turn communicated with a C# backend that was performing shell commands for the IBM Rational Team Concert CLI to manage document lifecycles.

For less than fifty users.

The system was exceedingly brittle. Though it was well-designed for performance, the Redux store on the frontend had a highly rigid schema that required careful attending when updating across the platform (which, happened roughly 2 times per week). The frontend had features like a social media-esque notification system that nobody asked for and nobody used. The actual users (people assembling proposals) hated it. The primary stakeholder was a fellow GD employee who held a senior leadership position and everyone building the product was afraid of her.

She did not need real-time websocket updates. She just needed her teams to find the right boilerplate section and paste it into a proposal.

So, myself and one other developer replaced the entire system with a single SharePoint site. We designed a simple tagging schema so the team could categorize their documents. They tagged the files, searched them, found what they needed. Done. Everyone was elated.

I do not tell this story to criticize the startup team. They were brilliant, well-intentioned engineers, and they taught me a lot (and quite patiently) about building scalable software systems. But they optimized for technical sophistication instead of user outcomes, and the result was a system that impressed architects but frustrated everyone who actually had to use it.

Coordinating Teams of Teams

The other thing I learned from GD was operating at scale without chaos. One program I worked on involved five teams of ten engineers, all building components of the same large system (the SAFe Agile DevOps way). Once per quarter, everyone came together for a planning ceremony. Each team would build out a three-month delivery plan based on their goals, present commitments, and critically identify dependencies on other teams.

This was the part that mattered most. Teams surfaced dependencies ahead of time. If you failed to plan ahead, the coordination of the entire system would fall apart. It is the primary reason why common wisdom dictates you keep teams lean. But in manufacturing settings, you really don't have a choice. I remember thinking this was so dumb. Forty, fifty engineers in a room for multiple days making sticky-note kanban boards and then walking the room and placing notes on other teams' boards. There was always some expectation people would need you for something but as those expectations scale and teams wind up delivering more for other teams than their own commitments, tempers flare.

Famously, at the end of the last day of these planning meetings, everyone raises their hand with the number of fingers corresponding to their confidence in the plan (1 = bad, 5 = great). I, like most people, usually held up a tepid 3. One manager had been pushed so far past his team's expected capacity that he held up 2 middle fingers.

Years later, I moved to PHIL, a much smaller company, and discovered that this problem was actually worse with leaner teams. The discipline of proactive dependency management was more important with fewer people.

At a small company, you typically have a handful of people who understand the full platform, and everyone else holds niche domain knowledge. Those few experts become natural bottlenecks. Every team needs something from them, and there are only so many hours in a day. Without deliberate planning, delivery slows to the pace of the most constrained person on the team. I watched a two-week feature stretch to six because one engineer was the only person who understood a critical integration, and every team needed him at the same time. When that kind of bottleneck gets overloaded, quality errors start compounding downstream because reviews get rushed and context gets thin.

The quarterly planning ceremony from GD wasn't glamorous. It wouldn't make for a good conference talk. But the underlying discipline of identifying your dependencies before they identify you scales down just as well as it scales up. I've carried it with me to every team I've managed since.

What Manufacturing Gets Right

The romantic version of software delivery is the SpaceX story. Small team, full autonomy, incredibly fast, deploying to space in twenty minutes. That's the aspirational poster on every engineering blog.

But most teams aren't SpaceX. Most teams are shipping into environments with real constraints: organizational, technical, regulatory, human. They have dependencies they can't eliminate, users they can't control, and systems they can't rewrite from scratch. The manufacturing mindset doesn't pretend these constraints don't exist. It plans for them.

I still think about that SpaceX story. I still want every team I work with to be capable of that kind of responsiveness. But I've come to understand that the path to twenty-minute deployments runs through the boring stuff — quality standards, dependency management, user-focused design — not around it.

The best engineering cultures I've been part of borrow from manufacturing without being trapped by it. They take the discipline and leave the bureaucracy. They plan like the stakes are high and iterate like the cost of change is low.

That combination is harder to build than any architecture diagram. And it's worth more than all of them.