💻Your Job Is Changing, But Not in the Way You Think

Presented by Incident.io

It's easy to be stuck with your paging tool forever.

Well, unless you're on Opsgenie. In which case, the clock is already ticking.

Most teams treat a migration as a copy-paste job. New tool, same setup, back to business. And honestly? You can survive that way.

But 99% of teams miss what's right in front of them. An opportunity to fix years of bottlenecks.

Eryn Carman at incident.io wrote the guide most teams wish they had before migrating. It shares:

↳ A four-step migration framework,

↳ 7 diagnostic questions (including one that will bring back painful memories if you've ever waited on someone on PTO to resolve a major incident), and

↳A full webinar to go deeper.

Whether you're moving 50 users or 5,000, this is worth your time.

Read 👉🏾 How to migrate your paging tool without breaking your team.

Thank you @incidentio for sponsoring this newsletter!

Hey {{first name | there}},

Software engineering has never really been about writing code.

There's a version of this conversation that starts with "the bottleneck was always writing code." I don't fully buy that. Engineering to me was about taking an idea, understanding the edge cases around it, and turning the whole thing into something that works reliably. Code was just the medium.

Housekeeping:

To make sure you don’t miss future emails, here are two quick GIFs showing how to move this email to your Primary tab and add this address to your contacts.

What’s changing now is the cost of that medium

Generative AI is different from previous tools that were supposed to threaten developers. Low code and no code had real limits, and engineers could see them clearly. Modern models behave differently. They generate output that often looks correct and sometimes even runs correctly, which makes it harder to distinguish solid implementations from fragile ones without applying engineering judgment.

Atlassian’s CTO recently described the shift as “left of code” and “right of code.” The idea is that the engineer's role is expanding in both directions, with problem framing, planning, and system design on one side, and testing strategy, rollout safety, observability, and operations on the other. Code sits in the middle of a broader workflow.

In practice, experienced engineers were already operating across much of this scope. The change is not only in what the job includes, but in how widely that expectation is distributed.

A large part of the value now comes from context. AI models can generate functions, services, and even structured codebases, but system context still lives with people. Business constraints, operational history, failed migrations, architectural tradeoffs, and internal reasoning are rarely visible in the code itself. Engineers who hold that context and can guide AI systems with it are becoming more central to production outcomes.

The transition also varies across organisations. In some companies, product direction sits with product and executive teams, while reliability and infrastructure are handled by platform or SRE groups. In those environments, engineers are still evaluated primarily on implementation work, even as expectations around system-level thinking continue to expand.

Where I think you actually win long-term is ownership. “Code being cheap” changes the economics of building software, but it doesn't change the cost of getting it wrong in production.

Understanding what the model gave you in PR #103, what assumptions it made, what it missed, and what breaks under load still requires the same foundational knowledge it always has. For a weekend project, this matters less. For production software with real users, it matters more than ever.

The engineers who figure out how to combine that ownership with AI-native ways of working will likely define what the senior engineering role looks like next. The structure of the job is already changing faster than most job descriptions reflect.

Thanks for reading this week's issue. Share this link with a colleague or fellow DevOps Engineer who’d find it useful.