Sameer had been a support engineer for four years when he realised he was invisible. Not to the customers — they knew him well, the calm voice who stayed on the bridge call until the system came back. Invisible to the organisation. Every quarter, the delivery teams presented charts of what they had shipped; Sameer’s team presented nothing, because what they did all day — absorbing failures, restoring service, protecting sleep — left no trace anyone upstairs could see. His manager put it bluntly during an appraisal: “Nobody doubts you work hard. They just can’t see what changes because of you.” This is a story about how he fixed that, and the career lesson folded inside it for every support engineer reading.

The night that started it

The turning point was an outage like any other. A payment-adjacent service fell over at 11 p.m.; Sameer triaged, escalated, coordinated the fix, wrote the timeline. Reading his own notes the next morning, something nagged him. He had written timelines like this dozens of times — first alert, diagnosis, mitigation, all-clear — and every single one died in a ticket nobody reopened. Weeks later, exploring tooling in this space, he came across the product demo on BestDevOps, the DevOps community and learning site — their DevOpsIQ platform renders exactly that kind of story as data: the sample dashboard walks through a fictional “Payment API” incident resolved in 57 minutes, laid out on a timeline a leader can read in seconds. Illustrative numbers, invented for the demo — but Sameer stared at it with the specific jealousy of a man seeing his invisible work made visible for someone else.

The insight wasn’t about buying anything. It was simpler: his nightly heroics were already data. Somebody just had to treat them that way.

Turning war stories into a ledger

Sameer started small, almost embarrassingly so. A shared sheet: date, service, minutes of user impact, time to restore, root cause category, what shipped in the day before the failure. Twenty minutes after each incident, no exceptions. Three months later his team had something no one else in the company had — an actual failure history, queryable, with patterns in it.

And the patterns talked. A third of their pages traced back to one brittle integration. Restore times were fine on weekdays and terrible on Sundays, because the runbook assumed a person who wasn’t rostered. One service consumed its reliability headroom at a frightening pace — by mid-quarter it was running on fumes, the kind of situation the DevOpsIQ demo expresses as a service with just 41% of its error budget left, except Sameer’s version was real and his number was worse. For the first time, the support team walked into a quarterly review with slides. Not apologies — findings.

What changed, and what it teaches

The immediate effects were operational: the brittle integration got rebuilt, the Sunday gap got rostered, two chronic offenders got hardening sprints. But notice the career physics underneath, because they apply to anyone in support or managed services.

• Measurement converts defence into offence. A support team with no data is a cost centre explaining itself. A support team with a failure ledger sets the engineering agenda, because it alone knows where the organisation actually bleeds.
• The reader matters more than the data. Sameer’s sheet won because he summarised it the way leadership tooling does — which services are holding, which are drifting toward danger — rather than dumping rows. That framing, one view of health and risk across services, is literally what platforms like DevOpsIQ sell to CTOs and SRE leads; a support engineer who produces it by hand is doing a leadership job before holding the title.
• Restraint is credibility. He tracked systems, never colleagues, and used only operational records his team already generated — the same read-only, metadata-not-code posture serious measurement products advertise. Nobody could accuse the ledger of surveillance, so nobody fought it.

The skills behind the story

If you want to run Sameer’s play, the skill list is short and learnable. Basic spreadsheet or SQL fluency — enough to group incidents by cause and trend restore times. Definitional discipline — deciding what counts as “restored” and sticking to it. Narrative compression — turning thirty incidents into three sentences an executive repeats. And enough delivery-side literacy to join your failure data to their change data; the correlation between “what shipped” and “what broke” is where support’s insight becomes engineering’s roadmap. None of this requires leaving support. All of it shows up later in interviews, which is why it belongs in any portfolio built to make hiring managers pay attention — a real ledger with real outcomes beats a tutorial project every time.

Eighteen months on, Sameer’s title changed to reliability engineer, a move that surprised nobody who had watched the reviews. The jump from support into reliability and platform work is a well-trodden one — this case for operations people embracing the DevOps path maps the route, and this decoder of DevOps role titles and ladders helps you aim it. But the engine of the move was never a certification. It was visibility: he made the invisible work measurable, and measurable work is promotable work.

One warning from his experience: expect a slow start. The first month of the ledger felt like paperwork with no payoff, and two teammates quietly stopped filling it in. What saved it was the first pattern — the brittle integration — because the moment the data caught something folklore had missed, the sheet stopped being Sameer’s project and became the team’s weapon. Budget six weeks of apparent pointlessness before the compounding begins, and recruit one ally who logs as faithfully as you do so the habit survives your vacations.

The quiet moral for support engineers

Support teams sit on the richest operational dataset in any company and most let it evaporate into closed tickets. Don’t. Start the ledger this week — one sheet, five columns, twenty minutes per incident. In a quarter you will know things about your organisation’s reliability that nobody else knows, and in the economy of engineering careers, being the person who knows is the whole game. The hard work was always visible to the customers. Now let the deciders upstairs see it too — your next title depends on it.