Twenty Years, Three Industries, One Engineer

In 2003, I was writing PLC ladder logic for industrial automation at Rockwell Automation in Milwaukee. In 2024, I am building FX swap market data publishers for Reuters at ING, one of Europe's largest banks. Between those two points there is a path through trading system low latency, emergency radiology, no-code platforms, classical music streaming, and hospitality technology — and I did not plan any of it.

What I want to examine, twenty years in, is why that path happened the way it did, what each crossing of an industry boundary cost and gave me, and what I think the common thread actually is — because people ask about that common thread a lot, and the honest answer is both simpler and stranger than most career retrospectives acknowledge.

Milwaukee, 2003

The Milwaukee School of Engineering is a practical place. It is not MIT. It does not produce many theoretical computer scientists. What it produces are engineers who can build things that work — who have held circuit boards, who have written firmware, who understand that software runs on hardware and hardware exists in physical space with physical constraints. I graduated in 2005 with a BS in Computer Engineering and a fairly concrete understanding of what I did not know.

Rockwell Automation, where I worked during my final years of school and briefly after graduating, is the largest industrial automation company in the world. The software I wrote there controlled real machines. Not metaphorically: the code ran on a controller on a factory floor, and if it had a bug, something physical happened. A conveyor stopped. An assembly sequence failed. The feedback from your mistakes was immediate and unambiguous in a way that enterprise software almost never provides. That is a good environment for learning to be careful.

When I moved to Nighthawk Radiology in 2005 — one of the early teleradiology companies, built on the then-new idea that radiologists could read scans remotely over the internet — I crossed my first industry boundary. I went from industrial machines to medical imaging. The domain was completely different. The stakes were completely different. But the fundamental requirement — write software that does not fail when something real depends on it — was identical.

What Finance Gave Me That Healthcare Could Not

I joined IMC Financial Markets in 2007. The move to finance felt like arriving in a different country — the culture, the vocabulary, the priorities, all foreign. Financial markets move based on information asymmetry and speed. The competitive advantage is measured in microseconds and in the correctness of your models. Nobody is impressed by good intentions. The market is the test, and the market runs continuously.

What finance gave me that healthcare had not was a performance culture with quantitative rigor. In a hospital system, you can have a general understanding that your system is performing adequately. In a trading environment, "adequately" is not a category. You know your p99 latency to the microsecond. You know exactly how many messages per second your system processed yesterday, and you know whether that was better or worse than the week before, and you know why. That culture of measurement — of refusing to let performance be a feeling rather than a number — has stayed with me through every subsequent role.

Healthcare gave me something finance could not: the direct connection between software quality and human outcomes. A trading system failure is expensive. A healthcare system failure can kill someone. The weight of that distinction is not something you feel equally from reading about it. You feel it when you are sitting in a workflow review with emergency radiologists at two in the morning, understanding what a delayed critical value notification actually means in a real patient's life. That weight makes a different kind of engineer. It is not better than the precision finance demands. It is complementary to it.

The Pattern Across the Crossings

After IMC, I ran the software development function at a healthcare group, then spent time at Mendix — where I built a virtual assistant for a no-code development platform before Siemens acquired the company for €600 million — then returned to IMC, then moved through the Amsterdam fintech scene. Each crossing looked, from the outside, like a change of direction. From the inside, it felt like the same thing done in a new context.

The pattern I keep returning to is this: every industry has a core technical problem that is specific to it and that outsiders consistently underestimate. In finance, that problem is deterministic low latency under adversarial market conditions. In healthcare, it is the coordination of asynchronous, time-critical workflows with human lives as the error cost. In classical music, it is the hierarchical metadata problem — the fact that the standard music data models were designed for pop and cannot represent the identity of a classical recording. In hospitality technology, it is the fragmentation of payment and property management systems across markets and currencies.

When you cross into a new industry, the first six months are humbling. The domain knowledge you lack is not a small gap — it is a chasm. And the engineers who have been there for years can see immediately whether you are engaging with the real problem or applying a generic solution to it. The ones who succeed at crossing are not the ones with the broadest skill sets. They are the ones who are willing to be genuinely ignorant for long enough to understand what the domain actually requires.

What Keeps Me Moving

People ask whether I regret not going deep in one domain — whether I would have been better served by spending twenty years solely in high-frequency trading, for example, where the depth of specialization is extreme and the compensation reflects it. It is a reasonable question.

My honest answer is that the breadth is not a compromise. It is the point. The most useful thing I bring to any new context is the ability to recognize which problems are truly domain-specific and which are instances of problems I have solved before, wearing different clothes. The reconciliation problem at IMC — trade positions across multiple clearing houses — is structurally similar to the workflow coordination problem at Lakeland — scan status across multiple radiologists and time zones. The metadata hierarchy problem at Primephonic is structurally similar to the instrument definition problem in options market making — both require representing things that have canonical identities but multiple representations. Seeing those structural similarities, and knowing which solutions actually scale, is something you can only build through breadth.

Now, at ING — a bank with an eighty-five billion euro market cap operating in more than forty countries — I am building the FX swap market data publisher that sends real-time prices to Reuters through the RFA feed. The domain is new in its specifics. The underlying problem — accurate, low-latency, highly available data distribution with proper market data protocols — is one I have been solving in various forms for fifteen years.

What I Would Tell the 2003 Version of Myself

From Milwaukee to Amsterdam is not a straight line, and it was not supposed to be. The interesting career is not the one you plan; it is the one you build out of genuine curiosity about how different industries work. Every time I crossed a boundary, I had to learn to be a beginner again. That is uncomfortable in a way that does not get easier with experience — it just becomes more familiar. You learn to trust the discomfort because you have seen enough times that what comes after it is understanding.

The common thread, after twenty years, is not a technology or a domain. It is the willingness to take problems seriously on their own terms. Every industry I have worked in has a core problem that looks simple from the outside and is genuinely hard from the inside. The job, always, is to understand which one you are dealing with.