Senior, staff, and the ladder above

Up to senior, the ladder is a single line and each step is a wider version of the last. At the next step it stops being one line. Two people with the same title spend their weeks doing work that has almost nothing in common, and the thing that decides which of them you become is not skill — it is which problem the organisation you are in happens to have.

The question underneath is usually practical rather than curious: whether to spend the next two years pushing for this, or whether the title is a description of a situation you are not in.

What actually differs#

One caution before treating that table as a ladder. Titles at this level are local to a company’s own framework, not a shared standard. Dropbox’s published engineering career framework runs individual contributors from IC1 to IC7 and describes each level in terms of scope, collaborative reach and levers for impact, assessed across results, direction, talent and culture alongside role-specific craft. It states its own purpose carefully: it is not a promotion checklist, it is there to help someone work out what their impact could look like at the next level. Two companies can both have “staff” and mean different rungs of a differently-shaped ladder — so the transferable question is what scope is being described, never what the word is.

The four shapes staff work takes#

Will Larson’s survey of the role sorts it into four archetypes, and the reason they are worth knowing individually is that they want different things from you and are available in different organisations.

The Tech Lead guides the approach and execution of a particular team, partnering closely with a single manager — sometimes two or three within a focused area. It is the most common of the four by a wide margin: the guide’s own estimate is roughly one Tech Lead for every eight engineers, and for many people it is their first experience of the role.

The Architect is responsible for the direction, quality and approach within a critical area, combining in-depth knowledge of technical constraints with user needs and organisation-level leadership. It appears where an area is both important and long-lived enough to deserve someone whose job is its shape.

The Solver digs into arbitrarily complex problems and finds an appropriate path forward — sometimes staying with one area for a long time, sometimes moving from hotspot to hotspot as organisational leadership directs.

The Right Hand extends an executive’s attention, borrowing their scope and authority to operate a particularly complex organisation. It exists only where there is an organisation large enough to need that bandwidth.

The split that matters when choosing is depth against motion. Tech Leads and Architects stay with the same teams and the same problems long enough to be accountable for how they turn out. Solvers and Right Hands move between problems, with relationships that are shorter and more transactional by design. People who want the second and are given the first describe the job as slow; people who want the first and are given the second describe it as rootless. Both are accurate reports about a mismatch rather than about the role.

Whether it is worth chasing#

The honest constraint is that the seat is a property of the organisation, not a reward the organisation owes you. Three of the four archetypes need a specific condition to exist — a critical long-lived area, a supply of cross-cutting fires, an executive with scope to lend. Where none of those conditions holds, pushing for the title produces a promotion to a job that is not there, and the usual outcome is a senior engineer with a new word on their profile and the same week as before.

The costs are worth pricing before deciding rather than after. Your feedback loop lengthens from a release to a quarter or worse, which is uncomfortable in a way that is hard to appreciate in advance — the standard sensation of the first year is being less productive while being more useful, and that is the same shift described in what actually changes between mid and senior, running further in the same direction. Most of your output becomes writing. And the work is less legible: what you prevented does not appear anywhere, which is a problem for you and for whoever has to argue your case.

Where it goes wrong#

The characteristic failure is imitating the outputs of staff work without the problem that made them worth producing.

It is easy to do accidentally, because the outputs are the visible part. Someone decides they are ready, and starts doing what the staff engineers around them appear to do: writing strategy documents, commenting on other teams’ designs, attending more meetings, reviewing changes outside their area. Every one of those actions is a real part of the job when it is downstream of a problem the person owns. Detached from one, the same actions make somebody whose contribution is opinions about work other people are accountable for — which is read, correctly, as overhead, and it is a difficult reputation to shed because the behaviour looks like initiative from the inside.

The tell is easy to check and unpleasant to apply. Take the last three documents you wrote. For each one, name the decision it changed and who would have made a different call without it. If the honest answer for all three is that nobody was going to act on them either way, the work was performance of the role rather than the role, and the fix is not more of it — it is to find one problem nobody currently owns and take responsibility for how it turns out.

The second failure is quieter and shows up after the promotion: being hired or promoted into one archetype while wanting another. A Solver placed in a Tech Lead’s seat experiences a year of meetings about work they are not doing; an Architect asked to behave like a Solver never stays anywhere long enough for the direction they set to be tested. Neither situation announces itself as a mismatch — both are experienced as being bad at the job — which is why asking which of the four a role actually is, before accepting it, is worth the awkwardness of the question.

Once the work has genuinely changed shape, the remaining problem is evidence, and it is a real one: almost nothing at this level leaves a diff behind. Gathering the case while it is still happening is the difference between a promotion conversation built on a record and one reconstructed from memory nine months later.