An eleven-level ladder took two months to build and was ignored within a quarter. A five-level replacement had no salary bands and functioned as a performance review process wearing a costume. The third attempt worked — not because the writing improved, but because the team calibrated it against real engineers before publishing and found a third of the definitions were unusable, according to one recruiter's account of building leveling systems for engineering teams in Dubai (hiredeveloper.ae).
That's the pattern I'd flag for anyone at 8-to-15 engineers wondering if it's time to formalize levels: the question isn't whether you're big enough. It's whether you can survive the first calibration pass without rewriting the whole thing.
Titles First Is the Tell That You're Not Ready
The most common failure mode isn't complexity — it's sequence. Someone opens a doc, types Junior, Mid, Senior, Lead, Principal, and then writes definitions to justify words that already exist in people's heads. The result is levels that differ only by adverb: senior works "independently," lead works "highly independently." Nobody can be promoted against an adverb, so the ladder becomes decorative and promotion reverts to manager discretion anyway — which is exactly the state you were trying to leave (hiredeveloper.ae).
I'd treat this as a diagnostic you can run before you write a single rung: if you can't describe the size of problem someone's trusted with and how much supervision that requires without reaching for a title first, you're not formalizing a structure that already exists informally — you're inventing one, and invented structures are the ones that get ignored by quarter two.
This matters more at mid-stage than people expect, because mid-stage is exactly when informal leveling (the stuff everyone already agrees on but nobody's written down) starts breaking under new hires who weren't there to absorb it by osmosis. A ladder written to formalize consensus survives calibration. A ladder written to manufacture consensus doesn't.
Managing a Team Isn't the Same Scope Problem as Managing a Ladder
There's a parallel worth drawing from how engineering manager tracks themselves get described. At the first management rung, scope is bounded and concrete: run one-on-ones, hire well, manage delivery for a single team of five to eight people, with success measured by whether the team delivers predictably and retains well (em-tools.io). The jump to the next rung isn't more of the same work — it's organizational breadth: mentoring other managers, contributing to engineering-wide initiatives, operating with more ambiguity and less supervision (em-tools.io).
I think that structure — bounded scope at the bottom, ambiguity and breadth at the top — is the actual test for whether your IC organization is ready for a formal ladder. Not headcount. Not "we've been operating for 18 months." The real signal is whether you're already making promotion calls that require distinguishing scope and ambiguity, informally, team by team, and getting inconsistent answers depending on who's doing the judging. If two different managers would place the same engineer at different levels because nobody's written down what "owns a service end to end, including its on-call" actually means versus "contributes under supervision," you don't have a leveling problem you're choosing to solve. You have one you're already failing to solve, informally, every performance cycle.
What to Watch Before You Publish
Two levels is a performance review in costume. Eleven levels is false rigor — every boundary becomes arguable in both directions, which is the worst property a system built for predictability can have (hiredeveloper.ae). Neither extreme fails because the number is wrong. Both fail because nobody tested the boundaries against actual engineers before calling it done.
So before you write the first draft, run the test you'll eventually need anyway: take five to ten real engineers, sort them into provisional levels using scope and supervision language only, and see where the arguments happen. If the arguments cluster at two or three boundaries, you have real levels worth formalizing. If they're everywhere, you don't have a ladder problem yet — you have a scope-definition problem that a ladder will only make official, not solve.
The ladder you publish should feel like documentation of something your best managers already agree on. If it feels like a document you're hoping will create that agreement, hold off. You'll rewrite it inside a quarter anyway.