Joe Justice: Hardware Can Get Faster (Part 1)
One road-legal car per week sounds like hype and a massive exaggeration. But 20 years ago, Joe Justice and a small team were already designing, building, testing, and selling a new car every week. If that was possible 20 years ago, why do established companies still take years today to make significantly smaller changes?
Joe Justice is the founder of WikiSpeed, previously worked at Tesla, and now consults for companies such as Toyota, Honda, and Mercedes-Benz. This interview focused on the fundamental question behind Agile Hardware: What really stands in the way of speed in physical product development?
I've been preaching the short answer here for years: It's not the individual steps that are slow; it's the overall workflow—with its queues, handoffs, and lengthy decision-making processes—that slows us down, because it was designed for a different era.
The WikiSpeed Story
Joe Justice WikiSpeed began in 2006 with a simple idea. He wanted to build a car using agile methods. What started as a single project grew into a network of 4,000 participants in 23 countries.
The work schedule was intense: On Thursday morning, a new vehicle design was created in CAD. Afterward, a machine cut the full-scale exterior mold out of foam. On Thursday evening, the mold was laminated with carbon fiber. By Friday, the vehicle was on display at auto shows, where the team gathered direct feedback from potential customers. Tests followed on Monday, including at government testing labs.
The interesting aspect for systems engineering lies in the cadence. WikiSpeed treated a car as a product that could be developed in short iterations—as a standard way of working.
Joe explains that government testing doesn't necessarily have to cost millions. WikiSpeed booked testing appointments directly with the labs. According to him, an appointment for emissions testing cost about $200. The team scheduled recurring appointments, took advantage of open slots, and avoided using expensive middlemen.
Regulation is often seen as an obstacle, but Wikispeed proves that there is another way and that regulation can be integrated into the weekly routine.
The material won't wait
Many objections to Agile Hardware start with the material. Metal can't be deployed, plastic can't be compiled, and a headlight isn't a microservice.
Joe challenges this intuition. Modern tools can cut metal to size in minutes, and 3D printing and other technologies quickly and automatically translate designs into parts.
Software development has been grappling with this problem for decades. Teams wait for decisions; decisions wait for meetings; meetings wait for calendar slots. Contracts wait to be reviewed. Suppliers wait in their own queues. Different time zones exacerbate the problem. In the end, the product comes to a standstill not because of the laws of physics, but because of the structure of organizations.
Anyone who wants to develop, manufacture, test, and approve a headlight today needs a team that can handle the entire process. Design, construction, testing, certification, and manufacturing must all be part of a single workflow. That is precisely where the traditional organizational structure falls short.
A functional organization separates CAD, purchasing, testing, quality, manufacturing, and legal affairs. This leads to handoffs and bottlenecks, which in turn increase the cost of changes. Conway's Law. Read more further down.
Tesla and the Issue of Scaling
The classic objection to WikiSpeed is that a prototype is not the same as mass production. When Joe got the chance at Tesla to test exactly that limit, he jumped at the opportunity. During his job interview at Tesla, no one asked him about his degrees; instead, they asked technical questions about machining aluminum, suppliers, and road approval. Joe had answers because he had solved these problems in practice.
This gave rise to a pattern that emerged throughout the conversation. Rapid hardware development scales by reducing wait times.
Rapid hardware development scales by eliminating wait times.
Joe Justice
A team must have the capability to solve a problem from start to finish. When a new component is developed, testing must not begin weeks later, but immediately: Tests must be conducted throughout the development process. AI can serve as a catalyst for automating work that people previously performed manually, slowly, and on an ad hoc basis.
The length of a test says nothing about its quality. A long test may not be very meaningful, while a short test may be more reliable at detecting a critical error. For hardware organizations, this is also bad news. Many have confused security with duration.
The European Excuse
In Europe, the objection is quickly framed differently. People say that Tesla and SpaceX have billions, and that China is a totalitarian regime that operates under different conditions. A medical technology company, a machinery manufacturer, or a supplier couldn’t operate that way. Joe interprets this objection differently.
When someone says, „That won’t work here,“ it often means, „I’m not allowed to change that.“
Joe Justice
A buyer can optimize the purchasing process, but cannot overhaul the product life cycle. A department head can make his or her role more efficient, but cannot change the company’s decision-making structure. There are many such examples: Employees are allowed to optimize at the local level, but not Conway Drift compensate for.
This reverses cause and effect: The organization calls it „our industry is different.“ What they mean is: The necessary changes are beyond their own authority. Many companies are still organized by function: Purchasing here. Software there. R&D there. Manufacturing over there. Quality next to it. This structure is easy to manage as long as the product development cycle is slow and predictable.
This model fails when it comes to complex products. Today, vehicles, medical devices, machinery, and aerospace systems consist of software, electronics, mechanics, data, operations, and service. The valuable functions arise at the interfaces. That is exactly where the silos are.
Sloan Silos and the Cost of Waiting
Joe uses the term "Sloan Silos" to refer to the functional organization based on Alfred P. Sloan. Historically, this structure has made large industrial companies manageable. It organized people according to their skills and management principles.
But when speed becomes more important than predictability, the Sloan silo backfires. Those closest to the work submit requests to higher-ups and wait for decisions. Every change has to pass through several areas of responsibility. This leads to long wait times, misunderstandings, and a loss of knowledge.
This system runs slowly with complex products. With complex products it no longer works reliably. During our conversation, I brought up the difference between “complicated” and “complex.” A car from the 1980s was complicated. A modern vehicle is a networked system comprising software, electronics, sensors, energy, the cloud, and regulation. It does not respond to changes in a linear fashion. Joe agrees, but adds one point:
Even a complicated system slows down in Sloan Silos. Complexity robs the system of its remaining tolerance.
Joe Justice
This is particularly evident in outsourcing. When an OEM can no longer manage complex systems in-house, key functions are transferred to suppliers. The supplier becomes more efficient, but with its own expertise. The OEM acquires capability in the short term but loses design control in the long term.
That's the point at which speed becomes a strategic factor. Whoever outsources the fast parts of the product is outsourcing the future.
Architecture That Doesn't Wait
The conversation then turned to product architecture. Joe prefers to use the term “module” rather than “platform” in this context, since “platform” can mean too many different things in a business setting—ranging from a technical foundation to a modular system to a business model.
Joe has a more precise way of putting it: a design that doesn't wait. A module is well-structured when it feels like a Black Box can be modified without requiring changes to other modules. With Wikispeed, for example, the team was able to change the powertrain without touching the seats, chassis, or interior. A module has stable interfaces and minimizes dependencies. This is not just architectural aesthetics, but Architecture for Flow.
Many platform programs fail in this regard: They build large shared structures but create new dependencies on waiting times. When the NVH Performance Since a platform depends on the wheelbase, battery weight, tires, body style, and target costs, everything is interdependent. So even though it’s called a platform, it behaves like a monolithic approval system.
A good platform provides abstraction. The smartphone is the best everyday example. An app uses the camera, location, network, storage, security, and sensors without having to redesign a physical device from scratch every time. The platform encapsulates hardware capabilities. It provides security mechanisms, an installation model, and interfaces. The app developer focuses on the app’s functionality, not on the electrical integration of the camera.
The same goal applies to vehicles. The platform must provide enough stability to allow for the rapid creation of variants. It must not centralize development to the point where every change has to be approved by a committee.
In three weeks: Conway’s Law, Modules, and Experiments
This one-hour interview is packed with an enormous amount of knowledge—so much, in fact, that it’s too much to cover in a single article. A summary of the second part will be available in a few weeks. If you don’t want to wait that long, you can, of course, already Watch the entire interview on YouTube.
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
Discuss on LinkedIn
A "Like" 👍 or "Share" ↻ would really help me out. Thanks!
