Breaking down the silo - how the future of hardware development is structured differently

From silos to collective ownership

Traditional hardware development processes often mirror physical products - siloed, isolated and tightly coupled. In contrast, modern product development thrives on shared systems and loosely coupled teams. That is, teams that operate independently and can make progress without significant dependencies or interactions with other teams.

The benefits of reducing coupling between teams are significant - improved flow, increased scalability, heightened resilience and ultimately, faster delivery. There is, however, a fine line between autonomy and siloes. Today's autonomous feature teams need to be enabled by platform teams:

• Platform teams own cross-cutting concerns such as shared UI components, design systems, firmware abstractions and development tooling.

• Feature teams focus on customer-facing functionality within specific product lines, building on the platform’s foundation.

This approach enables consistency, accelerates delivery and reduces duplicated effort. Crucially, it encourages collaboration across products and shifts the culture from isolated fiefdoms to collective ownership.

Enablers not bottlenecks

A common risk with platform teams, however, is that they become reactive gatekeepers rather than proactive enablers. Instead of supporting and helping feature teams accelerate, they actively slow them down. This entirely defeats the purpose of the model.

Successful platform teams must be proactive. They must anticipate future needs by a) developing shared infrastructure ahead of demand, and b) creating an internal "product" mindset around developer experience. In essence, they need to stay two steps ahead of their feature teams.

If a feature team’s velocity is held up waiting on changes from the platform team, the benefits of the topology are completely negated. The platform should therefore be treated as a shared product - backlogs, service-level expectations and active developer engagement is essential for long-term success.

Beware of the cargo cult

As teams modernise, they may be tempted to introduction cloud-native patterns like microservices and containerisation. While these approaches work well in the cloud, they don’t necessarily translate well to embedded and edge systems.

Separation of concerns is a worthy goal but in resource-constrained environments, microservices can:

• Increase startup time and memory usage

• Add unnecessary deployment and testing complexity

• Introduce fragility through inter-service dependencies

Instead of blindly cargo-culting cloud patterns, platform teams should favour modular monoliths or in-process services with clear domain boundaries. The goal is clean separation of concerns, not architectural dogma. Practicality should always win over theoretical purity and over-engineering, especially at the device level.

Conway’s Law still applies

Products built around siloed team structures inevitably reflect that fragmentation, in both the physical product and the supporting software. In some cases, your product lines may be so discrete that the lack of cohesion and consistency has minimal impact. But within individual product lines, it will likely result in issues - not least with confused users.

The power of platform-feature team models is that they drive consistency across your product lines and allow your organisation to scale without sacrificing quality. Shared design systems, common interfaces, and reusable components become force multipliers, not friction points.

But structure must match culture. That brings us to the hard part.

Reorganising is hard, really hard

Shifting from a traditional, siloed team structure to a platform-feature team model represents more than a restructure. It often demands a fundamental change in how the entire organisation operates. For hardware companies in particular, this change is profound.

Hardware development processes have long been shaped by a single moment of release, where the build must be right the first time. As a result, processes tend to be optimised for certainty and control, not iteration and learning.

Compare this with digital product development, where teams can deploy and iterate continuously. Their workflows are built for speed and adaption. If they get it wrong, they can quickly release a new, improved version.

Transforming organisations that grew up with a hardware delivery mindset to a more agile software delivery mindset may require seismic organisational change, involving practically every stakeholder in your firm. Changes may include:

• Reshaping team structures

• Rethinking release planning and validation

• Rewriting internal roles and responsibilities

• Redefining leadership expectations

Change of this magnitude would be hard for any organisation, but for hardware companies, where inertia is often reinforced by decades of process, regulatory demands and fixed release cycles, it could feel so existentially risky that it would be safer to not even try. This is totally understandable, but it doesn’t mean it’s impossible. It just means it must be led intentionally, with clear vision and cross-functional buy-in.

Final thoughts

Having worked with hardware companies for over two decades, we’ve seen first-hand how issues around siloed teams and outdated ways of thinking play out. In many ways, this article isn’t just about adopting new technologies - it’s about how those technologies can act as a catalyst for new ways of working.

Ultimately, this is not simply about upgrading your technology stack. It’s about reconfiguring mindsets and shifting away from traditional approaches towards methods and structures that enable companies to build better products, attract stronger talent and move faster than ever before.

So, structure your teams to scale. Empower platform teams to lead. Encourage autonomy and cross-team collaboration. And accept that meaningful change may require significant organisational transformation.