I recently opened a print preview of my CV. Almost seven pages — well over 10,000 characters. At that point you’re no longer holding a résumé, you’re holding a white paper on your own career. Do you expect a recruiter to read that?

The reason I even looked? I’m currently preparing for new assignments. And that means dusting off the CV, something most of us only do when we need to. Republishing it, rewriting it, review its structure and readability.

Beyond Jobs and Dates

A CV is not just a list of jobs and dates. It is a story, a personal timeline of work, choices, and growth. Some chapters are long and steady, others are short, intense, and full of change. Some read like turning points, others more like side quests.

And it is not only about employment. It is also about what kept those jobs possible, the trainings and courses that added new skills, and the private efforts that quietly shaped the professional ones. A CV holds more than positions — it holds the context around them.

The challenge is that stories have different versions depending on the audience.

• The full edition: the long CV. This is the archive, the complete record, everything that shaped you. It can run six or seven pages without apology.
• The condensed edition: a résumé. One or two pages that show the highlights, the turning points, the impact. Enough to get attention without drowning the reader in detail.
• The blurb: a short profile or summary. The “back cover text” that sparks curiosity and leaves room for conversation.

The trick is not just cutting text, but considering perspective. The same story can be told as a chronicle, as a highlight reel, or as an elevator pitch. Each version has its place and, perhaps, its own audience.

Working through mine reminded me of something important: the CV is not only for others. It is also for yourself. It forces you to step back and reflect. To connect the dots across years and projects. To see the through-line that might not have been obvious while living it.

That is why I now think of the CV as a living document. Updating it is not a chore. It’s a chance to look back, to take stock, and to think about where you’re going next.

While that is true it also raises another question, do I write a 20 pages life history based upon what is in my CV? I could, most of you who read this could also, maybe some have. It would not be for HR or ATS systems though, but for friends and relatives to read about what you did in that circumstance on that workplace.

Food for thought.

Repost from LinkedIn

This spring, I hit two milestones: 60 years of life, and 30 years in IT.

One says I'm getting old. The other says I'm just getting better at fixing things people shouldn't have broken in the first place.

This isn't a CV. It's a glimpse at what I've learned, built, broken, and survived — from retail stockrooms to server racks, from modding forums to public healthcare, from an IBM Aptiva to AI. It's also a thank-you to the systems, users, leaders, and digital worlds that shaped my perspective — namely, that formal training is nice, but lived chaos teaches faster.

You know who you are, you are still here – with very few exceptions, right there in my connections list.

I've spent three decades navigating the digital world — building, breaking, fixing, and occasionally muttering at machines until they listened. From shell prompts to diagnostic platforms, CMS systems to GDPR audits, and support tickets to strategic headaches, I've seen the loop from both ends. These days, I even let AI help me write things like this. Not because I need it, but because it's a damn useful tool — when guided by experience and the knowhow that hopefully goes with it.

I enjoy new tech, but I look for what actually works. Practicality, usability, and — ideally — something you can implement without holding a séance. Shiny features are fine but give me a tool that doesn't panic in production. Curiosity and hands-on experience have taken me further than any buzzword ever did.

It started back in 1995 with an IBM Aptiva. Sure, I'd messed with BASIC in the '80s while helping out in my parents' perfume and cosmetics business in Mallorca. I managed stock, sales, logistics — and developed a lifelong skill for spotting when someone spends too much on makeup and too little on actually looking good. But the Aptiva? That was the turning point. Mine to break, mine to learn from. Windows greeted me with a crash. I greeted it with stubbornness. We've been in a relationship ever since.

After a few years of evening courses and technical dabbling, I launched my own consultancy in 2000 — CONRAM — because enough companies were asking for help and freelance sounded better than "doing everything without benefits." I built websites, packaged software, managed projects, and kept clients up and running, sometimes in spite of themselves. Java apps, MSI installers, duct tape logic — I worked across the board with outfits like Framfab and WM-data and learned what makes systems tick. Or stop ticking.

In 2007, I was picked for Mercedes-Benz SveDan as consultant and - at a later date - joined Poolia. Started in the trenches of helpdesk — answering tickets, chasing down locked accounts, plugging in cables that were definitely "already tried" and quietly building the processes and documentation everyone ignored until things broke.

Over time, I helped turn the chaos into a structured "proper" Service Desk and ended up leading it. Alongside that, I worked on GDPR compliance and helped scale our Citrix systems when COVID hit and remote work went from optional to absolutely necessary, practically overnight.

When the support services became outsourced, I moved on as a Field Engineer and eventually shifted again — working as a Technical Specialist with diagnostics and systems for the cars themselves. I handled Xentry, recall campaigns, and reporting to Transportstyrelsen to make sure things were safe, documented, and legal. Usually in that order. Somewhere there, I managed to keep track of multiple internal systems and still remember where I parked when at the office.

In 2021, I was headhunted from Poolia and Mercedes-Benz to join Öresund's IT — a small but well-regarded consultancy focused on IT, where I've finally felt professionally aligned. It was a welcome shift, and I remain thankful for it. That move also took me deeper into public healthcare IT — a world of different rules, older processes, and ancient systems, but similar general madness. It's a sector where change creeps forward under the weight of tradition, policy, and three layers of approval.

Professionals who can lead surgical teams and fix hearts and bones still lose to a forgotten Caps Lock. I'm mostly in second-line application support these days — handling access, chasing bugs, untangling integrations, and trying to explain why systems don't like being poked too hard. It's not flashy, but it's real, and it works — assuming the vendors don't implode and someone actually logged the error.

I've collected a few unofficial titles along the way. Forum admin for Teknikens Värld. Long-time contributor and wrangler for PHP-Fusion — support lead, release manager, Swedish site operator, and occasional herder of digital cats. I've chaired school boards, currently serve in elected office — yes, really — helped more people with their computers than I can count and spent an arguably unhealthy amount of time in the virtual Middle-earth of LotRO, and long before that, charting hyperspace jumps in Homeworld. Homdax and Marancil — nicknames known in their corners of the internet, not for rank or title, but for helping out, keeping things moving, and occasionally stirring the pot with a well-placed post. Not a developer, not a modder — just someone who stuck around, shared knowledge, and helped shape the conversation.

What's kept me going? Curiosity, for one. A certain tolerance for chaos. And the belief that if something doesn't make sense, it's worth figuring out whether it's just bad design, bad decisions, or something people have given up on too early. I may be 60 now, but I still find myself staring at new tools, systems, and interfaces wondering: what is this trying to do, who is it actually for, and could it have been made more intuitive somehow? Not necessarily better in a perfect sense — just more usable, less obscure, and less likely to summon spiritual guidance just to print a PDF — or trigger existential dread during a PowerPoint presentation.

Maybe the rope and the well in the image above is symbolic — or maybe I've just spent 30 years dragging systems, users, and occasionally myself back into daylight.

So here I am. Thirty years into IT. Sixty years into life. Still asking questions, still testing limits, still muttering at cables like they can hear me — and still convinced that turning it off and on again is the closest thing we've got to actual magic.

Introduction

Information technology support is essential for every modern business, yet it remains an underfunded, underappreciated, and high-turnover field. Despite its critical role in keeping systems running, support is often treated as an afterthought—staffed by new hires who rarely stay long enough to master the job, let alone improve it. This post explores three fundamental issues plaguing IT support: the relentless cycle of staff turnover, the loss of knowledge due to inadequate documentation, and the disconnect between support and technical specialists.

The Revolving Door – Where Good Technicians Go to Disappear

IT support functions like a well-oiled machine—not because it is efficient, but because people pass through it at alarming speed. New hires arrive, learn just enough to manage the most common issues, and then leave for better opportunities before they get too comfortable. The cycle repeats endlessly: recruit, train, overload with tickets, watch them leave, then start over.

The root cause is simple: cost. Businesses are reluctant to invest heavily in support, treating it as a necessary but expendable function. Salaries for first-line support are low [1], and career prospects within the role are limited, leading to most employees treating it as a stepping stone rather than a long-term career. As a result, the average employment tenure is often no more than a year or two [2]. Many use the role to finance their studies [3], further increasing turnover rates.

By the time an employee gains real experience, they realise they can earn more elsewhere or move up to a specialist role. This leads to an IT support paradox: those who get good at the job rarely stay in it.

The Knowledge Black Hole – Why the Same Problems Get Solved Again and Again

With employees cycling through support faster than documentation is maintained, knowledge transfer is minimal at best. Most businesses assume documentation will be written naturally as part of the job, which is as realistic as expecting users to read error messages before submitting a support ticket.

Even when documentation exists, it is often incomplete, outdated, or too generic to be useful. Studies have shown that documentation defects are common in software and IT systems, ranging from incorrect procedures to missing information [4]. Institutional knowledge disappears when experienced staff leave, and without proper documentation, new employees are forced to learn through trial and error [5].

Instead of structured documentation, most support teams rely on verbal instructions, scattered emails, and undocumented fixes known only to a few senior staff. These individuals become the sole custodians of critical knowledge—until they also leave, at which point the team must start from scratch.

The Great Disconnect – Why Specialists Never See the Full Picture

Support is meant to filter simple issues and escalate complex ones to system specialists. In practice, this process is flawed. Some issues that should be escalated never reach specialists because support staff do not recognise them as systemic problems. Instead, recurring issues are handled in isolation, with each technician resolving the symptoms rather than identifying the root cause.

There is also an element of hesitation when escalating. Support staff do not want to appear incompetent, so they attempt to solve issues beyond their expertise. This often results in workarounds rather than permanent solutions. By the time specialists do become involved, the issue has either escalated into a full outage or has been patched together with so many temporary fixes that identifying the original problem becomes nearly impossible.

When issues are escalated, specialists often dismiss them unless they are immediately reproducible. This creates a frustrating cycle where support reports an issue, only for specialists to claim they cannot act without further evidence. The result? Users are advised to "restart the system and see if it happens again."

Conclusion

IT support remains an essential yet deeply flawed function within most businesses. The high turnover rate ensures that knowledge is constantly lost, poor documentation exacerbates the problem, and the disconnect between support and specialists prevents long-term solutions. Businesses that fail to address these structural problems will continue to face inefficiencies, frustrated employees, and recurring technical issues.

Until companies prioritise knowledge retention, invest in sustainable documentation, and foster better communication between support and specialists, IT support will remain trapped in a cycle of firefighting rather than progress.

References

Some sources you can check, there are many more...

1. TechPays – Entry-level IT support salaries range between €30,000–€36,000 in most of Europe.
2. Centum Search – The average tenure in IT support is 1–2 years, often less in high-turnover environments.
3. Eurostat – A significant percentage of IT support roles are filled by students financing their studies or using the job as a stepping stone into better tech careers.
4. arXiv – Documentation is frequently outdated or inaccurate, leading to inefficiencies and repeated errors.
5. Doakio (2023) – Poor documentation significantly slows down new hires and increases operational costs. (Archived at Internet Archive)

About This Post

This post is both an exploration of IT support's fundamental problems and a humorous reflection on the realities of working in first-line technical support. While written with a cynical tone, the issues discussed are based on real data and research. The goal is to shed light on the challenges faced by IT support teams and encourage organisations to take a more proactive approach to improving knowledge retention, documentation, and communication.