Most engineers who stall at a level have the skill. What they don't have is anyone willing to explain the machine they're inside. The explanation you get from your manager is partial by design. They know their part of the process and not the committee's, so what comes back is "keep doing what you're doing, you're close." Which is true, and useless, and then you're close again next cycle. So here is the machine, reconstructed from what the four big companies publish, what their engineers write up afterward, and what levelling aggregators have pieced together. None of it is your company's internal doc. Check the specifics with your own manager. The ladders don't line up Stage Google Meta Amazon Microsoft Apple Typical YOE Entry L3 E3 L4 (SDE I) 59–60 ICT2 0–2 Mid L4 E4 L5 (SDE II) 61–62 ICT3 2–5 Senior L5 E5 L6 (SDE III) 63–64 ICT4 5–8+ Staff L6 E6 L7 (Principal) 65–66 ICT5 8–12+ Senior staff L7 E7 L8 67 ICT6 12+ Principal / Distinguished L8–L9 E8–E9 L10 68–69 Distinguished rare Google's L5 is a senior engineer. Amazon's L5 is a mid-level SDE II. Recruiters map between them and the map is approximate, so the year ranges are typical rather than required. Two things here matter more than the numbers. The gap between adjacent levels is not constant. Entry to mid is mostly about becoming reliable. Mid to senior is about becoming independent. Then senior to staff, which is where the ladder stops behaving like a ladder: it's a change of job, and the things that earned you the last promotion only partly transfer. And every company has a level it considers a perfectly good place to spend a career. Google's L5, Meta's E5, Amazon's SDE II or III depending on who you ask, Microsoft's 63 or 64. Below that level there is an expectation you keep climbing, and at some companies a clock. Above it, promotion is optional and much harder, and nobody will chase you about it. What actually happens in the room The four processes differ enough that optimizing for the wrong one wastes a year. Google runs the most formal version. Your case is a packet: a self-assessment written against the level you're targeting, evidence (design docs, launches, metrics), and peer reviews from engineers you've worked with. A committee of senior engineers who have never worked with you reads packets in a batch and decides. Your manager nominates and advocates but doesn't sit on the committee for their own reports. Two consequences: peer feedback outweighs self-review, because committee members treat self-evaluations as unreliable; and the committee needs artefacts it can read, so a launch nobody wrote a design doc for is a weak exhibit. Meta decides inside the Performance Summary Cycle, twice a year. Self-review, peer reviews, a manager assessment calibrated against other managers. There's no separate application; promotion is one of the outcomes that cycle can produce. The practical consequence is that your evidence has to be legible every six months. A brilliant two-year project with nothing to show at the twelve-month mark is a liability in this system. Break work into visible halves. Amazon promotes on a written narrative, the promo doc, structured around the Leadership Principles and reviewed by bar raisers: senior engineers from outside your team, explicitly there to stop promotions that would lower the bar. Two things people learn the hard way: recency counts against you, because rejected cases routinely cite "the project is too new, we haven't seen the results yet"; and visibility is treated as part of the work rather than a bonus on top of it. Microsoft uses Connect, a periodic written record of priorities and impact, with promotions decided by managers in calibration. Its impact model scores three things separately: your own accomplishments, how you built on others' work, and how you contributed to others' success. That model exists specifically to break a culture of competing fiefdoms, and it means an engineer who ships a great feature alone can score below one who ships a slightly smaller feature and unblocks two other teams. All four are measuring the same thing Strip the vocabulary away and every ladder is asking how much of the world gets better because you're in it, and how reliably. Tasks, then problems and a team, then sustained impact on an organization. The word "sustained" is doing real work in that sentence. Once you have that, a lot of confusing feedback becomes readable: "You need more scope" means the problems you solve are chosen for you and bounded by your team. "We need to see it sustained" means you did one next-level thing and the committee wants to know it wasn't a fluke or a favour from your manager. "You're doing great work, but…" almost always means the work is invisible outside your team, or it's the same size of work you were doing last year, done better. That last one is the trap. The most common way strong engineers stall is by doing more of whatever got them to their current level. If you were promoted to mid-level for shipping features quickly and cleanly, shipping features even more quickly and cleanly does not get you to senior. Senior is a different shape of contribution: choosing which features, owning the outcome when they meet reality, making the people around you faster. What has to change is the shape of the work. More of it just earns you the same review again. The other half of it is that promotion is a lagging indicator. Google's "two quarters at the next level," Amazon's "consistently exceeded," Meta's "sustained" are the same requirement in different words. The committee is not betting on your potential. It is confirming a fact. Which inverts how most people plan. The question is not "what do I need to do to get promoted." It's "what does a person at the next level do all day, and how soon can I start doing it." Once you can answer that, the promotion is paperwork. Six ways good engineers stall Almost every stalled promotion is one or two of these. Be honest about which one is yours before you do anything else. Same-shape work. You're doing more of what got you here. Invisible impact. The work is real, but there's no design doc, no metrics, and nobody outside the team can describe it. No sponsor. Your manager likes you, but nobody with power is spending their credibility on you. Glue without credit. You hold the team together and get thanked, not promoted. Not enough time on the evidence. The next-level work started three months ago and the results haven't landed. Wrong team or wrong manager. There is no next-level work available where you sit, or your manager can't or won't make the case. Number four deserves its own note, because it's the one nobody warns you about. Tanya Reilly's talk "Being Glue" describes the work that keeps a team functioning and that no ladder is written in terms of: onboarding people, updating the roadmap, coordinating across teams, noticing the dropped task and picking it up. Reilly cites research finding that women volunteer for this non-promotable work substantially more often than men and are asked to do it more often, but the trap catches anyone conscientious. Her line is the one to memorize: if you only do glue, you will only get better at glue. So: name it to your manager, with hours attached, because most managers genuinely don't know. Get it written into the case under some legible label, "technical program leadership" or "team enablement" or whatever your ladder will accept. And if promotion stays blocked anyway, shift deliberately to quantifiable technical work for a while. That feels unfair. It's also the move that works. Two habits that fix most of it Most of the invisibility failure mode is solved by one ten-minute habit: a written update to your manager every Friday. Shipped / decided: One to three things that are done. With a number where possible. In progress: What's moving, and whether it's on track. Yes/no. If no, why and what you're doing. Blocked / need: What you need, as a request with a deadline. "Need a decision on X by Thursday or we slip a week." Helped: Who you unblocked, reviewed for, or taught. This is the line most people skip and the one that builds a senior case. Next week: The one outcome. Keep every one of them. They are the raw material for your promotion packet, and they mean the person who has to advocate for you already has the information before they need to ask for it. The second habit is how you write anything up. Committees believe numbers and distrust adjectives, so every project entry goes in a fixed shape: scope, then what you specifically did, then what changed and what happened afterward. Weak: "Led the migration of the billing service to the new platform." Strong: "Owned the migration of the billing service (12M requests/day, 4 dependent teams) to the shared platform: wrote the design doc, negotiated the API contract with Payments, ran the dual-write cutover with zero customer-visible errors. Result: p99 latency down 61%, two on-call pages per week eliminated, and the pattern was adopted by two other teams the following quarter." The "what happened afterward" clause is the one people leave out, and it's exactly what Amazon means by "too recent." If you can't fill it in yet, the project isn't ready to be an exhibit. Plan so that it will be. Where to find numbers when you think you don't have any: dashboards (latency, error rates, throughput, cost), ticket systems (pages, incidents, time to resolve), adoption (teams using the thing, engineers unblocked), time saved with the arithmetic shown, and failing all that, before-and-after descriptions from the people affected, quoted. The conversation, and when to have it Most engineers have the promotion conversation too late, too vaguely, or not at all. The right time is nine to twelve months before you expect the promotion, and the right shape is a request for a plan rather than a request for a title. Open it something like: "My goal is to be operating at [level] and to be put up for it in roughly [timeframe]. Here's a self-assessment against the ladder and where I think the gaps are. I'd like your honest read, and then I'd like us to agree on what 'ready' looks like — which projects, what evidence, what you'd need to see." Then ask three questions and write down the answers. "What would you need to see to put me up for this?" Push for specifics. "More scope" is not an answer. "Own the X project end to end and get it adopted by Y team" is. "What is the biggest gap you see?" Listen. Don't argue in the moment. This is the most valuable sentence you'll hear all year. "Is there next-level work available on this team in the next year?" If the honest answer is no, that is a different problem and no amount of effort fixes it. Follow up in writing the same day: "thanks for the conversation, here's what I heard we agreed." A manager who has agreed in writing to a plan finds it awkward not to follow through. Then put it on the agenda monthly. When the answer is no Most engineers get told "not yet" at least once, and what you do in the following month matters more than the no itself. Get the feedback in writing and specific. "Needs more scope" has to be translated into "needs to own a project like X." If your manager can't do that translation, ask them to get it from the calibration. Then sort the reason, because there are only three. The work wasn't there, which a better project fixes. The evidence wasn't there, which documentation and better-chosen reviewers fix. Or the sponsor wasn't there, which is fixable slowly, and sometimes only by changing teams. Set a date: "if I do X and Y, will you put me up next cycle?" In writing. And whatever you decide, don't go quiet. A denied promotion followed by six months of head-down work and no conversation is the most common way a fixable "not yet" turns into a permanent no. One honest caveat Staff is a different profession. The clearest signal of that is how the time gets spent: survey-based descriptions of staff-plus roles put coding at roughly a fifth of the week. The rest is writing, reviewing, aligning, deciding, and teaching. Charity Majors' argument that management is a change of profession rather than a promotion applies to the staff track too. So if you'd rather spend your week inside a codebase than inside other people's decisions, that's worth finding out before you spend a year building a case rather than after. The ladder above senior really is optional at every company in the table above. The useful test is one week, honestly reviewed: how did you feel at the end of a week where you wrote almost no code and three other people made progress they wouldn't have made without you? If that felt like a good week, the rest of this is worth doing. If it felt like a wasted one, get very good at senior and let someone else have the packet. Disclosure, since it should be out in the open: I make career toolkits for engineers, and the frameworks above are pulled from one of them, a $12 PDF on how promotion works at the big four. Flagging where this came from because it's mine and it would be odd not to. Everything useful in this post is in the post.