Series: Engineering Judgment, Part 2

Many engineering failures do not begin with bad execution. They begin earlier, when a path looks technically correct but cannot sustain the feedback loop required to make the system work.

That is why the stainless steel Starship story is useful far beyond aerospace.

The point is not to claim that stainless steel is universally better than carbon fiber. That would be the wrong takeaway. The useful lesson is that SpaceX changed the evaluation function: from asking which material looked most advanced to asking which material let the whole engineering system learn fastest.

Most teams say they want the best solution. In practice, "best" often gets quietly replaced by "most advanced," "most complete," "most elegant," or "most defensible in a review." Those are not the same thing.

In complex systems, the best solution is often the one that keeps the team inside a fast, honest feedback loop.

The Wrong Kind of Correct

Carbon fiber had an obvious appeal for a launch vehicle. It was advanced, strong, lightweight, and already associated with high-performance engineering. From a narrow materials perspective, the choice looked reasonable.

But engineering reality is rarely narrow. The material decision affected manufacturing speed, cost, repairability, test cadence, tolerance for failed prototypes, and the rate at which the whole organization could learn. A material can look superior on a single technical axis while making the overall system harder to iterate.

This is the trap of technical correctness.

A decision can be correct inside one frame and wrong inside the system that has to absorb it.

Software teams make the same mistake constantly. They choose a sophisticated distributed architecture before the product path is stable. They introduce a generic abstraction before the concrete use cases are understood. They pick a powerful framework that slows local debugging. They design for an imagined future scale while the present system still cannot be shipped safely.

None of those choices are necessarily bad in isolation.

They become bad when they move complexity into the part of the system that needs feedback most.

The Feedback Loop Is the Product

Engineers often evaluate a proposal by asking whether it is more advanced than the alternative. That question is too small. The better question is: what feedback loop does this decision create?

If a choice makes the first version slower, failures harder to interpret, changes harder to isolate, or recovery harder to perform, it may be damaging the system even if it improves some local metric.

In a complex project, feedback is not a nice-to-have. Feedback is the mechanism by which the team discovers what the real problem is.

Prototypes, staging, observability, and rollback are not operational accessories added after the "real" design. They are part of the design because they determine whether the system can learn.

The strongest engineering systems are not the ones that start closest to the final answer.

They are the ones that can survive being wrong and correct themselves quickly.

The Software Version of the Same Mistake

The same pattern appears in software with less drama and more meetings.

A team starts with a real need: serve multiple customers, improve reliability, support a new workflow, reduce latency, or make the system easier to operate.

Then the solution space expands.

Instead of solving the immediate constraint, the team starts designing a platform. Instead of supporting the known workflow, it builds a generic model for every future workflow. Instead of reducing risk, it introduces a new technology because the new path looks cleaner.

The design becomes more impressive, and the feedback loop becomes slower.

At first, this feels like rigor. The team is thinking ahead. It is avoiding future rework. It is building something "proper."

But if the system cannot produce a working version, reveal errors, and support correction, then the rigor is mostly theater.

The real test is whether the system can move one step forward without losing control.

Complexity Has to Live in the Right Place

There is a point here that is easy to miss: the question is not whether a solution is complex, but where the complexity lives.

Complexity in the core execution path is expensive. Complexity across module boundaries is expensive. Complexity in recovery logic is expensive. Complexity in areas that are hard to test is especially expensive.

But complexity inside a clear boundary can be acceptable. A difficult algorithm inside a replaceable component is different from difficult behavior spread across the entire architecture. A complex subsystem with strong ownership, tests, and rollback can be managed. Hidden complexity across layers cannot.

Good engineering does not eliminate complexity. It contains it.

When a team chooses a technical path, it is also choosing where future complexity will accumulate.

That location matters more than the elegance of the diagram.

If the complexity lands in a place where the team can isolate, test, replace, or delete it, the system can keep evolving. If it lands across ownership boundaries, deployment paths, state transitions, and failure recovery, every later change becomes more expensive.

This is why a less advanced option can be the more mature engineering choice: it may keep complexity in a place the team can control.

The Scarce Resource Is Not Cleverness

Most capable teams have enough cleverness.

What they lack is stable iteration capacity.

Can they produce a working version quickly?

Can they discover what is wrong?

Can they repair it without breaking the whole system?

Can they repeat that cycle without exhausting the team?

If yes, many imperfect initial decisions can be corrected.

If no, even a sophisticated initial design becomes fragile. Every mistake becomes expensive. Every uncertainty becomes political. Every change requires a meeting because nobody trusts the system to survive movement.

Some unimpressive-looking decisions age well because they preserve the ability to continue.

A Better Review Question

When a design looks clean on paper, the review should move past the usual adjectives. Optimal, scalable, complete, and architecturally clean still matter, but they are second-order if the team cannot learn from the system it is about to build.

A more useful review asks:

  • Can we build this reliably with the team we have now?
  • Can we ship it in stages?
  • Can we observe whether it works?
  • Can we roll it back?
  • If it fails, can we locate the failure?
  • Does it keep the main path simple?
  • Does it place complexity inside a boundary we control?
  • Will it speed up or slow down future learning?

These are less glamorous than comparing technical purity. They are also closer to what determines whether the project survives.

The most important engineering decision is often the one that keeps the system alive long enough to learn.

Stage Matters

Many "better" solutions are simply early.

A distributed architecture may be right later. A generic platform may be right later. A more advanced runtime may be right later. A deeper abstraction may be right later.

But if the current system has not yet stabilized its main path, those choices can pull the team away from the thing it most needs: a running system that can be observed and corrected.

Stage is not an excuse for low standards.

Stage is how standards become actionable.

At one stage, the correct decision is to reduce options and preserve velocity. At another stage, the correct decision is to invest in abstraction and long-term structure. The same technical path can be irresponsible in one phase and necessary in another.

This is why engineering judgment cannot be replaced by a ranking of technologies.

It depends on timing, team capacity, failure cost, and the feedback loop the system needs next.

The Lesson

The stainless steel Starship story is not an argument for always choosing the cheaper material, the simpler tool, or the less ambitious path. It asks us to judge decisions by the learning loop they create.

Sometimes the "better" solution is worse because it slows the system down before the system has learned enough. Sometimes the less elegant path is the more serious path because it lets the team build, test, fail, repair, and continue.

Engineering maturity shows up in the option that can survive the next hundred corrections.

Finding a perfect answer matters less than keeping the system capable of reaching a better answer later.

References