Let's begin with a brief clarification for anyone who has never worked in software: git blame is a command that shows you, line by line, who wrote each piece of code in a file and when. It was designed as a debugging tool. You use it to understand the history of a file, to find context for a decision, to track down when a particular behaviour was introduced.
This is not how it is used in many software teams.
In many software teams, git blame is used the way a detective uses fingerprints at a crime scene. Someone pushes a broken build. The server goes down. The client calls. And somewhere in the office — or more likely, somewhere in a Slack channel — a senior developer runs git blame not to understand the code, but to identify the suspect. To find whose name is next to the line that killed production. To establish, for the record, that it was not them.
This is git blame culture. It is extremely common. It is also, by every available measure, catastrophically bad for the teams that practice it.
A Brief and Completely Fictional Scenario That Has Definitely Never Happened to Anyone Reading This
It is a Tuesday. It is always a Tuesday. The deployment went out at 4 PM because that is when deployments always go out, despite the fact that everyone agrees deployments should never go out on a Friday afternoon and Tuesday at 4 PM is essentially a Friday afternoon in disguise.
By 4:17 PM, something is wrong. The nature of what is wrong is unclear, but it is clearly wrong in a way that is affecting users, which means it is affecting the business, which means it is affecting the mood of people who are above you in the org chart.
By 4:23 PM, someone has run git blame.
By 4:31 PM, a name has been identified. The name belongs to a developer who wrote a function three weeks ago that touched, tangentially, a module that is adjacent to, but not directly responsible for, the current problem. This distinction will not be made clearly in the Slack channel.
By 4:45 PM, the incident has been resolved by someone quietly reverting a different commit entirely. The developer whose name appeared in git blame has spent twenty-two minutes explaining, in writing, a decision they made three weeks ago in a context that no longer exists, to people who are not going to read the explanation carefully because the incident is already over.
The post-mortem will note the root cause as “human error.” It always does.
Why Blame Culture Exists and Why It Persists
Blame culture in software teams is not the result of bad people making bad decisions. It is the result of a specific organisational incentive structure that makes blame feel rational — even necessary — to the people practicing it.
When something goes wrong in a software system, there is pressure from above to explain what happened and who is responsible. This pressure is often legitimate: stakeholders need to understand failures in order to prevent them. But the question “who is responsible” is interpreted, in blame-culture environments, as “whose fault was this” rather than “who has the most relevant knowledge about this system.” These are different questions with very different answers and very different implications for how the team behaves afterward.
The developer who is blamed for an incident learns, very quickly, to take fewer risks. To commit less frequently so there are fewer lines with their name next to them. To avoid touching unfamiliar code. To write defensive code that is optimised for “not obviously my fault” rather than “actually correct.” To never, under any circumstances, be the last person to touch anything that might break.
This is individually rational. It is collectively catastrophic. A team of developers optimising for “not being blamed” is a team that moves slowly, communicates poorly, accumulates technical debt, and produces systems that are fragile in ways that are nobody's fault and therefore everybody's problem.
What Google Found When It Studied This
Google's Project Aristotle, which ran from 2012 to 2015 and studied hundreds of teams across the company, set out to understand what made some teams more effective than others. The researchers expected to find that the answer was talent — that the best teams were simply made up of the best individuals. They did not find this.
The single most significant predictor of team effectiveness was psychological safety: the shared belief among team members that the team is safe for interpersonal risk-taking. That you can ask a question without being judged for not knowing the answer. That you can raise a concern without being dismissed. That you can make a mistake without being made an example of.
Psychological safety is, functionally, the opposite of blame culture. You cannot have both simultaneously. In teams with high blame culture, psychological safety is low by definition — because the evidence available to every team member is that mistakes result in public identification and accountability, which means the rational strategy is to hide mistakes, avoid risks, and make sure that when something goes wrong, your name is not the one that appears in git blame.
The teams with the lowest psychological safety, Project Aristotle found, were not the teams with the most individual mistakes. They were the teams where mistakes were hidden longest and cost the most when they finally surfaced.
What Blameless Post-Mortems Actually Are
The engineering organisations that have moved furthest from blame culture — Google, Netflix, Etsy, and others whose incident response practices are publicly documented — have replaced blame-oriented incident review with what they call blameless post-mortems.
The structure of a blameless post-mortem is deceptively simple. It asks: what happened, in precise technical and timeline detail? What conditions made this failure possible? What can be changed — in the system, the process, the tooling, the deployment pipeline — to make this failure less likely or less severe in future? It explicitly does not ask: whose fault was this?
This is not because blameless post-mortems believe no one is ever at fault. It is because the question “whose fault was this” is almost always the wrong question, and answering it almost never produces the outcome you actually want, which is a system that fails less.
John Allspaw, who developed much of Etsy's incident response culture, put it clearly: “We want to understand what happened, not who to punish.” The distinction sounds simple. In practice, making it requires actively resisting an organisational reflex that is deeply ingrained in most companies.
The Git Push vs Git Blame Divide
There is a useful shorthand for the two cultures: the git push culture and the git blame culture.
The git push culture ships things. It iterates. It accepts that pushing code means sometimes breaking things, and it builds systems — tests, staging environments, feature flags, rollback procedures — that make breaking things safe enough to recover from quickly. It treats the commit history as a shared record of a team's decisions over time, not as a ledger of individual culpability.
The git blame culture audits things. It is very good at establishing who touched what and when. It is very bad at shipping software, building trust, or retaining engineers who have better options — which, in most markets, is most engineers.
The irony is that git blame, as a command, is genuinely useful in the git push culture. You use it to understand context, to find the developer who wrote a function so you can ask them what they were trying to do, to reconstruct the reasoning behind a decision. You use it as a tool for learning. The problem is not the command. It is what the culture makes of it.
For the Engineers Who Know the Difference
The Git Push Git Blame T-shirt (India) and (International) — for developers who ship things, break things, fix things, and have the commit history to prove all three.
0 comments