I Got Promoted to Staff. My More Talented Colleague Didn't. Here's Why.

I've participated in promotion committees at large tech companies, and now I run calibration sessions at my current company. Here's something that still surprises people: the engineer who gets promoted to staff is rarely the most technically brilliant person in the room.

Let me be clear about what I mean. Technical excellence gets you to senior. It's table stakes. But I've watched genuinely talented engineers stay stuck at senior for five, six, even eight years while less technically gifted peers leap past them. What makes the difference? It's almost never about code quality or system design chops.

If you're trying to figure out how to get promoted from senior to staff engineer, you're probably already good enough technically. Visibility, narrative construction, and understanding what your company actually rewards at that level: these are the real blockers. No promotion guide will tell you this stuff, because it sounds too much like politics. And engineers hate politics.

But here's the thing. You can navigate this system without becoming someone you're not. I've seen it done. I've done it myself. What follows breaks down the patterns I've observed from engineers who made the leap versus those who stayed stuck, along with specific tactics you can start using this week.

Decoding What "Staff-Level Impact" Actually Means at Your Company

Every company says they want "staff-level impact." Almost none of them define it concretely. This ambiguity isn't accidental. It gives committees flexibility, but it also creates a moving target that frustrates candidates.

So decode it yourself.

Start by reverse-engineering recent promotions. Find three to five engineers who got promoted to staff in the last 18 months. What projects were in their packets? What scope did they operate at? Who sponsored them? This data matters more than whatever your leveling rubric says.

When I was at Google, the unwritten expectation was that staff engineers needed to demonstrate cross-team impact, though the specific scope requirements weren't formally documented and varied based on team and organization. At my current fintech startup, staff means something different: owning a complete product vertical technically, including its reliability, scalability roadmap, and architectural decisions.

Real examples that got promoted:

• Designed and shipped a new data pipeline architecture that reduced processing costs by 40% across four teams
• Led a six-month initiative to deprecate a legacy system that was blocking two product launches
• Created an internal testing framework adopted by 80% of backend teams

Examples that got rejected:

• "Mentored junior engineers and improved team velocity" (too vague, hard to verify)
• "Led the rewrite of our core API" (scope was right, but they couldn't articulate why it mattered beyond their team)
• Shipped consistently excellent work within their team boundaries (senior-level impact, not staff)

Staff-level work solves problems that exist at the organizational level, not just the team level. One rejected candidate had rewritten an entire payment processing system, but when asked "why should anyone outside your team care?", he couldn't answer.

The Staff Engineer Promotion Packet Anatomy

Your promotion packet is a legal document. I don't mean that literally, but treat it that way. Committees work under time pressure, sometimes spending only minutes on each packet. Your manager might advocate for you, but they're working from what you've documented.

A strong staff engineer promotion packet includes these components:

1. The Impact Narrative

Not a list of accomplishments. It's a story about how you identified an important problem, built alignment around a solution, and drove it to completion with measurable results. I structure mine using this framework:

• What was the organizational problem? (Not the technical problem, the organizational one.)
• Why was I the right person to solve it?
• What did I do that a senior engineer wouldn't have?
• What changed because of my work?

2. Quantified Results with Context

"Reduced latency by 50%" means nothing without context. Did you reduce it from 200ms to 100ms, or from 2ms to 1ms? Was this a critical user-facing service or an internal batch job? How many users did this affect?

When writing staff engineer self-review sections, I follow a simple rule: every claim needs a number, and every number needs a "so what."

3. Cross-Team Influence Evidence

Most packets fall apart here. You need specific artifacts showing you influenced decisions and outcomes beyond your team. Design docs you authored that other teams adopted. RFCs where you were the technical decision-maker. Slack threads where other team leads asked for your input.

I keep a running document throughout the year. Every time I review another team's design, get pulled into an architectural discussion, or make a recommendation that gets implemented, I log it: date, context, outcome. Sounds tedious, right? It's saved my promotion twice.

4. Peer Feedback That Tells a Story

Generic "Marcus is great to work with" feedback won't help you. Coach your feedback providers. Tell them specifically what projects to reference and what aspects of your work to highlight. You're not gaming the system here. You're helping them give useful feedback.

Building Cross-Team Influence Without Authority

Most engineers read "cross-team influence" and think politics. I get it. I spent my first few years actively avoiding anything that smelled like corporate maneuvering.

But cross-team influence strategies in engineering don't have to feel gross. Here's what actually works for engineers who hate politics:

Be the person who writes things down.

When a cross-team problem emerges, volunteer to write the design doc or RFC. This is leverage disguised as grunt work. Whoever frames the problem typically shapes the solution. I've gained more organizational influence from well-written documents than from any meeting.

Solve their problem first.

Before you ask another team to adopt your framework or change their approach, help them with something they already care about. Review their design docs thoughtfully. Point out production issues before they become incidents. Build trust before you need it.

Create opt-in value.

Frameworks and tools that get adopted aren't pushed. They're pulled. When I wanted to standardize our error handling patterns, I didn't mandate anything. I built a library, documented it well, wrote a blog post showing the before and after, and shared it in our engineering Slack. Three teams adopted it within a month because it made their lives easier.

Run architecture office hours.

This one surprised me with how effective it was. I started holding weekly 30-minute sessions where anyone could drop in with architectural questions. No commitment, no agenda. Within two months, engineers from six different teams were attending regularly. That's influence you can't manufacture.

Skills needed for staff engineer level include technical depth, yes. But they also include the ability to make other teams want to work with you.

Staff vs. Principal vs. Management Track

Before you optimize for staff, make sure it's actually what you want. I've seen engineers burn years chasing a title that doesn't match their strengths or interests.

Staff Engineer: You're still an individual contributor, but you operate at organizational scope. You'll spend more time in documents and meetings than in code. Your impact comes from technical decision-making and enabling other engineers. If you hate writing and communication? This path will make you miserable.

Principal Engineer: Think of this as staff-plus. Principals at most companies set technical direction for entire product areas or the company itself. Staff engineer vs. principal engineer career path difference is mostly scope and time horizon. Principals think in years and ecosystems; staff engineers think in quarters and systems.

Engineering Manager: You're optimizing for people, not systems. Success is measured by your team's output, not your own. Some engineers thrive here. Others find it soul-crushing. Neither reaction is wrong.

Switching between the technical leadership track and management track isn't reversible at all companies. Google let you switch relatively easily. My current company would reset some of your accumulated credibility if you went from staff back to management.

Ask yourself honestly: What energizes you? For me, it was always solving hard technical problems at scale. Management would have been the wrong choice, even though people kept suggesting it.

The 6-Month Staff Engineer Interview Preparation System

Whether you're pursuing internal promotion or external opportunities, preparation follows the same pattern. FAANG staff engineer requirements for 2024 haven't changed dramatically from previous years: system design depth, technical leadership evidence, and communication skills.

Here's my staff engineer interview preparation guide, broken into phases:

Months 1–2: Foundation

• Review 20–30 system design problems. Not to memorize solutions, but to build pattern recognition.
• Read the staff engineer books. Will Larson's work is excellent, but also read postmortems and architecture docs from companies you admire.
• Identify your "signature stories." You need three to five project narratives you can discuss in deep technical detail.

Months 3–4: Practice

• Do two to three mock system design interviews weekly. Use paid services or find peers. Solo practice doesn't work at this level.
• Practice behavioral questions specifically around influence, conflict resolution, and technical decision-making.
• Refine your stories based on what lands and what falls flat.

Months 5–6: Polish

• Target specific companies and understand their interview formats. Amazon's loop looks nothing like Google's.
• Prepare questions for your interviewers that demonstrate staff-level thinking.
• Get comfortable with ambiguity. Staff interviews deliberately give you incomplete information to see how you navigate uncertainty.

Staff engineer promotion timeline in big tech varies. Senior-to-staff at Google can take anywhere from two to four years based on individual performance, team, and available opportunities, though there's no officially published typical duration. Smaller companies can move faster if you're in the right role. How long does it take to become a staff engineer? Honestly, it depends more on opportunity than ability.

Your 90-Day Action Plan

None of this matters if you don't act. Start here:

Days 1–7:

• Identify three engineers who recently got promoted to staff at your company.
• Schedule coffee chats with at least one of them.
• Start your impact log document.

Days 8–30:

• Audit your current projects against staff-level impact criteria.
• Identify one cross-team problem you could own.
• Have an explicit conversation with your manager about your promotion timeline.

Days 31–60:

• Begin drafting your promotion narrative.
• Volunteer for one design review or RFC outside your immediate team.
• Set up a system to collect peer feedback throughout the year.

Days 61–90:

• Review your draft narrative with a trusted staff-plus engineer.
• Create your list of staff engineer project examples for promotion.
• Decide: are you optimizing for internal promotion or external opportunities?

Look, the path from senior to staff isn't fair. Some people get lucky with high-visibility projects. Some have better sponsors. Real bias issues exist in the system, and we should keep fighting to fix them.

But within that imperfect system, you have more agency than you think. Engineers who get promoted aren't just the ones who do great work. They're the ones who make that work visible, document it compellingly, and build relationships across the organization.

You can do this without compromising who you are. I've done it. Engineers I've helped promote have done it. Now it's your turn.