The Difference Between Doing the Job and Proving You're Ready

You're the person your team depends on. You close out every sprint. You pick up the messy tickets nobody wants. Your code reviews are thorough, your oncall shifts are clean, and your manager has told you multiple times that you're doing great work.

Then the promotion decisions come back, and someone else gets the nod. The feedback you get is something like: "You're performing well at your current level, but we need to see you operating at the next level before we can promote you."

You're staring at that sentence trying to figure out what it even means. You're already doing everything asked of you. What else is there?

That question is the gap. And until you understand it, you'll keep excelling at the wrong thing.

Why being great at your job doesn't get you promoted

Here's the part nobody explains clearly during onboarding: at most tech companies, especially big ones, promotion isn't a reward for excellent performance at your current level. It's a recognition that you've already been performing at the next level for long enough that the title is just catching up.

Gergely Orosz puts it directly: most tech companies promote people who are already performing at the next level, not people who might be ready. Your impact and skills need to consistently exceed what's expected of you, and they need to match what's normal at the level above.

This means that being the fastest, most reliable engineer at L4 doesn't make you an L5 candidate. It makes you a very good L4. The promotion committee isn't asking "is this person great at their job?" They're asking "is this person already doing the next job?"

That's a different question with a different answer.

What "current-level work" actually looks like

Most engineers don't think of their work in terms of levels. They think of it in terms of quality. They assume that better execution at what they're already doing is the path forward.

At the mid-level (L4 / SDE II / E4), current-level work typically looks like:

• Shipping features on time within a well-scoped project
• Writing clean, well-tested code that doesn't cause production incidents
• Participating in code reviews and giving useful feedback
• Handling oncall rotations without escalations
• Completing the work your manager assigns to you

All of that is necessary. None of it is sufficient. A committee looking at that list sees someone who is doing exactly what their level requires. There's no signal that says "this person is ready for more responsibility." There's just evidence that they're meeting expectations.

What next-level work looks like

The shift from current-level to next-level isn't about doing the same work harder or faster. It's about doing different work. The specific differences depend on which level you're targeting, but the pattern is consistent: you move from executing to shaping.

For the jump from mid-level to senior, next-level work looks like:

• Scoping projects yourself instead of waiting for your manager to break them down. You identify a problem, propose a solution, get buy-in, and drive it to completion.
• Unblocking other engineers when they're stuck, not just when they ask for help. You notice the bottleneck and step in before it becomes a team problem.
• Making technical decisions that hold up under scrutiny. You're choosing the approach, writing the RFC, defending the tradeoffs. Not implementing someone else's design.
• Influencing work beyond your immediate tasks. You raised the issue that changed how the team handles deployments. You proposed the testing strategy that caught bugs earlier. The team is different because you were on it.

For the jump from senior to staff, Sean Goedecke describes it bluntly: staff promotions aren't earned through excellence at your current level. You have to be known and valued by your organization. You have to be leading initiatives that leadership actually cares about. Engineers fail at this transition by doing excellent work on problems the company doesn't prioritize.

The common thread across every level transition: you stop waiting for the work to come to you, and you start shaping what the work is.

The trap most engineers fall into

There's a specific trap that catches ambitious engineers who are working hard but not getting promoted. It goes like this:

You identify what you're good at. You double down on it. You become the best person on your team at that thing. Your manager appreciates it. You get positive feedback in your reviews. And you interpret that positive feedback as evidence that promotion is coming.

But what's actually happening is that you're building a deeper and deeper track record at your current level. Every clean oncall shift, every on-time feature delivery, every thorough code review is another data point that says "excellent L4." Not "emerging L5."

The promotion committee doesn't weigh volume. Reviewing 200 PRs doesn't count more than reviewing 50 if both cases show the same type of contribution. They're looking for evidence of a qualitative shift: moments where you operated differently than your current level would require.

How to tell which side of the line you're on

Run this test on your last quarter of work. For every major accomplishment, ask:

Could a strong engineer at my level have done this? If a competent peer could have produced the same result, it's current-level work. It might be excellent current-level work. But it doesn't differentiate your case.

Did I choose this work, or was it assigned to me? Next-level engineers identify the problems worth solving. Current-level engineers solve the problems they're given. Both are valuable, but only one signals readiness.

What changed because I did this? If your answer describes your personal output ("I shipped X, I reviewed Y"), you're describing activity. If your answer describes something that changed for the team, the product, or the org ("deploy frequency went up," "the team stopped losing time to flaky tests"), you're describing impact at a higher scope.

Did anyone outside my immediate team notice? This isn't about popularity. It's about influence radius. Next-level work tends to be visible beyond your direct team because it affects systems, processes, or decisions that other people rely on.

If most of your answers point to current-level indicators, that's the gap your manager is trying to describe when they say "we need to see more."

The documentation gap makes it worse

Even engineers who are doing next-level work often fail to get promoted because they don't document the difference. Their promotion case reads like a list of completed projects, not a narrative about operating at a higher scope.

When your manager pitches your case in a calibration meeting, they have maybe five minutes. They need to say something more compelling than "she ships fast and her code is clean." They need to say "she identified the root cause of our deploy reliability problem, proposed and drove the fix cross-team, and deploy failures dropped 40% in the first month."

If you haven't given your manager that second version of the story, they'll default to the first version. And the first version, no matter how true, sounds like current-level work to a room full of people making promotion decisions about engineers they've never met.

What to do with this information

You don't close this gap by working more hours. You close it by choosing different work.

Identify one next-level problem you can own

Look at what your team struggles with that nobody has fixed. Maybe deployment is too slow. Maybe handoffs between frontend and backend keep dropping. Maybe the PM and the tech lead keep misaligning on scope and nobody has stepped in to fix the process. Pick one. Propose a fix. Drive it.

Start tracking impact, not activity

When you log a win, push past the "what I did" and capture "what changed." If you built a monitoring dashboard, the win isn't the dashboard. The win is that the team's MTTR dropped, or that the oncall engineer can now diagnose issues in 3 minutes instead of 30.

Have the explicit conversation with your manager

Ask: "What would I need to demonstrate, specifically, for you to be able to make a case for my promotion in the next cycle?" If they give you a vague answer, push: "Can you give me an example of the kind of work that would count?" You're not being pushy. You're asking for the criteria so you can meet them.

Look at who got promoted and study the pattern

The engineers who got promoted recently at your company didn't get there by being generically excellent. They did specific things that mapped to next-level expectations. Find out what those things were. Ask them directly if you can. The answer is usually more concrete than you'd expect.

The gap between doing the job and proving you're ready for the next one isn't about talent or politics. It's about understanding what the next level actually requires and starting to do that work before you have the title. The title follows the work. It doesn't precede it.

---

CareerClimb helps you log wins with the impact framing that promotion committees actually respond to, and gives you a clear picture of where your case has gaps before review season starts. Download CareerClimb to start building your case today.