What Designing High-Voltage Products Taught Me About Software

What Designing High-Voltage Products Taught Me About Software

I spent close to seven years at ABB designing high-voltage products in the Power Grid division before I moved into software product management at Microsoft. That transition — from a world where the wrong design choice can literally start a fire to a world where you can hotfix in production — has been the most useful prism through which I look at software work.

There's a certain kind of seriousness in hardware engineering that, frankly, the software industry doesn't always have. Some of it is overhead. A lot of it is just engineering discipline that we've forgotten we need.

You can't ship a circuit and patch it later

In high-voltage design, you do your homework before the unit ships. You run simulations. You build a prototype. You test it in environmental chambers. You sit through design reviews where someone older and grumpier than you points at your schematic and asks, "what happens if this capacitor fails closed?"

That review culture is the single thing I miss most in software. Software has design reviews, but they're often performative — a meeting that ends with everyone nodding because nobody wants to look like they didn't read the doc. In hardware, the senior engineer is *paid* to find the failure mode you missed. The doc that doesn't get challenged is the doc that wasn't read.

I now treat my own product specs the same way. I look for the senior person most likely to disagree with me and I send the doc to them first.

Constraints make products better

Hardware engineering is constraint engineering. There's a power budget, a thermal budget, a cost target, a regulatory envelope, a manufacturing yield curve. The interesting work happens in the corners of that constraint space.

Software, by contrast, often pretends it has no constraints. Need more memory? Spin up another instance. Need more time? Push the date. Need more headcount? Open a req. The result is a lot of bloated, undisciplined software that does too much for too many users at too high a cost.

The platform work I do at Microsoft brings real constraints back: latency budgets, sovereignty requirements, tenant isolation, deployment topologies that don't bend to wishful thinking. I find this kind of work more rewarding than open-ended consumer product, partly because the constraints force the team to make actual decisions instead of accumulating features.

Sovereign clouds are a hardware problem in disguise

The work I'm doing now — rehoming the Experience and Devices stack into new sovereign clouds — feels surprisingly like hardware product work. You have a boundary you can't cross (data sovereignty), a substrate that's different from your reference platform (air-gapped environments), and a customer who can't tolerate "we'll fix it in the next release."

In a regular cloud rollout, you can iterate. In a sovereign cloud, you really can't. The customer is a regulated entity, the deployment is operationally fenced, and the cost of getting it wrong is measured in audit findings, not retention curves.

That changes how you spec. You can't just write the happy path and add edge cases later — you have to enumerate the failure modes up front, because there's no telemetry pipe back to your debugging team. That's hardware thinking, applied to software, and it's the most interesting product work I've done.

The discipline I want to keep

If I had to compress the lesson into one line, it would be this: the best product work assumes the system will be wrong, the user will be unhappy, and the post-mortem will be honest. Hardware engineering taught me to design for that day. Software gave me the tools to ship faster. The trick is using both.