I Lost 3 Senior Engineers to a Promise I Never Wrote Down: the 7-Step Career Ladder I Built in Singapore

Three senior engineers left within five months of each other. In two of the three exit conversations I heard a version of the same sentence: there was no visible path, and the one they had been told about verbally had changed. They were right. We had no ladder. We had a set of individual conversations held at different times by different managers, each reasonable on its own and collectively incoherent. This is the seven-step process I used to build one, written for Singapore specifically because step five runs into pass requirements that teams elsewhere never have to think about.

Step 1: Decide What the Ladder Is For

Ladders fail in two directions. Some are never written because the task looks enormous. Others are written so thoroughly that they become a forty-page document nobody opens, including the managers who are supposed to apply it.

Both failures come from skipping this step. Write one sentence: which recurring decision does this ladder exist to make? The honest answer for most teams is a version of “decide, consistently and defensibly, who gets promoted and what they have to demonstrate first.” That sentence excludes a great deal. It excludes being a complete competency taxonomy. It excludes being a training curriculum. It excludes being a hiring rubric, although it will inform one.

Keep the sentence at the top of the document. When someone proposes adding a dimension, the test is whether it changes a promotion decision. Most proposed additions do not, and the discipline of asking is what keeps the document to a length people will actually read.

Step 2: Choose the Number of Levels and Stop

For a team under fifty engineers, five or six levels. A workable shape on the individual contributor side: junior, engineer, senior, staff, principal.

You will be lobbied for more, and the lobbying is always well-intentioned. It comes from wanting to recognise someone without being able to give them more scope. That is a real problem and a ladder is the wrong tool for it. The cost of solving it with extra levels is that two adjacent levels become indistinguishable to anyone reading the descriptions, and once that is true the entire document loses authority, including the parts that were well written.

The test: hand two managers the descriptions for level three and level four with the labels removed, and ask them to assign three engineers. If they disagree, you do not have two levels, you have one level and a rounding error.

Step 3: Write Each Level as Observable Behaviour

This is the step that determines whether the ladder survives. Do not use years of experience as a criterion. It measures elapsed time rather than capability and it produces two reliable failures: fast-growing engineers hit an artificial ceiling and leave, and long-tenured engineers arrive at senior titles without the scope that should accompany them.

Write instead in terms of scope and verifiable evidence. For each level, answer four questions:

1. What size and ambiguity of problem do they take on? A well-specified ticket, a vague feature, an undefined business problem, or a problem nobody has noticed yet.
2. Where do they sit in the review relationship? Needs their design reviewed, reviews others, sets the standard others review against.
3. What is their blast radius? Their own work, their team’s work, several teams, the engineering organisation.
4. What are they trusted to decide alone? Specifically including decisions that are expensive to reverse, which is the cleanest single discriminator between senior and staff in practice.

Experience ranges can appear in brackets as a sanity check. They cannot be the criterion. The moment they are, every promotion conversation becomes a negotiation about tenure and the ladder stops describing capability.

Step 4: Split the IC and Management Tracks at the Right Level

Split where leading people becomes a distinct job rather than an extension of a senior engineer’s role. In most teams that is at senior: below it, everyone is doing some mentoring and nobody is doing management; at and above it, the two genuinely diverge.

Two rules make the split work, and they are the rules most often broken.

Both tracks must reach the same levels. If the management track goes higher, you have not built two tracks, you have built one track with a mandatory career change in the middle. Your strongest engineers will read that correctly and either take a management job they do not want or leave for somewhere that does not require it. Both outcomes are expensive and the second is harder to see coming.

Moving between tracks must be explicitly allowed and not treated as failure. An engineer who tries management for a year and returns to the IC track should return at the equivalent level with no loss of standing. Write that sentence into the document. Without it, nobody will try management, because the perceived cost of discovering they dislike it is their career.

The point where this intersects with team design is span of control, which deserves its own treatment: our guide to engineering org charts and span of control in Singapore covers how many people a manager at each level should actually have, and setting up a developer mentorship programme covers the mentoring load that sits on the IC track instead.

Step 5: Map Levels to Bands, Not to Salaries

Each level gets a band with a floor and a ceiling, and adjacent bands should overlap. Overlap is a feature: it lets you hire a strong candidate at the top of a lower level without forcing a promotion you cannot justify, and it lets someone grow within a level rather than needing a title change to get a raise.

In Singapore there is a constraint here that teams in other markets never meet, and it belongs in the design rather than in the first live hire.

Employment Pass qualifying salaries rise with candidate age and vary by sector, and applications are assessed against the points-based Complementarity Assessment Framework, which considers factors including salary relative to local benchmarks and the firm’s local employment share. The consequence for a ladder is specific: a band that looks internally sensible can sit below the prevailing qualifying salary for an older candidate at that level, which makes the level effectively unfillable by a pass holder. You will discover this at the worst possible moment, with a signed candidate and a rejected application.

So check each band against the current published thresholds when you set them, and again annually. Thresholds change, so treat any number you write down as perishable and confirm the current position with the Ministry of Manpower rather than with a document from last year. The band structure itself is the subject of structuring developer compensation packages in Singapore, and if equity forms part of the package, ESOP for developers in a Singapore startup covers the part that does not appear in a salary band at all.

Step 6: Design the Promotion Process Before the First Cycle

A ladder without a process is a list of adjectives. Four decisions, made before anyone is evaluated:

1. Who writes the evidence? The manager drafts, the engineer contributes. If the engineer writes the whole case, you are measuring self-advocacy, which correlates with confidence and culture rather than with scope, and you will systematically under-promote quieter people.
2. Who calibrates across teams? All managers at one level, in one room, same session. This is the step teams skip when they are busy, and it is the step that determines whether a promotion means the same thing under two different managers. Without it you will be asked, correctly, why progression appears to depend on who someone reports to.
3. Who decides? Name the role. Ambiguity here produces outcomes nobody owns and nobody can explain.
4. How is the outcome communicated, including a no? Write the shape of the no in advance: what was missing, what evidence would change it, when it will be looked at again. This is the most neglected item on the list and the one that most determines whether people trust the system.

Set the cadence at twice a year for a growing team. Annual is too slow when people are growing quickly and creates pressure to promote off-cycle, which undermines calibration. Quarterly turns into permanent promotion season and consumes the management time the ladder was supposed to save. Keep promotion decisions out of the performance review conversation: they rely on different evidence over different time horizons, and merging them means a strong quarter gets read as readiness for more scope. We set out that separation in running developer performance reviews in Singapore, and the opposite case in managing an underperforming developer.

Step 7: Run One Calibration Round, Then Fix What Broke

The first cycle is a test of the ladder, not of the engineers. Go into it expecting to find defects, and schedule the time to fix them while the evidence is fresh.

What to watch for: any level description where two managers assigned the same engineer differently, any criterion that nobody cited in any case, any promotion that felt obviously right but could not be evidenced against the written bar, and any engineer whose situation the ladder simply does not describe.

In our first round the defect was specific and would not have been predictable from the document: our senior description conflated two different things, technical depth in one system and the ability to operate across ambiguity, and we had engineers strong in one and not the other. Two managers read the same text as describing two different people, and both readings were defensible. We split the criterion, rewrote the level, and the second round ran without the argument.

Then publish. Every engineer should be able to read the ladder, find their current level, and read the one above it. If it is not published, it is not a ladder, it is the same set of private conversations that cost me three senior engineers, with a document attached. Progression visibility is one of the few retention levers that costs nothing to pull, which is why it appears in our guide to retaining senior developers in a competitive Singapore market.

Three Mistakes That Cost the Most

Using years of experience as the criterion. It is the fastest way to lose a fast-growing engineer and the fastest way to create a senior title with no senior scope behind it. Experience belongs in brackets as a sanity check, never in the bar.

Letting the management track go higher than the IC track. This quietly tells your strongest engineers that staying technical has a ceiling. They will believe you, and the ones with options will act on it before you notice the pattern.

Skipping calibration when the cycle is busy. It is always the step under time pressure and it is the step that creates fairness. One uncalibrated cycle will be remembered longer than three calibrated ones, because the people it disadvantaged will compare notes.

FAQ: Engineering Career Ladders in Singapore

Notes: Employment Pass qualifying salaries in Singapore rise with candidate age and vary by sector, and applications are assessed against the points-based Complementarity Assessment Framework. Thresholds and framework criteria are revised periodically, so confirm the current position with the Ministry of Manpower before relying on any figure, including any you have recorded internally. The level shapes, the four scope questions, the cadence recommendation and the calibration findings described here reflect the engineering teams we recruit for in this market and are offered as a starting structure to adapt, not as a standard. This article is general information about hiring and management practice, not legal advice.