Why Aren’t You Getting Promoted to Staff Engineer / Почему тебя не промоутят до стаффа? 🤔
(Перевод на русский ты найдешь в комментах)

Hey! It just so happened that I had to read and write a lot of feedback for IC6 promo packets in the last year. When it comes to promotion to IC5, it's usually pretty clear what's missing. But with IC6, the lines get really blurry. So I decided to write a short post about the most common reasons why a great engineer doesn’t get promoted — assuming the team needs a staff eng, and the person is actively working with their manager on it.

Let’s dive in 🚀

❌ Soft Skills. Sometimes, a person is a top-notch expert, crushes projects, writes great code, and knows architecture. But still — no promo. A recurring issue I’ve seen in many packets is the lack of trust and leadership skills. People don’t really enjoy working with the person, or they simply operate in isolation from the team. Others on the team don’t feel like they’re working with a Tech Lead. Managers want to see that the engineer is trusted by others — ideally a group of at least 6–10 engineers.

❌ Uplifting Others. Here's a fun analogy. If you’ve played World of Warcraft or Diablo, there’s this class of heroes — Paladins — who buff the group. That’s roughly how managers see IC6s: wherever you put them, they make everything and everyone better. It shows in things like mentoring engineers, doing code and architecture reviews, and keeping morale up in tough times 😀. When a project is failing and there’s pressure from leadership, it's the IC6 who takes the hit and pushes the group to land the project. I'm sure you've met people like this — always full of energy, technically solid, and highly trusted by other engineers.

❌ Outer Focus. One of the biggest mindset shifts between IC5 and IC6 is moving your focus away from yourself and toward others. As a senior, your job is to land the project you’ve been given — your direct impact. As an IC6, the focus shifts to the team’s projects. A good IC6 finds interesting projects for everyone else, even if it means giving up something interesting themselves. A common mistake I see is trying to lead everything. Taking on all the initiatives across the org and not giving others a chance. Instead, you should be enabling others to grow their leadership skills — giving feedback and guidance. As a result, you build trust, and people start relying on you more.

❌ Credit Stealing. One pattern I’ve seen a lot: the team agrees to tackle N issues in the codebase over the half-year. Tasks are split up. The aspiring IC6 sets up a recurring check-in every 2–3 weeks, where everyone syncs. Engineers work independently, and the problems were distributed as a team decision. Then, at performance review time, this person writes a massive self-review claiming they “organized everything” and that they helped the team solve N issues. Sounds like IC6 work, right? Organizing a sync meeting — sure, that’s fine. But claiming the team’s work as your own isn’t. The right thing to do is let the team talk about their own contributions. Even if you delegated all the work and provided technical help, it’s still better to let others share their wins. That builds the right kind of trust and relationships.

❌ No Personal Contribution. Some tech leads drift into pure project management and stop writing code or contributing technically. Unfortunately, PMing often is a second job for IC6s — but it shouldn’t fully replace engineering work. Yes, you can write less code on average, but if you’re spending 80% of your time in meetings and Google Docs, that’s a red flag. Prioritize what matters, skip unneeded meetings, delegate when needed, and let other engineers pick up some of the PM workload.

Let me know if you have questions. I think this write-up is equally relevant to Big Tech — the expectations and levels are pretty similar 👨‍💻

YouTube 📹 — Medium 📑 — LinkedIn 👨‍💻