What 20 years of enterprise infrastructure taught me about building hardware

People are sometimes surprised that someone who spent two decades on networks, virtualization and enterprise architecture is now designing circuit boards. To me it feels like a straight line. Here's what carried over.

1. Uptime is a design decision

At a hospital, infrastructure serving thousands of clinical users can't just "go down for a bit." That reality forced a habit: before building anything, ask how does this fail, and what happens then?

On a PCB, the same question becomes: what happens if the supply browns out, the connector wiggles, the Wi-Fi drops mid-write, or the user unplugs it during a firmware update? Designing for failure modes isn't pessimism. It's what makes a product feel solid.

2. Change control isn't bureaucracy

In regulated environments, every change has a plan, a test, a rollback and a record. Early in my career that felt slow. Later I understood it was the reason things didn't break at 3 a.m.

In hardware, it translates directly:

• Every board revision has a change list.
• Firmware versions are tagged and tied to the board revisions they support.
• OTA updates have a rollback path.
• Bring-up results are logged.

3. Standardization makes scale possible

When I rebuilt a large Citrix farm around best practices and standard builds, the biggest win wasn't performance — it was that every server behaved the same. Troubleshooting one meant understanding all of them.

On the bench, standardization looks like reusing proven sub-circuits: the same power input stage, the same USB-serial and auto-reset circuit, the same debug header on every board. Each project gets to start from known-good blocks instead of re-deriving them.

4. Proofs of concept beat slide decks

As a solutions engineer, I learned that customers believed working demos, not architecture diagrams. A proof of concept answers questions nobody thought to ask.

Hardware is the ultimate version of this. A printed enclosure in your hand teaches you more in thirty seconds than a week of CAD screenshots.

5. Translate between worlds

My favorite part of enterprise work was translating: turning clinical requirements into infrastructure, or a business problem into a technical design. Product development is the same skill. A speedcuber doesn't care about SPI clock rates; they care that the display is readable and the averages are right. Your job is to hold both views at once.

6. Documentation is a gift to your future self

Server build docs, install guides and change records saved me countless times. Now I do the same for hardware: pinout tables, bring-up logs, power budgets and assembly notes. Future me always thanks past me.

The through-line

Underneath it all, the job never changed: take a fuzzy requirement, make it real, measure it and improve it. The tools went from Cisco CLIs and hypervisors to KiCad and OpenSCAD. The engineering mindset came along for the ride.

If you're an IT or infrastructure person curious about hardware, you're more prepared than you think. Start with an ESP32 and a weekend.