Where Support Work Ends and Engineering Begins

Every support desk has someone who closes more tickets than anybody else, and every desk also has someone who got the title change. They are rarely the same person — and the difference has almost nothing to do with how fast they type or which certificate hangs on the wall.

You can watch the split happen in a new hire's first month. Two people get the same queue and the same broken laptops. One becomes very good at making symptoms disappear. The other becomes an engineer. Same title on paper, different career.

The second question is the one that separates people

Somebody's laptop will not connect to the office wifi. The support tech rejoins it, confirms the internet works, closes the ticket. That is a correct answer, and the user is working again.

The other person does the same fix, then asks a question nobody asked: why did it drop the profile at all? That question usually leads nowhere. But once a month it leads somewhere real — an overnight driver push, a DHCP scope quietly running out of addresses, a certificate expiring on a Sunday. Suddenly a fix you were about to repeat forty times this quarter does not need to be done at all.

Restoring service is the job. Understanding why the service left is the part that turns into a career, and it is on no ticket, no SLA, and no dashboard. You have to decide to care about it.

Ownership that survives the ticket closing

The tell I trust most is what happens after a problem is marked resolved. A support mindset ends at the close. The issue is gone from the queue, the user stopped complaining, the box is ticked. A month later the same fault returns under a new ticket number, handled by a different person, solved the same shallow way.

An engineer treats recurrence as information. The second time a machine loses its mapped drives, they do not just remap them — they go read the group policy, or ask what changed on the file server last Thursday. They also do the unglamorous thing of writing it down where the next person will look, because they have been that next person at 7am.

Nobody assigns that work. It is invisible on any report, and the clearest signal of who will run the infrastructure in three years.

The small tool nobody asked you to build

Every desk has a task that eats twelve minutes a day. Creating accounts for a batch of starters. Pulling a licence report for finance. Checking which machines have not phoned home since the last update. Twelve minutes feels small enough that you never count it, which is exactly why it survives for years.

The support tech absorbs it as part of the day. The engineer notices the rhythm and resents it slightly, then writes thirty lines of Python on a Friday to make it stop. The first version is ugly and breaks twice. After that, twelve minutes a day belongs to them again, and the whole team uses the script.

How the decision actually gets made

Promotions in IT are almost never awarded for ticket volume. Managers watch for something less measurable: who the other techs go to when they are stuck, who can explain a root cause to a non-technical manager without hiding behind acronyms, who says "I do not know yet, give me a day" and then comes back with an answer.

They also notice who escalates with a theory instead of a shrug. Handing a problem upward with three things you already ruled out is a different act from forwarding the ticket and hoping. The first reads as engineering. The second reads as a queue.

None of this means everyone should want the engineering track; some of the best people I have worked with chose to stay at the desk. But if you want to know which side of the line you are on, do not look at your title. Look at what you did the last time the same problem came back.

The difference between those two people on the Monday queue is not talent. It is a low tolerance for fixing the same thing twice.