Career & Leadership › Career Growth
Scope
How big and ambiguous the problems you own are.
Also known as: scope, engineering scope, scope of impact, level of scope, scope and seniority
Scope is how big, how ambiguous and how far-reaching the problems you own are. It’s one of the clearest ways to understand levels in engineering careers: higher levels are less about writing more or harder code, and more about taking on larger problems with more uncertainty and wider effects.
A rough ladder of scope
| Typical scope | Looks like |
|---|---|
| A task | A well-defined piece of work: “add this field”, “fix this bug” |
| A feature | Design and deliver a feature end to end, including edge cases, testing and rollout |
| A project | A multi-week effort with several components, involving other people and coordination |
| A system or area | Long-term ownership of a service or domain: its roadmap, reliability and health |
| Multi-team / cross-cutting | Problems spanning teams: shared platforms, migrations, standards, technical direction |
| Organization or company-wide | Strategy and architecture with broad, long-lasting consequences |
Companies label their levels differently, and the boundaries blur. Look at the kind of problems a person is trusted with (career ladder, senior engineer, staff engineer).
What increases with scope
- Ambiguity: from “do this” to “figure out what we should do” (handling ambiguity).
- Time horizon: from days to quarters and years.
- Number of stakeholders and need for influence without authority (influence without authority).
- Impact and risk, along with the consequences of wrong decisions (impact).
- Reliance on others: more of the outcome comes from aligning and enabling people, not your own typing (glue work).
How to grow your scope
- Do your current scope reliably. Trust is the currency for larger problems (ownership).
- Look beyond your tickets: what’s the problem behind the feature? What’s hurting the team (flaky tests, slow deploys, confusing docs)? Fix or propose fixes.
- Take on ambiguous or cross-cutting work when it appears, and ask for it.
- Write designs and drive decisions, not only implement them (design docs).
- Mentor and unblock others, making the team better (mentoring).
- Communicate impact so your growth is visible (brag document).
- Talk with your manager about the scope expected for the next level, and where you can get it.
Cautions
- Scope isn’t headcount or title. It’s about the problem and outcome. A big team doing low-impact work isn’t large scope.
- Bigger isn’t always better for you, since different people thrive at different scopes and some choose depth over breadth (IC vs manager, generalist vs specialist).
- Don’t take scope you can’t carry. Over-committing without support leads to dropped balls and burnout.
- Scope without results isn’t impact. Delivering on large problems is what matters.
When you wonder what “senior” really means, ask: what size and fuzziness of problem can I be trusted to take to a good outcome, with little guidance?