Career ladders in software engineering are the formal frameworks companies use to define what each level of engineer is expected to deliver. In practice they serve two functions: setting expectations for current-level performance, and defining what you need to demonstrate to reach the next level.

Most companies publish their ladder criteria internally (some, like Dropbox and Levels.fyi, have made portions public). The criteria typically cover four dimensions: technical skill, scope of impact, autonomy, and influence on others. What changes between levels is the radius of each.

At junior level, your scope is a feature. At mid-level, a component or service. At senior, a team. At staff, multiple teams or a product area. At principal, the engineering org.

**What you own:** Individual features, bug fixes, and small projects with supervision.

**What you're expected to deliver:** Working code that meets requirements, on time, with guidance from a senior engineer. You're not expected to define the requirements or own the system — you're expected to execute reliably.

**What actually gets you promoted:** Shipping reliably and quickly, ramping up on the codebase faster than expected, asking questions that show you're thinking about the system rather than just the task, and starting to contribute to code reviews. Promotions from junior to mid are mostly about demonstrated reliability and ramp speed — not complexity.

**What you own:** A component, service, or feature area. You take requirements and own the implementation end-to-end with minimal supervision.

**What you're expected to deliver:** Working systems that you've designed (within a given architecture), code reviews for junior engineers, and some contribution to technical discussions about your area.

**What actually gets you promoted:** The jump from mid to senior is often where people first get stuck. The bar shifts from 'executes well on given work' to 'defines what should be done and why.' Companies want to see you proactively improve systems in your area, mentor at least one junior engineer, and take on technical design work without being asked.

**What you own:** Team-level technical direction. You're defining how your team approaches technical problems, not just solving the ones assigned to you.

**What you're expected to deliver:** Technical design documents, architecture decisions for your area, mentorship of mid-level engineers, and cross-team collaboration on shared systems. You're also expected to proactively identify technical debt and risk — not just fix what you're assigned.

**Hard truth about senior level:** This is where most engineers plateau — and that's not a failure. Senior is a respected, well-compensated, stable level at most companies. Not everyone should try to reach staff. The question is whether you want to, and whether you're building evidence toward it intentionally.

**What you own:** Multi-team technical problems. You're setting technical direction across teams, identifying problems that teams haven't recognized yet, and driving solutions that reduce future work org-wide.

**What you're expected to deliver:** Cross-team technical initiatives you initiated (not just executed), architectural decisions that affect multiple teams, mentorship of senior engineers, and demonstrated influence over org-level technical direction.

**Why this jump is hard:** The senior-to-staff promotion requires evidence across multiple review cycles, not just one strong quarter. The opportunities to demonstrate staff-level impact aren't always assigned — you often have to identify and create them. And many engineers make the mistake of doing staff-level work without making it visible to the people who vote on their promotion.

**What you own:** Engineering org-level technical strategy. You're solving problems that span the entire engineering organization — sometimes before those problems are widely recognized.

**What you're expected to deliver:** Technical roadmap input at the org level, cross-org architectural standards, mentorship of staff engineers, and a reputation as the person teams consult for the hardest technical decisions.

**Realistic note:** Principal engineering roles are rare. At a 500-person company, there might be 2–5 principal engineers. The path requires years of consistent staff-level impact, organizational visibility, and usually a specific domain where you've become the recognized expert. Distinguished Engineer and Fellow levels above Principal exist at very large companies (Google, Amazon) and represent the apex of the IC track.

The level frameworks above align most closely with mid-to-large tech companies. Smaller companies often compress the ladder: what counts as 'senior' at a 50-person startup might be mid-level at Google.

The practical implication: if you're leveled as Senior at a startup and want to move to a big tech company, you may enter at mid-level (L4–L5). If you're Staff at a startup, you might enter as Senior at Google. This isn't a demotion in compensation — big tech total comp often exceeds startup comp at equivalent experience — but it can feel like a setback in title.

Levels.fyi and Blind both have data on how levels translate across companies. It's worth checking before accepting an offer.