DEV Community

Cover image for The First 90 Days of Learning IT
Andreas-Christian Hetzl
Andreas-Christian Hetzl

Posted on • Originally published at shift2it.hashnode.dev

The First 90 Days of Learning IT

A realistic 12-week structure that turns enthusiasm into visible proof.

The problem

You are motivated now, but motivation fades, and without a structure the first three months of learning IT dissolve into random videos. A realistic 12-week shape keeps you moving and produces proof along the way.

Why this matters now

With more people self-teaching IT, the people who succeed tend to be the ones with a plan, not the ones with the most enthusiasm. A clear 90-day structure, anchored to a target role, turns scattered effort into visible progress you can show employers.

Three months is also about the honest minimum to go from zero to a credible first application, and about the maximum you can run on motivation alone before it fades. So the plan has two jobs: cover the fundamentals a first role actually needs, and leave a visible trail of proof behind you, so that by day 90 you have something to show and not just a browser full of half-watched tutorials.

The practical framework

Twelve weeks, four phases, proof at every step (adjust to your target role):

  • Phase 1 (weeks 1-3): foundations. Computer and operating-system basics, plus your first documented home lab.
  • Phase 2 (weeks 4-6): connectivity and identity. Networking and identity basics; two troubleshooting write-ups.
  • Phase 3 (weeks 7-9): cloud and security hygiene. A cloud fundamentals path plus basic defensive hygiene; annotated screenshots.
  • Phase 4 (weeks 10-12): proof and positioning. A small script, a learning log, and a CV and LinkedIn rewrite around your target role.

Two rules hold the whole thing together. First, spend roughly 70% of your time doing and only 30% watching or reading: the doing is what sticks and what becomes proof. Second, each phase has one concrete output you finish before moving on, so you are never tempted to restart Phase 1 for the third time because it felt safe. If you can only protect a few hours a week, stretch the calendar rather than skipping the outputs; the order matters more than the dates.

What beginners often get wrong

Consuming content without producing anything, and switching topics whenever the next shiny tutorial appears. Input without output feels like progress but leaves you with nothing to show.

The other classic failure is the 'week 1 forever' loop: restarting the basics again and again because starting is comfortable and finishing is not. Related is tutorial-hopping across three courses at once, which spreads you thin and produces no single completed artefact. The cure for both is the same: pick one path, finish this phase's one output, then move on, even if the output is rough.

A better path

End every week with one small artefact and one sentence of reflection. The artefacts become your portfolio; the reflections become your learning log; together they prove direction and consistency.

A weekly rhythm that fits around a job or family: one short session to learn the week's topic, one longer session to actually build or break something, and fifteen minutes at the end to write up what you did and what confused you. Miss a week? Do not restart, just continue; a plan you can return to beats a perfect plan you abandon. Track it somewhere visible, even a single checklist, so the progress is real rather than remembered.

Example roadmap

Use the four phases above as your 90-day skeleton, and attach each week to the skills your ten target job descriptions repeat. The plan is a shape, not a guarantee; your background and target role will move the emphasis around.

Made concrete for an IT-support target: weeks 1-3 you install an operating system in a virtual machine and write down every step and error; weeks 4-6 you set up basic networking and user accounts and turn two real problems into ticket-style write-ups; weeks 7-9 you open a cloud free-tier account, deploy one small thing, and practise patching and backups; weeks 10-12 you write a short script, tidy your notes into a learning log, and rewrite your CV and LinkedIn around the role. Twelve weeks, one artefact each, and a portfolio that did not exist in January.

What to do this week

  • Pick a target role before week 1.
  • End each week with one small artefact.
  • Write one sentence of reflection per week.
  • Do not switch topics mid-phase chasing novelty.
  • Rewrite your CV and LinkedIn in the final phase.

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

Ninety days is enough to build real foundations and visible proof if you trade enthusiasm for structure. The goal is not to finish IT; it is to become a credible applicant for one role.

Key takeaways

  • Structure beats enthusiasm over 90 days.
  • Four phases: foundations, connectivity, cloud/security, positioning.
  • Produce one artefact and one reflection every week.
  • Anchor every week to your target role's repeated skills.

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)