The SRE vs sysadmin gap catches senior engineers by surprise — usually in an interview room, usually at exactly the wrong time. Here's the scene I've watched play out more than a dozen times.
A senior engineer at 14 years of experience sits down for a Staff SRE interview at a product company. Résumé says all the right things — Kubernetes at scale, observability, incident management, cost optimization. Three technical rounds in, the hiring manager asks a simple question: "Walk me through the last automation you shipped that reduced toil for your on-call team."
The candidate goes quiet. Then talks about the ticketing workflow he improved last quarter. And the runbook he rewrote. And the on-call rotation schedule he owns.
The interview ends politely. The offer never comes.
What happened in that room is the SRE vs sysadmin gap — the widening distance between what a senior operations-adjacent role looks like on paper and what the market actually pays for. That gap catches senior engineers across Indian tech every week, and most don't know it until it costs them a role.
I'll say it plainly: role-drift at senior level is not a personal failure. It's an industry pattern. Companies re-org. Priorities shift. Teams get restructured. The team that hired you as an SRE three years ago might now be running you as a very expensive operations engineer without ever having a conversation about it. It happens quietly, gradually, and by the time you notice, your résumé is misaligned with the actual market for your title.
The good news: you can fix this without changing jobs. That's what most of this guide is about. Five diagnostic signs to see where your role has drifted, followed by a specific 90-day play to reposition — inside your current company, without setting off any political alarms.
WHAT THIS SRE VS SYSADMIN GUIDE COVERS
- Why role-drift happens — the Indian tech context that quietly turns SRE roles into sysadmin work over 18-24 months, and where the SRE vs sysadmin line blurs most
- The 5 diagnostic signs — a clear checklist to see whether your role has drifted, and by how much
- What role-drift costs you — the honest interview reality when you finally do go back to market
- The 90-day fix-in-place play — how to reposition inside your current role without changing jobs, and how to signal the shift externally
- When to stay vs. when to leave — the honest test for whether repositioning is even possible where you are
This is a shorter guide — about 20 minutes of reading. If you're pressed for time, skip to the 5 signs and self-diagnose first. The SRE vs sysadmin fix-in-place section will make much more sense once you know which signs apply to you.
Why the SRE vs Sysadmin Line Blurs at Senior Level
Before the diagnosis, understand the mechanism. When you can see why the SRE vs sysadmin line quietly blurs in Indian tech contexts, you stop taking it personally — and you start responding to it strategically. Three specific patterns cause it more than anywhere else.
1. The IT services legacy
If you started your career at TCS, Infosys, Wipro, Cognizant, Capgemini, or any of the mid-tier services companies, you inherited a specific operational DNA — ticket-driven work, SLA-driven metrics, client-managed priorities. Even if you've since moved to a GCC or product company, that muscle memory doesn't leave you. It quietly pulls your work back toward the reactive, ticket-based rhythm you were trained in. Your new employer often reinforces this rather than pushing back, because senior operations engineers are useful and rare and easy to under-pay.
2. GCC re-orgs and priority shuffles
The Indian GCC of a global company is often the operations arm of a product built elsewhere. That means the SRE work that gets *invented* — the greenfield reliability engineering, the platform building, the observability architecture — often happens at the headquarters. What lands in Bangalore or Hyderabad is the *operating* of what was invented elsewhere. Over 18-24 months, a senior SRE role at a GCC can quietly drift from "reliability engineering" into "on-call operator for someone else's platform." The pay stays senior. The work stops being senior.
3. The unspoken deal at product companies
Even at Indian product companies and well-funded startups, there's an unspoken deal that most senior operations hires don't see coming. Product engineering ships features. Platform engineering builds tooling. Somewhere in between sits a role called "SRE" or "DevOps" that ends up absorbing the operational load nobody else wants — the flaky pipelines, the noisy alerts, the security scans, the compliance checks, the on-call rotation. Individually, each of these is legitimate SRE work. Collectively, if that's all you're doing, you're a sysadmin with a modern title.
The Industry Itself Can't Agree — What I've Seen in Interviews
Before the diagnostic, one honest admission: part of why the SRE vs sysadmin confusion is so widespread is that the industry itself has never really agreed on what SRE means. If we take the Google SRE playbook as the reference standard — which is where the discipline was formalized — then the role and responsibilities should be reasonably consistent across companies. In practice, they vary wildly. The SRE vs sysadmin definitional gap starts here, before any individual role even begins to drift.
Companies design "SRE teams," but the profile underneath differs so much that two engineers with identical Staff SRE titles at different companies might have almost nothing in common in their day-to-day work. Sometimes it looks like companies are just in a race to have an SRE team on the org chart. Sometimes their DevOps team was restructured — or simply renamed — and SRE became the label. The playbook is public. The interpretation is chaotic.
My own interview experience over the past year made this concrete in a way no article could have prepared me for.
Interview 1: "SRE means coding — a lot of coding"
One top product company told me their SRE team was mainly about coding — and a lot of it. I initially thought they meant automation, since that's one of the core Google SRE principles. So I asked whether their focus was primarily on the automation principle. The interviewer clarified — no, they expected coding on the frontend, coding on the backend, and coding for automation. All three. At a Staff SRE level. It wasn't a bad definition; it just wasn't the definition I'd been operating under.
Interview 2: SRE that was really operations with a modern title
Another company's SRE team was almost entirely focused on monitoring dashboards and incident management. No SLOs. No error budgets. No structured post-incident engineering. When I asked how they defined reliability targets, the conversation stalled — those concepts weren't part of their operating model. The team was doing valuable work, but calling it SRE stretched the definition further than the Google playbook would support.
My experience across a handful of these conversations was mixed enough that at some point I was genuinely confused. Which one is the correct SRE role? Is it a DevOps role in new packaging? Is it a sysadmin function with better tooling? Is it a production support engineer position with a modern title? The honest answer I settled on: all of them are being called SRE somewhere, and the market has made peace with this ambiguity, even if candidates haven't. Which means the SRE vs sysadmin question isn't a definition problem — it's a positioning problem.
So a fair question you might be asking now: if the industry itself can't agree, on what basis am I about to give you 5 diagnostic signs?
Fair. Here's the honest answer. The diagnostic below isn't the definition of SRE — it's the diagnostic I use, calibrated to the Google SRE playbook as the reference standard, because at least that's a coherent starting point that most senior interviewers implicitly benchmark against. If your role scores poorly on these signs, it doesn't mean your role is illegitimate. It means your role has drifted from what the more discerning half of the market will pay senior SRE compensation for. That's the actual game.
The 5 Signs Your SRE Role Has Drifted Into Sysadmin Work
Read these honestly. If you find yourself explaining away three or more of them, your role has drifted meaningfully. That's information, not a verdict — but you'll want to act on it. Each sign below is one axis of the SRE vs sysadmin diagnostic.
You're doing more toil than automation
Real SRE work is fundamentally about reducing toil through automation. The Google SRE book's definition of toil is worth knowing precisely: manual, repetitive, tactical work that scales linearly with your service. If you're spending most of your week doing work that a well-designed script could do, you're not doing SRE — you're doing operations that happens to use modern tools.
Early in my SRE work, resource provisioning was the killer. Everyone was spinning up infrastructure through the AWS console, ad-hoc Terraform runs, occasionally CloudFormation — different teams, different patterns, no consistency. Each new environment took 3-4 days of manual work.
I proposed we standardize on Terraform through a pipeline, using shared modules — even for observability setup. That single shift reduced spin-up time from 3-4 days to about 45 minutes. Same infrastructure, dramatically less manual work.
At my last organization, applying this same pattern to observability onboarding — moving several applications from different monitoring frameworks onto one unified tool — saved roughly 6,000 manual hours across the year. That's the difference between doing operations and doing engineering. The work still gets done. Nobody has to touch it manually. That's the SRE vs sysadmin line, made concrete.
Your on-call is reactive, not preventive
Sysadmin on-call is: page comes in, engineer wakes up, fixes the immediate problem, closes the ticket, goes back to sleep. SRE on-call is different in structure — it includes post-incident review, root cause analysis, action items that go into the backlog, and — critically — engineering work that reduces the probability of that class of incident recurring. If your on-call is purely reactive with no follow-through engineering, you're operating a system, not improving it.
1:30 AM call. Jobs failing on worker nodes on one of our Kubernetes clusters. I did what tired-on-call-engineers do — I bumped up the node count, watched the queue drain, went back to bed. Ticket closed. Problem fixed.
A month later, the same page. Same time of night. Same fix.
That was the moment I realized I was operating the system, not engineering its reliability. I started digging deeper. Root cause wasn't node capacity — it was that our scalability configuration had drifted. Some clusters had autoscaling disabled entirely. Some had customized node groups that hadn't been updated in ages. Version mismatches across clusters. Golden AMI versions long stale. No Pod Disruption Budgets. HPA misconfigured in places. No VPA where it would have helped.
I worked through it systematically — synced all of it, brought the clusters back to a coherent baseline, put guardrails in place so drift wouldn't accumulate again. After that, I never got that 1:30 AM call again.
The lesson isn't that I did anything heroic. The lesson is that the first fix was operations. The second look was engineering. Both stopped the immediate problem. Only one stopped it recurring. That gap — between the operations reflex and the engineering follow-through — is the SRE vs sysadmin gap in real time.
You have no SLOs, no error budgets, no product engagement
This is the single sharpest test in the whole guide. SRE as a discipline is built on Service Level Objectives (SLOs) and error budgets — the framework for making explicit tradeoffs between reliability and feature velocity, together with product teams. If you're not measured on SLOs, if you don't know what your error budget is, and if you don't have regular conversations with product teams about reliability tradeoffs, you might be doing valuable work — but it isn't SRE work in the way the discipline was designed.
In a stakeholder meeting early in my SRE career, someone asked me a simple question about the error budget for a particular service. I didn't have an answer. For me, at that time, SLA was the reliability conversation — a P1 gets addressed at emergency level, P2 within four hours, and so on. Error budget wasn't in my working vocabulary.
That question stuck with me for days. I went to my manager and asked to properly understand SLI, SLO, and error budget as concepts — not as textbook definitions, but as they'd apply to our actual services. Then I did the work: mapped out the SLIs for each service my team owned, proposed SLO targets, calculated what our error budget would look like on a quarterly basis. Talked to the stakeholders — got their input on what mattered most to them. Published the whole thing on Confluence so the definitions were visible, agreed, and consistent.
That document changed how our team operated. Not overnight. But it changed the conversation from "did we hit SLA" to "how much of our error budget did we burn, and on what." That's an entirely different discipline. And it started with me not being able to answer one stakeholder question. The move from SLA thinking to SLO thinking is the single sharpest edge of the SRE vs sysadmin divide.
Your work is measured in tickets closed, not reliability improved
How is your performance evaluated? If your annual review is dominated by ticket volume, response time, closure rate, or SLA compliance, your role has drifted into operations regardless of what your title says. Real senior SRE work is evaluated on reliability improvements, toil reduction, incident rate trends, platform capabilities added, and engineering influence. If none of those show up in your review conversations, your organization has quietly told you what it actually values from you.
The confluence document I mentioned in Sign 3 paid off in a way I didn't expect at the time. About nine months in, my manager said something in a review conversation that I still remember almost word-for-word:
"We finally met the SLO in the third quarter — one quarter before the target. And the reason we got there is because you clarified the SLOs on Confluence at the beginning. Everyone was on the same page. No stakeholder drift on what we were aiming for."
What that told me was: the framework itself was the win, more than any single technical improvement. Once everyone agreed what "reliability" meant, the operational work aligned automatically. The SLO document became the thing my performance was actually measured against — not ticket closure counts, not response times, not SLA compliance percentages. That's when I understood how much your evaluation reflects what you make measurable, and what a shift it is when you propose the measurement yourself. That shift, from operational metrics to engineering-outcome metrics, is where the SRE vs sysadmin distinction shows up in your annual review.
You haven't shipped code (or infrastructure-as-code) in 90 days
This is the résumé-killer signal. If a hiring manager asks *"what did you build last quarter?"* — and every senior interview will ask a version of this — you need to have an answer that involves code, Terraform, Ansible, a Kubernetes controller, an internal tool, a CI/CD pipeline, or something concrete you can walk them through. If you can't name a single thing you've shipped in the last 90 days that involved writing or configuring something new, your role has drifted so far that even the interviewers who normally give senior candidates the benefit of the doubt will start scoring you as operational.
This is the sign I've struggled with most, honestly. At senior level, I moved into reviewing PRs — architectural sign-off, code quality checks, security review. Reading code, not writing it. That's a legitimate senior activity, and it's what your team often needs from you.
But the honest truth is my hands-on coding got untouched for something close to 5-6 years. I told myself it was fine because I was doing higher-value work. And in the day-to-day, that was true.
In interviews, it wasn't. Coding rounds became the place where I lost roles I should have won. Not because I couldn't code — I could — but because I hadn't practiced coding under interview conditions in years. The muscle atrophies fast when you don't use it. And the market doesn't distinguish between "senior engineer who reviews code" and "senior engineer who writes code" in the interview loop — you're expected to be both.
If you're in the same spot, don't wait. Even one meaningful commit a month keeps the muscle alive. You don't have to become a full-time IC again. You just have to not let the gap widen to the point where interviews expose it. This is where the SRE vs sysadmin gap becomes most expensive — the gap between your review activity at work and your actual coding evidence in a live interview.
What Role-Drift Actually Costs You in the Market
Let me be direct about the stakes here, because this is the section that turns diagnosis into urgency. The SRE vs sysadmin gap isn't theoretical — it shows up as real money left on the table, and it shows up fastest during interviews.
Senior technical hiring in Indian tech in 2026 is more discriminating than it was three or four years ago. Companies aren't hiring "senior operations engineers" at Staff SRE compensation any more. The market has learned to distinguish between roles, and the pay gap between a real senior SRE and a drifted-into-operations senior engineer at the same experience level is now genuinely significant — often ₹15-25 LPA at the 12-15 year band, more at the Staff+ level.
Here's what happens in interviews when the SRE vs sysadmin drift shows:
| Interview signal | Real SRE response | Drifted-role response |
|---|---|---|
| "Walk me through your last automation" | Concrete tool, scale metric, impact | Runbook improvements, workflow tweaks |
| "How do you measure your team's reliability?" | SLOs, error budgets, specific numbers | Ticket metrics, response time |
| "Tell me about your last postmortem" | Root cause, action items, engineering follow-through | "We closed the ticket, moved on" |
| "How much code do you write?" | Ongoing IaC, tooling, sometimes services | "Not much, mostly scripting" |
| "What's on your GitHub?" | Reference implementations, learning-in-public | "Nothing recent, mostly private repos" |
Interviewers score these differences quickly, often within the first 20 minutes. The rest of the interview becomes about whether you're strong enough on adjacent dimensions to overcome the initial signal. Usually you're not — because that initial signal was measuring exactly the thing the role is being hired for.
And here's the compounding problem — the longer you stay in a drifted role, the harder it becomes to leave. Not because your skills atrophy, but because your demonstrable skills atrophy. What you can prove in an interview drifts alongside what you actually do at work. That's the trap. Break out of it while you're still comfortable, not when you're forced to.
The 90-Day Fix-in-Place Play
The core insight of this section: you can fix a drifted role from inside, without changing jobs, without political drama, and without your manager even necessarily knowing it's a repositioning move. Ninety days is enough to shift the SRE vs sysadmin balance meaningfully. Here's the play.
Days 1-30: Reposition your internal work
Week 1: Pick your one thing
Look at the 5 signs above. Which one applies most sharply to you? That's your focus. Don't try to fix all five in parallel — you'll fail. Pick one, commit to it, and let the others improve as a side effect.
Weeks 2-3: Ship one concrete thing
Whatever the drift is, ship one concrete engineering artifact in the next two weeks. An automation that reduces toil. A Terraform module. A monitoring improvement with measurable impact. A postmortem process. An SLO proposal. Something specific, complete, and pointable-to.
Week 4: Document it well
Write it up. Internal doc, wiki page, whatever your organization uses. Put your name on it. Circulate it to your manager and one skip-level. This isn't self-promotion — it's putting a visible marker down that says "this is the kind of work I do." That marker matters when review season comes.
Days 31-60: Build external evidence
Weeks 5-6: Reference implementation on your personal GitHub
Take the work you shipped internally, generalize it, and publish a reference implementation on your personal GitHub. No proprietary details. Just the shape of the pattern. This creates public evidence of the kind of work you do — evidence that survives any job change, any manager change, any organization restructure.
Weeks 7-8: Update your LinkedIn and résumé
Your headline, About section, and current-role bullets should now reflect the engineering direction you're actively moving in — not the operational reality you're moving away from. This is honest, because you're actively doing the work, not just claiming it. But it also positions you correctly if a recruiter reaches out. This is the point where the SRE vs sysadmin fix starts showing up externally, not just in your internal work.
Days 61-90: Establish the pattern
Weeks 9-10: Second shipped thing at work
Ship a second concrete engineering artifact. Same rhythm as the first one — narrow scope, real impact, well-documented. This is where you shift from "shipped one thing" to "shipping regularly." The pattern is more valuable than any individual artifact.
Weeks 11-12: Second reference implementation, plus a small piece of external writing
Publish a second reference implementation on GitHub. And write one short piece — a LinkedIn post, a blog post, a comment on a technical thread — that positions you publicly as thinking about the engineering direction of your role. Not marketing. Just visible engagement with the craft.
End of Day 90: Take stock
At the 90-day mark, honestly evaluate: has your day-to-day at work meaningfully shifted? Is there more engineering, less toil? Is your manager treating you differently? Has your résumé changed shape? If yes on all — the fix worked, keep the rhythm going. If no, the answer is in the next section. Either way, you'll be a step further from the SRE vs sysadmin drift than you were 90 days ago.
When to Fix It vs. When to Leave
Not every SRE vs sysadmin drift can be closed in place. Sometimes the drift isn't yours — it's structural, and no amount of individual engineering will change the fundamental shape of the role. Here's how to tell the difference.
Fix it in place if:
- Your manager is supportive of engineering work when you propose it
- Your organization has any active platform engineering or reliability engineering charter, even if your team isn't fully aligned with it
- You can identify concrete engineering work that would be valued if you shipped it
- Your compensation is reasonable for the level you're at, so you have runway to make internal changes
- You're within your first 24 months in the current role — the drift is still reversible
Start planning to leave if:
- Your manager actively pushes back when you propose engineering work ("we don't have time for that")
- Your organization has no active investment in reliability engineering or platform work
- Your team is measured entirely on operational metrics, and there's no path to change that
- You've been in the drifted role for over 24 months and every fix attempt has been deprioritized
- Your compensation is now below market for the operational level you've drifted into
If you're in the second category, the fix isn't repositioning — it's a move. But even then, do the 90-day work first. Because when you go to market, the shipped work and the reference implementations from that 90 days become the evidence that gets you interviewed at the level you actually want, not the level your current role has drifted to. The SRE vs sysadmin gap gets measured most sharply during an active job search — you want to enter that search from the SRE side of it.
My Story — Looking Back at 15 Years
Around 2021, I was in a role that had a good title, good pay, and a workload that had quietly turned into 80% operations, 20% engineering. Ticket queues. On-call. Runbook maintenance. Vendor escalations. All work that needed to be done, but none of it was the SRE work I'd been hired to do three years earlier.
The moment I recognized it was uncomfortable. I was presenting an SRE dashboard I'd built to a client team — one of the few genuinely engineering-forward things I'd done that quarter. Someone on the client side asked a sharp question about what our team's actual SLOs were. I couldn't answer clearly, because we didn't really have any. We had SLAs from contractual documents and ticket metrics, and I'd been calling those SLOs in my own head for months.
That wasn't the only moment. There was another one, sharper in a different way. A fellow team member — someone I respected — asked me at some point, casually, what my role was actually about at that moment. I started to describe it, and heard myself: monitoring setup. Alerting configuration. Dashboard maintenance. Not much else. It was an eye-opener — someone I worked alongside was seeing my role for what it had become, before I'd let myself see it.
What I did next wasn't dramatic. I picked one thing — proposing real SLOs for one service — and started that work quietly. Then a second thing. Then a third. Within about six months, my day-to-day work looked different. More importantly, I had specific engineering artifacts I could point to. That mattered when, three years later, the layoff hit and I needed to interview from a position of strength.
The one thing I wish I'd done from the very start of my SRE career — the thing I'd tell my 8-years-in self if I could — is read the Google SRE playbook properly and use it as my North Star. Not because it's the only valid framework for what SRE means (this whole post has been about how the industry itself can't agree). But because it's a coherent, thoughtful, opinionated reference point. Once you internalize its principles — SLOs, error budgets, toil reduction, the shift from operations to engineering — you have a compass. Without a compass, role-drift is inevitable, because there's nothing to drift against.
The lesson wasn't "leave when your role drifts." The lesson was: notice the drift early, act on it while you're still comfortable, and never let the gap between your title and your evidence grow beyond one quarter. And if you're in your first few years as an SRE — go read the playbook this weekend. Save yourself the SRE vs sysadmin drift I had to correct later.
A Word Directly to You
If you're reading this and something has been quietly nagging at you for months — the sense that your role has drifted, that your résumé and your day-to-day aren't matching up any more, that a job search would be harder than it should be at your experience level — trust that instinct. It's usually right. The SRE vs sysadmin gap doesn't announce itself; it accumulates quietly.
Role-drift at senior level is one of the most fixable career problems you'll ever face — but only if you notice it early. The engineers who get stuck aren't the ones who noticed drift and did nothing. They're the ones who never noticed at all, until the market noticed for them.
You're noticing. That's already the hardest part. What comes next is a decision — not a big one, not a life-changing one, but a small commitment to pick one of the five signs above, own that one, and work on it for 90 days. Not for the theoretical next interview. For the version of yourself you want to be at 20 years of experience.
SRE vs sysadmin isn't about titles. It's about what you spend your working hours actually doing. Reclaim that, and everything else — résumé strength, interview outcomes, market compensation, career optionality — follows quietly behind.
Go pick your one thing.
— Arvind
Quick Reference — SRE vs Sysadmin Diagnosis and Fix
The Core Question
Every SRE vs sysadmin diagnostic below flows from one question: is my week engineering the system's reliability, or operating it?
The 5 Signs Your SRE Role Has Drifted
- Doing more toil than automation (real SRE: under 70% toil)
- Reactive on-call with no engineering follow-through
- No SLOs, no error budgets, no product engagement
- Performance measured in tickets, not reliability outcomes
- No code or IaC shipped in the last 90 days
The 90-Day Fix-in-Place Play
Days 1-30: Pick one sign. Ship one concrete engineering artifact. Document it internally.
Days 31-60: Publish reference implementation on personal GitHub. Update LinkedIn and résumé to reflect direction.
Days 61-90: Ship a second artifact. Second reference implementation. One short piece of external technical writing.
Fix in Place if
Manager is supportive · organization has active reliability/platform charter · you can identify valued engineering work · you're within 24 months in the role.
Plan to Leave if
Manager blocks engineering work · no organizational investment in reliability · measurement is fully operational · 24+ months and every fix attempt died · compensation now below operational-role market.
The Core Principle
Never let the gap between your title and your evidence grow beyond one quarter. That's the whole game.