The standard career advice says to pick a domain and go deep. Become the payments person, the ad-tech person, the security person. Compounding expertise is real, and the people who spend fifteen years in one industry build a kind of pattern recognition that is hard to fake.
I did the opposite. Over about a dozen years I built software for environmental conservation, back-office finance, quantitative trading, agricultural commodities, e-commerce, and cybersecurity. Six industries with almost nothing in common on the surface. Every time I moved, I gave up the domain credibility I had just spent two or three years accumulating and started over as the person in the room who understood the systems but not yet the business.
For a long time I treated that as a liability I had to explain away. I don’t anymore. Moving across industries is a skill in its own right, and the practice of doing it well is one of the more useful things I’ve learned as an engineer and as a leader. Here is what actually transfers, what doesn’t, and when the hopping is a differentiator versus a problem.
The arc
A quick tour, because the specifics matter for the argument.
I started at the Natural Capital Project at Stanford, writing Python GIS models to evaluate environmental risk to habitats and to weigh the cost and benefit of conserving one piece of land over another. From there I went to Advent, building a portfolio modeler and rebalancer in C# and .NET for back-office financial advisors. Then Quantopian, integrating data from twenty-plus external vendors so that sandboxed trading strategies could run against clean, standardized market data. Then Indigo Agriculture, maintaining a set of microservices for algorithmically priced transport and execution in a three-sided grain marketplace, hedging commodity futures on the Chicago Mercantile Exchange. Then Perch, scaling the engineering behind a portfolio of several thousand consumer products through the company’s acquisition. Then Horizon3.ai, running the application platform organization at a Series C cybersecurity company.
Conservation cost-benefit analysis, portfolio rebalancing, market-data normalization, grain hedging, consumer-goods operations, autonomous penetration testing. If you had told me at any one of those jobs that the next one was coming, I wouldn’t have guessed the industry.
What transfers
The obvious answer is the engineering fundamentals, and that’s true but incomplete. Yes, a well-designed data pipeline is a well-designed data pipeline whether it’s moving satellite imagery or vulnerability findings. Postgres behaves the same way under load in agriculture as it does in security. The mechanics carry over for free.
The more valuable thing that transfers is a set of shapes. Most engineering problems are variations on a smaller number of underlying structures, and once you’ve seen a structure in two unrelated industries you start to recognize it everywhere. Normalizing twenty vendors’ stock data into one schema at Quantopian is the same shape as reconciling third-party transport and pricing data at Indigo, which is the same shape as making Salesforce the single source of truth for what a customer is entitled to at Horizon3. Different words, different stakeholders, identical problem: many upstream sources of truth that disagree, and a business that needs one answer.
Once you see problems as shapes rather than domain-specific puzzles, a new industry stops being intimidating. The grain marketplace looked nothing like the trading platform until I noticed it was a matching-and-pricing problem with three parties instead of two. The entitlements work at Horizon3 looked novel until I recognized it as the same reconciliation problem I’d been solving since my second job. Every industry hands you a fresh vocabulary, but the vocabulary sits on top of structures you’ve probably met before.
The other thing that transfers, and this took me longer to appreciate, is the ability to learn a domain quickly and deliberately. The first time you parachute into an unfamiliar business, learning it feels like drowning. By the fourth or fifth time, learning the domain is itself a repeatable process. You know to find the people who understand the money, to ask what the business actually sells and how it gets paid, to trace one transaction end to end before touching any code. Domain ramp becomes a skill you practice, not a tax you pay.
What doesn’t transfer, and why that’s the point
Domain intuition does not transfer. When I moved into agriculture I did not know why basis risk mattered or how grain moves physically from an elevator to a buyer. When I moved into cybersecurity I did not know what a pentest operation looked like from the inside or why customers cared about the difference between a host and an asset. That knowledge is earned, and there’s no shortcut. For the first few months in any new industry, the people around you know things you don’t, and pretending otherwise is the fastest way to lose their trust.
I’ve come to think the non-transferable part is exactly where the value is. If domain intuition carried over, industry-hopping would be trivial and unremarkable. It’s precisely because each business has real, hard-won specifics that walking in without them forces a discipline most people skip: you have to actually ask, actually listen, and actually understand before you build. Engineers who’ve been in one industry for a decade often stop asking, because they already know. Sometimes they know something that stopped being true two years ago.
Arriving without domain intuition also means arriving without domain assumptions. In agriculture I asked questions the veterans had stopped asking because the answers were obvious to them, and once in a while the obvious answer was wrong or outdated. The outsider’s naive question is occasionally the one nobody has re-examined in years. That’s not a reason to hop industries, but it is a real asset the hopper brings, and it fades the longer you stay.
The outside perspective is a portable asset
The single most useful consequence of working across industries is that you carry solutions between worlds that never talk to each other.
Financial-services engineering had rigor around correctness and auditability that most consumer companies would consider excessive, because in finance a wrong number is a real loss. When I moved into e-commerce, that instinct for treating certain data as load-bearing came with me, and it was genuinely differentiated in a place that had grown up moving fast. The reverse was true too. The velocity and experimentation culture of consumer software would have been a gift to some of the more cautious environments I’d worked in earlier.
At Horizon3, the reconciliation patterns from finance and trading shaped how I thought about making one system the authority on customer access. The data-normalization work from quant trading shaped how I thought about pipelines that had to absorb messy upstream sources. None of that was cybersecurity knowledge. It was pattern inventory built up in five prior industries, applied to a sixth. A person who had spent their whole career in security would have brought deeper domain intuition than I did and a smaller library of cross-industry patterns to draw on. Both are valuable. They’re just different bets.
What it costs
I don’t want to pretend this is free, because it isn’t, and the honest downsides are why the standard advice exists.
Every move resets your credibility. The domain expertise you spent two years building doesn’t come with you, and you walk into the new place having to prove yourself again to people who reasonably wonder why your background is a scavenger hunt. Early in my career I felt that acutely, and I spent energy defending the path instead of using it.
You also forgo the deep compounding that comes from staying. The engineer who has been in payments for a decade has intuitions I will never have about payments, because I keep leaving before that depth sets in. If your goal is to become the definitive authority on one domain, hopping is the wrong strategy, and no amount of pattern-matching makes up for it.
And it can read as a lack of commitment if you can’t articulate the thread. A résumé that touches six industries invites the question of whether you finish things or just get bored. The way through that isn’t to hide the hopping. It’s to make the throughline explicit: I’ve consistently done the same kind of work, building and scaling backend and platform systems, and I’ve done it against six very different problem domains on purpose.
When it’s a differentiator and when it isn’t
The hopping is a differentiator when the role rewards range: platform and infrastructure work that spans many product areas, leadership roles where translating between technical and business stakeholders is most of the job, early-stage environments where the domain is still being figured out and pattern inventory beats domain depth. In those settings, having solved the same structural problem in five industries is worth more than having solved five different problems in one.
It’s a liability when the role rewards depth: a domain where regulatory or technical specifics take years to internalize and where being wrong is expensive, or a role explicitly hiring for someone who already knows the terrain cold. I wouldn’t hop into a role like that and expect my range to cover for missing depth, because it wouldn’t.
The mistake I made for years was treating my own history as something to apologize for. What I’d tell a younger version of myself is that the pattern only reads as aimless if you let it. Done deliberately, moving across industries builds a specific and portable capability: the ability to walk into an unfamiliar business, learn it fast, recognize the underlying structure fast, and bring solutions from worlds that would never otherwise meet. Depth in one domain is a strong bet. Range across many is a different bet, and in the work I do, it has paid off more often than it has cost me.