Joe Justice: Conway’s Law, Modules, and Experiments (Part 2)

Develop, test, and build a new module in 30 days? For the first time? According to Joe Justice, this is a good first experiment for companies that want to explore Agile Hardware in more depth.

This is the second and final part of the summary of the interview with Joe Justice on the topic of speed (To the first part). Even though the terminology is different, the principles of Product Velocity are still evident throughout. This is not surprising, since Joe had inspired me to develop Product Velocity.

Conway's Law in Automotive Engineering

Conway's Law states that organizations build systems that resemble their communication structure. During the discussion, it became clear just how strongly this law applies in the hardware environment.

When an organization is structured by function, the result is a product full of functional dependencies. When an organization is structured by product modules, the result is modules with clearer interfaces. Product architecture and organizational architecture are intertwined.

Tesla and SpaceX According to Joe, they are increasingly using independent modules. This product structure allows teams to organize themselves around the modules. WikiSpeed operated in a similar way. There was a group dedicated to the powertrain. This group could modify the powertrain without affecting the seats, interior, chassis, or suspension.

Many companies take the opposite approach. They create interdependencies because their siloed structure causes overlaps between system and organizational structures. As a result, they need coordination, architecture boards, dependency management, and approval chains. The organization creates the problem and then purchases methods to manage it.

That also explains why some companies use Scaling Frameworks They only become slightly faster. They manage wait dependencies more effectively. They do not eliminate them.

Interfaces are more important than names

An interesting part of the conversation revolved around Semantic versioning for hardware. In software, semantic versioning—using numbers such as 1.2.3—indicates whether a change remains backward-compatible, adds new functionality, or breaks existing functionality.

For hardware interfaces, this is an appealing concept. A windshield wiper made of a more durable material would be a patch, while a windshield wiper with additional dirt detection would be a minor change with enhanced functionality. An incompatible mechanical or electrical change breaks dependencies and results in a major change.

Joe responded cautiously. A name or version number must not be used as a shortcut for testing and give a false sense of security. A system must treat a new module as if it did not yet know what had been connected. It must test it, establish a handshake, and independently identify its properties and verify its behavior.

This leads to a powerful idea: Emergent Architecture. According to Joe, Tesla vehicles were designed to actively detect connected components. The system constantly asks: What is connected to me? What is it? What interface does it offer? What safety mechanisms are in place? This allows a vehicle to handle components that did not yet exist at the time of its original design.

The Internet works on the same principle. When TCP, IP, and DNS were designed, they did not know every device connected to them IoT Device. The protocol enabled registration, addressing, and communication. New capabilities were added later.

In the world of hardware, this is a challenging way of thinking. Many companies try to fully define the product before mass production begins. Any surprises that arise later are considered mistakes. But an innovative system needs the ability to be pleasantly surprised in a controlled way.

Semantic versioning fits into this picture when it is used as machine-readable documentation and compatibility information. It does not replace testing or formal dependency checks. Misuse begins when the version number replaces trust.

Fewer modules, less cognitive load

Joe prefers a small number of large modules. He mentions about ten modules—a number that people can still grasp as a single system. These modules can, in turn, contain submodules. A battery pack has its own structure. The key is for people within the system to understand the major interfaces.

That sounds old-fashioned in an age when AI agents are exploring ever-larger design spaces. That is precisely why this point remains relevant. People are still part of the engineering loop. Those who do not understand the overall system end up optimizing local parts and creating new dependencies.

The number ten represents a goal: The system should fit in a team’s head. Not every single screw, but the major modules, their responsibilities, and their interfaces.

Joe Justice

Many companies are heading in the opposite direction. They have thousands of requirements, dozens of tools, vast traceability networks, and a product model that no one can keep track of anymore. The tools enable this complexity. Then that complexity is seen as proof of professional development.

That's dangerous. Requirements management tools are powerful because they can create transparency. But they can also generate tens of thousands of requirements simply because it's technically possible. The same risk applies to semantic versioning, platform models, and digital twins. The tool doesn't solve the structural problem.

Fake Agile Hardware

Agile hardware is a sham if it doesn't speed up design, build, test, and deployment.

That may sound trivial, but it’s a tough test. Many programs improve communication, roles, and meeting structure. The actual lead time remains almost the same. Then there are more boards, more coordination, and more status updates. The product doesn’t get delivered any faster.

Joe calls SAFe as a well-known example. He acknowledges that SAFe can be a step forward for some companies, as it is often faster than the existing system. But that’s not enough when competition comes from China, Tesla, or fast-moving suppliers. A Release Train Engineer manages dependencies between trains. A product-oriented organization structures the trains differently.

The crucial question isn't: Are we agile? The question is: Can we design, build, test, and deploy faster than before—safely, legally, and cost-effectively? If the answer is no, then the methodology is just window dressing. In that case, the organization may sound more modern, but it continues to operate under the old, wait-and-see approach.

The 30-Day Experiment

Toward the end of the conversation, the discussion turned to a concrete first step. What can a traditional hardware company try in 30 days to test Agile Hardware?

Joe proposes an experiment that deliberately starts small. The company should choose something that it can design, build, and test entirely in-house. Then, the company should assemble a team with all the skills needed for this end-to-end process.

For 30 days, this team is given the authority to decide everything needed for this river. The goal is a complete iteration—a true cycle of design, construction, testing, and results.

This proposal is powerful because it doesn't start with organizational theory. It starts with a product flow. The team learns where bottlenecks occur. It sees which decisions are missing. It identifies which interfaces are stable and which ones block every change.

I added to the Value Flow perspective. You can also get started via a specific bottleneck take place. One example is change impact analysis. The key is to make the impact measurable. How long does the process take today? Where is the delay occurring? Which measure will be tested in 30 days? What has changed since then?

Both perspectives complement each other. Joe starts with the physical end-to-end product. Michael starts with the bottleneck in the value stream. In both cases, the focus is not on a new process chart, but on a verifiable intervention in the flow.

A bottom-up approach isn't enough

A 30-day experiment proves that change is possible, but it is no substitute for leadership. Bottom-up initiatives reveal that many obstacles are not technical in nature. However, they remain localized if there is no strategic direction.

A top-down approach is necessary to prevent experiments from falling apart. Leadership must decide which workflows matter, which wait times are costly, and which organizational boundaries can be changed. Without this mandate, teams work against the structure. Then the structure wins.

That explains why many transformation programs fall short. They start from the bottom up, without control over dependencies. Or they start from the top down, without concrete process optimization. Neither approach is sufficient on its own. But when combined, they are incredibly powerful. The the Wagner case study cited above This showed that Wagner decided to use MBSE strategically (top-down). Implementation then took place in small iterations lasting 3–6 months, each of which generated its own return on investment. At the same time, these small initiatives all moved in the same direction until larger results began to emerge. One example is certification being achieved in days rather than months.

What Remains

Joe Justice isn't just another Agile evangelist telling hardware teams they need to be more like software teams. His argument is more pointed. Hardware isn't slow because it's hardware; it's slow when the organization, architecture, and validation processes are designed to involve waiting.

This is a problem for European industry. Many companies are investing in platforms, tools, frameworks, and supplier networks. These investments are only helpful if they reduce dependencies. A platform that needs maintenance is not a driver of speed. And tools, in particular, are known for disappointing because they fail to deliver the hoped-for speed gains.

The criterion remains simple: How quickly can a legal, secure, tested, and usable result be produced?

Joe Justice

Conclusion

Agile hardware begins with the ability to modify a product flow from end to end. The next logical step is to conduct many small experiments on real bottlenecks. Such experiments require a small team with all the necessary skills, stable interfaces, or the mandate to stabilize them. They require automated tests where manual approvals are currently required. They require metrics that are economically relevant.

After that, the discussion becomes more honest. If the flow has accelerated, the next bottleneck becomes apparent. If the flow hasn't accelerated, it becomes clear which structure is causing the blockage. In either case, the insights gained are more valuable than yet another maturity model.

Joe Justice shows that speed arises when product architecture, team structure, and validation all serve the same flow. Anything else is just queue management with fancier terminology.

Contact Joe Justice

X: https://x.com/JoeJustice
Facebook: https://www.facebook.com/Joe.A.Justice
LinkedIn: https://www.linkedin.com/in/joejustice/
Books: https://leanpub.com/u/joejustice
Classes: https://en.abi-agile.com/
YouTube: https://www.youtube.com/@JoeJustice0
Email: Joe@ABI-Agile.com