I've spent 28 years building software across industries that have almost nothing in common with each other. Flight control systems at a defense contractor. Consumer mobile apps that hit the top of the charts. Enterprise software serving global sales organizations. If you looked at those three careers on paper, you'd be forgiven for thinking they belonged to three different people.
They don't. And the reason they don't is the thing I keep coming back to: the work was never really about the domain. It was always about the architecture — understanding the deep structure of how a system, an industry, or an organization actually works, not how it presents itself on the surface.
Going architecturally deep
At BAE Systems, writing flight control software, I wasn't just learning a codebase. I was learning how defense programs are structured — the acquisition cycle, the way requirements cascade from mission need to software spec, the tolerance for failure (near zero) and the tolerance for change (also near zero). You could not be effective there without understanding why every process existed, not just what it asked you to do.
When I moved into consumer mobile, the surface looked completely different — fast cycles, viral loops, app store rankings, retention curves. But the underlying question was the same: what is the actual architecture of this system? In mobile, the system was the user. You had to understand human attention at a structural level. What makes someone open an app again? What creates the habit? I didn't learn that by reading theory. I learned it by shipping, watching the numbers, and asking why until the model in my head matched what the data was telling me. Several top-10 apps later, I had a working theory.
Enterprise software at Seismic was a third architecture entirely — one organized around organizational behavior, sales motion, and the economics of large B2B deals. The constraints are different again. Enterprise software doesn't go viral. It gets bought by a committee and deployed to thousands of people who didn't ask for it. That means the architecture of adoption matters as much as the architecture of the product. I had to rebuild my mental model from scratch, and I did.
The real skill is learning how to learn an industry
What I've come to understand is that depth isn't domain-specific. The capacity to go deep — to resist the shortcut of surface knowledge, to keep asking why until you hit the load-bearing structures of how something works — that transfers. It's slower at first. You spend the first year in a new industry feeling like you're behind. You are behind. But you're building something most people in that industry never build: an outsider's ability to see the whole system at once, combined with an insider's understanding of why it works the way it does.
That combination is genuinely rare. People who grew up in an industry often can't see its assumptions anymore. People who observe from the outside never get close enough to the real mechanisms. The engineer who has done both, in multiple industries, becomes something different: someone who can walk into a new domain and compress what would normally take a decade of experience into a year of very focused learning.
Leadership follows the same pattern
The same principle applies to leading people. Managing a team of defense-program engineers is structurally different from managing a consumer product team, which is structurally different again from leading engineering across a global enterprise software company. The org charts look similar. The actual work of leadership — what motivates people, what creates trust, what breaks it, how decisions should be made — is shaped by the industry context in ways that matter enormously.
I've had to rebuild my leadership model each time too. And each rebuild has made the model more robust, because I've had to separate the principles that are universal from the ones that are situational. The universal ones are fewer than most management books suggest. The situational ones are more important than most leaders acknowledge.
What I'd tell someone earlier in their career
Don't optimize for staying in a lane. The people who become genuinely hard to replace are the ones who have operated effectively in contexts that most specialists haven't touched. Every time you go deep in a new domain, you're not starting over — you're adding another dimension to a model that keeps getting more useful.
The discomfort of not knowing is the point. It's where the real learning happens. Get comfortable being the person who asks the obvious questions, because in a new industry, the obvious questions are the ones nobody who grew up there thinks to answer anymore.
The thread running through all of it — flight systems, apps, enterprise software — isn't a technology or a skill set. It's a posture: stay curious, go deep, and trust that the architecture of one thing always teaches you something about the architecture of everything else.
← Back