- Authors

- Name
- Youngju Kim
- @fjvbn20031
Table of Contents
1. The Engineering Career Ladder
Software engineer career growth paths split into two main tracks:
IC (Individual Contributor) Track:
Junior → Mid-level → Senior → Staff → Senior Staff → Principal → Distinguished Fellow
Management Track:
Senior → Tech Lead → Engineering Manager → Senior EM → Director → VP of Engineering → CTO
Most companies follow the same path up to Senior, then branch into IC and Manager tracks.
| Level | Experience (typical) | Scope of Impact | Autonomy | Ambiguity Handling |
|---|---|---|---|---|
| Junior | 0-2 years | Tasks | Follow directions | Clear problems |
| Mid | 2-4 years | Features | Some autonomy | Some ambiguity |
| Senior | 4-7 years | Projects/Teams | Autonomous | Ambiguous problem definition |
| Staff | 7-12 years | Multiple teams/Org | Full autonomy | Find ambiguous problems |
| Principal | 12+ years | Entire company | Set direction | Industry-level ambiguity |
| Distinguished | 15+ years | Industry | Pioneer new fields | Unknown territory |
2. What Each Level Really Means
Scope of Impact
The most important growth metric is scope of impact:
- Junior: "Does this function work correctly?"
- Mid: "Does this feature meet requirements?"
- Senior: "Is this system scalable and maintainable?"
- Staff: "Does this architecture fit the org's 3-year roadmap?"
- Principal: "Does this tech strategy align with business goals?"
Autonomy
| Level | Autonomy Level |
|---|---|
| Junior | Told what to do AND how to do it |
| Mid | Told what to do, decides how |
| Senior | Co-defines what, autonomous in how |
| Staff | Understands why, self-defines what |
| Principal | Sets the why, influences org direction |
Dealing with Ambiguity
As you grow, you handle increasingly ambiguous problems:
- Junior: "Fix this bug" (clear)
- Mid: "Improve this page's performance" (somewhat ambiguous)
- Senior: "Improve user experience" (ambiguous)
- Staff: "Define the system architecture direction" (very ambiguous)
- Principal: "Set the 5-year technology strategy" (extremely ambiguous)
3. Junior to Mid-Level (1-3 Years)
Core Competencies
- Code quality — Writing clean, readable code
- Debugging skills — Systematic approach to finding root causes
- Code review — Learning from others' code, giving constructive feedback
- Estimation — Reasonably predicting task timelines
- Fundamentals — Data structures, algorithms, networking, OS basics
Actionable Guidelines
DO:
- Ask questions, but research first (15-minute rule)
- Ask "why did you do it this way?" in code reviews
- Submit small, frequent PRs
- Build a habit of writing tests
- Keep daily learning notes
DON'T:
- Struggle silently for an entire day
- Nod when you don't understand
- Hold back PRs trying to make perfect code
- Criticize colleagues' code (constructive feedback is different)
Growth Checklist
- Can you fully understand the code of your assigned component?
- Can you systematically track and reproduce bugs?
- Can you write technical documentation others can follow?
- Can you participate in on-call rotations?
- Are you efficiently using the team's development processes and tools?
4. Mid to Senior (3-5 Years)
The Key Transition
The mid to senior transition is about moving from individual contribution to team contribution.
Senior Expectations
- Project ownership — Taking responsibility for feature delivery end-to-end
- Mentoring — Growing junior/mid-level developers
- System design — Designing scalable systems and making technical decisions
- Tech debt management — Judging when and where to refactor
- Cross-team collaboration — Effective communication with PMs, designers, other teams
What Senior Engineers Do
Technical decisions:
- "Kafka vs RabbitMQ — Kafka is better for our use case because..."
- "This service is ready to be split into a microservice"
- "This tech debt needs to be addressed this quarter"
Team contributions:
- Providing architectural feedback in code reviews
- Writing RFC (Request for Comments) documents
- Maintaining onboarding documentation
- Leading incident response and postmortems
Promotion Strategy to Senior
- Start a Brag Document — Record achievements weekly
- Gain visibility — Make your contributions known beyond your team
- Gap analysis — Identify differences between current and next level
- Secure sponsorship — Find a senior leader who will champion you
- "Already working at that level" — Perform next-level work before promotion
5. Senior to Staff (5-8 Years)
What Is a Staff Engineer?
A Staff Engineer has technical influence that extends beyond their team.
Will Larson's four Staff Engineer archetypes:
| Archetype | Description | Best Fit |
|---|---|---|
| Tech Lead | Guides team's technical direction | Team leadership + technical skills |
| Architect | Sets technical vision and direction | Deep system design capability |
| Solver | Solves the hardest problems | Deep domain expertise |
| Right Hand | Technical partner to org leaders | Broad vision + execution ability |
The Key Difference at Staff Level
Senior: "I will build this system well" Staff: "I will lead the org to build the right systems"
A Staff Engineer's typical week:
- 30% coding — Strategic prototypes, critical code reviews, direction-setting code
- 30% technical strategy — RFC writing, architecture reviews, tech roadmaps
- 20% mentoring/teaching — Growing senior engineers, tech talks
- 20% organizational impact — Hiring interviews, process improvements, cross-team coordination
Staff Promotion Strategy
-
Find and solve org-level problems
- Expand from "my team" to "my organization"
- Lead technical decisions that affect multiple teams
-
Write technical strategy documents
- RFCs, ADRs (Architecture Decision Records), technical vision docs
- These are Staff's core artifacts
-
Demonstrate multiplier effect
- More important than personal output: making others more effective
- "Because of me, the team became 30% more productive"
-
Sponsorship is essential
- Staff+ requires more than qualifications — you need a senior leader actively advocating
- Share your impact in skip-level 1:1s
6. Staff+ (8+ Years)
Principal Engineer
Principal Engineers influence company-wide technical direction:
- Developing 3-5 year technical strategies
- Playing key roles in company technology stack decisions
- Speaking at industry conferences, leading tech blogs
- Evaluating senior talent in hiring
- Providing technical counsel to CEO/CTO
Distinguished/Fellow
Industry-level influence:
- Leading open-source projects (e.g., creators of React, Kubernetes)
- Publishing academic papers
- Defining new technology paradigms
- Participating in industry standard development
7. IC vs Manager: Choosing Your Path
Comparison Table
| Factor | IC Track | Manager Track |
|---|---|---|
| Daily work | Coding, design, tech strategy | 1:1s, hiring, process management |
| Performance metric | Technical artifacts, impact | Team performance, people growth |
| Energy source | Solving technical problems | Supporting people growth |
| Stress source | Technical complexity | Org politics, conflict management |
| Growth ceiling | Principal/Fellow | VP/CTO |
| Job mobility | High (skills transfer easily) | Medium (org-context dependent) |
| Burnout cause | Tech change fatigue | Relationship conflicts, politics |
Signs You Should Choose IC
- You feel most energized when coding
- You enjoy diving deep into technical problems
- You look forward to code reviews more than 1:1 meetings
- You find more satisfaction in technical contributions than others' achievements
- You have no interest in organizational politics
Signs You Should Choose Manager
- You find fulfillment watching others grow
- You want to improve team processes and culture
- You are drawn to organizational problems more than technical ones
- You gain energy from 1:1 meetings
- You want to build hiring, onboarding, and feedback processes
Can You Switch Tracks?
Yes. The "pendulum" pattern of switching from Manager back to IC is becoming increasingly common. However:
- After 2+ years as a manager, coding skills may rust
- Returning to IC may mean a level decrease
- Experience on both sides is a valuable asset on either track
8. Tech Lead: The Hybrid Path
What Is a Tech Lead?
Tech Lead is a hybrid of IC and Manager:
- 50-70% technical: Coding, architecture decisions, code review
- 30-50% leadership: Project planning, team coordination, stakeholder communication
Core Responsibilities
- Setting technical vision — Deciding the team's technical direction
- Project execution — Schedule, quality, and risk management
- Technical mentoring — Supporting team members' technical growth
- Cross-team communication — Coordinating with PM, design, and other engineering teams
- Tech debt management — Planning and executing refactoring
Common Tech Lead Pitfalls
Pitfall 1: Trying to write all the code yourself
Fix: Focus on strategic code only, delegate the rest
Pitfall 2: Thinking technical skills are all that matter
Fix: Communication, conflict resolution, and project management skills are needed
Pitfall 3: Becoming a bottleneck
Fix: Document decisions, provide guidelines for autonomous team decision-making
Pitfall 4: Wanting to be evaluated only on personal contributions
Fix: Recognize that team performance = your performance
9. Promotion Strategy
9.1 Brag Document
Invest 15 minutes weekly recording your achievements:
# Brag Document Template
## 2026 Q1
### Projects
- [Large] Led payment system migration — reduced latency by 40%
- [Medium] Built onboarding automation — reduced new dev ramp-up from 2 weeks to 3 days
### Technical Leadership
- Wrote 3 RFCs (auth system improvement, API versioning strategy, monitoring standardization)
- Participated in architecture reviews 2x/week
### Mentoring
- Mentored 2 junior developers (1 successfully promoted to mid-level)
- Presented "System Design Fundamentals" tech seminar
### Organizational Impact
- Conducted 12 hiring interviews (3 hires made)
- Improved deployment process: frequency from weekly to 3x daily
9.2 Gaining Visibility
- Within team: Demo presentations, tech seminars, code review leadership
- Within org: RFC writing, cross-team project participation, incident response leadership
- Within company: Tech blog posts, all-hands presentations, internal tools
- In the industry: Conference talks, open-source contributions, tech blogging
9.3 Sponsorship vs Mentorship
| Role | Mentor | Sponsor |
|---|---|---|
| What they do | Advise and guide | Actively advocate for your promotion |
| Relationship | Informal | Formal/informal |
| When needed | Always | Promotion season |
| Example | "Have you considered this approach?" | "This person is ready for Staff" |
9.4 Skip-level 1:1s
Have regular 1:1s with your manager's manager:
- Share your impact and contributions
- Understand organizational strategic direction
- Request feedback on promotion readiness
- Discover hidden opportunities
10. Salary Negotiation
Total Compensation Structure
Total Comp = Base Salary + Stock (RSU/Options) + Bonus + Other Benefits
Big Tech Senior (US):
- Base: $180K-250K USD
- RSU: $100K-300K USD/year (4-year vesting)
- Bonus: 15-25% of base
- Total Comp: $350K-700K+ USD
EU Senior:
- Base: 70K-120K EUR
- RSU: Company-dependent
- Bonus: 10-20%
- Total Comp: 80K-200K+ EUR
Negotiation Strategy
-
Never name a number first — Let the company make the first offer
-
Secure competing offers — The most powerful negotiation tool
-
Compare total compensation — Don't just look at base salary
-
Know negotiable items:
- Base salary (most rigid)
- Signing bonus (most flexible)
- RSU amount / accelerated vesting
- Remote work days
- Learning budget
- Title
-
Counter-offer caution — If your current company counter-offers:
- Short-term positive but may affect long-term relationship
- Check if the reasons for leaving are actually resolved
- Many people leave within 6 months of accepting a counter-offer
11. When to Change Jobs
Signs to Leave
- Growth stagnation — Haven't learned anything new in 6+ months
- Cultural misfit — Company values don't align with yours
- Compensation gap — Significantly below market rate
- Manager problems — Bad managers are the most common reason for leaving
- Tech stack — Using only technologies with no market competitiveness
- Burnout — Unrecoverable without environmental change
Signs to Stay
- Growth opportunities — New projects or roles are opening up
- Great team — Team members and manager support your growth
- Imminent promotion — High probability of promotion within 3-6 months
- RSU vesting — Large vesting event approaching (watch for cliffs)
- Impact — You're making meaningful changes in the organization
The 2-Year Rule
- Staying at least 2 years prevents looking unstable on your resume
- However, this is a guideline — leave toxic environments quickly
- Staying too long is also risky — if beyond 5 years, do a growth check
12. Building Your Brand
Technical Blog
- Aim for 1 technical post per week
- One deep post beats 10 shallow ones
- SEO optimization: searchable titles, meta descriptions
- Practical code and experience sharing gets the most traction
Open Source Contributions
- Start with issues in popular projects
- Documentation improvements are the easiest first contribution
- Open-source your utility libraries
- "Made at Company X" projects strengthen both company and personal brands
Conference Talks
- Start with internal tech seminars
- Meetup talks → local conferences → international conferences
- Repurpose talk materials as blog posts
- Deep learning happens during preparation
Teaching and Mentoring
- Run internal study groups
- Participate in external mentoring programs
- Create courses on learning platforms
- Join technical book review programs
13. Regional Differences
US/Silicon Valley
- Performance-based promotion culture
- Total comp heavily weighted toward RSU
- Frequent job changes are normalized (2-3 year cycles)
- Strong dual-track IC/Manager ladders
- Relocation packages and visa sponsorship common
Europe
- Better work-life balance regulation
- Lower total comp but stronger social benefits
- Notice periods often 1-3 months
- Seniority and tenure sometimes valued more
- Remote work increasingly common post-2020
Asia (Korea/Japan)
- Korea: Transitioning from seniority-based to performance-based
- Japan: Still significant seniority culture (nenkou joretsu)
- Both: Increasing acceptance of job changes in tech
- Korean chaebols vs startups offer very different career paths
- Japanese companies may have unique rank systems (shunin, kacho, bucho)
14. Practice Quiz
Q1: What is the biggest difference between Senior and Staff engineers?
Answer: Scope of Impact
Senior engineers lead projects within their team. Staff engineers exert technical influence beyond their team at the organizational level. Staff engineers coordinate technical direction across multiple teams and establish organizational technology strategies.
Q2: What should a Brag Document include?
Answer:
- Completed projects — Scale, impact, measurable results
- Technical leadership — RFCs, architecture decisions, technical direction
- Mentoring — Who you helped and what outcomes resulted
- Organizational contributions — Hiring, process improvements, culture
- Learning and growth — New technologies learned, talks given, blog posts
Q3: How should you choose between IC and Manager tracks?
Answer: Observe your energy sources:
- If you get energized by solving technical problems → IC
- If you get energized by watching people grow → Manager
- If you enjoy both → Tech Lead (hybrid)
Important: Management is not a "promotion." IC and Manager are different professions. If you love coding but switch to management for the title, you may end up unhappy in both.
Q4: What is the most effective salary negotiation strategy?
Answer: Securing Competing Offers
Having offers from other companies dramatically increases your leverage:
- Apply to 3-5 companies of interest simultaneously
- Time your offers (aim to receive them around the same time)
- Compare based on Total Compensation (TC)
- Negotiate with other companies using the highest offer as baseline
Never bluff about fake offers — the industry is smaller than you think.
Q5: How to distinguish when to leave vs when to stay?
Answer: Use these three key questions:
- "Will I be more skilled 6 months from now?"
- No → Consider leaving
- "Can I achieve my goals in this environment?"
- No → Consider leaving
- "Are my reasons for leaving problems that exist everywhere?"
- Yes → Try to solve them internally first
Changing jobs should be a "growth choice," not an "escape."
15. References
Books
- "Staff Engineer: Leadership Beyond the Management Track" — Will Larson
- "The Manager's Path" — Camille Fournier
- "An Elegant Puzzle: Systems of Engineering Management" — Will Larson
- "The Staff Engineer's Path" — Tanya Reilly
- "Radical Candor" — Kim Scott
Online Resources
- StaffEng.com — Staff Engineer interview collection
- Levels.fyi — Compensation data by level
- Engineering Ladders — Career ladder frameworks
- Julia Evans — Brag Document — Brag doc writing guide
- Charity Majors — The Engineer/Manager Pendulum
Talks and Media
- LeadDev Conference — Engineering leadership conference
- Gergely Orosz — The Pragmatic Engineer
- Software Engineering Radio — Career Episodes
Tools
- Levels.fyi — Global compensation benchmarks
- Blind — Anonymous professional network
- Glassdoor — Company reviews and salary data