Most engineers optimise for the next title. The better move is understanding what the role actually demands — and whether that matches how you think.
Context
Why the hierarchy exists
Engineering orgs are structured around two things: scope of work and scope of judgment. Titles encode both. A junior engineer’s mistakes affect a module. A principal’s mistakes affect a product line. The ladder exists to map authority to consequence — not to create a queue for promotions.
Most dysfunction in engineering orgs comes from a mismatch: people operating at the wrong level, or level expectations that are never written down clearly enough to act on.
“In a hierarchy, every employee tends to rise to their level of incompetence.” — Laurence J. Peter
Insight
The two tracks most orgs don’t explain clearly
After mid-level, the path splits. Individual contributor (IC) and management are not interchangeable. They reward different instincts and punish different defaults.
| Level | Track | Primary output | Failure mode |
|---|---|---|---|
| Junior / Mid | IC | Assigned scope, delivered well | Speed over correctness |
| Senior | IC | Owns a system, unblocks others | Goes too deep, misses context |
| Staff / Principal | IC | Cross-team technical direction | Solves the wrong problem elegantly |
| Eng Manager | MGR | Team output, hiring, retention | Shields team instead of growing them |
| Director / VP | MGR | Org design, strategy, exec interface | Manages up, neglects ICs |
The senior-to-staff jump is the hardest. It’s when the job stops being about design or code and starts being about decisions other people execute.
Implication
What changes at each inflection point
Track 1: Domain Specialist
Junior → Senior: The shift is from “told what to build” to “figures out what to build.” Ownership of delivery, not just execution. Most people get this right eventually.
Senior → Staff: Scope expands beyond one team. You’re now shaping decisions across systems you don’t directly own. The mistake most seniors make here is trying to code their way to staff. It doesn’t work. Influence over architecture, not lines of code, is what drives this promotion.
Track 2: Domain Manager
IC → Manager: Output is no longer yours. You succeed when your team succeeds. Engineers who resist delegating, who still want to be the best coder in the room — they make poor managers and often resent the role within 12 months.
Manager → Director: The job becomes org design, not team output. You’re setting conditions, not reviewing PRs. Most strong EMs struggle here because they conflate doing with enabling at scale.
Action
How to use this
If you’re an IC: stop asking “how do I get promoted” and start asking “what decisions am I not yet trusted to make, and why.” Close that gap.
If you’re a manager: the table above is a diagnostic. If your ICs’ failure modes are showing, that’s a signal problem — they don’t know what the level requires. Fix the spec, not the person.
If you’re building an eng org: write down your level expectations before you need them. Level ambiguity creates politics. Clarity creates performance.
Operator-grade thinking for engineering leaders.