The skills helpdesk never teaches you (but you'll need)

Last time: what the job actually is. This time: what you're missing. "Get more experience" is useless advice, so here's what actually closes the gap.

Diagnosing without a second opinion

On helpdesk, if you're stuck, you escalate — someone above you has seen it before. When you're the whole IT department, there is no tier two. You are tier two. Getting comfortable being stuck, alone, and working a problem methodically anyway — instead of waiting for someone smarter to show up — isn't a technical skill. It's a nerve you build.

Making decisions with incomplete information

In a big company, big decisions get reviewed by committee. When you're advising a 15-person company on a 40,000 kronor server refresh, that call is yours. Nobody checks your work. You need to get comfortable making a real decision, explaining your reasoning honestly, and being accountable for it — even at 80% certainty.

Translating technical reality into business language

A construction company owner doesn't care about RAID configurations. They care whether the crew can access the drawings tomorrow, and what this costs. Explaining problems in technical language to a non-technical person isn't precision — it's a communication failure. "Your data survives one drive failing, not two, and here's what that risk costs you" is a completely different skill from knowing how RAID works.

Prioritizing when everything feels urgent

On helpdesk, priority comes from a system — SLA tiers, a queue. Running the whole department, you get five things at once before lunch: a dead printer, an invoice question, a real security issue, an owner wanting to talk laptops. Nobody sorts that for you. You triage on the fly and say what can wait, out loud, without sounding dismissive.

Basic business literacy

You don't need an MBA, but you need to roughly understand how your clients make money and what a bad month feels like for them. Recommend a purchase without understanding that, and you'll keep proposing technically-correct solutions that get quietly ignored — without understanding why.

Writing things down, consistently

This one's personal. I once nearly broke my own company's website — editing files in one folder while continuously re-uploading an old backup from a different one. My changes kept disappearing, and it took me embarrassingly long to figure out why. Thirty years in, and a basic process mistake still caught me. Documentation isn't a nice-to-have — it's what saves you at 3am, troubleshooting something you haven't touched in eight months.

How to actually build these, starting now

Write down not just what you fixed, but why you chose that fix over the alternatives. Explain tickets to a non-technical friend and see if they actually follow. Ask to sit in on client or vendor calls, even if it's not your job to be there. Volunteer for the ambiguous tickets nobody wants. And every time you recommend something, ask what it costs and whether you could defend that number to a business owner.

None of this shows up on a certification — which is exactly why it matters. Everyone applying for this work already has the certifications.

Next: money. How you actually price yourself when you become "the IT guy," and how getting it wrong leaves you overworked and underpaid.