The complaint arrives in nearly identical words from every direction: “our DevOps support team works hard, closes tickets, and has not gotten meaningfully better in two years.” Escalation rates stay flat. The same three senior people handle every genuinely hard incident. Juniors who were promising at hiring remain promising — and only promising — eight quarters later. This is a diagnosable condition with a specific root cause and a specific remedy. Let us work through it the way a support engineer would work through any recurring incident: symptoms, differential, root cause, fix.
The Symptoms of a Stalled DevOps Support Team
Check your own operation against these markers. Ticket resolution times improve for known issue classes but not for novel ones — the team is memorizing, not generalizing. Runbook coverage grows while off-runbook confidence shrinks. Escalations cluster on the same senior names year after year. Post-incident reviews produce action items about systems, never about skills. And attrition interviews quietly feature the phrase “I wasn’t learning anymore.” Two or more of these present together indicate the condition is established.
Ruling Out the Usual Suspects
Before treating, eliminate the explanations managers reach for first — because the standard remedies for them keep failing, and the failures are informative.
“They need more training content.” Most stalled teams have generous course access, often barely used past module three. If licenses fixed plateaus, this article would not exist. Rule it out.
“They need better processes.” Process rigor raises the floor of a team’s performance; it cannot raise the ceiling, because documented procedure is by definition yesterday’s knowledge. Teams with superb runbooks plateau exactly as hard. Rule it out.
“They need motivation.” Observe your stuck engineers honestly and you will usually find effort intact: evening study, home labs, certification attempts. Effort is not the deficient input. Rule it out.
Root Cause: Repetition Without Correction
What support work supplies in abundance is repetition. What it almost never supplies is inspection of the repetition by someone more skilled. An engineer can resolve four hundred incidents and receive zero feedback on the quality of their diagnosis path — whether they anchored on the wrong signal, missed the faster hypothesis, or fixed the symptom while walking past the cause. Closed tickets look identical whether the reasoning behind them was excellent or lucky.
Growth requires an error signal, and ticket queues do not emit one. The senior engineers on your team grew, almost certainly, during some earlier period when a sharper engineer was regularly reviewing their work — then the structure that grew them quietly disappeared, and everyone hired afterward got the queue without the correction. The plateau is not a people problem. It is a missing feedback mechanism, and no volume of repetition compensates for it, in the same way that a decade of unexamined incident handling teaches less than a year of examined handling. This is also why ambitious support engineers eyeing the transitions we mapped in the landscape of DevOps roles and the paths between them so often stall at the first rung: role changes demand demonstrated judgment, and judgment was never being built.
The Fix: Install a Practitioner Feedback Loop
The remedy is structural, inexpensive relative to attrition, and specific: attach each developing engineer to one senior practitioner who reviews their real work on a fixed cadence. Not a buddy system, not a rotating Q&A clinic — a sustained one-to-one arrangement where the same experienced eye returns to the same engineer’s diagnoses, scripts and escalation decisions every week or two, accumulating context about that individual’s failure patterns.
Implementation notes from teams that have done this well. First, review artifacts, not anecdotes: the actual incident timeline, the actual remediation commit. Second, mine your ticket history for teaching material — yesterday’s ugly escalation, replayed with a mentor asking “what was the earliest moment you could have known?”, is worth a month of courseware. Third, end every session with a stretch assignment slightly beyond the engineer’s current level: first solo handling of a priority-one, first SLO proposal, first capacity review. Fourth, have the mentor maintain a running log per mentee; patterns in the corrections become the curriculum.
Where does the senior eye come from? Use your own principals if they exist and have bandwidth — but ring-fence the time, or the queue will eat it. Where they do not exist, engage the capability externally. Experienced architects increasingly provide exactly this service; Rajesh Kumar’s practice spanning SRE, observability and incident management is a case in point — a trainer-architect with over fifteen years in production systems, whose work with organizations such as ServiceNow and Intuit now extends into one-on-one mentoring of engineers worldwide. External or internal matters less than constancy: one practitioner, the same engineer, months of continuity.
Verifying the Fix Took
Treat it like any remediation — define the signals before you start. Within two quarters, expect: novel-incident resolution times bending downward, escalation load spreading beyond the usual seniors, and post-incident reviews that begin referencing reasoning quality. Individual engineers should have visible artifacts of growth — the kind of demonstrable work we recommend assembling in a portfolio that proves what a support engineer can do — and the strongest of them will start pushing toward reliability engineering proper, a move whose logic we laid out in why operations engineers should lean into IaC and SRE.
A support team that only repeats will only plateau. Add one experienced practitioner per engineer, reviewing real work on a real cadence, and the queue itself becomes the curriculum. That is the whole diagnosis — and unusually for this industry, the fix is neither a tool nor a reorg. It is a person, applied consistently.
