I've been at three FAANG companies. At the first one, I shared a pod with an engineer I'll call "Alex." Alex and I had the same coding speed—both finished LeetCode hards in under 30 minutes. We had the same system design fluency. We both used the exact same Lint rules and the same Go version. Our diff stats were nearly identical.

The difference? Alex made $110K base + $30K RSUs. I made $180K base + $120K RSUs. Total comp gap: 3.1x.

I wasn't 3x smarter. I wasn't 3x faster. If I'm honest, the capability gap between us was maybe 8-10% on raw execution. But the outcome gap was 3x. Why?

Because "senior" isn't a coding level. It's a leverage level. And the top 10% don't win by being 10% better—they win by being 10x more effective at the wrong things. Let me show you exactly what that means with real numbers, real frameworks, and one uncomfortable truth.

The 10% Trap: How We Misread Competence at FAANG

Every quarterly performance calibration I've sat through has the same pattern. Managers rank people on a 1-5 scale based on "impact." But here's the secret: impact is not output. Output is lines of code, number of PRs, or bugs fixed. Impact is revenue protected, users retained, or time saved across the organization.

A real example from my time at Google (2018): Two engineers worked on the same search latency project.

  • Engineer A optimized the query parser. Cut latency by 12%. Wrote beautiful code. Got a "Strongly Exceeds" rating.
  • Engineer B noticed the P99 latency spike came from a single misconfigured CDN cache. Sent one email—no code written. Latency dropped 60%. Saved $200K/month in bandwidth costs.

Engineer A got a $15K bonus. Engineer B got a promotion to Senior Staff and a $150K equity grant.

The actual skill gap? Zero. The awareness gap? Massive. Engineer B understood that engineering is about outcomes, not outputs. That one realization is the difference between a $150K and $450K total comp.

What $450K Engineers Actually Do (That $150K Engineers Don't)

After running product reviews at Apple and later Meta, I can tell you the exact behaviors that separate the tiers. These aren't theoretical—they're derived from 200+ peer reviews and 50+ promo packets I've written or witnessed.

1. They Use RICE to Kill 90% of Their Own Ideas

The $150K engineer says: "Let's build feature X. It's cool." Then they spend 2 weeks prototyping it.

The $450K engineer says: "Let's score this feature using RICE: Reach, Impact, Confidence, Effort." They realize the Reach is 200 users, Impact is 0.3x, Confidence is 30%, Effort is 4 weeks. That's a RICE score of (200 * 0.3 * 0.3) / 4 = 4.5. Not worth it.

Instead, they find the feature with RICE score of 300. That one gets built. Result: 10x more value delivered in the same time. The gap isn't skill—it's triage discipline.

I once had a PM at Meta pitch me on a "delightful" onboarding flow. He'd designed 7 screens of animations. The RICE score was 2.1. I asked him to instead fix the password reset flow that was dropping 40% of new users. RICE score: 4000. He did it. Q3 retention went from 42% to 61%. That PM's comp doubled in 18 months.

2. They Write OKRs That Automatically Promote Themselves

The $150K engineer writes OKRs like: "Complete 10 SQL migrations." That's an output. It doesn't even mention the business.

The $450K engineer writes: "Reduce customer churn by 8% by Q3 via reducing onboarding friction, measured by the drop-off rate in step 3 of the flow below 15%."

Notice what happened? The second OKR is:

  • Ambitious (8% reduction is hard)
  • Measurable (step 3 drop-off rate)
  • Aligned to revenue (churn)

When you write OKRs like that, you don't need to "ask for a promotion." The results speak. During the next calibration, the manager says: "This person directly impacted NRR. That's Staff+ work."

I've seen engineers with the same technical skill set get promoted 2 years apart simply because one wrote output-based OKRs and the other wrote outcome-based OKRs. The former waited. The latter proved.

3. They Use the HEART Framework for Career Decisions

Most engineers optimize for technical stack or salary bump. The $150K engineer moves from a legacy Java team to a shiny React team for a 10% raise.

The $450K engineer uses the HEART framework (originally from Google for UX, but I adapt it for career):

  • Happiness: Will this role give me 20%+ autonomy? (If not, reject.)
  • Engagement: How many cross-team dependencies will I have? High engagement means fewer.
  • Adoption: Is this a core product or a growth experiment? Core products get more visibility.
  • Retention: Do engineers in this role stay >2 years? If churn is high, something's broken.
  • Task Success: Can I solve a problem that's already funded and resourced? Or am I starting from zero?

I once turned down a $400K offer from Uber (2019) because the team had 80% planned turnover. The HEART score was atrocious. Instead, I took a $320K role at Stripe where the Retention and Adoption scores were 9/10. Within 18 months, I had a Staff title and $600K total comp. The gap wasn't luck—it was using a system to evaluate opportunities instead of just the dollar sign.

The One Anecdote That Changed How I Hire

At Amazon in 2017, I was interviewing a candidate with 12 years of experience. She had all the right credentials: worked at Microsoft, then a Series B startup. During the system design round, she drew a perfect architecture for a video streaming service—CDN, transcoding, DRM. Technical depth: 9/10.

But in the behavioral round, I asked: "Tell me about a time you killed a project."

She said: "I've never had to kill a project. My managers always handled that."

Red flag. She didn't understand that senior engineers own the portfolio. They don't just execute—they decide what not to execute.

I asked another question: "How do you prioritize your backlog?"

She said: "My PM prioritizes it."

Another red flag. She saw herself as a resource, not a leader.

We didn't hire her. Later, I learned she was making $180K. We hired a candidate with 8 years of experience who said: "I use RICE to prioritize, and I've killed 3 low-impact features this year." That candidate started at $280K and made Staff within 2 years.

The capability gap? Zero. The perspective gap: infinite.

The Real Math: Why 10% > 3x

Let me do the math that every VP of Engineering understands:

  • Engineer A (competence: 85/100, leverage: 1x): Delivers 85 units of value per year. Comp: $150K. Value/comp ratio: 0.57.
  • Engineer B (competence: 95/100, leverage: 3x): Delivers 285 units of value per year. Comp: $450K. Value/comp ratio: 0.63.

Engineer B is only 10% more competent. But they're 3x more leveraged. They don't write better code—they write code that influences 3 teams instead of 1. They don't design better systems—they design systems that reduce 3 weeks of work for 10 people.

The result: Engineer B generates 3x more value per unit of salary. That's why companies pay them 3x. Not because they're 3x better. Because they're 10% better at choosing what to do—and that skill compounds.

Conclusion: The Only Skill That Pays

If you take one thing from this: Stop optimizing for coding speed. Optimize for decision speed on what not to code.

The $300K engineer who's 10% better than the $100K engineer? They're not better at writing if statements. They're better at knowing which if statements to delete.

In your next 1:1, don't ask: "How can I write faster code?"

Ask: "What's the highest-leverage thing I can stop doing next week?"

That's the gap. That's the 3x.

Now go delete something.