TL;DR: Hiring managers want candidates that can learn. Even if you formally learned a technical skill, the job is going to be different than what you learned. That is a fact. Whether you have more to learn or less to learn, you will have to learn on the job. So the key to getting any job is showing that you can learn. Presence of mind is the biggest factor for any company worth their stuff. Plus, a good place of work will invest in your skills with training.
Technical skills.. schmechnical skills?
When you show a certification or a degree, you demonstrate that you know how to do some thing. It proves you have a piece of knowledge. This is important, and knowledge is of course necessary for all lines of work in some capacity – but it does not prove you can adapt, that you can ask relevant questions, that you get it.
This is what people mean when they say "the education system is broken", "they're just teaching you to regurgitate information", "we need to be teaching critical thinking in schools" – in too many cases, high marks in school are explicitly tied to an ability to demonstrate knowledge. But if knowing was all it took, why has Wikipedia not run every occupation out of business?
It is not enough to know how to solve an equation, to write code, to replace a roof. The critical part of any job lies exactly outside of the job description: it's in the human interaction. It's in the communication; requirements gathering; consideration for others' needs.
Okay, but like, Comcast literally tracks my clicks to make sure I'm solving customer cases. How does that have to do with human interaction?
Yeah and Comcast sucks!! Seriously, Comcast suuuuuucks!!!
You can divide all roles along the dimension of dynamicity: will you be doing the same thing over and over again? Or will you encounter a new problem that you will be expected to navigate, learning and balancing the needs of those around you along the way?
More importantly: which of those two roles do you want to spend doing 40 hours a week working at?
I repeat, Comcast sucks.
Specifically, Comcast and other companies like it manage out any autonomy and ingenuity, by design. They take a Henry Ford, assembly-line view to work and workers and they break roles in places like support centers down into scripts. They make it so that "anyone can do it".
Same for Amazon warehouses and deliveries. Same for software developers at Oracle (there's a reason for the term "code monkeys"). Same for can crushing facilities. It is soda pressing! (.."So depressing")
The work doesn't have to suck, but the way those jobs have been crafted, they sure do suck.
Why are you talking about Comcast?
Fair question – let me bring it back here: technical skills say you can do a task. But they do not say you can take new information, needs, and context into account. And, importantly: any work where you repeat the same tasks without a clear service to others, without ownership over your work, or without novelty to it will suck.
Don't get me wrong, even with all of the things above going right, work can still suck. But without them, it will definitely suck.
Why good leaders don't care about (all) technical skills
I was a hiring manager at a few different companies, from the logistics space all the way to fintech. I would have made the same hiring decisions across all of those teams. Regardless of the context – warehouse or office, packages or loans, inventory management or API support – the people that will do the best job are the people that can try something new, learn from that experience, and get better the next time. They're the folks managers and companies want and need to invest in.
The people that were the most successful were always the ones that could learn. Show you have good sense, and the world is yours.
You've already had to learn on the job
I see two possible scenarios for how starting your career went:
-
You learned a concrete technical skill in a formal context, maybe you got a degree or certification in it. But when you started the job, you found that the tangible work of it was different from school. You had to be taught, or had to learn by doing, how to do the tasks of the job.
-
You did not learn a concrete technical skill in a formal context, so when you found yourself a job, you had to be taught, or had to learn by doing, how to do the tasks of the job.
In both cases, you showed that you can learn on the job, and what's more you had to. There are no roles in existence that do not require you to learn on the job.
The key to making a change in your career isn't showing that you can already do the job, it's showing that you can learn how to do the job.
Cool, so how do I show I can learn?
Look at your work history, think about the things you had to learn. The recruiters and hiring managers will come to you with prompts for stories of how you approach problems. They'll ask how you've improved processes at your place of work. They'll ask how you resolved conflict. They'll ask how you took the initiative.
Ultimately, all of these questions are coming back to one idea: how well do you learn?
They are not looking for stories where you immediately knew the right answer. A stronger story than:
I changed the format for sending escalations to warehouse managers; we saw these escalations resolved 40% more quickly.
is:
Initially, all escalations were written free-form, so there was no structure to them. I started off defaulting to a sort of letter-writing format. I found the information I packed in there was often missed, so we ended up having a lot of back and forth. Bit by bit I adjusted how I would write these escalations, ultimately moving toward a split approach: I would have one section with a bulleted list of what was being asked, with a second section outlining the reasoning. I asked the folks in the warehouse for feedback and heard that they did appreciate having both: they wanted the at-a-glance information, but having the reasoning also built a lot of trust between the support team and the people touching the product. When we reviewed how this impacted resolution time, we actually saw this format sped it up by about 40%; we rolled it out to the team after that.
I will concede, the detail provided in the second example (which reflects a real scenario I experienced at the logistics company) is longer. It is less concise. But it gives so much more clarity on the thought process, it gives enough information for the other person to see how I came to the solution; a great outcome without a reflection of how you got there makes it seem like a fluke. A great outcome with an explanation shows a pattern.
Showing that you have the ability to try, test, and tinker in a thoughtful way is miles better than stumbling upon a single solution without an idea as to how. Stating you improved an outcome shows you could solve one thing. Explaining how you tried, learned, and improved shows you can solve anything.
What now?
How does this resonate with you? What has your experience been? I want to hear in the comments below. Let me know your thoughts.
Want more career change guidance? Check out the full career transition handbook.
Let's make work suck less.