Hardware Companies Don't Know How to Build Software (And That's Fine)

I recently spent time inside a century-old industrial manufacturer standing up a digital division. Global company. Tens of thousands of employees. Factories on every continent. Products in millions of buildings worldwide. And now they wanted to be a “software company” too.

This is not a new story. Every hardware company with a board of directors and a copy of the Harvard Business Review has had the same revelation: the future is connected. Products need software. Data is the new oil. Digital twins. IoT. Cloud platforms. The works.

What is a relatively new story — and one that doesn’t get told honestly enough — is what actually happens when a company that has spent a hundred years making physical things tries to build software. The cultural collision is spectacular. And I don’t mean that in a good way.

Two engineering cultures that don’t understand each other

Manufacturing engineers and software engineers both call themselves engineers. That’s about where the similarities end.

Manufacturing engineering operates in a world of physical constraints, safety certifications, and product cycles measured in years. A new product line might take three to five years from concept to market. Every component is tested, certified, and validated against regulatory standards. A failure in the field doesn’t mean a user sees an error message — it means a building’s heating system stops working in February, or a fire suppression system doesn’t activate, or a refrigeration unit fails and destroys a hospital’s blood supply. The stakes are real, physical, and occasionally lethal.

The culture that produces this kind of engineering is — necessarily — conservative, methodical, and documentation-heavy. Every decision has a paper trail. Every change goes through a review process. Every specification is exhaustive before any physical prototype gets built, because tooling up a factory line is enormously expensive and you don’t get to iterate cheaply.

Software engineering — at least the modern startup-influenced variety — operates in a completely different universe. Ship early, get feedback, iterate fast. Minimum viable products. Two-week sprints. Continuous deployment. “Move fast and break things” might have fallen out of fashion as a slogan, but the underlying ethos is alive and well. Failure is cheap. Rollbacks are instant. The cost of being wrong is low, so you optimise for learning speed.

When these two cultures meet inside the same organisation, the results are predictably awful.

What I walked into

The digital division had been stood up about eighteen months before I arrived. They’d hired a CTO from a software background, recruited a team of developers, and set up shop in a separate office — physically and organisationally distinct from the core business. The theory was that separating the digital team would give them the autonomy to move at software speed without being constrained by the manufacturing culture.

In practice, here’s what had happened:

Death by committee. Every architectural decision needed sign-off from people who didn’t understand software architecture but had organisational authority. A decision that should have taken an afternoon — which message broker to use — had been in committee for six weeks. Not because anyone had strong opinions about RabbitMQ versus Kafka, but because the approval process was the same one used for signing off a new compressor design. The process existed because, in hardware, premature commitment to a component is genuinely expensive. In software, you can swap out a message broker in a sprint. The process didn’t distinguish between reversible and irreversible decisions, so everything moved at the speed of the slowest approval chain.

Waterfall in agile clothing. They’d adopted Scrum. They had sprints, standups, retrospectives, the full ceremony. But the actual work was still waterfall. There was a 200-page specification document that had been written before any code existed. The sprints were essentially phases of a waterfall project, chopped into two-week chunks. “Sprint 14: Implement sections 4.3 through 4.7 of the specification.” That’s not agile. That’s waterfall with better catering.

Hardware timelines applied to software. The roadmap had been defined with a three-year horizon, broken into phases with hard dates. This makes sense for manufacturing — you need to coordinate supply chains, factory schedules, and certification timelines. It makes no sense for software, where the entire point is to learn and adapt as you go. But the leadership team understood roadmaps that looked like Gantt charts, so that’s what they got.

Software people who didn’t understand the hardware. The flip side of the cultural gap. The software team was building a cloud platform to connect residential devices — thermostats, heat pumps, sensors. Low-cost devices with limited compute, unreliable network connectivity, and firmware that couldn’t be updated as easily as a web application. The software team initially designed the system as if the devices were just another API client — always connected, reliably available, capable of processing complex payloads. They weren’t. These were small, cheap, battery-powered devices on consumer WiFi networks. The constraints were entirely different from anything the software team had dealt with before.

The constraints are real

This is the bit that software people need to hear, because it’s easy to be dismissive. “Oh, the hardware people are stuck in the past. They don’t understand modern development. They need to move faster.”

No. The hardware constraints are real, and they matter.

Devices have limited resources. A residential thermostat isn’t running a Node.js server. It’s got a microcontroller with kilobytes of RAM, not gigabytes. The communication protocol needs to be lightweight — MQTT, not HTTP. The payload needs to be small. The device needs to handle network interruptions gracefully because WiFi in a residential setting drops out constantly. If your cloud platform sends a 50KB JSON payload to a device expecting a 200-byte MQTT message, you’ve got a problem that no amount of software sophistication will fix.

Firmware updates are not deployments. You can’t just push a new version of firmware the way you’d deploy a new Docker image. Firmware updates need to be downloaded over unreliable connections, verified, and applied atomically. A failed firmware update can brick a device. A bricked thermostat in someone’s home means a service call, a truck roll, and a very unhappy customer. The manufacturing team’s insistence on exhaustive testing before any firmware release isn’t bureaucratic timidity — it’s hard-won wisdom from decades of deploying physical products into environments they can’t control.

Certification is non-negotiable. Products that control heating systems, connect to electrical supplies, or interact with safety-critical building systems need regulatory certification. UL, CE, various regional standards. Certification takes months and costs serious money. It applies to the combination of hardware and software — change the software significantly and you might need to recertify. The software team’s desire to ship updates weekly ran headlong into a certification process that assumed quarterly releases at most.

The install base is enormous and slow to update. Once you’ve shipped a million devices into homes, you can’t assume they’ll all update promptly. Some will be on firmware from two years ago. Some will never update at all. Your cloud platform needs to support every version of every device that’s ever been shipped, potentially for the product’s entire lifetime — which in HVAC, is measured in decades. The software world’s approach of deprecating old API versions after a year doesn’t work when your API client is a physical device bolted to someone’s wall.

What actually works

After the initial collision, something interesting happened. The teams that worked well — and some did — were the ones that stopped trying to convert one culture to the other and instead found a way to respect both.

Separate the concerns properly. The cloud platform team operated on software timelines — continuous deployment, short iterations, rapid experimentation. The device firmware team operated on hardware timelines — longer cycles, exhaustive testing, formal releases. The interface between them — the device communication protocol — was designed to be stable and versioned, so the cloud side could evolve independently of the firmware. This is just good API design, but it took months of cultural negotiation to get there because the hardware side wanted the cloud team to operate on their schedule and the cloud team wanted the hardware side to move faster.

Embed people across the boundary. The best outcomes happened when software engineers spent time with the hardware team and vice versa. Not permanent transfers — just enough time for each side to develop respect for the other’s constraints. When a software developer sees what goes into certifying a device, they stop asking “why can’t we just push an update?” When a hardware engineer sees a feature go from idea to production in a week, they start understanding why the software team finds six-week approval cycles maddening.

Use hardware thinking where it matters. The manufacturing team’s approach to reliability — testing every edge case, planning for failure modes, documenting everything — is exactly what you want in the firmware and device communication layer. Software people tend to be optimistic about failure. “It probably won’t happen” isn’t good enough when the failure mode is someone’s heating going off in January. The manufacturing culture’s conservatism is a feature, not a bug, in safety-critical contexts.

Use software thinking where it’s appropriate. The cloud platform, the mobile application, the analytics pipeline — these are pure software problems. They should be built with software methods. Short iterations, fast feedback, hypothesis-driven development. The manufacturing team needed to trust the software team’s process here, even though it looked chaotic and undisciplined by their standards.

Make reversibility explicit. Jeff Bezos’s two-way door concept was genuinely useful here. Hardware decisions are mostly one-way doors — once you’ve tooled a factory line, you’re committed. Software decisions are mostly two-way doors — you can change direction cheaply. Making this distinction explicit helped the organisation apply the right level of rigour to the right decisions. A database choice? Two-way door — pick one, move on, change it later if needed. A device communication protocol? One-way door — thousands of devices will depend on it, so take the time to get it right.

The “move fast and break things” problem

Here’s my broader gripe, and it extends well beyond hardware companies. The software industry’s fetishisation of speed has created a blind spot around reliability and long-term thinking.

“Move fast and break things” was always a bad philosophy. It just happened to work in a narrow context — consumer social media, where the consequences of breaking things were that someone’s status update didn’t post. Apply it to IoT, healthcare, financial systems, or anything where the physical world is involved, and it’s genuinely irresponsible.

Hardware companies understand this intuitively. When you manufacture a product that goes into someone’s home and stays there for fifteen years, you think about reliability differently. You think about failure modes. You think about what happens when the network is down, when the power flickers, when the user does something unexpected. You design for the worst case, not the happy path.

Software companies — particularly the ones steeped in startup culture — could learn a lot from this mindset. Not the six-week committee meetings. Not the 200-page specification documents. But the underlying respect for reliability, for the user’s environment, for the fact that your product exists in a physical context that you don’t control.

The honest truth about digital transformation

Most “digital transformation” initiatives fail. McKinsey has been writing about this for years — the failure rate is somewhere around 70%, depending on how you define failure. In hardware companies specifically, I think the primary reason is cultural, not technical.

The technology is straightforward. Connecting devices to a cloud platform, collecting telemetry, building analytics — none of this is novel computer science. A competent engineering team can build it. The hard part is building the organisation that can sustain it.

That means:

• Hiring software people who respect hardware constraints instead of dismissing them
• Giving the digital team genuine autonomy over their development process
• Accepting that the cloud platform and the device firmware will move at different speeds, and designing the architecture to accommodate that
• Not treating “digital” as a separate business that will eventually replace the core — it’s an extension of the core, and it needs the domain expertise that lives in the manufacturing side of the house

The century-old industrial manufacturer I worked with is still on this journey. Some parts are working well. Others are still fighting the cultural war. But the teams that are succeeding are the ones that figured out the most important lesson: you don’t need to choose between hardware culture and software culture. You need both. The skill is knowing which one to apply, and when.

That’s not a technology problem. That’s a leadership problem. And no amount of Scrum training or cloud migration is going to solve it.