Broadly vs. Locally-useful skills
Broadly useful vs. Locally useful skills is something I don’t see discussed much.
We all talk about learning on the job, and how adding new skills is necessary. I agree, but I’d add a wrinkle. Learning things that you can apply broadly is valuable. So valuable that jobs where you learn a lot of broadly-applicable things can justify paying less, at least for a while. You are, after all, learning things that will help you make a lot more money in the future. That has value. Eventually if a company wants to retain people, it’ll have to recognize the value of the skills they’ve learned, but they may be able to be picky about who to keep.
On the other hand there are jobs where the skills you will learn are less applicable anywhere else. As an extreme, I’d think of some government and financial IT jobs where you might be working on bespoke COBOL-based, mainframe systems that are used only in that one place. The technology is well-established and you’re not likely to have the opportunity to learn much new about the foundational elements as those were defined decades ago and don’t move much. The tech is also less and less widely used with every passing year, so the skills you learn — while not becoming irrelevant anytime soon — are less relevant and needed in fewer places. Many of the old COBOL systems, especially in government, are unique to the organization. That makes it the worst of all worlds: if you go to work there, only your most general skills will translate to anyplace else.
If you take a job like that, if you’ve come in with any other skills (and yeah, that’s kind of unlikely unless you’re already in that space), they’re likely to atrophy because you’re not using them. That may be a valid tradeoff in some cases. Being a specialist in a narrowly defined field that few new people are entering can be a very lucrative place if you choose the right field and the right time. Being a specialist in a narrowly-defined and shrinking field can be pretty awful. Being a specialist in the things only one organization does is a recipe for career disaster. (But, if you’re close to retirement, it could possibly be a pretty neat way to wrap things up.)
Early in my life, I programmed on mainframes in COBOL and (mostly) some other languages. I’m sure I could do it again. But I’d be tossing away some highly valuable, broadly-applicable and current AWS skills that are worth a lot of money. Want me to to that? As a spiritual pilgrim once said to a penguin: “cough up some dough, mac.”
It’s not just technical skills. I try to remain as close to interesting tech as a I can, but my primary role is in program management. One of the things I’ve been thinking about a lot lately is how much the processes and tools vary across organizations. Working for AWS for a few years I acquired a lot of very widely applicable technical knowledge. Arguably, AWS can justify paying people less, at least for the first few years, because the payoff if you walk out the door with your AWS knowledge can more than make up for it.
At the same time, virtually all process and internal tooling at Amazon is bespoke. Moving to another company recently, I found myself completely out of place because I had never used Jira, had no idea what an OKR was or why I would want one, could not understand how a monthly report for a single 8-person team could run on to eight pages, and was shocked that they asked me to help put together slide decks.
[As an aside, if you use Powerpoint or any similar tool for routine internal meetings and communication, you should be drawn, quartered, flayed and dumped on Robert Gaskins‘ doorstep. One solid lesson I did learn at AWS is “put it in a doc, and keep the doc brief and to the point.” It’s surprising that something so blindingly obvious to anybody who’s done it isn’t obvious everywhere, but I think the Light Side is slowly winning.]
We only allow slides for presentations to 100+ people. Otherwise docs.
— Ryan Petersen (@typesfast) January 22, 2022
On balance, I think I should have been paying AWS (and probably was, in the form of below-market salary) for the tech education I was getting, but they should have been giving me at least a bit extra (which they weren’t) for the career costs of being stuck in tooling that made it harder to realize my value elsewhere. From what I hear, they’re now paying more. Also, they’ve at least gotten rid of Chime messaging in favor of Slack but that still doesn’t make up for the crime that is the “new wiki.” Small victories.
Most situations aren’t clear cut. If you’re in tech, you’ll find few organizations that run only broadly-used software stacks, so you’re going to run into bespoke tools and implementations. The closest I came was a client several years back who decided “we are going to move to SAP, we are going to only use SAP, and to keep our lives simple, we are going to reorganize our internal operations around the software because ERP and the functions it supports is not a differentiator for us.” They took a similar approach to their web presence, which was mostly promotional, and built it entirely on a standard commercial framework. The only place they put any special effort was in document management, which for their business was a critical capability.
One of the things that’s important when evaluating a job move is clearly understanding what the pros and cons of the learning opportunity will be. How much of it is broadly-applicable? How much of it is general skills and industry knowledge that can be broadly-applicable even if the specifics of the systems you work on are not? How much is purely in-house and inapplicable anywhere else? How much of your time will you spend on administration and overhead process that is organization-specific and doesn’t add any value to your experience at all?
To use an AWS example: understanding how the in-house integration/deployment system (Apollo) works isn’t applicable anywhere else. Understanding the benefits of CI/CD and more generally how it can be used is generally applicable, but you will have to come up to speed on other toolsets if you go elsewhere. Understanding how AWS VPCs and networking function is valuable to any company that makes substantial use of AWS tools, regardless of the specific development, deployment and operating environments built on top of them.
Where to draw the line varies. The considerations are different when you’re junior vs. senior, when if you’re in your first job vs. your last, if you want to limit yourself to a certain geographic location vs. becoming a digital nomad, if you have a family to feed and prize stability vs. single and ready to take chances. The amount of money offered and the other opportunities that go with the job also feed into how you should think about these tradeoffs.
When somebody I mentor is considering a new job, one of the things I ask them is “how much of what you’re learning would be applicable to some other company, and how much is not?” If the latter category is more than 30%, the potential employer needs to follow the advice given to the penguin, and cough up some dough. “Meet the market” is not sufficient when you’re asking people to leave valuable skills at the door, and in exchange offer the opportunity to acquire less generally-useful ones.