Hardware development's biggest problem is not engineering. It’s communication.

Hardware development's biggest problem is not engineering, it’s communication.

10 engineers → 45 connections

20 engineers → 190 connections

30 engineers → 435 connections

Every time you 3x your engineering organization, you 10x the number of connections (Metcafes Law)

Engineering used to be single player (one person on CAD), then it became multi player (CAD Engineer, Sim Engineer, Electrical Engineer). Now it’s multi-disciplinary. Systems are now so complex that the tiniest change in one engineers excel power budget model, effects a CAD engineers design, effects a sim engineer’s boundary conditions, effects the multiphysics model, which the breaks a mission critical requirement.

Most teams are still relying on word of mouth, slack, email and design reviews. The moment you cross 10 engineers, and don't have a solution to this, its hard to build important things.

How do you solve this?

The answer is iteratively.

Iterate your communication system at the same speed you iterate your product (or in reality, org chat).

This is a hard problem, how do you think about configs, variants. Do you group by function (analysis, structures, systems) or by products (Gen 1, Gen 2, Gen 3). How do you enable teams to move fast in thier bubble (engines, powertrain) but stay deeply connected to changes that may effect them.

The system that works at 30 people one team, won’t scale to 100 people with 5 teams, it doesn’t scale to different functions (analysis, systems etc) and it doesn’t scale to multi program.

We’re privileged enough to be working with the fastest growing important automotive, robotics, nuclear, space and defense companies globally. If you're growing from 10 → 50, 50 → 100, or 100 → thousands – we'd love to hear how you're solving this!