Type Conversion

Type Conversion: What Changes (and What Doesn’t) When You Start a New SRE Job

Pilots have a specific term for moving from one airplane to another: a “type conversion”. Not “learning to fly” again — you already know how to fly. It’s the process of taking everything you already know and re-mapping it onto a new machine that does the same job with a different cockpit.

Starting a new SRE job is the same thing. And thinking about it that way has changed how I plan the first few weeks in a new seat.

The principles don’t change

Aerodynamics doesn’t care what airplane you’re in. Lift, drag, thrust, weight — every single-engine piston airplane you’ll ever fly balances the same four forces the same way. A stall is a stall. A stabilized approach is a stabilized approach. The control surfaces that do the work — ailerons, elevator, rudder — are present on every one of them, even when they’re shaped differently or hung in a different place on the fuselage.

SRE is the same underneath. Error budgets, blast radius, the instinct to widen the time window before trusting a correlation, the discipline of not doing anything you can’t undo quickly — none of that is specific to a company. You bring all of it with you on day one. The job isn’t “relearn reliability engineering.” It’s “figure out where this particular airplane keeps its flap controls.”

The instruments are always there — the panel layout isn’t

Every airplane you strap into will show you airspeed, altitude, and engine RPM. That’s not optional; you cannot fly safely without them. What changes is where they are on the panel, and maybe whether you’re reading a needle or a glass display.

Every production system you’ll ever own is going to show you latency, error rate, and saturation, whatever the org calls its version of the USE or RED method. That information exists somewhere, because you can’t run anything at scale without it. What changes is whether it lives in Datadog or Prometheus/Grafana or a homegrown dashboard nobody’s updated the README for. Whether there is an alert on CPU saturation or queue depth, and whether the number you’re staring at is raw or something three layers of aggregation removed from the truth. The first week on a new system is instrument scan practice: find the gauges, confirm what they actually measure, and figure out which ones lie under load.

The controls you already know may work differently

This is the part that trips people up, because it’s where confidence and competence quietly come apart. You know how flaps work. You’ve used them hundreds of times. But if you learned on electric flaps — a switch, a preset, done — and the new airplane hands you a mechanical Johnson bar you have to feel your way through by position, “I know how flaps work” isn’t enough anymore. Retractable gear instead of fixed. A constant-speed prop with a blue lever to manage instead of one knob that just goes faster or slower. Same job, same physics, genuinely different procedure, and the procedure is exactly where accidents might happen.

New job, same story. You know how deploys work. You’ve shipped code for years. But if you learned on a fully automated ArgoCD pipeline and the new shop is still doing blessed-branch deploys by hand through a Jenkins job somebody’s afraid to touch, “I know how deploys work” is not the same as knowing how deploys work *here*. Kubernetes instead of a fleet of long-lived VMs. A change-management process with an approval board instead of merge-and-go. The underlying skill transfers. The muscle memory for the specific lever in front of you does not, and that’s the gap that gets people in trouble in the first month — not lack of skill, but skill applied on autopilot to the wrong control.

The numbers you have to memorize are airframe-specific

Every airplane has its own set of V-speeds — best glide, maneuvering speed, gear and flap extension limits — and you memorize them cold for *that* airplane. The number for best glide speed in a 172 will get you killed in a Bonanza. Knowing that V-speeds exist and knowing what they are for this specific one are two completely different kinds of knowledge, and only the second one is useful in an emergency.

Same with paging thresholds, SLO targets, and escalation policy. You already understand that error budgets exist and that burn-rate alerts are how you catch them early. That’s the concept, and it travels. The actual numbers — what latency triggers a page here, what counts as a SEV1, who gets called at 3 a.m. and in what order — are specific to this system, this traffic pattern, this org’s risk tolerance, and you have to learn them cold before you’re the one holding the controls during an incident. Nobody hands you a card with the new numbers on it before your first on-call shift, any more than they hand a pilot a V-speed card mid-flight. You go find it, in the runbooks and the postmortems and the people who’ve flown this one before you, before you need it.

How you actually check out on a new type

Pilots don’t skip the transition training just because they’re experienced. A thousand hours in one airplane buys you good instincts and bad habits in equal measure when you move to a different one, and the honest pilots know it. The process is always the same shape: study the systems (the POH, the equivalent of the wiki nobody’s updated since the last incident), fly with someone who already knows this airplane before you fly it alone, and treat the first hours as information-gathering.

I’m about to do this again — new company, new stack, new set of V-speeds to learn — and the plan is the same one I’d give anyone else walking into a new seat: don’t assume the panel is laid out the way your last one was, don’t trust a control until you’ve confirmed what it actually does *here*, and spend the first weeks flying the pattern with an instructor in the right seat before you take it up solo. The principles of flight got you your license. They will not, by themselves, tell you where this airplane keeps its flap controls.

Where I land

The comfort in all of this is that the hard part — the part that took years to build — is the part that transfers completely. You are not starting over. You’re doing a type conversion, not primary training. The four forces still balance the same way; the instruments still tell the truth if you know how to read them; and the checklist still doesn’t fly the plane — the pilot who knows when to deviate from it does. That pilot is still you. You’re just learning where the controls and instruments are.

 

AI and SRE

AI and SRE: The Same Force Cuts Both Ways

I’ve spent most of my career in the “in-between” role — the one that sits between software engineering and operations, making sure the systems that carry the weight of the business stay up, stay fast, and stay honest about what they’re actually doing. Listen, follow the data, don’t do anything you can’t undo quickly. That’s been the job for a couple of decades.

In the last year, the job changed more than it did in the previous ten.

The pro: a week of work in an afternoon

I’m not talking about autocomplete. I’m talking about handing a genuinely open-ended problem — “why did this pipeline start drifting eleven months ago and nobody noticed,” “here are forty repos, tell me which ones are safe to migrate first and why” — to an AI agent and getting back, in an hour or two, the kind of analysis that used to take a week of careful, interruption-prone human attention.

I’ve used this to cut a major cloud cost center by more than 90 percent, to untangle a production bug that had been quietly rotting for the better part of a year across a dozen services, and to review an entire database-upgrade runbook for gaps before we touched a production system carrying terabytes of customer data. None of that work was “prompt a chatbot and copy the answer.” It was iterative, it was checked against real logs and real output, and it was faster than anything I could have done alone at any point in my career.

I’ve seen AI correctly identify issues with merge requests, pull requests. I’ve seen it correctly root cause incidents in minutes that would have a much longer time to diagnose collecting all the information manually. (I’ve also seen cases where it made the wrong diagnosis too.)

That’s not a marginal improvement. That’s a different order of magnitude. And it’s real — I’m not describing a demo, I’m describing what shipped.

The con: a week of work in an afternoon

Here’s the part our industry is not saying out loud enough: the thing that makes AI a superpower for an individual engineer is the exact same thing that makes fewer engineers necessary. If one person with the right judgment and the right tools can now do what used to take a small team, the small team is the thing that’s at risk — not the work.

We’re already living in that answer. Layoffs in this field are accelerating again, and I don’t think that’s a coincidence of macroeconomics alone. Some of it is straightforward: the leverage AI gives a skilled engineer is being converted directly into headcount reduction, not just output growth. That’s not a hypothetical for me. It’s not a hypothetical for a lot of people reading this.

I don’t think wringing our hands about it changes anything. I do think pretending it isn’t happening is worse than useless — it leaves people unprepared for a transition that’s already well underway.

So what’s actually different about the job now?

If the leverage is real in both directions, the question worth asking isn’t “will AI take SRE jobs” — some of that has already happened, and more of it will. The question is what part of the job doesn’t compress the same way.

A few things I keep coming back to:

Verification doesn’t get automated away — it gets more important.

AI output is confident and plausible whether or not it’s correct. The instinct that’s always separated a good SRE from a dangerous one — don’t assert a root cause ahead of the evidence, widen the time window before trusting a correlation, verify the actual numbers instead of estimating — matters more now, not less, because the volume of plausible-sounding output you have to check has gone up by an order of magnitude too.

The bottleneck moved from “can we generate an answer” to “can we trust this one,” and that second skill is still entirely human.

Judgment about what to build, and what not to automate, gets scarcer and more valuable.

Anyone can now generate a script. Knowing which problem is actually worth solving, what the blast radius is if it’s wrong, and when the “clever” fix is a trap — that’s still earned the hard way, through incidents you’ve lived through.

The work shifts from doing to reviewing, and that’s a harder skill to teach.

Reading someone else’s (or something else’s) work critically, catching the plausible-but-wrong answer, knowing which five lines of a five-hundred-line diff actually matter — that was always a senior skill. It’s now most of the job, for anyone using these tools seriously.

Communication and trust go up in value as raw output gets cheap.

When everyone can produce more, the differentiator becomes who people trust to have checked it, and who can explain a tradeoff clearly enough that a room full of stakeholders can make a fast, confident decision. That’s always been true in aviation — the checklist doesn’t fly the plane, the pilot who knows when to deviate from it does — and it’s becoming just as true here.

Where I land

I’m not going to pretend this is a comfortable transition, for me or for anyone else in this field right now. The pace of layoffs is real, and anyone telling you AI is purely additive to the job market isn’t looking at the same data I am.

But I also can’t unsee what’s now possible. A week of work in an afternoon isn’t a slogan for me, it’s what happened, repeatedly, on real production systems. The honest position is that both things are true at once: this is a genuine force multiplier, and it is a genuine threat to how many of us the industry needs. Pretending otherwise, in either direction, doesn’t serve anyone.

We can’t put the genie back in the bottle. There is a real cost; a human cost and the environmental costs.

What I’m doing about it is the same thing I’d tell anyone to do with any new tool that changes the shape of a system: don’t assume, follow the data, and don’t do anything you can’t undo quickly — including your assumptions about your own career!

Thoughts on Documentation

When I worked at RIM (Blackberry), we had the luxury of having technical writers on staff. They were brilliant at yanking information out of engineering and organizing it into cohesive sets of documentation. Not all companies or departments can afford a good technical writers on staff, so we all need to pitch in and do it. What constitutes good technical writing?

Continue reading “Thoughts on Documentation”

The Tail at Scale Revisited

My last article discussed some of the missing math related to setting back-end objectives. This article presents a chart which is useful in understanding the relationship to the user experience and we examine ways to dramatically improve the overall performance. Continue reading “The Tail at Scale Revisited”