# Blameless Culture

Published articles for Blameless Culture.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Using a Bitbucket Dashboard Game to Improve Pull Request Reviews

DevFeed: [Using a Bitbucket Dashboard Game to Improve Pull Request Reviews](<https://devfeed.tech/articles/the-wall-of-shame-27745.md>)

Original publisher: [Read original article](<https://gagor.pro/2026/04/the-wall-of-shame/>)

Author: Tom

Published: 2026-04-19T00:00:00Z

Content type: opinion

Language: en

Sources: [Tomasz Gągor](<https://devfeed.tech/sources/tomasz-gagor.md>)

Topics: [pull-requests](<https://devfeed.tech/topics/pull-requests.md>), [bitbucket](<https://devfeed.tech/topics/bitbucket.md>), [DevOps](<https://devfeed.tech/topics/devops.md>), [App](<https://devfeed.tech/topics/app.md>), [Web](<https://devfeed.tech/topics/web.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [best-practices](<https://devfeed.tech/tags/best-practices.md>), [bitbucket](<https://devfeed.tech/tags/bitbucket.md>), [blameless-culture](<https://devfeed.tech/tags/blameless-culture.md>), [developer](<https://devfeed.tech/tags/developer.md>), [devops](<https://devfeed.tech/tags/devops.md>), [gamification](<https://devfeed.tech/tags/gamification.md>), [html](<https://devfeed.tech/tags/html.md>), [kanban](<https://devfeed.tech/tags/kanban.md>), [people](<https://devfeed.tech/tags/people.md>), [pr-reviews](<https://devfeed.tech/tags/pr-reviews.md>), [productivity](<https://devfeed.tech/tags/productivity.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>), [review](<https://devfeed.tech/tags/review.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>), [team](<https://devfeed.tech/tags/team.md>), [team-culture](<https://devfeed.tech/tags/team-culture.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

A team struggled with delayed pull request reviews that blocked colleagues and caused work to drift between sprints. They built a Bitbucket-based dashboard that ranked developers by outstanding reviews and displayed it on a shared TV, using humor and social pressure to encourage the team to review pull requests before standup.

### Source excerpt

A story of how a team used "The Wall of Shame" to turn a bottlenecked PR review process into an engaging game.

## How to run postmortems effectively?

DevFeed: [How to run postmortems effectively?](<https://devfeed.tech/articles/how-to-run-postmortems-effectively-28868.md>)

Original publisher: [Read original article](<https://medium.com/volvo-cars-engineering/how-to-run-postmortems-effectively-9c6a7d521174?source=rss----4eed8113139---4>)

Author: Peter Bergman

Published: 2024-09-17T08:49:33Z

Content type: tutorial

Language: en

Sources: [Volvo Cars Engineering - Medium](<https://devfeed.tech/sources/volvo-cars-engineering-medium.md>)

Topics: [incident](<https://devfeed.tech/topics/incident.md>), [systems](<https://devfeed.tech/topics/systems.md>), [context](<https://devfeed.tech/topics/context.md>)

Tags: [blameless-culture](<https://devfeed.tech/tags/blameless-culture.md>), [errors](<https://devfeed.tech/tags/errors.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [incident](<https://devfeed.tech/tags/incident.md>), [mistakes](<https://devfeed.tech/tags/mistakes.md>), [organization](<https://devfeed.tech/tags/organization.md>), [outages](<https://devfeed.tech/tags/outages.md>), [postmortem](<https://devfeed.tech/tags/postmortem.md>), [postmortem-documentation](<https://devfeed.tech/tags/postmortem-documentation.md>), [postmortem-report](<https://devfeed.tech/tags/postmortem-report.md>), [processes](<https://devfeed.tech/tags/processes.md>), [retrospective](<https://devfeed.tech/tags/retrospective.md>), [retrospectives](<https://devfeed.tech/tags/retrospectives.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [systems](<https://devfeed.tech/tags/systems.md>), [teams](<https://devfeed.tech/tags/teams.md>)

### AI overview

This article explains how to conduct effective, blameless postmortems after incidents such as outages, production bugs, or service disruptions. It emphasizes identifying root causes, examining systemic factors and context, and improving processes rather than assigning individual blame.

### Source excerpt

Incidents are inevitable. As we all know, system outages, bugs in production, or service disruptions, can all have significant impacts. When that happens, the company pays the price. It's better to see it as a chance to learn instead of pointing fingers. This is where postmortems come into play. A postmortem, also referred to as an incident analysis, or retrospective, is a vital practice for understanding what went wrong, why it happened, and how to avoid such occurrences in the future. Understanding postmortemsWhat is a postmortem and why is it important? An incident postmortem is a review process carried out after an incident. Its purpose is to determine the root causes and identify strategies to avoid similar future incidents. What does blameless mean? In a blameless postmortem, the emphasis is on learning from mistakes and improving processes, rather than pointing fingers. By focusing on systems, components, roles, processes, procedures, and not individuals, we can foster a blameless culture where teams feel safe to openly discuss incidents and contribute to meaningful solutions. The aim here is to reframe the discussion to focus on the systemic factors that contributed to the incident which let teams uncover deeper insights and implement more effective solutions. What about the human factor? Even though many incidents can be attributed to being caused one way or the other by humans, due to the human factor, so to speak, it is important that we aim to shift the conversation towards understanding the "second stories" behind the incident. The "first story" of human error focuses on individual mistakes, while the "second story" examines the systemic factors contributing to errors. To do so, we focus on the underlying factors and context that may not be immediately apparent. Through the use of "second stories", human error is seen as the effect of systemic vulnerabilities deeper inside the organization. If we assume that all actions are made in good faith, then what