The Promotion Principle
The single most important principle in any promotion process is this: promotion should confirm what is already true.
When someone is promoted to SSE, they should already be operating at the SSE level. The promotion is a formal recognition of a reality, not the beginning of an experiment. The new title and the new compensation reflect work that is already happening, impact that is already being created, patterns of behaviour that are already consistent.
The alternative - promoting someone because they have potential, because they deserve a reward for loyal service, because they have been at the current level for long enough, because it will make them feel valued - is a setup for failure. The promoted person now has a title that implies a level of capability and responsibility they may not yet have. The gap between title and performance is visible to their peers. The pressure of the new expectation creates anxiety rather than confidence. The manager who made the promotion now has a performance concern where previously they had a development conversation.
This principle has corollaries that are worth stating explicitly.
Tenure is not a criterion. Three years at ISE does not make someone an SSE. It makes them an experienced ISE. The question is whether they are doing SSE-level work, not how long they have been doing ISE-level work.
Potential is not evidence. "I think she has what it takes" is a prediction, not an assessment. Predictions about potential are unreliable and carry the full weight of manager bias. Assessments of demonstrated behaviour are verifiable. The promotion case should be built on the latter, not the former.
Loyalty is not a criterion. Engineers who are reliably present, who are good colleagues, who have contributed consistently - these things matter for performance assessment. They do not constitute evidence of operating at the next level.
A difficult year is not disqualifying in itself. Someone who was clearly operating at the next level for the six months before a restructure that disrupted everything should not be denied promotion because the last quarter was chaotic. Context matters. The question is whether the sustained pattern of behaviour is at the target level, not whether every month has been perfect.
What Evidence Looks Like
The promotion case is built on evidence. Not manager advocacy. Not a sense that someone is ready. Evidence.
Evidence in the context of promotion is concrete, specific, verifiable demonstration of behaviour at the target level. The building blocks:
Artefacts
Artefacts are things the engineer has produced that can be inspected. Technical design documents, architecture decision records, proposals for significant technical changes, postmortem analyses, documentation of engineering practice, technical roadmaps, written communication on complex cross-team problems.
Artefacts are valuable because they are externally assessable. A calibration panel can read a design document and form a view on whether it demonstrates SSE-level systems thinking. They cannot assess a manager's claim that "she's been doing great work" without something to point to.
For the promotion case, identify the three or four most significant artefacts produced over the assessment period. Each artefact should demonstrate a specific capability at the target level. The artefact plus a brief description of the context and the impact is the core of the promotion case.
Outcomes
Outcomes are the impact of work, not just the work itself. Not "led the migration of the authentication service" but "led the migration of the authentication service, reducing authentication latency by 40%, eliminating two categories of production incidents, and completing six weeks ahead of the planned timeline while coordinating delivery across three engineering teams."
Outcomes matter because they demonstrate that the engineer is not just doing the work but doing it to a standard that creates value. The question "so what?" should be answerable for every piece of evidence in the promotion case.
Peer and Stakeholder Observations
Manager assessment alone is insufficient. A promotion case that rests entirely on the manager's testimony about the engineer's capability is weaker than one that includes consistent observations from peers, senior engineers, or stakeholders who have worked with the engineer.
These observations should be specific, not generic. "She's great to work with" is not a useful observation. "In the cross-team authentication initiative, she navigated the relationship with the platform team effectively, brokered a technical compromise that both teams could support, and delivered the outcome without the escalation that had characterised previous cross-team work" is a useful observation.
Consistency
Perhaps the most important element of evidence is consistency. A single exceptional piece of work demonstrates that someone can perform at a high level under the right conditions. Consistent performance across a range of work - different types of problems, different team dynamics, different levels of ambiguity - demonstrates that the capability is robust and reliable.
The promotion case should show a pattern, not a peak. Two to four pieces of evidence distributed across time and across different work types is more compelling than one showstopping piece of work.
The Calibration Process
Calibration is the process by which managers assess engineers using a shared framework and compare their assessments to ensure consistency. Without calibration, promotion decisions are made independently by individual managers, with the result that standards drift - one manager's ISE is another's SSE.
Why Cross-Manager Calibration Matters
The inevitable consequence of uncalibrated promotion processes is inequity. Different managers apply different standards, have different working relationships with their engineers, and bring different biases to their assessments. Without a mechanism for comparing and aligning those assessments, the variation in promotion outcomes reflects manager variation rather than engineer capability variation.
Calibration does not eliminate bias, but it reduces the impact of individual manager bias by introducing external perspective. A manager who consistently rates their engineers highly relative to the rest of the organisation must explain why. A manager whose engineers are consistently rated lower than comparable engineers at other organisations must examine whether the bar they are applying is right.
How to Run a Calibration Session
A calibration session brings together three to eight managers to assess a cohort of engineers against a shared capability framework. The session should be structured, not free-form.
Before the session: each manager prepares a one-paragraph assessment of each engineer in scope, referencing the capability framework and including specific evidence. The assessment is not a recommendation (promote/don't promote) - it is a description of where the engineer is operating.
During the session: managers present their assessments. The group interrogates the evidence: Is this evidence of ISE-level capability or SSE-level capability? Does the delivery capability evidence support the technical capability evidence? Is this a consistent pattern or a single impressive piece of work?
Disagreement is productive: when managers disagree, the conversation about why they disagree surfaces implicit assumptions and standards that can then be made explicit. "I wouldn't rate that as SSE-level systems design" followed by "why not?" is a valuable calibration exchange. The goal is not consensus for its own sake - it is calibration of the standard.
After the session: the outcomes of the calibration (engineer X is operating at level Y; engineer Z is not yet demonstrating level Y consistently in dimension W) inform promotion decisions and development plans. The calibration output should be shared with the engineers to the extent that it informs their development.
What to Do When Managers Disagree
Disagreement in calibration should be expected and is productive. The failure mode is false consensus - everyone agreeing to avoid the discomfort of conflict, with the result that nothing is calibrated.
When managers disagree, the structured approach is:
Name the disagreement specifically. Not "I see her differently than you do" but "I think the authentication service design demonstrates SSE-level systems thinking; you're rating it as strong ISE. What's the difference in how we're interpreting it?"
Go back to the framework. What does SSE-level systems thinking actually require? What evidence would constitute clear demonstration of it? Does the design document demonstrate that?
Consider the observer effect. A manager who has worked closely with an engineer may see things that external observers cannot. A manager who has worked at a distance may have a more objective view but less context. Both perspectives are useful; neither is definitive.
Make a decision and document the reasoning. Calibration should produce a decision, not perpetual discussion. The reasoning for the decision should be documented so that it can inform future calibration.
Promotion Conversations
The most important promotion-related conversation is not the one where a promotion is announced. It is the ongoing conversation about where the engineer is relative to the next level, and specifically the conversation where an honest assessment must be delivered that someone is not yet ready.
How to Have an Honest Conversation When Someone Isn't Ready
This conversation is uncomfortable. Most managers avoid having it until the engineer formally applies for promotion or raises the topic themselves - by which point the engineer may have been operating under false assumptions for months.
The conversation should happen before the engineer has formed a strong expectation of imminent promotion. If an engineer is actively expecting to be promoted in the next cycle and that expectation is not founded in evidence, the manager has waited too long.
Structure for the conversation:
State the assessment clearly. Not "I think you still have some development to do" but "Based on where you're operating right now, you're not yet at the SSE level consistently. Let me be specific about where I see the gap."
Be specific about what SSE looks like. Reference the capability framework. Describe what SSE-level delivery capability looks like in practice, and then describe what you are currently observing.
Identify the gap precisely. "Your technical capability is clearly at the SSE level - the authentication service design was excellent work. Where I don't yet see SSE-level capability is in how you drive cross-team work. At SSE, I expect to see someone identifying and navigating the dependencies and stakeholder dynamics without needing direction from me. In the past quarter, I've stepped in three times to unblock cross-team issues that I would expect an SSE to have managed independently."
Offer a development contract. The honest conversation about not being ready must come with a clear description of what "ready" would look like and a genuine development plan for getting there. Not "keep working on it" but "here's what I need to see, here's what we can do together to create the opportunity for you to demonstrate it, and here's when we will check in."
Do not soften it into meaninglessness. "You're making great progress and getting really close" is not an honest assessment if the person is significantly below the next level. Softening is a kindness that costs the engineer months of operating under a false assumption. Direct honesty is kinder.
How to Avoid False Hope
False hope is worse than disappointment. A manager who says "I think you'll probably be ready for promotion in the next cycle" when they are not confident in that assessment is creating an expectation they may not be able to meet.
The rule: do not predict timelines unless you genuinely believe them. "I think if you demonstrate the cross-team delivery capability we talked about over the next two quarters, you'll have a strong case for promotion" is an honest statement with a conditional. "You'll definitely be promoted next year" is a prediction that removes the conditionality.
When the evidence is genuinely ambiguous, say so. "I think you're getting close, but I'm not yet seeing the consistency I need to make a strong case. Let's focus on the next three months and see where you are."
Levelling Consistency
Levelling consistency is the problem of ensuring that the title "Senior Software Engineer" means the same thing across all teams in an engineering organisation. Without explicit calibration, the same title attached to different expectations creates a dysfunctional internal market.
The "Same Title, Wildly Different Expectations" Problem
In organisations that have grown through acquisition, merger, or rapid organic growth, levelling inconsistency is common. Team A's SSE is doing work that would be rated as ISE in Team B. The engineers in Team A are not aware of this - they believe they are SSEs because they have SSE titles. The problem surfaces when engineers move between teams, when they interview externally and find their level does not match market expectations, or when calibration sessions reveal the inconsistency.
The causes:
Local norm drift. Each team develops its own implicit standard for what "senior" means, calibrated against the population of engineers in that team. A strong ISE in a team of graduate engineers can end up with a senior title because they are the most capable person in the local context.
Promotional generosity in hiring. Hiring managers frequently offer the next level above what a candidate is demonstinely at in order to close the offer. This creates immediate levelling inconsistency and sets incorrect expectations.
Absence of regular cross-team calibration. Without a mechanism for comparing standards across teams, drift is inevitable.
How to Address Levelling Inconsistency
Addressing levelling inconsistency requires honesty about the current state, a plan for correction, and a commitment to not repeating the error.
Audit the current state. Map each engineer in the organisation to the capability framework level they are actually operating at, independent of their current title. This will surface the inconsistencies.
Do not demote - but do not promote further without evidence. Removing a title is rare, disruptive, and demotivating. The practical approach is to acknowledge that levelling has been inconsistent, freeze further progression for engineers who are significantly below their current title's expected level, and create genuine development plans to close the gap.
Communicate clearly. Engineers who discover that their title does not reflect genuine capability in the market will leave. Honest communication about what is happening - why the audit was done, what it found, what the plan is - is better than allowing the discovery to happen through external interviews.
Fix the hiring process. Levelling consistency starts at the point of hire. Job offers should be made at the level the candidate is genuinely demonstrating, not at the level that closes the deal. A candidate hired at a level they are not yet operating at will be visibly mislevelled within six months.
Common Biases
Biases in promotion decisions are not primarily individual character flaws. They are predictable consequences of poorly designed processes. Naming them makes them visible and easier to mitigate.
Recency Bias
The promotion assessment is disproportionately influenced by the most recent work, regardless of whether that work is representative of the engineer's sustained capability. An engineer who had an excellent quarter in the assessment window looks stronger than an engineer with a consistently excellent two-year track record but a difficult final quarter.
Mitigation: ensure the evidence gathering covers the full assessment period, not just the last few months. Ask explicitly: is this a pattern, or is this a peak?
Likability Bias
Engineers who are easy to work with, socially comfortable in the team, and well-liked by their manager receive more positive assessments than their performance evidence strictly justifies. Engineers who are technically excellent but interpersonally difficult receive more negative assessments than their impact warrants.
Mitigation: separate "is this person a good colleague?" (a legitimate but limited factor) from "is this person operating at the target level?" Likability is not a promotion criterion. Patterns of behaviour that damage team effectiveness are a separate conversation.
Output vs Impact Confusion
Measuring output (how much code was written, how many tickets were completed, how many PRs were merged) rather than impact (what difference did this work make to the product, the team, the organisation) systematically undervalues engineers whose contribution is primarily through technical leadership, architecture, or developing others.
An SSE who spends significant time mentoring junior engineers, reviewing architectural proposals, and raising technical concerns before they become problems has a lower direct output than an ISE who ships features quickly. The SSE's impact is much higher. A process that measures output will promote the wrong person.
Mitigation: require evidence of impact, not activity. "What changed because of this work?" is the right question.
The Loud in Meetings Heuristic
Promotion decisions are frequently influenced by visibility - who speaks up in meetings, who presents to senior leaders, who advocates loudly for their own work. This systematically advantages extroverted engineers, native English speakers, and engineers with higher social confidence, independent of their actual capability.
Mitigation: actively seek evidence from contexts other than meetings. Code review quality, written communication, peer feedback from people who work closely with the engineer. Do not use "I haven't heard much from them" as evidence of low capability.
Gender and Demographic Patterns
The research on performance assessment bias is extensive and consistent. Women's performance is more often attributed to luck or team effort; men's performance is more often attributed to individual capability. Technical competence is more readily recognised in men. Interpersonal skills are held to a higher standard in women. Engineers from underrepresented ethnic backgrounds are more frequently assessed as "not quite ready" despite equivalent evidence.
These patterns are not primarily about individual managers being biased. They are about how bias operates through normal assessment processes in the absence of deliberate countermeasures.
Mitigation: review promotion outcomes for demographic patterns. If a particular demographic group is consistently underrepresented in promotions relative to their proportion in the talent pool, that is a process problem, not a talent problem. Investigate the process.
The Promotion Document
A promotion document is the written case made for an engineer's promotion. It is not a performance review, not a job description, and not a character reference. It is a structured argument that the engineer is already operating at the target level, supported by specific evidence.
What a Good Promotion Case Looks Like
Opening statement: a one or two sentence summary of the case. "This is a case for promoting [Engineer] from ISE to SSE. Over the past 12 months, she has consistently demonstrated SSE-level technical capability, delivery capability, and people/org capability through the following evidence."
Technical capability evidence: two or three specific examples. Each example should include: what the work was, what the engineer did specifically, what the outcome was, and why this demonstrates capability at the target level. Reference the capability framework.
Delivery capability evidence: two or three specific examples using the same structure.
People/org capability evidence: two or three specific examples using the same structure.
Consistency statement: a brief note on whether the examples represent consistent patterns or exceptional moments. "These three examples represent the consistent pattern I have observed over 12 months, supported by peer feedback from [names]."
Gaps and mitigations: if there are areas where the evidence is less strong, name them and explain why you are still making the case. "Her organisational capability evidence is thinner than ideal - the team has not provided many cross-team opportunities in the past year - but the examples she has generated in the limited opportunities available are clearly at the SSE level."
Peer and stakeholder corroboration: one or two brief supporting observations from people who are not the manager.
What a Worked Promotion Case Does Not Include
- Claims about potential ("I believe she will grow into...")
- Statements about loyalty or tenure ("She has been with us for three years...")
- Generic positive statements without evidence ("He is a strong engineer with great technical skills")
- Statements that describe personality rather than behaviour ("She has great executive presence")
- Evidence that demonstrates ISE-level capability being described as SSE-level ("She consistently delivers features well" - that is ISE)
Connection to Your Operating Model
Promotion and levelling is where the rest of the career and capability system becomes real or becomes fiction.
Career pathways set the expectations. The promotion process is how those expectations are assessed and acted on. A pathway that describes what SSE looks like but is never used as the standard for promotion decisions is decoration.
Capability frameworks provide the assessment structure. Without a capability framework, promotion conversations have no shared vocabulary. The calibration panel cannot have a productive conversation if "SSE-level systems thinking" is not defined.
Learning and development is what makes promotion readiness achievable. Engineers should be developing toward the next level through deliberate development plans, not discovering the bar only when they apply for promotion.
Career conversations are the ongoing mechanism through which engineers understand where they stand. Promotion decisions should never be surprises. The conversation about promotion readiness should have been happening regularly in 1:1s and career conversations throughout the assessment period.
Levelling consistency is only achievable when all of these elements are working together - when the pathway is shared, the framework is applied consistently, the calibration is structured, and the conversations happen regularly. Absent this system, levelling is at best an annual estimate and at worst a political outcome.