From support engineer to SRE: a transition plan that uses what you already know

Ask a support engineer how they feel about their job title and you will usually get some version of the same answer: the work is real, the respect is not. You spend your days inside production systems, reading logs, reproducing failures, translating panic into tickets, and being right under pressure. Then you look at SRE job descriptions and something dishonest happens in your head: "I have never really done that."

You have done more of it than you think. The support-to-SRE path is one of the most natural transitions in this industry, and it is walked constantly. What follows is a map: what carries over as-is, what genuinely does not, and a plan for the gap.

What you already have

Training environments can teach tools and controlled failure. Support teaches what changes when the failure is live. You do these things daily and no longer notice:

• Production fear calibration. You know what a real outage feels like, what "this is urgent" versus "this feels urgent" looks like, and how to act carefully inside a system people depend on.
• Diagnosis under incomplete information. Support is the art of working backwards from a vague symptom reported by someone who cannot describe it. That is the core loop of incident response. SREs call it troubleshooting; you call it Tuesday.
• Log and error fluency. Reading a stack trace without flinching, correlating timestamps across systems, spotting the one line in a thousand that matters.
• Escalation judgment. Knowing what you can safely handle, what needs a second pair of eyes, and how to hand context over cleanly. This is exactly the on-call muscle.
• Writing under pressure. Ticket updates, reproduction steps, workaround docs. Incident communication is a first-class SRE skill and most engineers are bad at it. You have years of reps.

When you feel like a fraud reading an SRE job description, reread this list. The instincts are the hard part to teach. The tools are the easy part.

What genuinely does not carry over

Respecting yourself means being honest about the gaps too. Three of them are real for most support engineers:

1. You read systems; SREs also change them. Support diagnoses and routes. SRE diagnoses and then fixes the cause: patching the config, writing the migration, changing the alert. The shift is from "identify and escalate" to "identify and own."

2. Automation as a reflex. The SRE instinct is "I have now done this twice, so I will make a machine do it." If you have never scripted away a piece of your own workload, this reflex is unbuilt, and it is the single most important one to build.

3. Infrastructure literacy. Depending on your support role you may know the product deeply but the platform shallowly. Containers, orchestration, infrastructure-as-code, CI/CD, cloud networking: some subset of these is likely thin.

Notice what is not on this list: intelligence, seriousness, "engineering mindset." The gap is specific skills, not identity.

The plan: five steps from support to SRE

Step 1: Automate your own support work, this month. Whatever you repeat, script it: log collection, environment checks, ticket triage helpers, that diagnostic query you paste every week. Python or Bash, ugly is fine. If you use it as public evidence, strip out secrets, customer data, and anything proprietary. This does three jobs at once: builds the automation reflex, produces evidence, and often gets noticed internally. Every strong support-to-SRE story we have seen includes this step.

Step 2: Learn the platform under your product. You already know how the product fails. Now learn the layer it fails on: Linux fundamentals if they are shaky, then containers, then Kubernetes if your employer runs it. You have an advantage no bootcamp student has - real failure modes you personally witnessed. When you learn what a readiness probe is and realise it explains that outage from March, the knowledge sticks.

Step 3: Volunteer at the boundary. The move is usually made at the seam between teams, not through a job board. Ask to shadow an on-call rotation. Take the runbook nobody maintains and fix it. Offer to write the post-mortem draft. Ask for the ticket that is one notch past your comfort zone. Boundary work makes the transition visible to the people who can sponsor it.

Step 4: Reframe your CV in SRE language, without lying. "Handled customer tickets" becomes "diagnosed production incidents across X services, wrote reproduction cases, and drove escalations to resolution." Same facts, correct altitude. Add the automation from step 1 as an engineering bullet, because it is one.

Step 5: Aim at the adjacent titles first. Junior SRE, platform support, production support engineer, NOC-to-SRE tracks, "support engineer, infrastructure" at companies whose product is infrastructure. These roles can be the bridge: a year in one turns your support background into direct evidence of infrastructure ownership.

Do not wait until you meet every requirement. Apply when you can show one complete troubleshooting story, one useful automation, and enough Linux and networking knowledge to explain what the system is doing. Let repeated interview feedback choose the next gap you close.

The route is credible, but your employer still matters

Internal moves are the easiest path when they work and the slowest when they do not. If support has no engineering ladder, no access to infrastructure work, or no manager willing to let people cross the boundary, excellent preparation can still leave you waiting.

Titles are unreliable too. Some SRE jobs offer real automation and reliability ownership; others are support roles with a pager and a shinier name. Read the responsibilities, ask who changes production, and run the plan for the external market if the internal route goes nowhere.

SREs call it troubleshooting; you call it Tuesday.

The proof problem

There is one structural unfairness in this transition worth naming. Your strongest qualification - years of live production judgment - is the hardest thing to demonstrate in a hiring process. It does not screenshot well. It does not fit in a repo. A CV line saying "good under pressure" is exactly the kind of claim reviewers ignore, even when, in your case, it is the truest line on the page.

So the transition plan above is really a proof-generation plan: the automation is inspectable, the boundary work produces witnesses, the reframed CV survives the six-second scan. You are converting invisible competence into visible evidence, piece by piece.

Where we fit in

That proof problem is the reason SkillBricks treats support engineers as a first-class audience rather than an afterthought. Our assessments drop you into a live environment with something broken and watch how you work: the diagnosis path, the checks before the fix, the recovery when the first theory is wrong. That is the exact skill support built in you, measured directly instead of inferred from job titles. The result is a verified brick on a wall you control, free, forever, anonymous until you decide otherwise.

If you have ever thought "just watch me work for twenty minutes and you will see" - that is, almost word for word, the product. Start your wall and let it do the talking.