What does it mean to not have enough scope to be promoted?

"Scope" is essentially a fancy word for technically challenging, high-impact projects.

To better understand how to evaluate scope, I highly recommend this Q&A from a Microsoft engineer on evaluating projects: "How to identify projects that are more suitable for senior engineers?"

So when an engineer says "I don't have a lot of scope", there are many different ways this can happen:

1. There are many projects, but there aren't a lot of projects with hard technical problems that also have good business impact (i.e. substantially affect whatever OKRs/KPIs your team has). The pool of projects is easy-to-do and/or low impact.
2. Your team just doesn't have many projects in general. This can happen on teams where shipping things is very hard (this is very common in Big Tech).
3. There are meaty projects with good scope, but they're all taken by existing senior/staff engineers on your team.

Here's some more concrete examples, with #1 being pretty real:

1. You work on Facebook feed, and your goal is to increase the number of reactions on posts. This product is literally one of the most optimized in the entire world, so your team runs 5 experiments each half, and they all fail to move metrics. You are effectively working on a solved problem, so there's not much scope.
2. You are a mid-level engineer looking to get promoted to senior. At your company, senior engineer means operating as a tech lead, owning and leading projects. Your team of 8 engineers already has 4 very well-established senior/staff engineers. There's really no opportunity to lead any project on your team as there's always already a lead on it given how senior your team is.

Most of the time scope means scale and complexity.

Scale has multiple aspects that are not software scale: time (Can you keep a 6-month goal on track?), team size (Can you distribute the work among 3 engineers and keep everybody on impactful work). If you can ship 1-month to 2-month projects without problem but find it hard to predict what's achievable in 6 months and then deliver that? (It has to be more impactful than repeating 1-month projects 6 times.) Can you lead a few junior engineers and create enough impactful work for them instead of just enough for yourself?

Similar for complexity. Once you involve more people and more moving parts the complexity may go up exponentially instead of linearly.

There's another way to look at it from the impact's perspective: Can you bend the curve of linear impact? If you can deliver the impact of n in a 1-month impact, can you deliver a lot more than 6n in 6 months? If a junior engineer can deliver the impact of m in a given time, can you lead 2 junior engineers and enable them to deliver a lot more than 2m in the same time?

There's a small chance that it's management bullshit (but I don't see the likelihood if you are in a Series C startup). In some of those big techs, when a manager fails to help you promote due the things out of your control (e.g. promotion quota due to budget limit), they have to tell you what to work on and improve next. However, you are supposed to be promoted already. What can they ask from you? That's when they need to bullshit you with vague concepts.

I really like Alex's answer -- another dimension is that people need to understand your scope (and this is often a distinct problem from attaining the scope).

If you're working on a project, it's your job to explain to your manager and teammates what work is involved, why it's important, and how it can benefit them.