Good Decisions, Wrong Order

Sit through enough hardware program post-mortems and a pattern emerges. The team is competent. The reviews were held. The reasoning was documented. And somewhere in month seven, a decision made in month two starts costing money. Tooling estimates come in high. A mount envelope won't work with an enclosure that was locked in the spring. A compliance requirement arrives after the geometry did.

The conversation that follows always sounds the same. Someone should have caught this earlier. Manufacturing should have been in the room. The requirements should have been tighter. The team gets a little smaller in its chair, the fix gets scoped and paid for, and the program keeps moving.

But nobody was actually wrong.

The industrial designer who chose that form direction was working from sound research and a valid brief. The engineer who inherited it made the best call available given what was already locked. The product manager who set the priorities was optimizing for the segment marketing was targeting. Every decision was defensible in isolation. The retrospective can't find the guilty party because there isn't one. Most rework in hardware development isn't caused by bad decisions. It's caused by good decisions made in the wrong order.

One clarification before going further, because the word carries baggage. Rework here means redoing design work. Unlocking geometry, rerunning decisions, paying for a second pass at something the team considered finished. It does not mean scrap and repair on parts coming off a line. Different problem, different cost, different fix.

Two kinds of rework

Look through this lens and rework splits in two, and the halves fail very differently.

Execution rework is local. The right constraint was resolved and the solution was mediocre. A tolerance nobody stress-tested. A snap geometry that needed one more iteration. A fastener choice that deserved a second look. These dominate the count in any given program, and most are recoverable inside the envelope you already have. You fix them, you move on, you get faster next time.

Ordering rework is structural. A decision made at rank three foreclosed something that turned out to be rank one, and the team didn't know, because rank one had never been named. Fixing it doesn't mean iterating on a part. It means climbing back up the stack, unlocking geometry, and rerunning decisions everyone considered finished. Fewer of these per program by count. Nearly all of the cost.

Any process that optimizes for reducing execution rework and ignores the ordering problem is optimizing the smaller of the two costs. That's the trap most hardware teams are in.

Go back to the enclosure

The enclosure locked in month two was the better enclosure. Cleaner, well-tooled, solved the problem actually sitting in front of the team that week. It also took the mount envelope off the table.

The premise is that four rules, applied at the right moments, prevent the expensive kind of rework.

Nobody had ranked mounting. Not every constraint restricts the others, but the ones that do, the ones that close doors the moment you commit, need to be named and ranked before any of them get solved, ordered by how much downstream freedom each removes. Everything else is a checklist, decidable in any order. Had mounting been ranked above form, the enclosure decision would have looked different the week it came up. Instead it looked free.

The decision went to whoever had the file open. Constraints have a natural owner, the discipline whose expertise is the sharper tool for that specific problem. On a real program that is industrial design for one decision, mechanical for the next, electrical for the one after. Lead should follow the constraint. Usually it follows the calendar.

It was evaluated as an enclosure decision. It was the best enclosure available, which was the wrong question. The question is which option keeps the most doors open for the problems still ahead. A solution that wins locally while foreclosing something higher ranked gets rejected, even when it is the better part.

And the person who owned the mount never saw it. Only the discipline that isn't driving can see what a solution just closed off on their side. Twenty minutes in month two. Tooling money in month seven.

None of this requires knowing the right order on day one. You can't. Foreclosure depends on the solution space you are still exploring, and that space narrows as the program runs. The first ranking is a Rev A, revisited as concepts firm up. A constraint moving from seven to three is not a miss, it is the process working. What matters is that the order is written down, so when it moves, everyone can see that it moved.

Why it isn't standard practice

None of the underlying ideas are new. Ranking by dependency, preserving optionality, front-loading constraint discovery. All documented, all taught. What isn't documented is how to run them on a team of twelve with one prototype budget.

Large organizations solve the ordering problem with systems engineering functions and formal dependency analysis. That infrastructure doesn't scale down. Nobody builds a dependency matrix for eleven constraints and five people, because the setup costs more than the ordering is worth. What makes it runnable at that size is a team small enough that confirmation is a conversation rather than a meeting, and enough programs behind you to rank foreclosure by judgment instead of building three prototypes to find out.

Two questions:

1. On your last program, when was the manufacturing process selected, before or after form freeze?

2. And which decision caused your last redesign?

Most people know both answers before they finish reading. If the process came second, and the redesign traces back to something locked before anyone thought to question it, ordering rework is happening on your programs. Not because anyone is doing anything wrong.