Technical Leadership Track (IC / Staff-Plus Ladder)
The staff to principal to distinguished-engineer / architect career ladder where one leads through technical judgment, design authority and influence rather than personnel management — parallel to the management ladder, with no direct reports.
Also known as: staff engineer, principal engineer, IC leadership ladder, technical track, individual-contributor track, staff-plus, dual ladder, leadership not management, title-less technical leadership
Part of: Technology Leadership (Heis)
Documents (8)
- Alex Ewerlöf's Post Alex Ewerlöf · 2026-10-08 source ↗ Reader 🖥️
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. - Addy Osmani’s Post Addy Osmani · 2026-07-11 source ↗ Reader 🖥️
As coding agents make solving cheap and abundant, an engineer's durable career value shifts from being the fastest problem-solver to the 'ungradeable' meta-skills that have no answer key — selecting which problems matter, judging quality through earned taste, directing agents rather than doing the work, sprinting the hard last mile, and owning the outcome. - We don't write code anymore Vincent Quigley · 2026-06-12 source ↗ Reader 🖥️
Software engineering has entered a fourth generation of abstraction in which implementation is cheap and the hardest, most valuable work has moved up a level to framing, specifying, steering, and reviewing — which requires engineers, teams, and engineering management itself to reorganize around judgment and review capacity rather than code production. - The engineering manager role is splitting in two Stephane Moreau · 2026-06-09 source ↗ Reader 🖥️
The engineering-manager role is fracturing into two divergent futures — the code-adjacent tech lead manager and the non-technical multi-team EM — and because AI-shrunk teams are driving the split as an unplanned byproduct of flattening, engineers on the management path must diagnose which future their company is building and prepare accordingly rather than aiming at a single 'EM' destination. - InfoQ Launches Online AI Engineering Cohort and Certification for Senior Software Practitioners Artenisa Chatziou · 2026-05-22 source ↗ Reader 🖥️
As engineers advance into senior/staff/principal roles, the number of people inside their own organization able to meaningfully challenge their reasoning shrinks, and this is offered as the justification for InfoQ's new paid online cohort product — a confidential, cross-company peer group that substitutes external peers for the internal challengers senior engineers lack. - Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge Emad Mokhtar · 2026-05-07 source ↗ Reader 🖥️
The Staff Engineer skillset of defining outcomes, reducing ambiguity, creating guardrails, and reviewing work — originally built for leading human teams — transfers directly to leading AI coding agents, and is becoming more valuable, not less, as agents take over more implementation. - When AI Writes Almost All Code, What Happens To Software Engineering? Gergely Orosz · 2026-01-06 Reader 🖥️
As AI crosses a real capability threshold and starts writing the large majority of code for many developers and teams, the part of software engineering that was always about judgment, verification, architecture, and accountability — not typing syntax — becomes more valuable, not less, while the raw ability to write code in a given language stops being a differentiator at all. - Update on Software Engineering Career Ladder jamesshore.com · 2024-08-20 source ↗ Reader 🖥️
OpenSesame's redesigned career ladder deliberately shifts the organization's definition of engineering seniority away from individual ownership and self-promotion toward teamwork, peer leadership, and manager-verified skill fluency -- trading the old system's clarity and perceived fairness for reduced self-promotion/tenure bias, at the real cost of a heavier, judgment-intensive evaluation burden that falls unevenly on managers depending on how well they already know their people.
Propositions touching this concept (10)
By publication month, oldest first (extraction month when no publication date is known).
2024-08
- explicitcorroboratedThe Technical Lead role is explicitly defined as 'coding-centric,' with the majority of time spent as a player-coach alongside the team rather than in pure leadership or management activity; the same player-coach framing extends to the newly added Staff Engineer title, which works hands-on with each team in turn rather than managing people.
- implicitSeveral specific skills were deliberately added or reclassified between the April and August versions of the ladder (e.g. 'Assume positive intent' and 'Build quality in' added; 'Grit' renamed 'Persistence'; 'Evaluate complex dependencies' moved up from Senior Software Engineer to Technical Lead; 'Reflective codebase architecture' moved up from Senior Software Engineer to the new Staff Engineer level), indicating the skill list is actively recalibrated based on where each skill is actually exercised, not fixed at first design.
2026-03
- explicitWithout personnel authority (e.g. as a principal engineer with 40 architects to orchestrate), one is forced to develop a non-coercive leadership style that transfers well into formal roles later.
2026-04
- explicitcorroboratedBecoming a principal engineer requires influence, communication, and strategy — not just technical skill
2026-05
- explicit⚡ disputed & corroboratedThe Staff Engineer leadership skillset — defining outcomes, reducing ambiguity, creating guardrails, reviewing work — is becoming more valuable, not less, in the AI era; engineers who already made the shift from coder to enabler for human teams are early, not late, to AI.
- implicitThe piece assumes the Staff Engineer leadership skillset is something any individual engineer can acquire unilaterally through personal initiative, the way the author did informally before being titled — it has no account of how an organization deliberately trains, structures, or rewards this transition across its wider engineering population, nor what happens to engineers who haven't yet built the human-leadership reps the author leaned on.
2026-10
- 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.
- 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.
- 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.
- 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.
Open gaps (15)
- 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).Alex Ewerlöf's Post — 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.Alex Ewerlöf's Post — 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.
- incompleteEikeland's developer-to-leader sorgprosess prescription is rich on the loss side but thin on the gain side. The transition presumably brings new sources of meaning (impact through others, system-level effect, mentoring, organisational design), but the conversation barely names them. The risk for the listener is to internalise the loss-frame and miss the path through.4) Morten Eikeland: Det finnes alltid et hierarki — read next: Camille Fournier's Manager's Path; Will Larson's Staff Engineer/An Elegant Puzzle on the IC-vs-manager fork; Lara Hogan on growing engineering leaders. Pair with Olga Khazan or Lori Gottlieb on the psychology of mid-career identity transitions.
- incompleteBredde/dybde sounds clean but is operationally underspecified. How does a sjefsarkitekt choose which initiatives to take as 'mine'? Ulseth nods that they should be 'both important and interesting' and that the two usually overlap — but the harder cases (important-but-boring, interesting-but-marginal) are not discussed. This is the place where pendling-by-design either works or quietly collapses into one side.14) Øystein Ulseth pendler mellom å lede og levere — read next: Cutler on how leaders allocate attention; deep-dive into 'staff-plus' patterns where senior ICs balance technical and political work.
- incompleteNo data on whether pendling actually produces better outcomes. The argument is largely 'I felt better and have heard I do better.' The episode lacks any reference to organisational research on whether engineer-manager pendulum careers correlate with better team or product outcomes — and whether the benefits go to the individual, the team, or the organisation.14) Øystein Ulseth pendler mellom å lede og levere — read next: Pragmatic Engineer / Newcomer on staff-plus role outcomes; LeadDev surveys on engineer-manager transitions; academic work on bidirectional career mobility in knowledge work.
- evidentiaryThe central premise — that seniority narrows the internal pool of people who can challenge one's reasoning — is asserted with no supporting data, survey, or citation, despite being the entire justification for the product; no evidence is offered that a paid, 5-week, cross-company cohort measurably closes that gap better than existing alternatives (internal skip-level mentoring, external meetups, architecture review boards, informal peer networks).
- incompleteThe article never addresses the tension between breadth (community, speaking, diverse skills) and depth (deep technical mastery). Principal engineers are typically expected to have both, but the article focuses entirely on the breadth side. An engineer following this advice exclusively might develop excellent leadership skills while falling behind technically — which would undermine their credibility in the role.Developing Your Leadership Skills toward Principal Engineering — read next: Will Larson's 'Staff Engineer' or Tanya Reilly's 'The Staff Engineer's Path' for the technical depth dimension; also the original talk video for potential coverage of this balance
- incompleteThe article is a journalistic summary of Weston's talk, not an independent analysis. The real intellectual content is in the original QCon presentation, which likely contains more nuance, caveats, and audience interaction than this compressed version captures.Developing Your Leadership Skills toward Principal Engineering — read next: Watch the original talk: 'The Principal Engineer's Path' by Sophie Weston, QCon London
- incompleteThe piece is written entirely from the perspective of one self-motivated individual's personal transition; it never addresses the team or organizational dimension — how review capacity, coordination, and quality standards hold up when many engineers in the same org are each independently 'leading' their own agent swarms, or how an organization trains and rewards this shift systematically rather than relying on individuals to discover it the way the author did.Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge — read next: extract-engineering-manager-role-splitting-in-two and extract-software-teaming-age-of-ai-zuill-herr, which address the team- and org-level coordination costs this piece elides.
- incompleteNo discussion of durable, large-scale, or legacy codebases; every example (CLI tool, personal dashboard, browser extension, a user-management endpoint) is small, disposable, or greenfield. The claim that the Staff Engineer skillset transfers to leading agents is untested against the harder case of agents operating inside a decade-old, high-stakes production system.Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge — read next: extract-orosz-when-ai-writes-almost-all-code (production-quality regressions already observed) and extract-whats-an-orchestrator-why-software-needs-one (accountability scaling with agent-driven productivity).
- illogicalThe author frames 'reviewing becomes more important' as sufficient reassurance without reconciling it with his own admission that agents 'make mistakes... sometimes create bugs that look very convincing.' If agent output is specifically liable to look convincing while being wrong, review itself becomes harder exactly as it becomes more necessary — a tension the piece raises but doesn't resolve.
- uninformedAll reported practice comes from one senior, well-resourced team (10+ years' experience each) at a company absorbing roughly $2,000/month per engineer in AI spend; the piece generalizes 'the review bar cannot drop' and 'months of coaching to get good engineers up to standard' as achievable expectations without addressing whether less senior, less resourced, or more cost-constrained teams can sustain the same review intensity, or what happens to engineers who never built hand-written-code intuition in the first place.
- incompleteThe piece names the manager-led evaluation burden as a known cost but gives no account of how much manager time it actually consumes, and no fallback plan if the stated theory -- that the burden 'is only going to be difficult the first time, and then will get easier' -- turns out not to hold.Update on Software Engineering Career Ladder — read next: A later Shore update or comparable published career-ladder retrospectives reporting measured manager time burden over multiple cycles.
- uninformedPublished August 2024, the ladder has no skill addressing AI-assisted development, coding-agent supervision, or AI fluency at any level -- even though the same period's industry discourse was already reframing exactly the skillset the ladder specifies for Staff Engineer and Technical Lead (defining outcomes, reducing ambiguity, mentoring, architectural review, cross-pollination) as increasingly valuable, and increasingly time-starved, specifically because of AI coding agents.Update on Software Engineering Career Ladder — read next: extract-mokhtar-staff-engineer-leading-agents and extract-the-future-of-software-engineering, which argue this exact Staff Engineer skillset becomes more load-bearing (and more oversubscribed) as teams adopt coding agents.
- incompleteThere is no discussion of how skill ratings are verified beyond a single manager's own judgment -- no peer input, no cross-manager calibration process, no appeals mechanism -- despite the explicit goal of reducing bias; if two managers rate the same demonstrated behavior differently, the piece gives no mechanism for catching or correcting that.Update on Software Engineering Career Ladder — read next: Calibration/peer-review mechanisms in other practitioner career-ladder writeups, or a later Shore follow-up addressing cross-manager consistency.