People often liken companies, or even entire industries, to tall buildings. You’ve probably been advised to get your foot in the door, get in on the ground floor, work your way up, and make it to the top.
Software is different. Its abstract nature and broad applicability give software engineers a network of back alleys, or perhaps skyways, that let us move from one industry to another with relative ease. There are of course specializations—like a data scientist knowing Pandas inside out, or a game developer being a whiz with Unreal Engine—but the principles truly are the same, and they translate well across an astounding range of applications.
Domain expertise is nice to have, but the real art of engineering is fundamentally abstract. It’s about the application of technology to solve problems, more than the particular tech or problems. It’s something many non-engineers take for granted, because when it’s done well, they’re not even aware that it’s happening. Imagine how unpleasant it is for a new PM to slowly realize that everything is broken by default, and that the only way great software happens is for skilled human beings to work hard constructing it. “Why can’t you just fix this bug for me?” “Why is this simple feature taking you a month to implement?” Bad news, valued coworker: There’s no silver bullet.
Even hiring managers who should know better often focus on experience with specific tech stacks, rather than the more important question of whether a candidate is good at the actual discipline of engineering. “I see that you know Ruby on Rails, but we’re looking for a Django expert.” Learning languages, frameworks, and tools is not the hard part of engineering. The hard part is managing complexity. It’s breaking problems into pieces, solving those pieces independently, and stitching the solutions together to create something wonderful.
If you’re a software engineer who feels trapped, don’t be afraid to interview for jobs in a completely different industry. If you’ve made a career change and are realizing how much you don’t know, be reassured that lack of domain knowledge does not mean you’re an impostor. If you’re a good engineer—if you’re inspired by the potential of technology to solve real problems, and relentlessly focused on applying it to do so—you’re going to be terrific. As for “making it to the top,” remember that only you get to decide what that means.
Edited
As always I love your posts. I think this discounts one variable. The idea that especially at a startup, you're hoping at minimum to reach your cliff and at maximum join on the ground floor, so you can get opportunities that are greater than you could have otherwise gotten on the open market. It takes really confident leaders to listen to the message and not the messengers, so usually, even talented people need to build trust with the decision makers. The other thing this requires usually is the experience from both the business and engineering to know that sometimes the lead time of someone learning a language or framework is better than the churn of not having good problems solvers. I have experienced this problem over and over - a big benefit of being a consultant. I agree that over longer time horizons, your premise is 100% accurate, in my experience. Unfortunately, we live in an inefficient world, where often symptoms alleviation is valued more than cure. : (