The Volcano That Was Never There

August 31, 2026 SupportTrenches Careers & Wellbeing 7 minutes

Years ago I was very comfortable in L2. Good numbers, good reputation, the kind of comfort where you know which log file lies to you and which one just gets confused. And I wanted L3. Badly.

There was exactly one problem with L3 at that company: it was the end of the pole. Nothing behind it. No L3.5, no "Advanced Advanced Support", no polite conveyor belt to somebody smarter in a different time zone. There was an L4, but L4 did support ops and red escalations - process people with fire extinguishers, not case work.

So the promotion looked less like a career step and more like a career cliff. Because L2 has a wonderful, unspoken superpower: the fence. Every truly horrible case - the intermittent one, the one that only happens on Tuesdays in one data center, the one where the customer's environment violates three laws of physics - can be documented, packaged neatly, and lofted over the fence. Not out of laziness. That is what the tier model is for. But it does mean somebody else eventually opens that gift.

At L3, I would be somebody else.

I spent weeks running the movie in my head. Me, typing "unfortunately, there is no solution" into a ticket. The customer reading it. The DSat (dissatisfied customer) survey arriving with a score that looks like a rounding error. Then management, holding a clipboard, gently guiding me toward an active volcano while thanking me for my service.

That is the fear nobody talks about in career-ladder conversations. It is not "can I do the work." It is "what happens when the buck stops at me and I am out of answers."

The sentence that fixed it

One of the L4 engineers - a man whose default facial expression suggested he had personally read every core dump ever produced - noticed I was stalling. He asked why. I told him.

He said, roughly: "don't worry. I did L3 for years, then L4. There has never been a dead end. Worst case, it goes to development."

Which, on the surface, is just "there is another fence." Fine. Comforting in a bureaucratic way. But that was not actually the useful part, and it took me a while to see it.

The useful part was the second thing he said, and it is the whole reason this article exists.

Every case ends up in one of six buckets:

1. It is a bug. Then it is not your problem to solve, it is your problem to prove. Reproduce it, isolate it, write it up so tightly that engineering cannot argue with it. Done.
2. It is a misconfiguration. Then you found the answer, and the answer is uncomfortable for someone, which is a different kind of work but still a resolution.
3. It is an unsupported setup. Then the answer already exists in a document somebody wrote years ago, and your job is diplomacy, not debugging.
4. It cannot be reproduced by anyone, ever, including the customer. And here is the part that surprised me most: given enough honest joint effort, customers themselves start saying things like "you know what, that was probably just bad luck."
5. It is a feature request wearing a bug costume. Always in disguise - if it had walked in labeled "enhancement request", somebody would have caught it at L1 and it would never have reached you. Instead it arrives as "the product does not work", which is technically true in the same way a bicycle does not work as a submarine. The moment you can name the missing capability, the case is resolved. Your job is to log it with the customer, the segment, and the count of who else asked, and hand product a problem rather than a spec. Not your job to build it.
6. It is political and several paygrades above you. Contract interpretation, a promise a salesperson made in a room you were not in, two VPs disagreeing about who owns the integration. You escalate, and then you watch an escalation manager visibly rolling his eyes because he is missing the big game for a debate that should have been settled on a golf course between two people who both know exactly what they agreed to. Painful, expensive, entirely out of your hands. Still not a dead end. Just a different kind of drainage.

That is it. That is the complete list. Not one of those outcomes is "there is no solution and I am personally to blame."

The reframe

I had been thinking about L3 as the person who must know everything. That is what makes the job look terrifying, and it is completely wrong.

L3 is not the last person who knows. L3 is the last person who classifies. The deliverable is not a fix. The deliverable is an unambiguous verdict on which of the six buckets this thing belongs in, with evidence strong enough that nobody downstream can shrug it off.

Once you see the job as classification, the volcano evaporates. Classification is finite. Omniscience is not. And "unsolvable" is not a category that exists in software - things that run on deterministic machines fail for reasons, and reasons can be found or bounded. Sometimes the bound is "we cannot reproduce this in six weeks of trying, here is exactly what we ruled out." That is a legitimate, professional, honest answer. It is not a failure. It is a map with a labeled blank spot, which is infinitely more valuable than a confident lie.

The DSat apocalypse also never came. Customers do not punish you for not knowing. They punish you for pretending (lying), for going silent, and for making them repeat themselves. I have delivered "this is a product limitation, and here is what we can do instead" hundreds of times. Almost nobody screams. Some of them thank you, because you are the first person in three weeks who told them something definite.

Why this matters if you lead people

I nearly did not take that promotion. Not because of skill gaps. Because of an imaginary volcano and a movie in my head.

Somewhere in your org there is an excellent L2 who is quietly avoiding the top of the ladder for exactly the same reason. They will not tell you this. They will say they "like the variety at L2" or "want to develop more first." What they mean is: I am afraid of being the end of the line.

You lose power horses 🐎 to that fear all the time, and it costs you nothing to fix. It costs one honest conversation from someone who has already been at the top of the pole and can say: there is no dead end, only classification.

👉 The fear of senior escalation roles is almost never about technical depth. It is about the fantasy of being the sole owner of an unsolvable problem.

👉 That fantasy is false. Cases resolve into a small, finite set of verdicts. Teach the buckets explicitly, in onboarding, in writing.

👉 The senior deliverable is a defensible verdict, not a fix. Reward the quality of the verdict, or people will hide behind endless investigation to avoid delivering one.

👉 Two of the six buckets are not technical at all. If your senior engineers cannot recognize a disguised feature request or a political case on sight, they will burn weeks debugging a decision.

👉 "We cannot reproduce it, here is precisely what we eliminated" is a professional result. If your culture treats that as failure, your engineers will stop escalating and start stalling.

👉 The most senior technical people in your org are usually the best recruiters you have - if you let them talk to the hesitant ones instead of putting them in another planning meeting.

Most good technicians are not afraid of hard problems. They are afraid of being the last person holding one. Show them the list of possible endings, and the cliff turns into a step.

👇 What promotion did you almost turn down because of a disaster that never happened?

This article is also available in German.

CareerCustomer SatisfactionCustomer ServiceManagementRetention