So Your Manager Said “You Need Bigger Scope”

How to decode the feedback, reshape your work, and get credit for the problems you already own

So your manager just told you “you need bigger scope” and then moved on to the next topic. You walked out of the room thinking: I’m already drowning in work, what does this even mean? I’ve been on both sides of that conversation in perf and promo cycles – as an IC told “you’re not operating at Staff scope yet,” and as a manager trying to compress a messy calibration into a single sentence of feedback that sounds actionable but is really a shortcut.

Most of the time, scope is a placeholder. It’s a word we use when we’re reacting to a pattern but haven’t done the hard work of naming it. For ICs, that makes scope feel slightly mystical and out of reach. Some blend of “be more senior,” “do bigger things,” and “have more impact,” while still shipping your current backlog and not dropping any balls. I used to take that kind of feedback as a character judgment: maybe I don’t think big enough, maybe I’m just a solid mid-level engineer who happens to have a Staff title. Over the years, after sitting through enough promo committees and calibration meetings, I stopped treating scope as an identity label and started treating it as a description of the problems you’re trusted to hold.

As you move from mid-level to senior and Staff+, your company quietly changes the job on you. Earlier in your career, the game is simple: take a defined problem, do solid work, don’t blow anything up. The unit of work is a ticket, a story, a feature, a clear slice of analysis. Past a certain point, the expectations shift. The question becomes: can you be trusted with problems that are fuzzy, cross-cutting, politically sensitive, and important enough that leaders lose sleep over them? That shift is what people are trying to point at when they say “scope,” even if they don’t have the language for it.

When managers and promo committees talk about scope they’re usually blending a few dimensions in their heads. They’re looking at outcomes: what results you’re accountable for, and how much they matter to the business. They’re thinking about ambiguity: how clear the problem is when it lands on your desk, and how much shaping has to happen before the work is even ready for a ticket. They’re watching risk: what can go wrong if you make a bad call, or if the work fails in production, or in front of a regulator, or on a key customer account. They look at time horizon: are you solving next quarter’s problems, or shaping the next one to three years. They pay attention to coordination: how many teams, disciplines, or systems have to move together for this to work. They notice stakeholders: who cares about this work – your squad, your org, senior leaders, partner teams, regulators. And they look at systems: are you touching one service or flow, or the shape of a whole platform or product area.

Most senior IC rubrics in engineering, product, design, and data are some remix of these ideas. At Staff levels and beyond, scope is less about how many things you ship and more about how consequential the problems are that you reliably take from fuzzy idea to stable reality. That’s helpful to understand conceptually. The trouble is that when it shows up as “you need bigger scope,” it still doesn’t tell you what to do on Monday.

From an IC seat, that sentence often lands in two unhelpful ways. First, it sounds like “just do more.” You’re already maxed out. Being told to “take on more scope” can sound like “be 120% as productive, with the same support and the same constraints.” Second, it’s underspecified. No one tells you which dimension of scope is missing. Are you too focused on near-term execution? Are you avoiding ambiguous problems? Are you only owning slices of projects instead of end-to-end outcomes? The default reaction is either shame – I’m not senior enough – or confusion – I don’t know what they want from me. Neither reaction helps you grow.

A more useful approach is to treat scope as a diagnostic clue rather than a verdict. Over time, I started to hear “you need bigger scope” as a family of more specific messages. When a manager uses that phrase, it often maps to one or more recurring patterns.

Sometimes it means you own tasks, not outcomes. You reliably deliver your tickets, designs, or analyses, but someone else is holding the end-to-end customer or business outcome. You’re seen as contributing to important work, not owning it. Your name shows up all over Jira, but when people talk about who owns the result, they name your manager, your tech lead, or the project lead.

Sometimes it means you avoid messy, ambiguous problems. You do great once the problem is defined. Your design docs are clean, your execution is solid, and you hit your dates. But you’re not the person people call when something is unclear, cross-cutting, or politically touchy. When a senior leader says “we need to fix onboarding; customers keep dropping,” that problem quietly routes around you and lands on someone who is known for shaping vague problems into concrete work.

Sometimes it means your work is too local. You’re doing good work inside your immediate team or service, but it doesn’t change much outside that boundary. Other teams don’t feel your impact. If your project vanished, only your squad would notice. In calibration, your manager struggles to explain how your work affected anything beyond your lane.

Sometimes it means you don’t change the trajectory. You improve the quality, stability, or speed of work that was already going to happen. You close gaps, fix bugs, refactor messy code, tighten up specs. All of that is valuable, but you rarely originate or reshape the work so that the overall trajectory of a product, system, or metric is meaningfully different. Leaders don’t see a before-and-after story tied to you; they see incremental improvement.

Sometimes it means risk lives above you. When a decision has regulatory, financial, or reputational risk, the call is always made by someone more senior. You’re consulted, you do the analysis, you write the doc, but you’re not the accountable owner. When things go well, you’re thanked for your help. When things go badly, your manager is called into the meeting.

Sometimes it means you’re stretched thin but not concentrated. You’re helping on many things, often as the fixer or the one who unblocks others. You parachute into incidents, do quick reviews, patch things up. But because your effort is fragmented, nothing with your name on it shows up as a clear, consequential outcome. People know you’re useful; they don’t see a big bet that you own end-to-end.

And sometimes it means leaders don’t think of you for the next big thing. When leadership allocates the next hairy problem or high-visibility bet, your name doesn’t come up. Not because you’re not capable, but because you haven’t yet built the pattern of owning and winning at those kinds of problems. In conversations about who should run a critical migration or lead a risky redesign, you show up as “strong support” rather than “primary owner.”

None of these patterns feel good to read. I’ve been in several of them. The upside is that each one suggests a different set of moves. The job is to figure out which one fits your situation, with as much honesty as you can manage.

You don’t have to decode this alone. Your manager might not have perfect clarity either, but you can pull them into sharper thinking. In your next 1:1, instead of asking “how do I get bigger scope,” ask them to look at specific work. For example: when you say “bigger scope,” can we get concrete about where you already see me at the right level and where you see the gap to the next one. Or: if you look at the last 6–12 months of my work, which projects felt like the right scope for a senior engineer or PM, and which felt too small or narrow. What’s the pattern.

You’re aiming for stories, not slogans. Calibration and promo discussions are full of phrases like “Staff-level scope” or “principal-level impact.” Underneath those phrases are real events: launches, outages, audits, strategic shifts, customer escalations. Your goal in that 1:1 is to get your manager to replay those scenes and place you inside them. That gives you something you can actually work with.

One exercise I give people I coach is very simple. List your top three to five projects from the last year. For each one, write a line or two on the scope dimensions: what outcome were you on the hook for; how ambiguous was the problem when you started; what was the risk profile; what time horizon did it affect; how many teams and systems were involved; who were the key stakeholders. Then compare that list to your level rubric, and if you can, to example promo packets at the next level in your org. Look for two things: your median scope, which is what’s typical for you, and your most frequent scope pattern. When I sit in promo meetings, that median and that pattern matter far more than your single biggest win.

Company context warps all of this. Scope is not an absolute quantity; it’s relative to the company’s size, structure, and risk profile. At a big company like Amazon, you can work on a single service whose customer and revenue impact would count as a whole business at a startup. On paper that looks huge. In practice, your day-to-day might still be narrowly framed if you’re only tweaking small pieces of that system. In large, regulated environments like fintech, health, or aviation, risk and stakeholders matter a lot. Owning scope often means owning the relationship with risk, compliance, or legal partners and being trusted to navigate them without babysitting. In FAANG-scale product orgs, coordination and systems tend to be the bottleneck. Bigger scope might mean taking on a cross-team migration, a shared platform that many teams depend on, or a multi-year vision for a product area. In earlier-stage companies, time horizon and outcomes often dominate. A Staff IC might own a whole problem space end-to-end – discovery, design, build, launch, iterate – because there’s no one else to catch the pieces.

When someone says “you need bigger scope,” you can quietly ask yourself: bigger in which of these dimensions, relative to the way this company actually works. That question alone will keep you from chasing abstract bigness and will steer you toward the parts of scope that matter where you are.

Once you have a sense of the pattern, you can make moves over a three to six month window that grow your scope without turning you into a martyr. One move is to shift from feature ownership to problem ownership. Stop framing your work as “I own Feature X” and start framing it as “I own Problem Y for Customer Z.” That small shift changes who you talk to, what metrics you watch, and how you make tradeoffs. Another move is to volunteer for one ambiguous, cross-cutting problem. Not five. One. Pick something like stabilizing a flaky area that spans services, rationalizing a confusing part of the UX that touches multiple surfaces, or untangling a recurring incident pattern.

You can also start taking the first pass on defining the work. When a vague request comes down from leadership, offer to draft the problem statement, the success metrics, and a couple of options. Senior scope often starts with being the person who can turn “we should fix onboarding” into a concrete plan others can inspect and refine. At the same time, concentrate your impact. If you’re spread across many efforts, work with your manager to consolidate. Ask which one or two bets this half, if they go well, would clearly demonstrate Staff-level scope for you. Then be intentional about saying no to other nice-to-have asks that would dilute that.

Another powerful move is to own the risk conversations. Instead of escalating risk for others to solve, show up having already mapped the risks, proposed mitigations, and made a recommendation. Over time, people start to trust you with hairier decisions. And as you do all of this, narrate your scope. Don’t assume people see the size of the problems you’re holding. Use status updates, design docs, and 1:1s to make the scope visible: the cross-team decisions you’re steering, the tradeoffs you’re holding, the future impact you’re designing for. That’s not bragging; it’s creating an accurate shared picture of your role.

When you write promo packets or self-reviews, skip the vague claim “I took on bigger scope” and show it instead. Anchor your stories in the same dimensions. Describe the outcomes: what you owned end-to-end, how many customers or systems it touched, what changed in the metrics. Describe the ambiguity: how fuzzy things were at the start, what you did to clarify the problem space. Describe the risk and the stakeholders you carried, the time horizon you were shaping, the coordination and systems you orchestrated. Then explicitly connect those examples to your level rubric so the reader can see that your median and most frequent scope have already moved to the next level, not just one lucky project.

For me, the big unlock was stopping the habit of treating scope feedback as a judgment on my worth. When I heard “you need bigger scope,” I used to translate it to “you’re not actually Staff; you’re just pretending.” That mindset made me defensive and quietly anxious for years. Over time, with some help from managers and peers who were honest with me, I started treating scope as a design problem instead. Given my skills, interests, and the current state of the org, how can I shape my portfolio of work so that my median and typical scope match where I want to be.

Seen that way, scope becomes something you and your manager can design together. You have real constraints: reorgs happen, roadmaps change, leaders rotate, market shocks hit. Luck and timing always play a role. But you have more influence than you think over the shape of the problems you hold and the way they’re perceived. Once you stop treating “you need bigger scope” as a mysterious curse, you can start treating it as an invitation to redesign the work so that it grows you and moves the business at the same time.