The first career ladder I helped write was eleven levels long, took two months, and was quietly ignored within a quarter. The second had five levels and no salary bands, which made it a performance review process wearing a costume. The third one worked, and the difference was not the writing — it was that we calibrated it against real engineers before publishing it and discovered that a third of our definitions were unusable. This is the method that came out of that, written for Dubai teams, where the thing you are competing with is not another ladder but a recruiter’s message containing a title and a number.
The 3 Ways Career Ladders Die
Before the method, the failure modes — because if you recognise one of these in a draft you already have, you can fix it without starting again.
They are written as titles. Someone opens a document and types Junior, Mid, Senior, Lead, Principal, and then tries to write definitions that justify the words. This is backwards and it produces definitions that differ only in adverbs: a senior engineer works “independently”, a lead works “highly independently”. Nobody can be promoted against an adverb, so promotion reverts to manager discretion and the document becomes decorative.
They have too many levels. Eleven levels felt rigorous and was in fact a way of avoiding hard calls. Each level needs a defensible boundary against its neighbours, a funded salary band, and a promotion conversation per engineer per career. At eleven levels the boundaries were so narrow that every promotion case was arguable in both directions, which is the worst possible property for a system whose entire job is to be predictable.
They are never published. This is the most common and the most costly. A ladder that lives in a leadership folder cannot do the one thing a ladder is for, which is letting an engineer aim at something specific without having to ask. If it is not published, with bands, it is not a ladder.
The 7 Steps, In Order
Order matters here more than in most processes, because several of these steps are only cheap if the previous one is done. Step five in particular will send you back to rewrite step one, and that is the system working rather than failing.
Step 1. Write the levels before the titles
Open a document and do not type a single job title. For each level write two sentences: what size of problem is this person trusted with, and how much supervision does that take. “Owns a service end to end, including its on-call, and is the person others ask before changing it” is a level. “Senior Software Engineer II” is a name you will argue about for a week.
Titles come last, in about twenty minutes, once the substance is agreed. Doing it in this order removes roughly 80% of the political heat, because people argue viciously about titles and reasonably about scope.
Step 2. Cap it at six levels
Six covers junior to principal for essentially any team under about eighty engineers: L1 junior, L2 engineer, L3 senior, L4 staff, L5 senior staff, L6 principal. Under fifteen engineers you can genuinely run four.
If you find yourself wanting an eighth level, the honest diagnosis is almost always that two existing levels are badly defined and people are being promoted sideways to escape a boundary nobody can articulate. Fix the definition instead of adding a rung.
Step 3. Split the technical and management tracks at level 4
Below L4 there is no meaningful distinction — a mid-level engineer who mentors is still a mid-level engineer. At L4 the paths genuinely diverge, and the rule that makes the split credible is that both tracks must reach the same top band.
If your management track tops out two bands above your technical track, you have not built a dual ladder. You have built a single ladder with a decorative branch, and your strongest engineers will read that correctly within a quarter and apply for management jobs they do not want. If you are standing up that management side for the first time, hiring an engineering manager in Dubai covers what that role actually needs to be able to do.
Step 4. Attach a salary band to every level before you publish
This is the step that converts a performance framework into a career structure, and it is the one most often deferred — usually with the reasoning that bands can be added later once the levels settle. They cannot, because the levels do not settle until money is attached to them. Nothing clarifies a definitional dispute faster than knowing what the answer costs.
Benchmark against the Dubai market rather than against your existing payroll, which is the second common error: deriving bands from what you currently pay encodes every historical anomaly into the structure permanently. Our method for building a developer salary benchmark for Dubai covers how to get defensible numbers, and you should expect the exercise to surface two or three people sitting outside any band. That discovery is uncomfortable and it is the entire point.
Need the market numbers before you set the bands?
We place engineers across the UAE every week and see what offers actually close at each level — including where published bands and real closing numbers have drifted apart.
Lance-toi — calibrate your bands with usStep 5. Calibrate on real engineers, in one room, in one sitting
This is the step that separates a ladder that works from a ladder that reads well. Put every manager in one room with the draft and the name of every current engineer, and place each person against the levels. One sitting, no homework, no going away to think about it.
Three things will happen, all of them useful. First, you will find definitions that cannot be applied — two managers will read the same sentence and place the same person a level apart. Those sentences are broken and you rewrite them on the spot. Second, you will find engineers whose actual scope does not match their current title, in both directions. Third, you will find a level that nobody lands on, which usually means it is not a real level.
In my third attempt at this, calibration invalidated about a third of the definitions. That felt like failure in the room and it was the most valuable afternoon of the project. The arguments in that session are the specification — the document is just the transcript.
Step 6. Define the promotion evidence, not the promotion feeling
For every level transition, name the artefacts that count as evidence. Not competencies, not behaviours — artefacts a manager can point at:
- L2 → L3: owned a service through at least one significant change, including its on-call, without a senior reviewing design decisions.
- L3 → L4: wrote a design document that changed how another team built something, and led at least one incident to resolution.
- L4 → L5: owned a migration or a cross-team technical decision end to end, including the part where other teams had to be persuaded.
- L5 → L6: set a technical direction that outlived the project that produced it.
The purpose of naming artefacts is to change what a promotion conversation is. With evidence defined, the conversation is a review of things that exist. Without it, the conversation is an argument about potential, which the most articulate engineer wins rather than the most effective one. That distinction matters more in a market like this one, where a sizeable share of your team did not grow up inside your company and have no shared sense of what “senior here” means.
Step 7. Publish it — bands included — and then leave it alone for four quarters
Publish to the whole engineering team: the levels, the definitions, the evidence requirements and the bands. Then do not edit it for a year.
The restraint is the hard part. You will spot wording you want to improve within a fortnight. Leave it, because a ladder that changes every quarter cannot be aimed at, and being aimable is the whole product. Let one complete promotion cycle run against a stable document, collect the places it genuinely failed, and revise once — annually, with a changelog.
Where the Ladder Meets the Hiring Market
A ladder built only for internal promotion breaks the first time you hire externally at L4 or above, which for most growing Dubai teams is within weeks. The pressure is always the same: a strong candidate holds a title from a previous employer and will not move backwards on paper.
Translate scope, not titles, and do it in the interview rather than at offer stage. The four questions in the chart above — largest thing owned end to end, who made the design calls, who they escalated to, what broke and who fixed it — place someone accurately in about twenty minutes, and they work equally well on a candidate from a forty-person startup and one from a large platform company whose remit was narrow but deep.
When you do decide to stretch, say so explicitly: hire at L4 with a documented path to L5 and a named reviewer at six months. That is a legitimate decision. What is not legitimate is quietly placing someone a level above their scope to win the offer, because your existing engineers at that level will notice within a month and conclude, correctly, that the ladder is negotiable. Keeping the screen and the ladder in sync is also what makes a technical interview scorecard worth maintaining, and it is upstream of every competitive offer negotiation you will run this year.
What a Ladder Does and Does Not Fix
I want to be honest about the size of the effect, because career ladders get sold as a retention cure and they are not one.
A ladder does nothing about an engineer leaving for a 30% raise, a relocation, or a manager they cannot work with. What it fixes is narrower and surprisingly common: the person who left because they could not see a future and assumed there was not one. Nobody puts that on an exit interview, which is why it is routinely under-counted.
In Dubai that category is larger than most employers expect, for a structural reason. Strong developers here are approached constantly, and every approach arrives with a defined title and a specific number. If your internal answer to “what happens next for me” is a conversation that keeps getting rescheduled, you are not losing on compensation — you are losing on legibility. The ladder’s job is to make your offer as readable as the external one. Paired with the broader retention mechanics in retaining senior developers in Dubai, and the operational side covered in building HR management systems in Dubai, it is one of the cheapest interventions available to an engineering leader.
A ladder is only as good as the market data behind it
We place developers across the UAE and help engineering leaders set levels and bands that hold up against the offers their team is actually receiving.
Lance-toi — brief our Dubai teamFrequently Asked Questions
How many levels should an engineering career ladder have?
Six is the number I would defend for almost any Dubai team below roughly eighty engineers, covering junior, engineer, senior, staff, senior staff and principal, with a management track branching at the staff equivalent. The temptation is always to add more, usually because someone deserves a promotion and no existing level fits. Resist it, because every level you add has three costs. You have to write a defensible definition that distinguishes it from its neighbours, which gets harder as the gaps narrow. You have to benchmark and fund a salary band for it. And you create another promotion conversation per engineer per career, each of which consumes manager time and generates disappointment when it does not land. Teams under about fifteen engineers can genuinely run on four levels. If you find yourself needing eight, the real problem is usually that two of your existing levels are badly defined and people are being promoted sideways to escape them.
Should the salary bands be public to the team?
Publish the bands. I have watched this decision go both ways many times and the version where bands stay hidden fails for a predictable reason: the information leaks anyway, in a distorted form, through candidates and departing colleagues, and the distorted version is always worse than the truth. Hidden bands also remove the ladder’s main retention benefit, which is not fairness but legibility. An engineer who can see that level five pays a defined range and can read exactly what level five requires has a reason to stay for eighteen months. An engineer who is told there is a ladder but not what it pays has been given a performance framework and called it a career. What you should not publish is individual positions within bands. The band is structural information and belongs to everyone. Where a specific person sits inside it is their business and their manager’s.
How do I level a candidate coming from a big tech company?
Translate the scope, never the title, and expect the translation to be unflattering. Titles inflate differently at every company, and a senior at a large platform company may have owned a narrow slice of a mature system with substantial support, while a senior at a forty-person startup may have carried three services and the on-call pager alone. Neither is better, but they are not the same level. The usable method is to ask for the largest piece of work the candidate owned end to end, then establish who made the design decisions, who they escalated to, what broke and who fixed it. That conversation places people accurately in about twenty minutes. The failure mode to guard against is matching a candidate’s previous title to keep them interested, because the cost arrives later: either you have put someone above their actual scope and your existing level five quietly becomes meaningless, or you have created a salary outlier that your next benchmark exercise will surface as an anomaly you cannot explain.
Does a career ladder actually reduce attrition in the Dubai market?
It reduces one specific kind of attrition, which is worth being precise about rather than overselling. A ladder does nothing about an engineer who leaves for a thirty percent raise, a relocation, or a manager they cannot work with. What it addresses is the departure that happens because someone could not see a future and assumed there was not one. In the Dubai market that category is larger than most employers think, because the alternative is unusually visible: strong developers here are approached constantly, and the approach always comes with a defined title and a number. If your internal answer to what happens next is a conversation that keeps getting rescheduled, you lose on legibility rather than on money. The ladder makes your offer comparable to the external one. That is a real effect and a bounded one, and it only works if the bands are published and the promotion criteria are evidence-based rather than discretionary.
William
Talent Sourcing Expert at HireDeveloper.ae. Screens and levels engineering candidates for UAE employers, and calibrates client hiring bars against the offers candidates are receiving elsewhere.