On most hardware programs, industrial design works up a direction and then hands it to engineering to make buildable.

Nobody decided that. It isn't in anyone's process document. It's a default — residue from two professions trained separately and hired separately — and it holds even on teams where both disciplines are in the building and get along.

Plenty of programs run a worse version of it. Industrial design isn't early in the sequence at all; it's called in near the end, once engineering has a working solution, and asked to make it look finished. Surface treatment, a color break, a logo placement. By then the proportions are set, the split lines are where the tooling wanted them, and the parts a user actually touches were shaped by what was convenient to build. There's real work to do at that stage, but it's decoration, not design — and it's common enough that a lot of teams don't know there's another way to run it.

The handoff is where intent gets lost. That's the familiar complaint, and it's true. It's also the smaller problem.

The larger one is that a fixed sequence means whichever discipline goes first ends up answering questions that belonged to the other. A thermal path, a load case, a mount envelope - decided implicitly by whoever was holding the file when the geometry firmed up, weeks before the person who actually owns that constraint ever sees it.

The pen moves

Every constraint has one discipline whose expertise is the sharper tool for it. Not more senior, not more important. Sharper for that specific problem.

Mount envelope, load case, thermal path: mechanical leads. Grip, sightline, control layout: industrial design leads. Board-to-enclosure fit, connector placement: electrical leads.

And sometimes it inverts in a way nobody expects. On a program where the internal layout has to serve the hand before it serves the trace, industrial design can hold the pen on board topology - working out where components need to sit for the ergonomics to work, then telling electrical what footprint to build around. That isn't ID overstepping. It's ID holding the constraint that ranked first.

Which discipline leads changes a dozen times over a program, and the pattern is different on every project. What stays constant is that lead follows the constraint — not the calendar, and not the org chart.

The other discipline isn't absent. They co-author the same artifact from different expertise, and they confirm before anything advances. But one of them holds the pen, and it should be the right one.

Driver or contributor

The same distinction shows up in how teams hire outside help.

A driver takes the pen when the constraint is theirs. They push back on a brief that frames the problem wrong, surface the conversation internal politics has been deferring, and hold intent through manufacturing. A contributor produces deliverables on request and waits for the next ask.

Both have a place. The mistake is hiring one when you needed the other, and the cost shows up in the product.

But the distinction isn't really about the vendor. It's about whether the program has a rule for who leads. A team without one will turn a driver into a contributor inside two months — not deliberately, but because there's no moment when the pen is supposed to change hands, so it never does.

Who decided

On your last program, who decided the board outline?

Not who drew it. Who decided it. And was that the discipline whose expertise was sharpest for the constraint the outline was actually serving — or was it just whoever got there first?