Turn ten job descriptions into a weekly schedule you can actually follow.
The problem
You have picked a target role. Good. Now what? Most people go straight to a course catalogue and pick whatever looks closest, then study in whatever order the videos happen to be numbered. Three months later they know a lot about some things, nothing about others, and still cannot tell whether they are ready to apply. The missing piece is not motivation or material. It is a plan built from the role itself.
Why this matters now
There has never been more free IT learning material, and that is exactly the problem: with unlimited input, the scarce resource is your attention and the order you spend it in. Workforce research such as the WEF Future of Jobs report keeps stressing specific, demonstrable skills over general study, and community data like Stack Overflow's developer survey shows how normal self-directed learning has become. The people who get hired are rarely the ones who studied the most; they are the ones who studied the right things in an order that produced proof along the way.
The practical framework
A study plan is just a job description, translated. Five steps:
- Collect ten real postings for your one target role, in your actual market.
- Tally the skills. Every time a skill appears, add a mark. You will end up with a short head (skills in eight or nine postings) and a long tail (skills in one or two).
- Cut the tail. The head is your syllabus. The tail is noise for now.
- Order by dependency, not by interest. Some skills are prerequisites for others: operating systems and networking usually come before cloud services; identity before security tooling. Learn the ones other things stand on first.
- Assign each head skill a week and an artefact. One skill, one week, one small piece of proof. That is the plan.
The output should fit on a single page. If it needs a spreadsheet with tabs, it is a wish list, not a plan.
What beginners often get wrong
Building the plan around courses instead of skills. A course is someone else's ordering of a topic, designed to be complete rather than to match your target role, so following it end to end means studying plenty you do not yet need while missing things the postings actually asked for. Use courses as a resource for a skill on your list, not as the list itself.
The second mistake is planning by hours instead of outputs. 'Two hours of study a day' measures attendance; 'one documented artefact this week' measures progress. Only one of those survives contact with a busy week, and only one of them is visible to an employer.
A better path
Write the plan where you will see it, keep it to one page, and treat each week as a closed loop: learn just enough about the week's skill to attempt something, do the thing, write up what happened in a few sentences, then move on. Do not aim for mastery in week one; aim for a defensible first pass you can deepen later.
Review the plan every two weeks against fresh postings. Job requirements drift, your understanding of the role sharpens, and a skill that looked essential in week one sometimes turns out to be rare. Adjusting the plan with evidence is a sign it is working. Rewriting it from scratch every fortnight because you found a new roadmap graphic is not.
Example roadmap
What the tally looks like in practice for an IT support target (your market will differ):
- Appears in nearly every posting: Windows and basic troubleshooting, user account and access handling, ticketing and clear written communication, basic networking.
- Appears in about half: a cloud platform's fundamentals, remote support tooling, hardware basics.
- Appears once or twice: a specific vendor product, scripting, a niche compliance term.
That gives you roughly six to eight head skills. At one skill and one artefact per week, that is a two-month plan with proof attached, and a defensible answer when an interviewer asks why you learned what you learned.
What to do this week
- Collect ten real postings for one target role.
- Tally how often each skill appears.
- Keep the head, cut the long tail.
- Order the head skills by dependency, not by interest.
- Give each skill one week and one artefact.
- Keep the whole plan on a single page.
- Re-check it against fresh postings every two weeks.
How to tell it is working
Progress in an IT transition is easy to fake to yourself and hard to fake to an employer, so measure the things employers can see. You are on track when, each week, you can point to one new artefact (a lab note, a troubleshooting write-up, a small script) and explain it in plain language. You are on track when you can name your target role without hesitating and list the skills it asks for. And you are on track when your CV and profile use the same words as the job descriptions you are reading. If a week passes with hours of video but nothing you could show or explain, that is the signal to change the routine, not to push harder at the same thing. Keep a short log of what you produced each week; over a couple of months it doubles as both a portfolio and proof of consistency, which is exactly what a hiring manager wants to see from someone changing fields.
A realistic note on pace
Career-change advice tends to swing between two unhelpful extremes: 'anyone can do this in a few weeks' and 'you need a four-year degree first'. Both are wrong for most people. The honest answer is that it depends on your starting point, the time you can protect each week, the language you are working in, and the roles your local market actually hires for. Be sceptical of anyone promising a fixed timeline, instant placement, or a specific salary on day one; realistic guidance talks in ranges and trade-offs, not promises. What you can control is consistency and visibility: small, steady, documented progress toward one clear role beats sporadic bursts of enthusiasm aimed at everything at once. Protect a few focused hours a week and defend them like any other commitment, because steady beats heroic almost every time.
Turn your non-IT experience into an asset
If you are coming from manufacturing, hospitality, retail, logistics, finance, administration, customer support or the trades, you are not starting from zero. Those jobs build exactly the skills IT teams complain are missing: calm problem-solving under pressure, clear communication with frustrated people, documentation, prioritisation and reliability. The mistake is to hide your old career as if it were an embarrassment. Instead, translate it. 'Handled escalations on a busy shift' becomes evidence you can triage and de-escalate, which is most of helpdesk work. 'Reconciled daily figures' becomes attention to detail and process discipline. Write one or two lines per past role that map a real responsibility onto an IT-relevant strength, and use them in your CV and interviews. Career changers who do this well often interview better than fresh graduates, because they can talk about real situations, real stakes, and real people.
Where SHIFT 2 IT fits
Inside SHIFT 2 IT, I go deeper into turning your current background into a realistic roadmap toward your first target IT role โ including how this fits the bigger sequence of learning, proof and positioning.
Final thought
A study plan built from real postings does two things a course catalogue cannot: it tells you what to skip, and it tells you when you are ready to apply. Let the role write your syllabus, and studying stops feeling like an endless queue and starts feeling like progress toward one specific job.
Key takeaways
- Build the plan from job postings, not from a course catalogue.
- Tally skills; keep the head, cut the long tail.
- Order by dependency, not by what looks interesting.
- One skill, one week, one artefact โ on a single page.
- Re-check against fresh postings every two weeks.
If you are planning a move into IT, start by choosing a target role before choosing certifications.
This article is part of my SHIFT 2 IT series for people moving into IT realistically.
Top comments (0)