The Staff-Level Resume Problem

There is a point in a technical career where the resume format stops fitting. Your best work that year was a design document that stopped a bad architecture, a migration you convinced four teams to do, and a standard that made a class of bug impossible. None of it is a shipped feature with your name on the commit.

The standard advice — quantify your impact, describe what you built — doesn’t map cleanly onto work whose output is other people’s decisions. But the work is describable. It needs a different unit than a feature.

Why the usual bullets fail here

A staff-level engineer writing bullets in the mid-level format ends up with two bad options.

They can describe the artefacts they personally produced, which under-represents the year: “wrote the event schema RFC” is one document, and the actual work was the six months of getting it adopted. Or they can describe the outcomes they influenced, which over-represents their part: “reduced platform incident rate” was mostly other people’s fixes.

The resolution is to make the mechanism the subject of the sentence. Not the artefact, not the outcome — the thing you did that caused other engineers to do something different.

Illustration: Wrote and drove adoption of the service-ownership standard — every service now has a named owner, a runbook, and an alerting contract, which is what made the on-call handover between teams work at all.

That sentence contains an artefact, a scope, and a consequence, and it’s honest about the fact that the services were not yours.

The four kinds of staff work, and how to write each

Technical direction. Choosing, or preventing, an architectural path. This is the highest-value thing on the list and the easiest to write badly, because “defined the architecture” is unfalsifiable. Name the decision and the alternative:

Argued the case for keeping the monolith and extracting only the two write-heavy domains, against an initial plan for a full decomposition; wrote the sequencing document the team executed over the following year.

Prevented work is legitimate and rarely claimed. An engineer who talked an organisation out of a doomed rewrite has produced more value than one who delivered a feature, and the bullet can say so plainly.

Cross-team execution. Getting something done that no single team owned. The interesting content is always the coordination mechanism, not the technical change:

Ran the TLS certificate rotation across nineteen services owned by five teams — built the automated issuance path, then worked team by team through the deployments that needed changes, with a shared tracking board and a hard cutoff date.

Raising the floor. Standards, tooling, defaults, review practices, test infrastructure. What makes this legible is naming the class of problem that stopped occurring:

Introduced a schema-compatibility check in CI, which ended the recurring class of incident where a producer deployed a breaking change ahead of its consumers.

Growing other engineers. Mentoring, review, design coaching. Keep it concrete and keep it modest — this is the section most likely to tip into self-congratulation:

Mentored two engineers through their first on-call rotations and their first design documents; ran the fortnightly design review that most of the team’s proposals went through.

The line you have to hold: this is not a management resume

The failure mode of a staff resume is that it reads like an engineering manager’s. Once that happens you’re competing in a category you didn’t apply to, and a technical reviewer will conclude you’ve stopped writing code.

Three things keep it on the right side of the line.

Keep the technical detail in. A staff resume with no databases, protocols, or failure modes on it looks like someone who left the technical work behind. Even your influence bullets should carry a load-bearing technical noun: the schema check, the certificate issuance path, the write-heavy domains.

Keep at least one hands-on bullet per role. Something you built. It can be small — the controller, the library, the migration tool. It establishes that the abstraction-level work is grounded.

Use verbs that aren’t management verbs. “Owned”, “designed”, “argued”, “wrote”, “drove”, “built”, “introduced” are engineering verbs. “Managed”, “oversaw”, “coordinated resources”, “aligned stakeholders” are not, and they read as a career change you didn’t announce.

Scope claims get probed harder at this level

Influence work is uniquely easy to overstate because the evidence is diffuse. If you say you set the technical direction for an organisation, the interviewer will ask what specifically changed as a result, who disagreed, and how it went — and a vague answer at staff level is much more damaging than at mid level, because judgement is the entire thing being assessed.

The safe construction is to claim the mechanism and let the outcome be adjacent rather than attributed. “Wrote the standard that every service now follows” is defensible. “Improved reliability across the organisation” is a claim about other people’s work that you’ll be asked to justify. The distinction is the same one described in scope, not years, applied at a level where the temptation is stronger.

Structural changes worth making

A short positioning line at the top. Past senior, titles stop being informative, and a two-line summary earns its space. Say what kind of engineer you are and what you tend to be pointed at: “Backend engineer, mostly distributed data systems. Usually the person brought in on migrations and on making other teams’ services operable.”

Fewer roles, more depth on the recent ones. Nobody assessing a staff candidate needs four bullets about a role from a decade ago. Group the early career into one line.

Consider a selected-work block. One system, described in five lines with its constraints and trade-offs, does more for a staff application than fifteen scattered bullets — see a selected-work block for the system you know best.

Name the artefacts. Design documents, RFCs, standards, and postmortems are the physical output of staff work and most resumes omit them entirely. Design documents, RFCs, and what they show covers how to reference them without attaching a portfolio.

The uncomfortable check

Read your staff-level resume and ask: could a competent engineering manager have written this same page about their own year?

If yes, you’ve described the coordination and left out the engineering. The fix is not to remove the influence work — it’s the most valuable material you have — but to put the technical substance back underneath each piece of it, so that every claim about other people’s behaviour is anchored to something you personally designed or built.