I feel a strong sense of irony whenever I hear the term “on-call.”
I switched into tech after completing a six-year medical degree, where on-call had a very different meaning. In the hospital, being on-call meant a pager blaring every other minute, a never-ending list of unwell patients, and a constant stream of urgent tasks that were already overdue.
Now, in tech, my on-call experience is… a little anticlimactic by comparison. At its worst, it’s a 3 a.m. alert on my phone telling me a system is critically down. At which point I would groggily roll out of bed, rub the sleep from my eyes, and shuffle ten feet to my laptop to investigate. That’s it. No adrenaline, no emergency resuscitations — just some logs, a Slack channel and a whole lot of coffee.
I work on the Continuous Delivery team. We run a 24/7 on-call rota, each taking a full week at a time (yes, including weekends). During work hours that week, we step back from feature development. Instead, we focus on maintenance: fixing bugs, answering questions from other engineers, and keeping our tooling — like our deployment platform Spinnaker — running smoothly.
If there’s an incident involving systems we own — say, Spinnaker suddenly stops working — the on-call engineer is the first point of contact. But that doesn’t mean you’re on your own; the rest of the team is always there for support.
I started my first tech job about nine months ago. Coming from a 12-week bootcamp focused on full-stack technologies, I was slightly embarrassed to admit that DevOps had mostly flown over my head. Kubernetes who? I quickly discovered that infrastructure is an entire world of its own — and I had (and still have) a lot to learn.
So it may be surprising that I joined the on-call rota just five months into the job.
I was the most junior person on the team. The breaker of code, the introducer of bugs, the asker of many, many questions. How was I supposed to be the person engineers turned to when Spinnaker broke?
The answer, I learned, is: I wasn’t supposed to do it alone.
For every question I couldn’t answer, there was someone on my team willing to lend a hand. To explain. To guide. To teach me how to find the answer or show me where to look. Honestly, it’s the only reason I didn’t run away screaming after my first week on-call — every engineer had been there, and thankfully, it hadn’t made them bitter or left them eager to watch me suffer.
Every question I answered in our public channels taught me something new. Every time something broke, I gained a better understanding of how — and more importantly, why — it broke. What had previously taken weeks to grasp started to make sense during a single on-call shift. And that’s continued to be true.
As things break, as bugs emerge, as systems get twitchy — I walk away more confident and better prepared for the next time.
One thing I still struggle with is the unpredictability. I’m someone who likes to know what their day looks like. My productivity thrives on having a plan. So when a quiet day suddenly turns chaotic — like when five engineers try to deploy at 5 p.m. on a Friday and everything breaks — it can feel overwhelming.
But that’s on-call life.
It’s not glamorous. It’s rarely exciting. And it’s often inconvenient. But it’s also one of the most valuable learning experiences I’ve had in tech — and one I wouldn’t trade.
