How to Get Promoted in Tech (What Actually Counts)

Most people trying to get promoted in tech are running an experiment they have already run several times, which is to work very hard at the job they currently have and wait for someone to notice. It is an entirely reasonable theory of how organisations should work, and it fails often enough that the failure has its own recognisable shape: strong reviews, a well-liked engineer, an obvious contribution to the team, and a promotion cycle that quietly passes without them. When they finally ask why, the answer is some version of a sentence that stings because it sounds like praise: you did everything we asked of you.

That sentence is the whole problem in miniature. In most technology organisations a promotion is not a reward for excellent performance at your current level, it is a decision that you are already operating at the next one, and the case is built from evidence rather than effort.

This brief covers what that actually means in practice: how levelling frameworks generally work, the difference between output and impact, how to keep a written record nobody else is keeping for you, how visibility follows the shape of your work, what to ask your manager, why sponsorship matters more than mentorship at decision time, how cycle timing and calibration settle much of it in advance, and the honest case for leaving instead. It sits alongside our walkthrough on negotiating a tech salary and the brief on the highest paying tech jobs, which cover getting the number and picking the track. Keep the companion open and enter your figures once as you read.

How promotion decisions actually get made

Start with the mechanics, because most disappointment here comes from imagining a process that does not exist. In the imagined version, your manager observes your excellent year, decides you deserve more, and grants it. In the version that runs at most technology companies of any size, your manager writes a case, that case is read by people who have never worked with you, it is compared against cases written for other people at the same level across other teams, and a group decision is made under a budget and a distribution constraint. Your manager is your advocate in that process, not the decision maker.

That single structural fact explains almost everything that feels unfair about promotions. It explains why your manager can be genuinely enthusiastic and the answer can still be no. It explains why the quality of the written case matters as much as the quality of the work. It explains why the people in the room, who only know you through documents and second-hand reputation, need evidence they can repeat rather than a warm impression they cannot defend.

It also tells you where your leverage is. You cannot control the budget or the distribution, but you can control what evidence exists, how clearly it is written, how many senior people have seen it directly, and whether the work you took on was even capable of demonstrating the next level. Those four things are what the rest of this brief is about.

Why doing everything asked of you is not enough

The most common promotion case that fails is not lazy, careless, or unlucky. It is diligent. It reads as a long list of tasks completed on time, tickets closed, a project delivered, a teammate helped, all of it accurate and all of it describing someone performing their current level competently. The reviewer’s honest reaction is that this person is doing their job well, which is a compliment and a rejection at the same time.

The reason is that “what was asked of you” is a description of your current level. Your manager, your sprint board, and your on-call rotation are all instruments for extracting the work your current level is supposed to produce. If you do only that, however well, you generate exactly zero evidence about the level above. The work that demonstrates the next level is almost always work that was not assigned to you, because assigning it would have required someone to already believe you could do it.

This is uncomfortable, and it is worth naming the discomfort honestly rather than dressing it up as motivation. It means the promotion path asks you to do something extra, on top of a job that is already full, and without a guarantee. It is also why the rest of this brief spends so much time on choosing that extra work carefully. The goal is not to work more hours. It is to spend a meaningful share of the hours you already work on things that generate next-level evidence rather than more of the same evidence you already have.

How levelling frameworks generally work

Most technology companies of any size run some form of levelling framework: a written ladder of levels, each with a description of expected scope, autonomy, technical depth, and influence. The details differ, the naming differs, and the number of rungs differs, so treat anything specific you read as a general pattern rather than a description of your employer. What is broadly consistent is the shape. Early levels are defined by task execution with support, middle levels by independent ownership of well-defined problems, and senior levels by ambiguity: taking a poorly defined problem and returning a defined one, solved.

Two features of these ladders matter more than the wording. The first is that the gap between rungs widens as you climb. Moving from the first level to the second is largely about becoming reliable, while later moves ask for changes in kind rather than degree, which is why later promotions take longer and why an internal timeline that felt fast early can feel stalled later without anything having gone wrong.

The second is that most frameworks contain a level that is described as the terminal or career level, the point at which staying indefinitely is expected and normal rather than a sign of failure. Knowing where that sits at your employer is genuinely useful, because a great deal of career anxiety comes from applying early-career promotion speed to a stage of the ladder where it was never the norm.

Scope versus seniority: the distinction that decides cases

If you read a levelling framework closely, the thing being described at each rung is scope, not seniority. Seniority is a fact about time and title. Scope is a fact about the size and ambiguity of the problems you are trusted with and the number of people affected by getting them right. Two engineers with identical tenure can sit two levels apart because one owns a component and the other owns an outcome that several components have to deliver together.

A practical way to locate your own scope is to ask what breaks, and who notices, if you disappear for a month. If the answer is that your tickets go unclaimed, you are being priced on task execution. If the answer is that one system degrades, you own a component. If the answer is that a cross-team initiative loses its direction, several people lose their unblocker, and decisions start getting deferred, you are already operating at a scope well above task execution, whatever your title says.

That question is uncomfortable but useful precisely because it is answerable. It also points directly at the fix. Growing scope is not a personality change, it is a sequence of deliberate decisions to own something slightly larger and more ambiguous than the last thing, repeatedly, until the honest answer to the disappearing question changes. The distinction between titles and the work behind them shows up elsewhere too, which our breakdown on developer versus engineer takes apart in detail.

Output versus impact, and why only one gets you promoted

Output is what you produced. Impact is what changed because you produced it. The gap between those two sentences is where most promotion cases quietly die, because engineers are trained to be proud of output and levelling frameworks are written entirely in the language of impact.

Consider the same year described both ways. Output: shipped fourteen features, closed a large number of tickets, reviewed a great deal of code, migrated a service, wrote documentation. Impact: cut a recurring source of on-call pages that were waking three people a week, unblocked a partner team that had been waiting a quarter, made a fragile deployment process something a new joiner could run on their first week, and reduced the time to diagnose a class of incident from hours to minutes. The second version describes the same twelve months and reads two levels higher, not because it is embellished but because it answers the question the framework actually asks.

Translating output to impact is a skill, and it is mostly the discipline of asking “so what” one more time than feels necessary. You migrated a service, so what: the old one required manual intervention weekly. So what: that was several hours of senior engineer time every week and a recurring source of customer-visible errors. That last sentence is the one that belongs in the case. Where you can attach an honest figure, attach it, and where you cannot, describe the change in kind rather than inventing a precise number you would not be able to defend if someone asked.

Making impact legible to people who did not watch you work

Here is the part that feels unfair and is simply true: impact that nobody outside your immediate team can see is, for promotion purposes, close to invisible. The people deciding are reading a document. They cannot see your persistence, your judgement in a design discussion, the disaster you quietly prevented, or the six weeks you spent making something boring reliable. They can only see what was written down and what someone with standing is willing to say out loud.

This is not a call to perform. It is a call to close a translation gap that exists whether or not you engage with it. The work of making impact legible has three parts: writing it down while you still remember the details, framing it in the terms the framework uses rather than the terms your team uses internally, and ensuring at least a few people outside your reporting line have direct rather than second-hand exposure to it.

The third part is the one people skip. A senior person who has seen your design document, watched your demo, or worked with you on a shared incident can say something specific in a calibration discussion. A senior person who has only heard your manager praise you can, at best, not object. The difference between those two positions has decided more promotion cases than any amount of additional effort would have.

The promotion document, written continuously

The single highest-return habit in this entire brief costs about fifteen minutes a fortnight. Keep a running document of what you did, why it mattered, what changed, and who saw it. Update it while the work is fresh. Do not wait for review season, because by review season you will have forgotten the specifics that make an entry persuasive and will be reconstructing a year from a calendar and a commit log.

The reason this works is not mystical. Nobody else is keeping your record. Your manager is holding a whole team across a long calendar and a great deal of organisational noise, and memory in every direction is heavily weighted toward the last six weeks. If your best work happened in February and your case is written in November, an undocumented February effectively did not happen. The document is the only thing that makes the whole year available.

It compounds beyond promotions too. The same document becomes your performance review self-assessment, the raw material for a resume rewrite, the source of interview stories with real specifics attached, and, if you eventually decide to leave, the evidence that you were operating above your title. Our walkthrough on writing a tech resume turns exactly this kind of record into hiring language, and building a tech portfolio covers making the work itself inspectable.

What belongs in a brag document and what does not

A useful entry has four parts and takes two minutes to write. What the situation was, what you actually did, what changed as a result, and who observed it. That last field is the one most people leave out and the one that turns a record into a case, because it tells you later exactly who could be asked to vouch for a given item.

Include the things that feel too small to mention, because they are usually the influence evidence the framework wants and you will never remember them otherwise: the design review comment that changed a direction, the new joiner you got productive in a week, the runbook that stopped a repeated escalation, the difficult conversation you handled between two teams, the estimate you pushed back on that turned out to be right. Include failures and what you changed afterwards, because a case that contains only successes reads as marketing to an experienced reviewer, and a well-handled failure is genuine seniority evidence.

Leave out pure activity with no consequence attached, leave out claims you cannot support if questioned, and leave out numbers you have invented to sound impressive. An inflated figure that collapses under one follow-up question damages the credibility of everything else in the document. Where you have a real measurement, use it. Where you have an estimate, say it is an estimate. Where you have neither, describe the change qualitatively and let it stand on its own.

What a promotion case is actually built from

People assume a promotion case is mostly a list of accomplishments. In practice a case that survives review is a mix, and the accomplishments are only the largest single part of it. The illustrative split below shows roughly how the weight tends to distribute, so you can see where your own preparation is thin rather than pouring more effort into the part you have already done well.

Read the chart as a diagnostic rather than a formula. If you have the first segment and none of the others, you are the person who did excellent invisible work and is confused about the outcome. If you have the last three and not the first, you are visible, well-liked, and being priced at your current level, which is worse because it is harder to notice. The honest exercise is to score yourself out of four and put your next quarter into whichever part scores lowest.

Visibility without self-promotion theatre

Most people who dislike the visibility conversation are reacting to a caricature: the colleague who narrates routine work as heroics, appears in every channel, and somehow gets credit for things other people built. That behaviour is real, it is corrosive, and it is not what is being recommended here. It is also, over a long enough period, less effective than people fear, because reviewers who have been doing this for a while learn to discount narration that never resolves into consequence.

The version that works is duller and more durable. Write a short summary when something lands, in a place people outside your team can read. Demo the thing rather than describing it. Answer questions publicly rather than in direct messages, so the answer accumulates as a visible record. Write the design document even when nobody insisted on one. Credit the people who helped, specifically and by name, which costs you nothing and makes people considerably more willing to talk about your work when you are not there.

The distinguishing test is simple. Self-promotion theatre claims credit disproportionate to the work. Legibility makes real work findable. If your summary would still be accurate and useful to a stranger six months from now, it is the second thing, and you should feel no discomfort about writing it. Enter your own figures in the companion as you go, and it will read your promotion case back in numbers.

Choosing work that is inherently cross-team

The most efficient visibility strategy is not a communication habit at all, it is a selection habit. Some work introduces you to the organisation as a side effect of doing it, and some work, however valuable, keeps you entirely inside one team’s boundary. Choosing more of the first kind changes your reach without requiring you to talk about yourself at all.

Work that is inherently cross-team tends to share a few features. It touches a shared interface, a shared platform, or a shared process. It requires agreement from people who do not report to the same person you do. It produces an artefact other teams consume, such as a library, a runbook, a migration path, or a document that becomes the reference. It shows up in an incident that crossed team boundaries. It is often the work nobody has claimed precisely because it sits between owners, which is exactly why claiming it is a scope argument you get to make with actions rather than words.

There is a real cost to be honest about. This work is usually slower, more political, and less satisfying than building something clean inside your own area, and it can look less productive on a sprint board. That is the trade. You are exchanging short-term measured output for the exact evidence the next level requires, and the exchange only pays if you also make the result legible when it lands.

The manager relationship and what to ask directly

Your manager is the person who writes your case, defends it in a room, and knows the constraints you cannot see. That makes the relationship worth investing in deliberately rather than treating one to ones as status updates. A status update is information your manager could get from the board. The valuable use of the time is calibration: are we agreed on what level my current work demonstrates, and what would change that.

Bring the promotion document to the conversation, not as a demand but as raw material. Say plainly, once and without drama, that promotion is something you are working toward, and ask for help identifying the gap. Managers are generally far more willing to help with a specific, well-framed question than with a vague ambition, and stating the goal explicitly moves it from something they might infer to something they can plan around.

Also accept what your manager cannot do. They usually cannot promise an outcome, cannot control the budget or the distribution, and cannot fabricate scope that the team does not have. If your team genuinely has no next-level work available, that is real information about whether the promotion is reachable where you currently sit, and it is better to learn it early than to spend two more cycles waiting for an opening that structurally does not exist.

Ask what is missing, not whether you are on track

The single most valuable change you can make to these conversations is swapping one question for another. “Am I on track for promotion?” invites a reassuring answer that costs nothing to give, and you will leave feeling good and knowing nothing. Managers are not being dishonest when they say yes to it. They are answering a question about trajectory in a context where trajectory genuinely does look fine.

Replace it with questions that have no comfortable non-answer. If my promotion case were written this cycle, what would the strongest objection to it be. What is the largest piece of scope I have not yet demonstrated. Which specific piece of work in the next six months would most change that. Who else needs first-hand exposure to my work for the case to survive calibration. Each of these forces a specific gap into the open, which is the only thing you can act on.

Then close the loop. Write the answers down verbatim, restate them in your own words at the next one to one to confirm you heard correctly, and reference them when you report progress. This turns a vague ambition into a short list of named gaps with owners and dates, and it also creates a shared record, which quietly protects you if your manager changes partway through, an event common enough to plan for.

Sponsorship is not mentorship

A mentor talks to you. A sponsor talks about you. It is worth holding those two sentences in mind because the industry uses the words almost interchangeably and they do entirely different jobs at promotion time.

Mentorship is advice, feedback, and perspective delivered in conversations you are part of. It is genuinely valuable, it accelerates learning, and it is comparatively easy to obtain because giving it costs the mentor an hour and a little goodwill. Sponsorship is someone with organisational standing arguing for you in a room you are not in, spending their own credibility on the claim that you are ready. That is where promotion decisions are usually settled, and it is a fundamentally different transaction.

The practical consequence is that you generally cannot ask for sponsorship the way you can ask for mentorship. Nobody spends credibility on a request. They spend it on evidence. That means the route to sponsorship runs entirely through senior people having direct exposure to your work: reviewing your design, watching you handle a hard incident, receiving something you built that made their life easier, seeing you handle disagreement well in a room. Every one of those is a normal work interaction, which is the good news. The bad news is that they only happen if your work reaches beyond your own team, which brings the argument back to the selection habit.

How to earn a sponsor without asking for one

Since asking rarely works, the question becomes what produces sponsors reliably. The answer is unglamorous: repeatedly make a senior person’s problem smaller in a way they personally observed. That is the whole mechanism, and everything else is a variation on it.

In practice that looks like volunteering for the cross-cutting problem a senior engineer or a director has flagged and nobody has picked up. It looks like writing the document that resolves an argument they were tired of having. It looks like taking a genuinely thankless piece of shared infrastructure and making it stop generating pages. It looks like being the person who follows up after a meeting with a clear written summary of what was decided, which is a small habit with a disproportionate reputational return.

Two cautions. First, this only works if the work is real. Manufactured helpfulness is transparent and expensive to your credibility. Second, a sponsor is not a patron, and the relationship is not owed maintenance. You do not need coffee chats or a formal arrangement. You need a track record they have personally seen, so that when your name comes up they can say something specific rather than something polite. Networking of this kind is also what makes internal moves and, later, external ones easier, a pattern our walkthrough on switching careers into tech treats as central rather than optional.

Cycle timing: why the decision starts before the conversation

Promotions in most organisations run on a cycle, commonly once or twice a year, and the cycle has a shape most people only learn after missing it once. Well before the decision meeting, managers are asked to nominate candidates. Before that, they are informally sounding out peers about who is ready. Before that, they are forming their own view from what they have seen over the preceding months. By the time you have the formal conversation, a great deal of the decision has already been shaped.

This has a direct planning consequence. If you start building your case in the month before the cycle, you are not building a case, you are hoping the evidence you happen to have is sufficient. The work that gets you promoted in the current cycle was mostly done in the previous two, which is why the continuous document matters and why “I will focus on this after the current project” is such an expensive sentence.

Learn your employer’s actual calendar: when nominations happen, when the written case is due, when calibration meets, and when decisions are communicated. Then work backwards. If nominations close in September, your evidence has to be visible by August, which means the scope-expanding work needs to start by roughly the spring. The companion will estimate how many months sit between you and the next decision point on your cycle length.

Calibration, and why your manager is not the only voice

Calibration is the meeting where cases from different teams are compared and levels are made consistent across an organisation. It exists for a defensible reason: without it, a generous manager’s strong performer and a demanding manager’s strong performer end up at different levels for the same work. With it, your case gets read by people who have no context on you at all.

The implications are worth internalising. Your case competes against cases written for people you have never met, which means the absolute quality of your year is only half the picture. A specific, evidence-dense case beats a warm, general one even when the underlying work is comparable, because the room can only assess what is written. And a single credible voice in the room saying “I worked with them on that migration, they were operating above their level” outweighs several paragraphs of manager praise, which is precisely why cross-team exposure matters more than it should.

This also reframes rejection usefully. A case that fails calibration often fails for a reason that is specific and fixable: not enough scope, not enough evidence, not enough external corroboration, or a comparison against a stronger case in the same cycle. Ask for the actual reason, in writing if you can, and treat it as the gap list for the next cycle rather than as a verdict on your ability.

What a promotion is worth against the alternatives

The reason to be clear-eyed about all of this is that the outcomes differ substantially in money, and the differences compound. The illustrative chart below takes a single current salary of an illustrative $95,000 a year and shows what four different outcomes are worth in the first year, so the comparison is concrete rather than abstract.

Two honest readings sit in that chart. The first is that a promotion is worth roughly four times a merit raise on these illustrative figures, which is a large enough gap to justify a deliberate two-year effort. The second is that the external move is larger still, which is the uncomfortable part most career advice skips. Both readings are true at once, and the rest of this brief takes the second one seriously rather than pretending loyalty is always rewarded.

The honest exit case: when leaving is the faster raise

It would be dishonest to write a promotion brief without saying plainly that changing companies is often the faster raise. The mechanism is structural rather than cynical. An internal promotion is priced against your existing salary and a constrained raise budget, and the organisation already has you. An external offer is priced against the current market for the level you are being hired into, and the organisation does not have you yet. Those two pricing processes routinely produce different numbers, and the gap tends to widen the longer you stay in a role whose market rate has moved.

There is also a title mechanism. If your current employer’s ladder has no open scope at the next level, or the team’s charter simply does not contain next-level problems, the promotion may be genuinely unreachable where you sit, however good you are. Another employer hiring at that level has, by definition, next-level work available. That is not a reflection on your performance, it is a reflection on the shape of the two organisations.

None of which makes leaving automatically correct. A move resets accumulated trust, context, and relationships, carries real probation risk, and puts you in a room where nobody has seen you handle anything yet. The title you were given still has to be earned. Our brief on remote tech jobs covers how location and remote bands change the arithmetic further, sometimes more than a level change does.

Internal promotion versus external move, and the real trade

Put the two options side by side and the choice becomes less emotional. The internal promotion is lower risk, keeps the context and relationships you have built, is usually a smaller percentage raise, and depends on a process you only partly control. The external move is higher variance, usually a larger raise, resets your accumulated trust to zero, and depends on an interview process you control more of than you think.

A sensible sequence avoids treating these as opposites. Run the internal case properly, which costs you nothing you were not already doing: build the evidence, keep the document, ask what is specifically missing, and give it a defined number of cycles rather than an open-ended wait. In parallel, keep your market awareness current, because knowing your approximate market value is useful information whether or not you act on it, and it is very hard to acquire quickly when you suddenly need it.

Where people go wrong is using an offer as a threat. A counteroffer accepted after an ultimatum tends to solve a salary problem while creating a trust problem, and the retention it buys is often short. If you genuinely want to stay, make the internal case on its merits and ask directly what would change the answer. If the honest answer is that nothing would within a reasonable horizon, that is your information, and our walkthrough on negotiating a tech salary covers turning a real market position into a number.

Where certifications and portfolios still help after you are inside

CredYard’s usual question is whether a credential pays back, and the honest answer changes once you are already employed. Certifications do most of their work at the hiring gate, where an employer has no evidence about you and needs a trustworthy proxy. Internally, your employer already has far better evidence, namely a year of watching you work, so a badge adds much less to a promotion case than it did to an application.

The exception is specific and worth knowing. A credential is genuinely useful internally when it unlocks work you could not otherwise be assigned: a cloud platform your team is adopting, a compliance or security area with a formal requirement, a specialisation the team needs and nobody currently holds. In those cases the credential is not the promotion argument, it is the key that opens access to the scope that becomes the promotion argument. That is a real return, and it is a different return from the one on the marketing page.

Portfolios follow the same logic with a twist. Internally, your portfolio is the set of artefacts your organisation actually uses: the design documents, the runbooks, the shared library, the migration guide. Those are inspectable evidence in the same way a public project is inspectable to an external hiring manager. Price any credential spend against the scope it opens using our ROI calculator before you commit the money or the evenings.

Promotion on remote and distributed teams

Everything in this brief gets harder over a video link, and it is worth saying why rather than pretending the playing field is level. A great deal of ambient visibility in an office is accidental: the corridor conversation, the whiteboard someone walked past, the overheard debugging session that told a senior engineer something about how you think. Remove those and the only evidence that reaches people outside your immediate team is evidence you deliberately created.

The compensation is that written culture rewards exactly the habits this brief already recommends. In a distributed team, the design document, the written incident review, the recorded demo, and the public channel answer are not extra work on top of the real work, they are how the work is conducted. That makes the legibility problem easier to solve deliberately even as it becomes harder to solve accidentally, provided you accept that the deliberate part is not optional.

Two practical adjustments help. Bias toward asynchronous artefacts that persist, because a document read by twelve people over six months outperforms a brilliant contribution in a call that four people attended and nobody recorded. And be deliberate about first-hand exposure to senior people, since it will not happen by proximity: volunteer for the cross-team review, present at the wider forum, and take the shared incident. Our brief on remote tech jobs covers which roles genuinely support this way of working.

A worked example: two cycles to a senior title

Make it concrete with one illustrative engineer. Priya is a mid-level engineer earning an illustrative $95,000, fourteen months into her level, at a company running two review cycles a year. Her reviews are strong and her last promotion conversation ended with a warm “keep doing what you are doing”, which she correctly reads as a warning rather than a compliment.

She starts with the disappearing test and does not like the answer: if she vanished for a month, her tickets would go unclaimed and nothing else would break. So she changes selection rather than effort. She volunteers for a migration two teams depend on that has been stuck for a quarter because it sits between owners. It is slower and more political than the feature work she prefers, and it puts her in weekly contact with a staff engineer and a second team’s lead, neither of whom had previously seen her work.

She also starts the document, fifteen minutes a fortnight, four fields per entry, including who observed each item. At her next one to one she stops asking whether she is on track and instead asks what the strongest objection to her case would be if it were written today. The answer is specific and useful: she has never owned an outcome that spanned teams, and nobody outside her team could speak to her work. That is now a gap list rather than a feeling.

Ten months and two entries-heavy quarters later, the migration lands, the staff engineer who watched her run it can say something concrete in calibration, and her case is written from a document rather than a memory. On these illustrative figures the promotion is worth about $11,400 a year, roughly four times the merit-only outcome, and she also knows from her own market research that a well-run external move might have paid nearer $17,100. She stays, because the scope she now owns is the kind that compounds. Run your own version of these numbers in the companion.

Common mistakes when going for a promotion in tech

The failure modes repeat often enough to list, and each has a cheap correction:

• Working harder at your current level. More output of the kind you already produce generates more evidence for the level you already hold. Change what the work is, not how much of it there is.
• Assembling the case at review time. A year reconstructed from a commit log in November loses everything persuasive about February. Keep the document continuously, four fields, fifteen minutes a fortnight.
• Asking whether you are on track. It invites a reassuring non-answer. Ask what the strongest objection to your case would be today, and what specific work would remove it.
• Staying entirely inside one team's boundary. Work that never crosses a team line produces no first-hand witnesses for calibration, which is exactly where the case is decided.
• Confusing mentorship with sponsorship. Advice in a room you are in does not move a decision made in a room you are not in. Earn exposure with senior people through real shared work.
• Treating a rejection as a verdict. Most failed cases fail for a specific, fixable reason. Ask for it explicitly, in writing where possible, and convert it into the next cycle's gap list.
• Waiting indefinitely for scope that does not exist. If the team's charter contains no next-level problems, no amount of patience creates them. Give the internal case a defined number of cycles, then reassess honestly.
• Using an offer as a threat. A counteroffer taken after an ultimatum fixes a salary problem and creates a trust problem. Decide what you actually want before you interview elsewhere.

Every one of these is a failure of deliberateness rather than ability, which is genuinely good news, because deliberateness is the one input entirely under your control.

The promotion checklist

Work this list in order for the cycle in front of you:

• Read the ladder. Find your employer's written level definitions and identify, in their words, the specific expectations of the level above yours.
• Run the disappearing test. Write down honestly what would break, and who would notice, if you were gone for a month. That is your current scope, whatever your title says.
• Pick one scope-expanding project. Something larger, more ambiguous, and preferably touching another team. Prefer the unclaimed problem sitting between owners.
• Start the document today. Four fields per entry: situation, what you did, what changed, who saw it. Fifteen minutes a fortnight, not a review-week sprint.
• Translate output into impact. For every entry, ask "so what" until the sentence describes a change rather than an activity, and label estimates as estimates.
• Ask the sharper question. What is the strongest objection to my case today, what scope have I not demonstrated, who needs first-hand exposure to my work.
• Create witnesses. Get at least two senior people outside your reporting line direct exposure to your work through reviews, demos, or shared incidents.
• Learn the calendar. Find out when nominations, cases, and calibration actually happen, then work backwards so your evidence is visible before nominations, not after.
• Price the alternatives. Know roughly what your level pays in your market, so you can compare the internal outcome against a move on numbers rather than feelings.
• Set a horizon. Decide in advance how many cycles you will give the internal case before reassessing, and honour it calmly when the date arrives.

Someone who works all ten is running a process rather than hoping. The parts people skip, the document, the witnesses, and the sharper question, are precisely the parts that separate a case that survives calibration from a year of excellent invisible work. Price the whole picture in our ROI calculator before you spend money on a credential you hope will substitute for any of it.

The bottom line

Promotion in most technology organisations is not a reward for doing your current job well. It is a judgement that you are already operating at the next level, made by people who did not watch you work, from a written case, in a meeting you are not in. Once you accept that description, almost every practical step follows from it: choose work that is larger and crosses team boundaries, translate output into impact, keep the record continuously because nobody else is keeping it, get senior people direct exposure to your work so someone can vouch first-hand, ask what is specifically missing instead of whether you are on track, and understand your employer’s cycle so your evidence exists before nominations rather than after.

Hold the honest caveat alongside it. A well-run external move commonly pays more than an internal promotion, and if your team’s charter simply does not contain next-level problems, the promotion may be unreachable where you sit no matter how well you execute. Run the internal case properly, give it a defined horizon, and keep your market awareness current so the comparison is made on numbers rather than nerves. Pressure-test any credential spend along the way with our ROI calculator, read the walkthrough on negotiating a tech salary for the conversation that turns a level into a number, and remember that the engineer who gets promoted is rarely the one who worked hardest. It is the one whose next-level work was already visible when the room sat down.

CredYard publishes this brief to describe how promotion processes commonly work in technology organisations, and nothing in it evaluates your employer, your manager, or your individual career situation. Levelling frameworks, review calendars, calibration practices, and raise budgets are set by each company and differ widely, so confirm how yours actually operates with your own manager and internal documentation rather than relying on the general patterns described here. Every salary, percentage, timeline, split, and worked example above is an illustrative construction chosen to show relative weight and reasoning, not a measured statistic, a quote, or a forecast, and real outcomes vary by employer, level, market, and negotiation. Where a decision involves resigning, relocating, or committing money to a credential, weigh it with people who know your specific circumstances, including a qualified financial or career professional where the stakes warrant it.