From Developer to SRE — What Actually Changes

The Move

When I joined Fortinet as an SRE Specialist, I expected the main challenge to be learning new tools. I was wrong. The tools were learnable in weeks. What took longer was the mindset shift.

As a developer, I asked: *does this feature work?*

As an SRE, I ask: *what happens when this feature breaks at 3am?*

What SREs Actually Do

There's a lot of confusion about what SRE means in practice. At its core, it's about applying software engineering principles to operations problems. That means:

• Service Level Objectives (SLOs) — defining what "good enough" reliability looks like in measurable terms
• Error budgets — if you're more reliable than your SLO requires, you have budget to take risk. If you're burning the budget, you slow down.
• Toil reduction — automating repetitive operational work so engineers can focus on meaningful problems
• Incident response — structured processes for detecting, responding to, and learning from failures

The Hardest Part

The hardest part isn't the technical work — it's the on-call rotation.

Being responsible for production at 3am is humbling. It teaches you:

• Documentation matters — a runbook written in a hurry at 2am is unreadable
• Alerting clarity is critical — alerts must be actionable or they're noise
• Blast radius reduction — before any change, ask "what's the worst case and how do we limit it?"

What I Wish I'd Known Earlier

The skills that made the biggest difference weren't purely technical:

1. Write everything down — decisions, incidents, architecture changes. Memory is lossy.
2. Automate defensively — automation that can fail silently is worse than no automation
3. Build relationships with the dev teams — SRE and dev are partners, not adversaries

Conclusion

SRE is fundamentally an optimistic discipline. It accepts that systems will fail and asks: how do we build them to fail gracefully, recover quickly, and improve after each incident? That mindset has changed how I think about every line of code I write.