Magnus McCune

I work at the intersection of industrial data, AI, and systems architecture. These days that happens at HiveMQ, where I focus on Industrial AI & IIoT as VP of Product Strategy & Incubation. I spend a lot of time thinking about how to make operational data less of a headache and more of an asset.

This blog is where I write down what I've learned the hard way: scaling MQTT to millions of connections, watching "simple" architectures fall apart in production, modeling operational data so it's useful instead of decorative, and wiring the whole thing into systems that can actually reason and act. It's aimed at engineers, architects, and product folks who are trying to ship real systems in the real world, not just toy demos.

I came up through architecture and engineering roles and now sit in product strategy, which means I spend a lot of time translating between deeply technical teams and business outcomes. I like taking big, fuzzy problems—like "why is this factory drowning in data but still flying blind?"—and breaking them into concrete patterns, diagrams, and decisions that teams can execute on. A lot of my work centers on incubation: taking an idea from "this might be interesting" to "we've validated this, scoped an MVP, and know whether it belongs in the roadmap."

I tend to think in layers: how data moves, how it's shaped and governed, and how it's ultimately used to make decisions or take action. Most of the interesting problems live at the boundaries between those layers, where organizational reality, legacy systems, and ambitious roadmaps collide.

I'm hands-on by default. I run a fairly opinionated homelab with edge devices, Jetson hardware, multiple k8s clusters, Proxmox, and a small zoo of embedded boards to prototype workflows. That environment is where I try ideas, break them safely, and get a feel for what might actually be worth recommending before anyone bets a real project on it.

You'll see a mix of experiments, sketches, and working notes here: things I've tried in the lab, patterns that held up in the field, and tools I've added to my own toolbox along the way. Some posts are polished; some are closer to "here's what I learned while falling into this particular ditch."

Underneath all of this is a bias toward critical thinking and clarity. Our industry is noisy right now; there's a lot of hype, a lot of buzzwords, and not enough grounded conversations about tradeoffs, constraints, and failure modes. My goal here is to share patterns, scars, and working theories—not commandments—and to push the conversation in a direction that's useful to people actually building and operating these systems.

When I'm not neck-deep in systems, I'm usually exploring cities, coffee in hand. I've spent a lot of time in places like Mexico City, San Francisco, and a rotating cast of European stops, and I tend to navigate by cafés, tacos, and interesting public spaces. The same curiosity that drives my work shows up in how I travel: I like understanding how places work, not just how they look.

I'm also a tinkerer away from the keyboard. That shows up as small hardware projects, homelab experiments that don't need to justify a business case, and time outside resetting my brain—walking, hiking, or just being somewhere that isn't full of screens.

Wherever I'm based at the moment, there's usually a thread of food and learning running through everything: cooking, hunting down new restaurants, and reading about whatever has my attention that month—building science, cars, machining, 3D printing, or the broader "maker" ecosystem. It all feeds the same itch: understanding how things are put together, and how to make them a little better.