Push and Pull

&gt; You should review PRs, you should review them in a timely fashion. You should, you should, you should. That’s all Push. Any wonder that so many teams struggling with PR dwell time?<p>The problem with this is nobody is performance managed on PR reviews. Features are often what get put on performance reviews, so it becomes beneficial to the PR author to go work on another feature than review someone else’s PR. Reviewing a PR for a feature doesn’t get your name attached to it. More often than not, your review is considered a formality imposed by upper management and impediment to the feature in the eyes of line managers. Those headwinds turn PRs into a classic Volunteer’s Dilemma [0].<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Volunteer&#x27;s_dilemma" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Volunteer&#x27;s_dilemma</a>

Kanban would help, with max tasks in progress for team and PR being a task.<p>Now you can’t do a new thing you have to take the PR!

I don’t really understand the pull. It sounds like push is the shoulds and pull is the musts. As far as I understand it, push is the ‘do X’, pull is the ‘hold accountable when they don’t do X, or praise when they do’.<p>But these seem as two sides of the same coin, not as orthogonal concepts.

Those async status updates really hit home as an example. This was a good, quick one and something I&#x27;m going to put some attention towards in the future.