Why Design Reviews Break at 50 Engineers

There is a specific meeting that starts happening in hardware companies around 50 engineers. It's the one where eight people sit in a room, look at a schematic diff for forty minutes, and approve it — and the board comes back from the CM with the USB connector behind a plastic wall.

Nobody in that room was incompetent. The review process is incompetent. This is the failure mode: design reviews are a system for concentrating human attention on the changes that matter, and past a certain size, the system distributes attention exactly wrong.

What works at 10 engineers

At ten engineers, a design review is simple. There is one senior engineer — everyone knows who — who holds the whole product in their head: the schematic, the layout, the enclosure, the firmware bring-up sequence, and the CM's tolerances. When a change goes out for review, it goes to her. She knows that the connector on J7 can't move because the enclosure cutout was finalized last sprint, and she knows the firmware team's bring-up assumes the pull-up on that net.

This works because the entire product state fits in one person's working memory. The reviewer's job is pattern-matching against the full context of the design, and at small scale she has all of it. Reviews catch real problems. The cost is low: one meeting, a handful of comments, a sign-off.

Nobody designs this system. It emerges. Which is why nobody notices when it stops working.

What breaks at 50

Three things break at roughly the same time, and they reinforce each other.

Change volume. At 10 engineers, the review queue is a handful of diffs a week. At 50, every discipline is landing changes daily — mechanical refines the enclosure, electrical re-routes a section, firmware cuts a new bring-up build, manufacturing updates the BOM. No single person can review all of it with the same depth, so reviews either slow everything down or get shallow. Usually they get shallow, because schedule pressure always wins the argument nobody has out loud.

Cross-discipline interactions. Hardware is not four parallel projects. It's one product with four coupled surfaces. The failure cases here are so repetitive they have names in the industry: a connector moves a millimeter in ECAD and the cutout doesn't follow in MCAD — the USB port behind a wall. A standoff gets nudged in mechanical, the board arrives with mounting holes off the bosses. One PCB-focused analysis found that a company reviewing a year of respins traced over 60% of them to mechanical interference — ECAD and MCAD out of sync. The BOM changes without downstream teams knowing; firmware gets tested against the wrong hardware revision; the bring-up team debugs phantom failures for a week before anyone asks which revision the board actually is.

Each of these is a change that was fine inside its own discipline and wrong for the product. That's the key point: the defect lives in the interaction, and interactions are what scale quadratically. At 10 engineers the interactions fit in the senior engineer's head. At 50, they live in nobody's head.

Tribal knowledge leaves. The person who knew why that pull-up was there, why the enclosure can't be touched after week 30, why the CM hates the flex in rev B — that person leaves, or moves to another project, or just can't keep 500 new facts in their head. The rationale for past decisions evaporates. Reviews keep checking the rules everyone still remembers and stop checking the ones that left.

The meeting tax

The standard response to these failures is more process: a weekly cross-functional review, a sign-off sheet, mandatory attendees from every discipline. This is where the reconciliation tax starts compounding. Now eight people spend forty minutes looking at changes they mostly don't understand, because the meeting exists to synchronize four disciplines' worth of context in real time, and that is not a thing human beings can do in forty minutes.

So the meeting becomes a status check. Real issues get found the way they always get found at this scale — by the person who happens to notice something in their own domain, late, after the change has already propagated. The formal review adds cost without adding coverage. Everyone knows it. Nobody cancels it, because the last bad respin needs a corrective action, and the corrective action is always "more review."

Reviews that catch nothing

This is the end state: rubber-stamping. The review still happens, so the process chart looks healthy. Approvals still get recorded, so the audit trail looks healthy. But the approval no longer carries information. When a reviewer signs off on a diff they didn't fully understand, the sign-off is a liability reduction ritual, not an engineering act.

The uncomfortable part: this is not fixable by trying harder. Attention is the scarce resource, and the process as designed spends it on the wrong things — full-room walkthroughs of low-risk changes, while the cross-discipline interactions that actually cause respins get glanced at because nobody in the room owns them.

And even as AI-assisted design tools enter the picture, the industry's position is clear: production boards still require multi-engineer human sign-off. EEBench's analysis of AI-generated circuit boards concluded that human oversight remains essential before anything ships to production. The problem was never that humans are out of the loop. It's that the humans in the loop are being asked to review things the process gives them no way to actually see.

What a working review system looks like

A working system starts by admitting the constraint: human attention is finite, cross-discipline interactions are where defects live, and meetings don't synchronize anything.

Every change gets a computed blast radius. Before any human looks at a diff, the system should answer: what else does this touch? The schematic, the layout, the enclosure, the BOM, the firmware assumptions, the test fixtures. If the tooling already tracks the data — Git, the CAD tools, the PLM — the interactions are derivable. A review that starts with "this change affects these three artifacts in two other disciplines" lets a human reviewer aim their attention at the coupling instead of the change.

Review is gated by risk, not by ritual. Low-blast-radius changes get lightweight sign-off. High-blast-radius changes get the full cross-functional treatment — with the interaction map attached, so the reviewers aren't reconstructing context from memory.

Approvals stay human, but the proposal is automated. The working model is: agents do the tedious work of assembling the diff, tracing the impacts, and flagging the interactions; humans make the judgment call. Stop bad hardware changes before they ship — not by removing reviewers, but by giving them the one thing they don't have at 50 engineers: the full product context, computed, for this change, right now.

Nothing needs to be migrated to get this. The data already exists in the tools the team uses. A governed layer above the existing stack can read the diffs, compute the interactions, and propose the review package — no migration, no rip-and-replace. The teams keep their tools; the review system gets the context it never had.

The company that keeps scaling past this point isn't the one with the most disciplined reviewers. It's the one that stopped asking humans to do the machine's job of holding every interaction in memory — and started asking them to do the one job machines can't: judgment.