Alex Ewerlöf's Post

Alex Ewerlöf · article · 2026-10-08 source ↗ Reader 🖥️

Hands-On Leadership & the Pendulum Informal Leadership Technical Leadership Track (IC / Staff-Plus Ladder)

On the Y-shaped career ladder, Staff Engineers — unlike Engineering Managers, who spend their discretionary time on people-admin — should put their extra time into deepening technical skill and staying hands-on in code and architecture, because the alternative is sliding into an 'Ivory Tower Architect': elevated pay, voice, and autonomy without the grounding that earns it, which working engineers quietly route around.

practical · argumentative — A prescriptive argument for how Staff Engineers should spend their time, built on a personal-experience warning ('I learned it the hard way') rather than data.

Structure

Part	Role
The Y-shaped ladder premise: Staff and EM are peer levels, but EM's time is consumed by people-admin while Staff's is not	context/premise
The prescription: Staff's freed-up time should go to technical depth, not elevated-voice generalism	conclusion
The Ivory Tower Architect (ITA) anti-pattern and litmus test (do they code regularly? are they on-call?)	warning/evidence
Personal confession: time spent only in closed-door meetings as an engineers' representative while skilled engineers worked around him	evidence (anecdotal)

Key terms

Ivory Tower Architect (ITA)
The failure mode of a Staff Engineer (or any senior technical role) who accumulates elevated pay, voice, and autonomy without staying grounded in actual code and architecture work — a role engineers learn to work around rather than with.
Y-shaped career ladder
A dual-track career model where individual-contributor (technical) and management tracks diverge after a common early stage but meet at a comparable level — Staff on the technical branch, Engineering Manager on the people branch.

Propositions

explicitStaff Engineers should sharpen their technical skills more than anyone else at their level, because — unlike Engineering Managers, whose time is consumed by admin work, 1-1s, hiring, and performance/salary review — Staff's discretionary time has nowhere else productive to go but technical depth.conf: high
supportsUpdate on Software Engineering Career Ladder · p7 — Ewerlöf's prescription that Staff should stay hands-on and coding-centric matches a real, structurally-encoded career-ladder design (Technical Lead and Staff Engineer both defined as player-coach, coding-centric roles) rather than being an idiosyncratic personal opinion.
explicitIf a Staff Engineer is not meaningfully deeper and wider in technical skill than other engineers at their level, the role is an anti-pattern — both EM and Staff are nominally expected to be 'very technical,' but Staff's distinguishing value specifically is going deeper into tech.conf: high
extendsDeveloping Your Leadership Skills toward Principal Engineering · p1 — Ewerlöf's claim focuses on technical depth as Staff's distinguishing value versus EM; the other document adds that influence, communication, and strategy are also required for the adjacent principal-engineer level — a complementary, not contradictory, fuller skill picture one level up.
explicitcontestedThe biggest pitfall for a Staff Engineer is becoming an Ivory Tower Architect — elevated pay, voice, and autonomy without staying grounded in code — and architecture should not be abstracted away into a dedicated, non-coding role, because architecture is every engineer's concern.conf: high
contradictsStop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge · p1 — Ewerlöf insists architecture must not be abstracted away from hands-on coding and warns against the Ivory-Tower-Architect drift toward 'defining outcomes' over doing the work; the AI-era piece argues the opposite directional bet — that the shift from coder to outcome-defining enabler is exactly what positions a Staff Engineer well for leading AI agents. Same role, same vocabulary (outcomes, guardrails, review), opposite verdict on whether drifting away from hands-on execution is a trap or an advantage — a tension worth reading together rather than resolving by assertion.
explicitWhether someone is a real Staff Engineer or a ceremonial title-holder can be tested with a simple observation: do they code regularly, and is a good signal that they are held accountable for tech health by being on-call.conf: high
explicitA Staff Engineer who spends most of their time in closed-door meetings representing engineers, while skilled engineers go to great lengths to work around them, has painted themselves into a career-limiting corner.conf: high

Arguments

Staff Engineers should spend their freed-up discretionary time on technical depth rather than on EM-style generalist/representative activity. strength: medium

Explicit premises:

EM's discretionary time is consumed by people-admin (1-1s, hiring, reviews); Staff's is not.
Staff's organizational impact comes from fluency with engineers and contribution to code/architecture.
The alternative failure mode (Ivory Tower Architect) is observably bad — engineers route around it.

Implicit premises:

Technical depth is a scarce, high-leverage resource that the organization needs concentrated somewhere, and Staff is the right place to concentrate it rather than, e.g., distributing it more evenly or letting it specialize into a separate architect role.
'Coding regularly' is still the right proxy for technical groundedness regardless of how the nature of coding work itself is changing (the post predates, and does not consider, AI-assisted/agentic coding tools).

Inferences:

If AI coding agents substantially change what 'contributing to code' requires or looks like, the litmus test itself ('do they code regularly') may need redefinition rather than simple application — a question this 2024 post has no occasion to address.

Narratives

The author's own account of having spent much of his Staff-level time in closed-door meetings as an engineers' representative, only to find skilled engineers quietly working around him rather than through him.
→ Supports the proposition that drifting away from hands-on code into a purely representative role is a specific, recognizable career trap — stated as lived experience ('I learned it the hard way') rather than argued abstractly.

Questions addressed

✅ What should a Staff Engineer do with the discretionary time an Engineering Manager doesn't have (because EM time is consumed by admin)?
Sharpen technical skill — go deeper and wider into tech than other engineers at the same level.
✅ How can an organization (or the engineer themselves) tell a real Staff Engineer from a ceremonial titleholder?
A litmus test: do they code regularly, and are they on-call.
⭕ Does the meaning of 'coding regularly' or 'contributing to code' as a groundedness signal change once AI coding agents do a growing share of the typing and even the design decomposition?
Not addressed — the post predates the agentic-coding wave this corpus mostly examines.

Gaps

incompleteThe post's entire argument and litmus test ('do they code regularly?') is built on a pre-AI model of what staying technically grounded means, with no engagement of how AI coding agents change what 'contributing to code' requires or signals — a question this corpus's own AI-era treatment of the Staff Engineer role addresses directly and with a near-opposite emphasis (shifting Staff value toward outcome-definition and guardrail-setting over hands-on execution).
Read next: extract-mokhtar-staff-engineer-leading-agents#p1 for the AI-era counter-claim that the 'coder to enabler' shift is early rather than a retreat from technical grounding.
uninformedThe Ivory Tower Architect anti-pattern and the 'Staff is an anti-pattern if not deeper in tech than EM' claim rest entirely on the author's personal experience and reasoning from the Y-shaped ladder's structure, with no organizational data, survey, or comparison of Staff Engineers' actual effectiveness by how hands-on they stay.
Read next: extract-shore-software-engineering-career-ladder-update#p7 for a documented organizational ladder design (Shopify-style) that encodes the same coding-centric Staff/Tech-Lead expectation structurally rather than as individual advice.