Claim
Promoting a senior IC to "principal" by stacking technical output is a category error. The principal+ role is defined by force-multiplier behaviour — making the whole team better through advocacy, mentorship, cross-org influence, and connecting work to business strategy — not by closing 10× more tickets.
Mechanism
Past a certain technical level, marginal output gain from one IC is small; marginal output gain from raising the floor of an entire team is large. The principal title exists to compensate that pattern. When organizations promote on individual code output, they end up with the "brilliant jerk" archetype that tanks team velocity. When they promote on multiplier behaviour, the title stops being an extension of the senior ladder and becomes a distinct craft requiring interpersonal skill, strategic judgment, and architectural breadth.
Conditions
Holds when:
- The career ladder explicitly defines principal-level competencies (cross-org collaboration, architecture, mentorship).
- The org is large enough that a multiplier role pays back — typically past ~30 engineers.
Fails when:
- The org calls itself "flat" and refuses titles. Botros: "all databases have schemas, even the ones that say they don't" — implicit ladders favour incumbents and bias.
- The role is staffed but not given cross-org scope — the principal becomes a glorified senior with no multiplier surface.
Evidence
"A principal engineer does not produce 10x the features or fix 10x the tech debt tickets. A truly valuable principal engineer makes their whole team better by advocating for best practices, gently reminding people of why the processes we have exist, and helping the less experienced engineers find ways to 'level up'."
"For an engineer to get to the principal level, there needs to be cross-organizational, collaborative signals, and there needs to be a clear understanding of architecture and design decisions that go far beyond the immediate technical area of expertise."
"Promoting any engineer to principal without demonstrative skills in more than just 'the code' would be a disservice to the team."
— Silvia Botros, "The reality of being a Principal Engineer," LeadDev, 2020-08-10
Signals
- Team velocity rises after the principal joins (not just principal's own velocity).
- The principal's calendar shows cross-team time — design reviews, recruiting, mentorship — not just IC focus blocks.
- Architecture decisions are documented and understood across teams the principal does not formally own.
- Newer engineers cite the principal as a reason they stay or got promoted.
Counter-evidence
Charity Majors warns the multiplier framing, taken too far, turns the principal's calendar into Swiss cheese — endless glue with no ship surface. Tanya Reilly counters that glue is the work — but only when the org names it as the work and reviews on it, not on commits. Without explicit competency definitions, the multiplier role gets reabsorbed into "senior senior" by promotion committees who can only score code.
Cross-references
- Glue work is technical leadership, not a tax on the IC — Tanya Reilly's reframe of glue as the technical leadership surface.
- Staff engineering has four archetypes — two of them rotate across teams by design — Will Larson's four-archetype map of the role.
- Killing your own initiatives loudly is the highest-trust move with executives — Jessica Fain's complement: principal-level behaviour includes killing your own work.