I once joined a team to help with “DevOps stuff.” It was a group of five or six good engineers - focused and busy. They had their habits, processes, and rituals, and everything worked more or less fine, except for the review process. They produced many changes but struggled to review them on time, which blocked other team members and caused tasks to drift from sprint to sprint without real progress. Certain patterns had emerged: some people checked PRs more often than others, while some only checked them on Friday evenings (a pointless time, as you usually don’t want to release anything then). Others only did so if explicitly demanded.
They had an idea: let’s create a sort of “review duty.” They had a spare TV nearby, so they published a small web page showing who should focus more on reviews that day. It improved the situation slightly, but eventually, they got used to the board and started ignoring it again.
We started thinking about something more engaging - something that would naturally motivate people to act and review at least a few PRs. We all appreciated sarcasm, so instead of referring to humble emotions like duty or dedication - the “usual motivational bullshit” - we leaned into a more powerful emotion: the shame!.
I built an application that used the Bitbucket API to scan all team projects for repositories and active Pull Requests. I sorted and grouped the list by developer. The final result was a list topped by the person lagging behind the most on reviews. We called it “The Wall of Shame”.
We loaded the page on the nearby TV and added an HTML refresh to reload it automatically every five minutes. Then, the game began!
It started even before the morning standup. No one wanted to be at the top when the team gathered. If you saw you were at the top and only needed two reviews to push the next person into first place, you would perform those reviews right before the meeting. When the team gathered, you would suddenly drop to second place 😈, and the next person was “blamed” for not keeping pace. People learned this pattern quickly. Soon, the second (and eventually third) person on the list would review one or two PRs before the standup just to avoid the top spot. The standup would start, the page would refresh, and the team would shout, “Shame! Shame!” before we all burst out laughing! 🤣
The team understood the intent, so despite the jokes and sarcasm, we took it with a smile. Like in a game of tag, we all ran away from the top spot.
Most best practices advocate for a “blameless culture”, but we did the opposite. We had strong enough relationships to be “blameful” and have fun with it. As a result, by the time the standup finished, many PRs had enough approvals to be merged. People were free to finish their tasks, and the bottleneck of waiting for others was removed.
Soon, we extended the board with another screen: Open PRs that were approved but not yet merged. Since the team received configuration changes or improvements from other teams, it happened a few times that everyone approved but forgot to actually merge and deploy. Having a board for “stale PRs” allowed us to quickly identify them during standup and ask: “What do we need to move this forward?” Often, it was just a matter of merging and deploying. This was our nod toward Kanban philosophy - limit work in progress, start finishing, and stop starting. There is no need to check this board constantly. Right now, we review it as a team twice a week, on Tuesday and Thursday, which is enough to ensure we don’t become anyone’s bottleneck.
I can’t share screenshots of the app since it was built as part of my corporate work, but “vibe-coding” something like this is trivial today. Some services might not even need a dedicated app. If you can create a proper query (GitHub allows this), it could just be a report that, when checked regularly, unblocks your team.
If “teamwork” isn’t motivating enough for you, “blame and shame” might just do the trick! 🤣
Enjoyed this post?
