Cross-Functional Design Reviews That Actually Worked
How aligning mechanical, electrical, and firmware engineering early helped us reduce redesigns, shorten decision cycles, and build a more reliable product.
Introduction
Most engineering problems don't belong to a single discipline. A mechanical engineer designs a bracket that blocks a connector. An electrical engineer relocates a PCB and shifts the product's center of gravity. A firmware engineer bumps up a sensor's sampling rate and suddenly exposes mechanical vibration that was invisible before. Every one of those decisions makes sense on its own. Put together, they can create problems none of the individual teams saw coming.
Working on Everbowl, we realized a lot of our biggest headaches weren't from bad engineering. They came from engineering in isolation, where something that worked fine in one domain quietly created a constraint in another.
So we stopped treating design reviews as milestone check-ins and started running them as actual collaborative sessions, with mechanical, electrical, and firmware all evaluating major decisions together. The payoff wasn't just fewer meetings. It was fewer redesigns, faster decisions, and a product that came together a lot more smoothly.
The problem: local optimization creates global problems
Early on, each subsystem moved forward on its own. Mechanical focused on enclosure geometry, structural integrity, and manufacturability. Electrical optimized PCB layout, sensor placement, and power distribution. Firmware worked on sensor processing, calibration, and communication. Each team was doing good work within its own lane.
The trouble showed up at integration. A mechanical change would ripple into PCB packaging. PCB routing would push back on the enclosure design. Firmware requirements exposed limits in where sensors could actually go. None of this showed up in a single CAD model or schematic on its own. It only became visible once the whole product came together.
The lesson was simple enough: a product can only be as integrated as the communication between the teams building it.
What changed in our design reviews
We stopped reviewing finished designs and started reviewing design intent. Instead of asking "is the enclosure finished?" or "is the PCB complete?", we asked how a change would affect assembly, whether firmware could actually calibrate around a given tolerance, whether a mounting position would mess with cable routing, whether servicing would get harder, and whether a structural change would touch sensor performance.
The conversation moved from approving finished components to understanding how things actually interact.
Mechanical decisions that needed electrical input
A recurring example: where to put the load cells. Mechanically, that placement was simple enough on its own. But moving them shifted PCB routing length, cable management, connector accessibility, ADC placement, and noise susceptibility, all at once.
Later, when we integrated the ADCs directly onto the load-cell PCBs, what looked at first like a pure electronics improvement actually needed new mounting geometry, different fastener locations, modified structural brackets, and updated assembly steps. Without the early back-and-forth, each of those would have kicked off its own separate redesign cycle.
Electrical decisions that changed mechanical design
It ran the other way just as often. Connector orientation would affect enclosure wall thickness. Component height would eat into internal clearances. USB access would shape the external geometry. Sensor locations would dictate where mounting features had to go.
A PCB is never "just electronics." Its dimensions, connectors, thermal behavior, and servicing needs all become mechanical constraints the moment it's designed. Catching that early saved us several enclosure revisions later on.
Engineering insight: In hardware, every PCB is also a mechanical part, every bracket has an opinion about the electronics, and every firmware algorithm is quietly assuming something about the physical system it's running on.
Firmware revealed problems no CAD model could
Some of the most useful feedback in the whole project came from firmware. Bumping up the sensor sampling frequency exposed measurement instability that had been invisible at slower rates: more measurement noise, small baseline drift, more sensitivity to vibration.
Our first instinct was that it was a software problem. Digging into it with the mechanical team showed the real cause was structural: a small amount of flex in the load-bearing frame allowed tiny movements that only became visible once firmware was sampling fast enough to catch them. Instead of filtering the signal in software, we stiffened the structure and made the mounting more consistent, which gave us better mechanics, simpler firmware, and measurements we could actually trust.
Faster decisions through shared context
A benefit we didn't expect going in was how much faster decisions got made. Before, a design question would bounce from mechanical to electrical to firmware and back to mechanical again, and every one of those iterations ate into schedule. Once all three disciplines were in the room from the start, most questions got resolved in a single discussion.
Here's roughly what that looked like across the project:
| Metric | Early development | After cross-functional reviews |
|---|---|---|
| Average design decision cycle | ~5–7 days | ~1–2 days |
| Major redesign iterations | 6 | 2 |
| Assembly-related design changes | Frequent | Occasional |
| Integration issues found before prototype | ~40% | >85% |
These numbers are specific to how our process changed over time, not an industry benchmark. The improvement came from everyone sharing the same understanding of the problem, not from adding more meetings.
Reviews became system reviews, not discipline reviews
As Everbowl matured, our review checklist changed shape too. Instead of asking discipline-specific questions, we started reviewing every change from a systems perspective, checking mechanical (does this affect structural stiffness? can it be manufactured consistently? is assembly intuitive?), electrical (will routing stay reliable? is servicing still possible? does connector access improve?), and firmware (does calibration change? are we introducing new error conditions? can software compensate if it needs to?) all in the same session.
A design wasn't considered done until all three had weighed in, and that alone cut down on a lot of downstream surprises.
Why this worked
It wasn't longer meetings that made the difference. It was asking different questions. Instead of defending their own piece of the design, each team started thinking about the product as a whole: mechanical engineers thinking about calibration, electrical engineers thinking about assembly, firmware engineers thinking about structural behavior.
The conversation shifted from who owned which component to who was responsible for how the whole system performed. That shift cut more redesign effort than any single engineering improvement we made.
How this shows up at Hoomanely
Building Everbowl reinforced how much cross-disciplinary collaboration actually matters. A lot of the improvements to manufacturability, sensing accuracy, and reliability didn't come from any one team working in isolation. They came out of conversations between mechanical, electrical, and firmware. Treating every design review as a system review let us catch integration problems early, cut unnecessary redesigns, and end up with hardware that actually worked as one cohesive thing. That's still how we approach reviews on everything we build now.
Key takeaways
- Hardware products tend to fail at the interfaces between subsystems more than inside any single component.
- Cross-functional reviews catch integration issues before a physical prototype exists.
- Mechanical, electrical, and firmware decisions need to be evaluated together, not passed sequentially down a line.
- Shared context cuts down on redesigns and speeds up decisions.
- Firmware often exposes mechanical limits that static analysis alone won't catch.
- Good design reviews optimize for the system, not for one discipline's piece of it.
Conclusion
One of the more valuable changes we made on Everbowl wasn't a new material or a different sensor. It was changing how we ran design reviews. Bringing mechanical, electrical, and firmware perspectives together early turned integration problems into design conversations, instead of letting them surface as production problems later.
Well-engineered products rarely come from one discipline doing exceptional work in isolation. They come from every discipline understanding how its decisions land on the others. The most useful design review isn't the one that signs off on a component. It's the one that actually makes the system better.
