The scope ladder

Promotion is mostly a story about scope. Titles track how large a problem you can be trusted with, how little clarity you need to start, and how far your decisions ripple. Years of experience and lines of code are weak proxies.

The engineer who still waits for well-specified tickets after three years is stuck at junior scope. The engineer who finishes a multi-week feature, then asks what painful problem the team should tackle next, is already practicing SDE2.

The four rungs

Each rung widens the radius of what breaks if you disappear for two weeks.

The jump from task to feature is mostly autonomy: you take a product intent and turn it into a plan. Feature to project is ownership of outcome: you care about launch, metrics, and follow-through, not just your PRs. Project to multi-team problem is influence: you move people you do not manage. That last rung is the heart of SDE3.

Walking through a jump

SDE1 → SDE2. Before: you pick up "add export to CSV" from the backlog. A senior sketched the API. You implement, write tests, address review, ship behind a flag your mentor configured.

After: you notice support tickets about "can't get my data out." You propose CSV export and a rate-limited async job for large accounts, write a one-page design, agree metrics with the PM (export success rate, p95 job time), implement with a staged rollout, and send a launch note with dashboards. You still write most of the code — but you owned the outcome.

The difference is not difficulty of the TypeScript. It is problem selection, design, rollout, and communication.

SDE2 → SDE3. Before: you migrate one service to the new auth library, hit the deadline, write the runbook.

After: three teams are stuck on auth migrations. You draft a shared playbook, run a design review that sets the standard, build a small compatibility shim, and coordinate a sequenced rollout. You write less of the total code. The org-level problem moves because of you.

Common mistakes

• Confusing effort with scope. A hard bug can still be a task.
• Calling a pile of tickets a project. A project has an outcome, milestones, and a finish line.
• Jumping to multi-team meetings without finishing a project. Influence without delivery is theater.
• Waiting to be tapped. Scope is proposed, contracted, and finished — not assigned by magic.

Check yourself

1. You shipped a well-specified CSV export. Which rung was that? A task or a thin feature. SDE2 scope starts when you own the problem, design, rollout, and metrics.

2. What changes from project to multi-team problem? You move people you do not manage. Alignment and a shared path matter as much as your PRs.

Key takeaways

• Scope is the main axis of level: task → feature → project → multi-team problem.
• Each jump adds autonomy, then outcome ownership, then influence.
• SDE1→SDE2 is owning a feature outcome. SDE2→SDE3 is owning a problem that crosses teams.
• Finish a rung before you perform the next one.

Further learning

Next, find work that is worth that scope in high-leverage work.