Main idea

When a Product Manager opens a pull request on the main product, review stops being a technical check between peers. It becomes the place where the organization states what it agrees to receive, from whom, and on what perimeter: the contribution is reviewed, accepted, corrected or rejected, and that verdict is the only real limit placed on the widening of roles.

A rejection then carries information with three possible readings, and nothing in the pull request itself says which is the right one. The person may not have the level for this type of contribution. The subject may be too risky to be opened up. Or the engineering team has not yet laid down the guidelines, tools and guardrails that would let other profiles contribute safely — and it is that third reading that gets forgotten, because it puts the people doing the rejecting in question.

Repeated rejection therefore reads as a signal about the organization, not only as a judgment on a contribution.

Why it matters

It shifts a debate of principle — "can a PM push to production?" — onto an existing mechanism, already tooled, already traced, that settles things case by case without any general rule having to be written.

And it gives an observable indicator to a team that wants to open up contribution: the rate and the grounds of rejection say where the opening actually stands, independently of stated intentions.

Nuances and limits

An implicit governance mechanism is still a mechanism without a mandate: reviewers arbitrate questions of perimeter and risk without having been asked to, and without their decision being contestable anywhere else.

And review only sees what is submitted to it. Whatever was built outside the repository — an internal tool, an automation, a dashboard — escapes this control entirely.

Open questions

• Where do you discuss a rejected contribution when review is the only place the decision was taken, and review is not a place for organizational debate?