Evolution of Modern IT Support

#ITManagers #ITSM

I wrote this after another round of interacting with the support team of a large IT provider. I came with a concrete problem: symptoms, versions, logs, and a reproducible case — everything prepared. The reply was polite and cold: “It’s not on our side. Please contact your local network engineers.” In other words — I was bounced.

This happens everywhere. At that moment I realized I had seen this picture before — but from the other side. I remembered my path: from a general IT support tech in the public sector to a Service Delivery Manager in an international company. I remember the time when one person fixed everything — from power outlets to software code. And I remember how, in big organizations, walls grow between teams: tickets go in circles, metrics look fine, but the service is still down.

Since then I’ve had a simple belief: support in the 21st century should be measured not by the number of “support tiers,” but by the speed and quality of recovery — and by continuous service improvement (CSI). Not “whose ticket is this,” but “who took ownership and drove it to the finish.” This is the main theme of the article: how to bring back integrity and speed to support without losing safety and process maturity. Below I explain what we lost on the way from the “One-person band” model to narrow specialization — and how broad skills returned as version 2.0.

When one IT person fixed everything

In the late 1990s and early 2000s, IT was rather closer to a craft than to a formal process. In small companies, one person was expected to “close the loop” end to end: pull and crimp a cable, reinstall Windows and bring up a domain, set up backups and write a script, fix a printer and repair a report in the database. “One-person band” wasn’t a metaphor; it was how you survived: fewer approvals, higher speed, lower cost.

This created a useful habit: think about the whole system. There were no queues or portals. If a storekeeper’s invoice didn’t print, you followed the chain: is there paper? any paper jam? is the printer on? is the cable/port OK? does the OS see the printer? is the print queue stuck? is the driver correct? is the print server available? did the switch go down? does the user have app permissions? is the database answering? And you keep going until the invoice comes out. The only thing that mattered was bringing the work back online as fast as possible.

Of course, that model had downsides. Reliability depended on personal heroics. Knowledge passed hand to hand. Documentation lived in people’s heads — or in a tools folder on a USB stick (if it existed at all). But I learned something I still value: if you can bring a system back to life in five minutes — do it; then figure out how to make the fix official and repeatable. I didn’t know the word “Agile,” but I worked in an agile way.😅

The big machine and the thick walls of specialization

Later I worked in a large national company. There wasn’t an IT “department”; there was an IT organization of about 500 people. Predictability, roles, processes, regulations — everything ran on rails. Along with that came thick walls of specialization between teams. I had to choose a specialty and became a DBA, even though I loved programming — DBAs were paid more back then 💸: backups and recovery, performance, HA/DR, patching, compliance — that became my world.

I saw the same story many times. At night performance drops; a ticket arrives — a user form “hangs.” DB monitoring shows rising I/O waits. I suspect storage and reassign the ticket to the storage team — an hour later it comes back: “no issues found.” I send it to the network team — an hour later it returns again. The ping-pong repeats, the problem stays. The SLA expires, and the person holding the ticket at the deadline looks “responsible.” A day later we discover the root cause: a tiny setting on one ERP node (servers I didn’t own at all).

Specialization is not the enemy. It gives deep expertise and quality. The problem is different: there’s no end-to-end ownership and no strong bridges between teams — no one who leads the request to the end and is accountable for the outcome. This is when I first truly felt that “correct” is not always “helpful” for the service.

“Correct” is not always “helpful”

I remember the feeling well: you do everything “by the rules,” and the service is still down. You hand off, wait for answers, request approvals — while people need it working now.

One night the warehouse stopped: shipments were blocked by a bug in a print form. Formally, it wasn’t my area. I found the form, reverse-engineered it in a dump editor, found the bug, fixed it — quick and straight to production. Five minutes later the line was running again, and the company didn’t lose hundreds of thousands of dollars. Formally it was the developers’ responsibility; at night they were asleep, and even if we`d woke them up, the fix would have dragged on until morning — because they play only by the rules.

This case — like the “one-person band” days — confirmed a core support principle: restore first, then normalize. The right sequence is: bring the service back as fast as possible, while logging your steps and notifying owners; then in the morning formalize the change, fix the code and docs, and briefly review the causes. That way, a heroic episode turns into a process improvement — and next time it’s not bravery that saves the day, but the system.

A team of “Universals 2.0”

When I became a team lead, I bet on managed breadth. Not “everyone does everything,” but each person can carry a task across a team boundary without dropping the ball. A developer isn’t a DevOps engineer, but can assemble a simple Jenkins pipeline for a new feature; later, a professional DevOps will refine it, but work doesn’t stop and we get healthy redundancy. A support engineer isn’t a back-end dev, but opens the git repo, reads logs, and explains the problem in code terms to developer; in simple cases they submit a neat pull request. A DBA isn’t a product owner, but can propose a safe workaround so the business doesn’t stall.

To make this work, we needed guardrails. Any change goes through a short pull request and review. Releases go out in small batches with a fast rollback option (release/change management style). Access follows the principle of least privilege. The team discusses the product regularly, including cross-functional topics. As a result, the whole team sees the product end to end.

The key effect: the useless loops disappeared. Where a request used to bounce between queues, it now moves in a straight line: one person takes it, calls in the right people, records the steps, and delivers the result. Speed grows not through heroics, but through real teamwork and a habit of seeing the whole system. Ownership stays: no matter who is fixing the issue right now, there is always someone who holds the full picture.

Full circle — but on a higher level

We really did return to breadth — but consciously. “Universal 2.0” is not a person who does everything alone; it’s someone who drives a task to the result, understands neighboring parts of the system, and brings in the right people at the right time.

A short manifesto of modern support

1. Own it to the finish. Every request has an owner until it is done.
2. Speed with quality. Restore fast, but keep quality under control.
3. Managed breadth. T-shape skills, guardrails, paired on-call, cross-training.
4. Transparency and learning. Blameless RCA (root cause analysis), clean runbooks, updates after every case.
5. Metrics that matter. Measure not “how many reassignments,” but how fast and how reliably the service was restored.