Stage gates get a bad reputation in teams that have only experienced them badly. When a gate exists to satisfy a reporting requirement, it adds overhead without adding value. When a gate exists to force a genuine cross-layer alignment review before a costly commitment, it prevents the expensive mistakes that are otherwise discovered at integration.
The difference is in the gate definition. A gate defined as "review complete by date X" is a milestone. A gate defined as "the following conditions must all be true before proceeding" is a decision point. Decision points are what stage gates are supposed to be.
Why Hardware Needs Gates That Software Does Not
Software can be redeployed in minutes. A PCB respin is a four-to-six week cycle, a non-trivial cost, and a supply chain dependency. This asymmetry means that the standard agile principle of deferring decisions until the last responsible moment does not transfer cleanly to hardware. In software, the last responsible moment for many decisions is late, because reversal is cheap. In hardware, the last responsible moment for a PCB layout decision might be week two of a six-month project.
Stage gates encode when certain decisions must be made by. They are the mechanism that prevents teams from deferring hardware decisions past the point where they can be reversed cheaply.
Gate Conditions, Not Gate Milestones
A well-defined gate has conditions that must be true before the team passes through it. Not "firmware development complete" but "firmware specification reviewed and accepted by electronics team" and "interface between motor driver and firmware control loop tested at the specified operating temperatures."
A team can build excellent firmware against an incorrect assumption about what the sensor will deliver. The firmware is complete. The system is not ready. A gate that checks firmware completion passes. A gate that checks firmware-sensor interface validation does not.
Every gate condition should name the layer it tests, the specific claim it validates, and the evidence required to pass. "All four layers aligned" is not a gate condition. It is a wish.
The Irrigation Project: A Gate That Held
On the wireless irrigation control project, the architecture-to-prototype gate almost did not pass. The firmware team had built their module against a valve interface specification that had changed in the mechanical layer without the update being propagated. The gate review caught it. Three days to reconcile the specification. The alternative, discovered at prototype integration, would have been a firmware rewrite and a potential valve redesign. The gate held. The project did not slip. That is the value of a gate that is a genuine decision point with real conditions.