I made one significant career transition: out of academic research, after a PhD in biomedical engineering, into industry work building machine learning systems for medical products. On paper this looks like a short hop. It did not feel like one. The technical overlap was substantial and almost none of my difficulty was technical.
That experience is why I am sceptical of the standard skills-gap framework, which asks you to rate yourself out of five on a list of technologies, compare against a target, and generate a study plan. It is a satisfying exercise. It is also, for most pivots, solving the wrong problem — because what stops people is rarely that they cannot do the work. It is that nobody can tell they can do the work, and that they have misread what the work is.
It is worth saying that continuous retraining is not an exotic situation. The World Economic Forum's Future of Jobs Report 2025 estimates that a majority of the global workforce — around 59% — will need some form of training before 2030, irrespective of whether they change roles at all. Everyone is doing some version of this.
Job postings are not requirements documents
The first serious error is treating a posting as a specification. It is not. It is a document written by a recruiter, often adapted from a template, sometimes describing an amalgam of two people, frequently listing every technology anyone on the team uses, and routinely carrying a years-of-experience number that was picked to set a level rather than to state a threshold.
I have written these. The list in the posting is not the list in my head when I read applications.
So do not derive your gap analysis from one posting. Read fifteen for the same role across different companies, and pay attention to what repeats. The requirement that appears in all fifteen is real. The one that appears twice is somebody's local stack. The thing described in the responsibilities section rather than the requirements section is usually closer to the actual job.
Then do the thing that people skip because it is uncomfortable: talk to two or three people who currently hold the role. Not for a referral — for a description. Ask what they actually spend Tuesday doing, what they were unprepared for, and what someone from your background typically gets wrong. Half an hour of this beats a month of desk research, and it regularly reveals that the target role is not what you thought you were aiming at.
Knowledge gap versus evidence gap
Once you have a real picture, sort what is missing into two piles, because they need entirely different responses.
A knowledge gap means you genuinely cannot do it. You have never written production code, never run an experiment, never handled a client. This needs learning, which takes time you must actually budget.
An evidence gap means you can do it, or could within weeks, but you have no way to demonstrate it to a stranger. This is far more common, and it is the pile most career-changers misdiagnose as the first kind — which is why they spend a year on courses and remain unable to get an interview.
The responses diverge sharply. A knowledge gap closes through sustained practice on real problems with feedback. An evidence gap closes by producing one visible artefact: something built, something written, something shipped, a contribution to a project someone else maintains. That takes weeks, not years, and it moves you further.
For me, the pile that mattered was neither, quite. It was vocabulary and judgement — knowing what "good" meant in a commercial context, where the same technical work is evaluated against deadlines, regulatory review and maintenance burden rather than novelty. Nobody could have put that on a skills matrix, and no course teaches it. I learned it by being adjacent to people who had it.
What actually transfers
Career-changers systematically undervalue what they already have, because they are looking at the technology column.
From research, what transferred was not the subject matter. It was the ability to work on something for a long time with no feedback, to design a comparison that actually tests the thing, to read a paper critically and quickly, and to write down a complicated argument so that someone else can follow it. That last one turns out to be unreasonably valuable in industry and is in short supply.
Whatever you are coming from has an equivalent set. Teaching gives you the ability to explain and to hold a room. Operations roles give you an understanding of how processes fail, which is most of reliability engineering. Clinical work gives you a tolerance for ambiguity and consequence that most engineers never develop.
The catch is that transferable skills do not sell themselves. Nobody reads "eight years teaching" and thinks "excellent stakeholder communicator." You have to do the translation explicitly, in the language of the target field, attached to a specific instance.
Sequencing, honestly
Some practical constraints on the plan.
Do not learn more than two things seriously at once. Attention divides badly and half-learned skills do not compound.
Prefer depth in one thing over breadth across five. A hiring manager can evaluate depth. Breadth at a shallow level is indistinguishable from having read the documentation, and it is what most transition portfolios look like.
Learn in the order the work requires, not the order a curriculum suggests. If the role is mostly data plumbing with a little modelling, learn the plumbing first even though the modelling is more interesting.
Build the evidence as you go rather than at the end. The common plan — six months of study, then build a portfolio — front-loads the least useful part. Build something small in week three, badly. You will learn faster and you will have something to show if an opportunity appears early.
And add slack to every estimate. Learning something genuinely new while employed takes most people longer than they plan by a wide margin, and the plans that survive are the ones with room in them.
The move that beats all of this
The most reliable pivot is a sideways step inside your current organisation, and it is under-attempted because it feels like cheating.
Your employer already knows you are competent and already trusts you. The bar for moving you into an adjacent function is dramatically lower than the bar for an outsider, and in many places there is a formal mechanism for it. Volunteering for the project nobody wants that happens to sit in your target area is the cheapest transition available: you get paid to acquire the experience, and afterwards you have it on your record as employment rather than as a side project.
The reason people skip it is that it feels slower and less decisive than a clean break. It is usually neither. When I look at a candidate whose last eighteen months show them doing the new work inside their old company, I do not think of them as a career-changer at all. I think of them as someone who does the new work, which is the entire objective.
What to actually produce
If you want a deliverable from this article, it is not a matrix. It is a page with four things on it: the three requirements that appeared in every posting you read, the one you genuinely cannot do yet, the artefact you will build in the next six weeks that demonstrates the ones you can, and the name of one person in the role who has agreed to talk to you.
That page is worth more than any amount of self-rating, because every item on it is falsifiable.
Tags
Taresh Sharan