# Careers into support, and careers out of it

> The industry treats operations as a stage people pass through, which is wrong in both directions: it gives the people who stay nothing to grow into except management, and it leaves the people who go without an accurate account of what they learned. The skills are real, transferable, and badly named.

Source: https://ronutz.com/en/practice/careers-into-support-and-out-of-it  
Updated: 2026-08-09

---

## The ladder metaphor does real damage

Support is described as an entry point. First line, then second, then *out* — into design, into architecture, into management. The word people use is *progression*, and it carries an unexamined claim: that staying is not progressing.

That claim costs the industry twice.

**It gives senior operational people nowhere to go.** The best diagnostician on a team has one visible route upward, and it is management — so organisations reliably promote their strongest investigator into a role where they no longer investigate. Everyone can name somebody this happened to. Almost nobody calls it a loss.

**And it leaves the people who do move on unable to describe what they gained**, because *"I worked in support"* is heard as a starting position rather than as an education.

## What the work actually teaches

Three things, and the first is rarer than the industry admits.

**How systems fail.** Not how they work — how they *fail*, which is different knowledge and is almost never taught anywhere else. Design education covers intended behaviour. Operations is a decade-long empirical study of the gap between intended and actual, conducted on real estates at real scale. A designer who has spent five years watching things break makes different decisions, and [designing for three in the morning](https://ronutz.com/en/practice/designing-for-three-in-the-morning) is that knowledge written down.

**Reasoning under uncertainty and time pressure.** Deciding with incomplete information, on a clock, with consequences — repeatedly, until it is a habit rather than a performance. Most disciplines never rehearse this.

**Breadth nobody else gets.** A support engineer sees a hundred estates; an architect sees the ones they built. That breadth is why an operations background is the single most reliable source of the sentence *"that will not survive contact with a real network"*, and why it is worth so much in the roles below.

## Where it carries, and what carries

**Design and architecture** — the failure knowledge is the differentiator, and it is the reason ops-to-design is the strongest of these transitions rather than merely the most common.

**Pre-sales and solution engineering** — credibility that cannot be faked. *"I have run this in production"* is heard differently from *"I have studied this"*, and customers detect the difference in the first ten minutes.

**Product management** — you know what the field actually complains about, as opposed to what surveys report.

**Security, specifically incident response** — the same muscle. Time pressure, incomplete information, adversarial ambiguity, and a write-up at the end.

**Teaching** — and this is worth naming precisely: the value is not that you know the product. It is that you have stories that are **true**, and a room full of practitioners can tell the difference between an example that happened and an example that was constructed.

## What does not transfer

**Heroics.** The reputation for being the person who fixes it at three in the morning feels like career capital and is the opposite: it is a role, and roles are hard to leave. The organisation optimises around your availability, and you become expensive to promote and impossible to replace — which sounds like security and functions as a ceiling.

The version that does transfer is *"I reduced the number of three-in-the-morning events"*, which is a different sentence about a different person.

**Estate-specific depth.** Ten years of knowing one network intimately is enormous value to one employer and very little to the next. The tell is simple: **if most of what you know is proper nouns, the knowledge is not portable.** That is not an argument for leaving. It is an argument for deliberately learning the general form of what you know — the mechanism rather than the hostname.

## Staying is a legitimate answer

Nothing above argues that everybody should leave.

Some of the best engineers this industry has are people who stayed in operations for twenty years and got progressively better at something genuinely difficult. **The problem is not staying; it is staying by default** — remaining because leaving requires an act and staying does not, and then discovering at year twelve that a decision was made without ever being taken.

The distinction is worth checking annually and takes one question: **am I still learning things that would matter somewhere else?** A yes is a good year regardless of title. A run of noes is information, and it is better to have it at year six than at year twelve.

## Coming the other way

People arrive in operations from helpdesk, from field service, and — often the strongest — from having been the customer who got good at it.

The thing that most helps somebody arriving: **the estate will teach you faster than any course, provided somebody tells you why things are the way they are.** Which is the argument for [reading a design you did not write](https://ronutz.com/en/practice/reading-a-design-you-did-not-write) as an early skill rather than a senior one, and for the reasoning being written down at all.

## Translated honestly

What the experience is actually called, when the résumé stops using the industry's word for it:

| what it says | what it is |
|---|---|
| *Worked in support* | a decade-long empirical study of how systems fail |
| *Handled escalations* | decision-making under time pressure with incomplete information |
| *Dealt with customers* | holding a technical position while somebody is angry and partly right |
| *Worked with vendors* | operating inside another organisation's constraints to get an outcome |
| *Was on call* | sustained responsibility for consequences, not availability |

None of that is inflation. It is the same experience, described by what it required rather than by the department it happened in — and the difference between those two descriptions is most of why good operations people undersell themselves.