6 posts tagged with "career"

A 3.5-year engineer at a 120-person scaleup I worked with last year was "obviously senior" — by everyone's intuition. Her Git and IDE data told a different story: she was shipping more features than any senior on the team, but she wasn't reviewing PRs from people outside her squad, never owned a system-design proposal end-to-end, and her commits clustered in a narrow 2-component surface area. Her manager's gut said senior. The behavioral evidence said: ready in 6-9 months, not today. The 6-month data revisit confirmed it — she got there, and the promotion landed stronger than the intuition-based one would have.

Promotion decisions fail in two directions. Promote-too-early produces under-supported seniors who quietly under-perform and sometimes leave. Promote-too-late loses your best engineers to competitors who saw the readiness first. A 2023 First Round Review study on engineering careers found the single largest driver of senior-engineer regret was "promoted without being ready," cited by 41% of respondents. Data-backed criteria reduce both errors.

Will Larson's 2021 survey of 14 staff engineers at large tech companies produced a finding most ladders still ignore: only one in three senior engineers wants the Staff title, and of those, fewer than half make it in five years. The promotion is not a natural continuation of Senior. It's a role change — different work, different signals, different failure modes. Engineering ladders that treat it as "Senior+" produce stalled careers and a pile of ICs who quit for an EM job at another company.

This framework is what actually predicts readiness, drawn from a mix of Larson's research, Tanya Reilly's The Staff Engineer's Path, and the patterns we see in delivery data across 100+ B2B engineering organizations.

A principal engineer at a 200-person fintech spent Q3 writing 180 lines of code. Her team shipped 340,000 lines in the same period. When her CTO looked at coding-time dashboards for a performance review, she almost got flagged as underperforming. What actually happened in Q3: she rewrote the payment reconciliation spec that unblocked two teams, mentored three senior engineers into tech-lead roles, and killed a six-month project that would have shipped something the market didn't want. Her measurable output was tiny. Her impact was the largest of any engineer in the company that quarter.

This is the principal engineer measurement paradox. Every staff-plus framework (Will Larson's, Tanya Reilly's The Staff Engineer's Path, the Google internal engineering ladder) acknowledges it: principal engineers are paid for judgment and force multiplication, not throughput. But most engineering orgs measure them like senior engineers with a bigger title. This article is how to measure principal impact honestly — and how a principal should measure their own impact when the review conversation comes.

An Engineering Director who led a 50-person org well is usually the wrong person to lead a 500-person org well. Not because they lack talent — because the role at 500 is a different job, not the same job at higher intensity. Research from First Round Review's survey of 300+ engineering leaders consistently finds that the transitions at ~80, ~150, and ~300 engineers are where the most senior leader burnouts and quiet departures cluster.

This is a data-grounded guide to the four transitions an Engineering Director faces as the org grows from 50 to 500 — what to let go of, what to pick up, and what our IDE heartbeat data says about the warning signs of a Director who didn't make the shift.

Your best senior engineer just got promoted to "lead." Nobody wrote down whether that means Tech Lead or Engineering Manager, so now she does both. She's reviewing every PR, running every 1:1, planning every sprint, and still expected to ship her own code. Three months in, her output collapsed and so did team delivery. A 2024 Stack Overflow Developer Survey found that engineers in hybrid "lead" roles report 1.6× higher burnout than those on either a pure IC or pure management path. Merging the roles is the single most common — and most expensive — leadership mistake we see.

Tech Lead and Engineering Manager are different jobs with different success metrics, different time allocations, and different failure modes. Pick one per person, or pick both and hire two people.

A newly hired VP of Engineering has three things the org watches closely: what they cut, who they keep, and how fast they announce a plan. Get the sequence wrong and credibility is gone by week 4 — the org decides you're either a reorganiser or a lame duck before you understand the codebase. Michael Watkins' The First 90 Days is the foundational reference, but it's written for general executives. Engineering orgs have specific traps.

The counter-intuitive move: announce less in the first 30 days than you think you should. Not "listening tour" theatre — an actual measured pause while you read the org's calendar, incident history, and deploy pipeline.