git blame culture, metaphorically

Software engineers rely on a tool called git to manage changes to their code — git makes it easier for many engineers working on the same set of files to all make their changes without losing work, among other things. For engineers, a common task when working on large, shared codebases is to run a command called git blame. This command tells you who made the last change to each line of a file, like this:

git blame some_file =>

a9b531b1 (David Colby 2022-05-13 20:26:44 -0500  20) def wild_method
a9b531b1 (David Colby 2022-05-13 20:26:44 -0500  21) do_something_wild
a9b531b1 (David Colby 2022-05-13 20:26:44 -0500  22) end

With one command, I can learn who is responsible for each line of code, when they made the change, and using that random string of numbers at the beginning I can even see everything else that changed at the same time that line changed. Incredible power.

git blame is a wonderful tool for collaboration on larger teams and is even useful if you are working on a codebase alone. Six months from now, you may not remember why you wrote that weird line of code at 2am. git blame gives you a simple way to see the full set of changes in context and, if you’re diligent about writing clear documentation you might even have a nice explanation of what you did and why attached to the changeset.

git blame is a tool for good, when used for good.

It makes it easier for teams to learn about the history of a project, identify who is most likely to have context for a question you have or a bug that has been uncovered, and it helps you and your team collaborate more effectively.

git blame is also a tool for literal blame. We can use it to find out who made a change that caused a bug so we can point the finger at them for failing. In some engineering cultures, the most important use of git blame is to figure out who to be mad at for the latest outage or poorly executed feature.

Blame culture

Outside of code, we don’t always have such an obvious tool for assigning blame, but in a culture determined to assign blame to individuals, a metaphorical git blame is usually close at hand.

When a problem occurs, blame cultures look for a person to pin it on. The root cause is a person who should be punished for a mistake, and if we remove that person, we no longer have the problem they caused. This sounds silly when we write it down out of context — who would take such a surface level approach to resolving organizational issues? — but is a basic operating principle for many companies.

Blame culture is often rooted in leaders that:

• Avoid difficult conversations
• Look for easy answers
• Are insecure in their own abilities

A blame culture stifles innovation and risk-taking. Employees shift into self-preservation mode as they see teammates blamed for taking a risk on a challenging project. Creativity disappears as boundary pushing work is replaced with easy-to-deliver work, even when that work is unimportant to the business. Problems that could be fixed by better systems occur repeatedly because root cause analysis always points to a person rather than a process.

Over time, a blame culture falls behind competitors. Ambitious high-performers are chased out or leave on their own for opportunities with more growth potential. Product innovation grinds to a halt, and new features are always shallow copies of something a competitor did first. Communication suffers and trust between teams drops as team members circle the wagons to protect each other instead of reaching out to help everyone grow. No one has any fun in a blame culture.

Addressing blame culture requires tackling the root cause at the leadership level. If you have built a culture of blame, the only person you have to blame is yourself — and it is up to you to fix it.

From blaming to learning

When something goes wrong — say, a critical bug hits production or a project delivery deadline is missed — the conversation that follows must be focused on learning and improving, not assigning blame.

Why did that bug get to production? What can we do to make our systems more resilient? Why did we miss the delivery deadline, and how can we more closely align development timelines with business expectations?

At each phase of the conversation, our aim is to learn. To do this we must create psychological safety for the team. They have to be able to speak openly and honestly about issues so we can understand the root cause of the issue and design effective systems to avoid the same issue in the future.

As leaders, this means asking thoughtful questions, listening more than we speak, having empathy for each member of the team, and ensuring that blame is not part of the conversation. Feedback should be shared when an individual needs to change a behavior or take a different action, but that feedback is secondary to learning and improving for next time.

Plenty of tools and frameworks exist to help guide these conversations, but to begin you don’t need a new framework or some heavy, frustrating AAR process. Instead, start with a mindset shift.

When something goes wrong, your job as a leader is to guide your organization’s response to the issue towards an adaptation that will protect against that issue in the future. To do this, you must understand the root cause of the issue (not a person!) and identify a process, system, or behavior change that will make your organization more resilient against that issue.

This doesn’t take a huge framework, giant document templates, or multi-hour meetings. Often, it starts with a simple conversation with the people closest to the issue to understand what went wrong and hear their thoughts on what should have been done differently. If you approach this conversation with empathy, ask good questions, and listen more than you speak, you may be surprised at how much you can learn in a short period of time.

If you’ve built a culture of fear, and a reputation for blame, you will find that you have to humble yourself, own past mistakes, and work very hard to pull the right information from your team the first few times you have these conversations. There is no getting around that, and there is no getting around the fact that in long-running blame cultures, some people will never fully let their guard down and approach the work with their learning hat on.

All of that first requires the most important change, and one that can only come from within. You have to put your own ego and insecurities aside and approach each new problem with a goal of learning and growing, not shifting accountability.