Etude · The anti-cascader
Pull vs push
You are the team lead. Two ways the same migration shows up in your week.
You lead a Java service team. Eight engineers, your own roadmap, your own oncall. The platform team's "Spring Boot 3 migration" is on the company-wide tracker.
It can show up in your week one of two ways. Walk through both.
Side-by-side
Scenario A · push
- TriggerPlatform team's deadline
- AuthorBot account, no in-team context
- Cognitive loadHigh — context-acquisition by reviewer
- Risk ownerWhoever clicks merge
- PacingExternally imposed
- Outcome at month 6Half-merged, long tail, escalation
Scenario B · pull
- TriggerYour engineer's clock
- AuthorYour engineer (with bob's help)
- Cognitive loadLow — explanation arrives with diff
- Risk ownerThe team that wrote the code
- PacingTeam's own clock
- Outcome at month 6Done; team learned the migration
The diff is identical. The codemod is identical. Only the load-bearing arrow flipped.
Why pull works
Push fails because the team that owns the code didn't author the change. They don't trust the diff and they can't pace it. The PR sits in the queue with no one whose job it is to push it through.
Pull works because the team is the agent. The team's engineer ran the codemod, watched the diff, ran the tests, opened the PR. The merge confidence is first-person. That confidence is what closes the long tail.