[somsak2]

The thing is, for a junior engineer, this is not that bad of an idea. I don't think that it should be part of a formal performance process, but if you're green and aren't putting out enough PRs, it suggests you're either struggling to contribute, or putting out PRs that are far too large and need to be broken up to be easier to review & safer to deploy.

Think of it as a threshold. A high number doesn't suggest you're great. But a low number can often be a symptom of a greater problem.

[pcthrowaway]

I assume this suggestion only applies to big orgs where juniors can get a steady stream of small, well-scoped items to tackle.

At a lot of smaller orgs I assume it's harder to do this? Where I've worked, juniors often receive exploratory items that are lower-priority, and off the critical path, but they're expected to have reduced output, as well as asking for guidance as needed from more senior members.

Perhaps this is a failure of planning (which would have been my own failing as a lead at times), as well as management

[jiveturkey]

> steady stream of small, well-scoped items to tackle

Yes. The part of the quote parent left out is

> or the ability to close Y story points per sprint

With that in mind, it makes sense and the metric is dependent on the entire org functioning well. So to the extent it does so, this is an objective, very quantifiable, metric that all junior engineers can be compared with.

That said, this is a guide for startups. So I do believe this metric is garbaj. Junior engineers will be unfairly held to task for org dysfunction.