Same level. Same title. Watching people who joined after me get promoted to staff.

My manager kept saying I was doing great work. "High quality. Reliable. Good execution."

But when promotion time came, the answer was always the same: "Not quite staff-level impact yet."

I didn't understand. I was shipping projects. Meeting deadlines. Writing good code. What was I missing?

So I did something I should have done two years earlier: I started asking the people who actually got promoted what they did differently.

Fifty-three engineers. All promoted to staff or higher in two years or less.

The pattern wasn't what I expected.

The first person I talked to was someone I'll call Sarah. Promoted to staff in eighteen months.

I asked her how she found her projects. I was expecting some answer about working harder, or being more visible, or getting lucky with a high-impact assignment.

Instead, she said: "I talk to the product manager every week. Just fifteen minutes. I ask her what's keeping her up at night."

I must have looked confused, because she continued: "Engineers wait for projects to be assigned. I ask where the pain is, then I go solve it before it becomes a ticket."

That week, the PM mentioned that customer support was drowning in requests about a confusing workflow. Nothing urgent. Not on the roadmap. Just… painful.

Sarah spent two weeks simplifying it. Support requests dropped 40%. The PM mentioned it to the VP. The VP mentioned it to the CEO.

Three months later, Sarah was leading a cross-functional initiative to redesign the entire onboarding flow.

She didn't wait for a high-impact project. She made one.

I talked to an engineer I'll call Marcus next. Staff engineer at a different company. Promoted in twenty months.

"I read every incident report," he said. "Not just from my team. From every team. Then I look for patterns."

He noticed that three different teams had production issues related to the same database. Each team solved it differently. None of them talked to each other.

Marcus wrote a proposal to standardize the approach. Built a library. Shared it in the engineering all-hands.

Six months later, it was used by twelve teams. Infrastructure costs dropped 15%. He got promoted for "organizational impact."

He didn't get assigned to fix the database problem. He noticed a pattern nobody else was paying attention to.

By the tenth conversation, the pattern was clear.

Every single person who got promoted fast did the same thing: they found problems before those problems became projects.

They talked to people outside engineering. Product managers. Customer support. Sales. Even finance.

They asked: "What's hard right now?" "What's costing us money?" "What are customers complaining about?"

Then they went and fixed those things. Before anyone asked them to. Before it was on a roadmap. Before it was formally scoped.

And when promotion time came, they had a portfolio of work that directly solved business problems. Not just "completed assigned projects."

Here's what I'd been doing wrong:

I waited for my manager to assign me projects. Good projects. Important projects. I executed them well.

But my manager didn't know what the product team was struggling with. Or what customer support was seeing. Or what operational problems were costing the company money.

My manager knew what was already on the roadmap. And by definition, if it's on the roadmap, it's not a gap. It's not a problem that needs discovering. It's already been discovered and prioritized.

The engineers getting promoted weren't just executing roadmap items well. They were finding the problems that hadn't made it to the roadmap yet.

I had a coworker, let's call her Lisa, who'd been senior for four years. Smart engineer. Great code quality. Always delivered.

Never promoted.

I asked her: "When was the last time you talked to someone outside engineering about what problems they're facing?"

She thought about it. "I mean, I go to the planning meetings. The PM tells us what to build."

"But do you talk to the PM outside of those meetings? Do you ask what's hard for them?"

She looked uncomfortable. "I don't want to bother them. They're busy."

That's what I'd been thinking too. For three years.

The engineers getting promoted weren't bothering people. They were building relationships that gave them visibility into problems worth solving.

I changed my approach.

Started having coffee chats with the product manager. Not about my projects. About her problems.

First conversation, I learned that the analytics team was manually generating reports every Monday. Took them three hours. They'd been doing it for six months.

Nobody had told engineering because "it wasn't that bad" and "we have bigger priorities."

I spent a weekend automating it. Three hours of manual work became five minutes automated.

The analytics team mentioned it to their director. The director mentioned it to my skip-level. My skip-level asked why this hadn't been prioritized formally.

Because it wasn't on the roadmap. Because nobody in engineering knew it was a problem.

I started having lunch with someone from customer support once a month. Just to hear what customers were actually saying.

I learned that our error messages were useless. Customers couldn't tell the difference between "try again" problems and "call support" problems. Support was getting hammered with questions they couldn't answer.

I spent two weeks improving our error handling. Better messages. Better logging. Clear next steps.

Support tickets dropped 30% in a month.

My manager didn't assign this work. It wasn't on any roadmap. But when promotion discussions came around, my director knew about it. Because the support director had told him.

Six months after I started this approach, I had my performance review.

My manager said: "You've been doing something different lately. I've been hearing your name from other teams. The PM mentioned you. The support director mentioned you. My skip-level asked about the analytics automation."

I got promoted three months later.

Not because I worked harder. Not because I wrote better code. Because I started solving problems that other people cared about.

Here's what I learned from studying those fifty-three engineers:

The people who get promoted fast don't wait for high-impact projects to be assigned. They find problems that matter to the business and solve them.

They build relationships with people who see different parts of the problem space. Product managers see customer needs. Support sees user pain. Finance sees cost. Operations sees reliability.

They ask one question consistently: "What's hard right now?"

Then they go fix it. Before it's a roadmap item. Before it's a formal project. Before anyone assigns it.

And when promotion time comes, they have a track record of organizational impact. Not just good execution.

The mistake I made for three years was waiting for someone to hand me a high-impact project.

But high-impact projects don't get handed to you. They get discovered. By talking to people. By paying attention. By asking what's broken.

The engineers getting promoted fast weren't luckier. They weren't smarter. They weren't getting special assignments.

They were just asking different questions. And then actually solving what they found.

As I've learned to identify high-impact work and share these insights, I've discovered that communicating these lessons effectively matters. Narrareach helps me understand which story formats resonate with readers — showing what narrative patterns get 8–10x more engagement on Medium, Substack, and LinkedIn. Whether you're writing about career growth or project selection, it reveals what actually connects with people navigating similar challenges. Please check them out.

Have you ever felt stuck at the same level while watching others get promoted? What changed for you?