"but I’d like to see her taking on a bigger scope." - I’ve been hearing the feedback a bunch! And I’m curious what that actually means in this context.
To me, a bigger scope could mean making more impact by owning problems end-to-end: understanding pain points, aligning with PMs, designers, and engineers to drive a solution through to delivery. It could also mean leveling up the team and org overall - being that glue to helps others grow.
On the other hand, I’ve also seen “bigger scope” interpreted as chasing high-visibility projects - things like performance wins or shipping critical features that generate revenue. But that can also land people in the situation you described in this article, being the go-to person for X, and stuck there.
I’m wondering what's your take on this (maybe a topic for another article!) What are good questions could ask to better understand what “bigger scope” actually means when people say it.
Yeah, you’re right to be suspicious of “bigger scope” as generic feedback. It’s often a polite way of saying “do something different” without saying what or why.
When I hear leaders use that phrase, they’re usually mixing at least three ideas:
Owning bigger outcomes – not just doing tasks well, but picking a problem that matters and carrying it end-to-end (exactly like you described: from pain point → alignment → delivery → follow-through).
Holding more ambiguity – stepping into problems where the boundaries are fuzzy, stakeholders don’t agree, or the path isn’t clear, and still getting to a sane outcome.
Raising the team’s baseline – leaving systems and people stronger behind you, so the same type of work is easier next time and less dependent on you.
The mess happens when “bigger scope” gets translated into “go chase the most visible project,” which is how people end up as the performance person, the checkout person, the whatever person… and then get stuck there. That’s scope in the sense of “surface area of heroics,” not scope in the sense of “how much durable value and capability exists because you were here.”
If I were in your shoes, I’d go back with really pointed questions, for example:
When you say “bigger scope,” what outcomes do you actually have in mind? Can you name 1–2 types of problems you’d like to see me own end-to-end?
Where do you think I’m over-indexed on glue work vs shaping the problem itself?
If we were writing my promo packet a year from now, what concrete stories would you want to be in it that aren’t possible today?
Is the ask here to be on more visible projects, or to change how I work on the ones I already have?
Those kinds of questions help your manager to get specific: is this about business impact, complexity, people development, or just “be seen more”? And it also gives you a way to push back if “scope” is really just code for “please take on more high-stakes work with the same support structure,” which is exactly the trap I described in the article.
You’re right this probably deserves its own piece – “How to decode ‘bigger scope’ feedback” is basically a genre at this point.
I really like this approach - let's pair, ask questions and document our findings together. I've been doing the first two for a while, and I'm still building the habit of documenting learning.
"but I’d like to see her taking on a bigger scope." - I’ve been hearing the feedback a bunch! And I’m curious what that actually means in this context.
To me, a bigger scope could mean making more impact by owning problems end-to-end: understanding pain points, aligning with PMs, designers, and engineers to drive a solution through to delivery. It could also mean leveling up the team and org overall - being that glue to helps others grow.
On the other hand, I’ve also seen “bigger scope” interpreted as chasing high-visibility projects - things like performance wins or shipping critical features that generate revenue. But that can also land people in the situation you described in this article, being the go-to person for X, and stuck there.
I’m wondering what's your take on this (maybe a topic for another article!) What are good questions could ask to better understand what “bigger scope” actually means when people say it.
Yeah, you’re right to be suspicious of “bigger scope” as generic feedback. It’s often a polite way of saying “do something different” without saying what or why.
When I hear leaders use that phrase, they’re usually mixing at least three ideas:
Owning bigger outcomes – not just doing tasks well, but picking a problem that matters and carrying it end-to-end (exactly like you described: from pain point → alignment → delivery → follow-through).
Holding more ambiguity – stepping into problems where the boundaries are fuzzy, stakeholders don’t agree, or the path isn’t clear, and still getting to a sane outcome.
Raising the team’s baseline – leaving systems and people stronger behind you, so the same type of work is easier next time and less dependent on you.
The mess happens when “bigger scope” gets translated into “go chase the most visible project,” which is how people end up as the performance person, the checkout person, the whatever person… and then get stuck there. That’s scope in the sense of “surface area of heroics,” not scope in the sense of “how much durable value and capability exists because you were here.”
If I were in your shoes, I’d go back with really pointed questions, for example:
When you say “bigger scope,” what outcomes do you actually have in mind? Can you name 1–2 types of problems you’d like to see me own end-to-end?
Where do you think I’m over-indexed on glue work vs shaping the problem itself?
If we were writing my promo packet a year from now, what concrete stories would you want to be in it that aren’t possible today?
Is the ask here to be on more visible projects, or to change how I work on the ones I already have?
Those kinds of questions help your manager to get specific: is this about business impact, complexity, people development, or just “be seen more”? And it also gives you a way to push back if “scope” is really just code for “please take on more high-stakes work with the same support structure,” which is exactly the trap I described in the article.
You’re right this probably deserves its own piece – “How to decode ‘bigger scope’ feedback” is basically a genre at this point.
I really like this approach - let's pair, ask questions and document our findings together. I've been doing the first two for a while, and I'm still building the habit of documenting learning.