Change Industries, not Roles
There’s a somewhat hidden career move that I’ve seen far too many people be completely unaware of. It’s the type of move that can often result in careers leaping forwards ahead of their peers, and it’s one that I want to talk about.
Specifically, I’m talking about making changes across industries, not roles or levels directly.
Often, when we think about how we can best improve our knowledge and capabilities, we focus on things like soft skills. How well we can teach others or how well we can learn a new language or framework. This is very good, it’s certainly not something that we should avoid. But this can also significantly harm the trajectory of your career. You’ll see different things and level up - maybe become a manager or take on some big projects because you have some kind of esoteric knowledge about the c compiler or specific aws services - and that’s good! But at the same time, you become incredibly siloed. Your knowledge becomes hyper linked to a specific kind of area, whether that’s the Australian marketplace, or healthcare, or remote working. Useful, yes, but also limiting.
Personally, I think that taking the time to consciously change industries, taking the time to actually put in an effort to identify the ways in which you can make a change to an area that you have as little knowledge or understanding of (within reason), can lend itself to giving you the single biggest breakthroughs of your career.
Consider just a single slice - technical versus non technical companies. Technical companies (for a developer), are some of the most highly sought after locations to work. They’re stereotyped as having the best technological problems, having the coolest offices and working with the smartest people in your field. Certainly, this is true. I don’t doubt that some of the smartest programmers I’ve met have been in big tech often for the entirety of their careers. But there is an alternative side that is just as important to understand.
Technical companies are more likely to bias towards quantity and speed rather than quality
Virtually all successful technological companies today operate under the idea of building fast. Ship fast and break things is the famous facebook motto. This leads to an obvious expectation to be constantly pushing out new code as fast as you humanly can, with little care for the actual quality of what comes out. After all, the cost to actually deploy a change to fix the problem that you caused is relatively low. Google in fact tracks errors as a goal to hit, not something to be afraid of. The view is that if your service is never having problems or experiencing some kind of outage, you’re probably being too conservative in your approach. This might sound hyperbolic but it’s not! Now, that’s not to say that Google engineers have carte blanche to bring down YouTube on a wild attempt at improving latency. The specific numbers and formats are almost always worded in terms of SLOs like “Average latency under 5ms” or “Percentage of successful video uploads” with a target of 1 in a million. These kinds of approaches are generally speaking usually best employed at companies with both Google’s scale and maturity, so that if a team “over spends” and accidentally does bring down YouTube, they can at least recover relatively quickly
But this is a mindset that is likely literally impossible to appear in many non technical companies, where the goal is often the exact opposite. Make as few problems as you can, which often goes hand in hand with the idea that you should be releasing as few changes as you can into production - because changes require significant overhead. Approvals from different people and guarantees that nothing will go wrong that could cause unexpected issues or negative customer feedback. Often non technical companies lag behind the tech world by many, many years in terms of even the same processes. See: non tech’s love of scrum compared to big tech’s at best apathy and at worst outright disdain for the practice.
You could imagine yourself working in a tech company for a decade or more, biasing towards releasing as often as you can, suddenly finding yourself working for a medtech company. Maybe one where your software interfaces a lot with physical hardware. In this kind of environment, you can’t just deploy a change and fix it later. Infamously a bug in the Therac-25 machine literally killed a person. Even ignoring the ethical concerns, just testing things may take longer. Unit tests take seconds, end to end testing minutes or hours. Physical testing may take days. In this kind of environment a lot of the attitudes that turbocharged your career will now place it in serious jeopardy, and it’s something that you may never have truly understood without actually entering that environment.
Locality of Ownership
Tech companies tend to have a significant bias towards ensuring that the person who is best suited to resolve some kind of pain (Such as a noisy alarm or a feature causing negative customer feedback) is actually the one on the receiving end of that pain. They can’t just hide several layers away from the impact of their work (or lack thereof). They will be made to (in some way), actually feel the impact of what they need to do, so that they can resolve the problem as quickly as possible. Something which can often be sorely missed in non technical companies, where the idea of having developers on call could be thought of as strange, absurd, or even patently unheard of.
This directly leads to significantly longer cycles in nontechnical companies (because problems take longer to be visible), and often results in larger problems (because by the time they’re visible they’re more difficult to solve properly). It comes from a place of fundamentally misunderstanding how value is created in software. To non technical companies all too often software is a polarised function. Some staff create, and others maintain. You have developers to create your application, and support staff to help customers resolve issues. This is wrong, and directly leads to developers creating more problems as a result. The two functions ultimately have misaligned incentives. One side wants to create as much as they can. The other wants to block as much as they can so that they can ensure their own goals aren’t being impacted.
I’d like to say that because I’ve seen both sides of the fence, I’m able to see these things, but I’m fully aware there are my own silos that I’m unaware of. There are industries and places that I’ve never worked in that are almost certainly completely different to what I’ve seen.
I often think back to a conversation I had at one point in my career. I was talking to somebody and I briefly mentioned that I was surprised that we had a monthly release cadence, which was tightly controlled and scheduled. I said that we should be focusing much more of our effort into doing weekly, or even daily releases. This person’s response was immediate: “Oh you want us to be like google!”. It gave me a keen insight into their mind and their thinking. Because at the average tech company, the idea that they might only release once per month would have been a major aberration - maybe due to regulatory concerns or physical limitations. Something I considered incredibly normal and mundane, was something only the best of the best could do to someone else.
This is ultimately what I find most exciting when I think about the next ten or twenty years of my career. More and more companies are changing how they work in completely new and unexpected ways, and that change is what people should look for when asking themselves if they’re in the right place, or if there is something that they’re missing out on elsewhere.