You can solve any problem in an enterprise setting by assigning it to the team that is not in the meeting.

You can potentially extend this to settings other than meetings, as long as you get agreement with the rest of the participants that the problem sits with team X.

There are certain quorum criteria that you need to meet, depending on the size of the problem. For instance, a problem that requires a quarter's worth of work from team X, might require at least 2 different teams to agree, a 2 out of 3. Of course this isn't really solving any problems, it's assigning blame. But you can pretend it's problem solving, as you have one less problem to solve. That's how a lot of the problems are "solved" today. You pass them to someone else, and as long as you've achieved some form of consensus, your team can be successful.

I call this the enterprise problem solving law.

If the most efficient way for a team to "solve" a problem is to assign it to another team, they will do.

Problems are "solved" not by direct action but by strategic reallocation.

Here's a couple of examples of how this works in practice.

You're part of an application team that wants to integrate with the central identity provider. You're in a meeting with the identity team but can't figure out a way to integrate. The tooling team is missing from the conversation. You're in luck because that's exactly what the tooling must add to their remit, and immediate roadmap. The tooling team just became the blocker and the actual problem solver.

Or maybe you're part of the vulnerability management team. You're in a meeting with the platform team to identify why you're not making a dent on your vulnerability metrics. The application team is missing from the meeting. The platform team insists that the majority of the vulnerabilities originate from dependencies that are the within the application team's remit.

No one communicated or agreed with the application team that this is within their remit. But, you've achieved consensus, the problem is solved. After all ignorantia juris non excusat, you proclaim happily.

Anthropology has a lot to teach us about this behaviour. Mary Douglas has just the quote from Risk and Blame ¹.

If you want to cast blame, there are always loopholes for reading the evidence right. Science has not produced a run of people who don't wish to dominate one another.
-- Mary Douglas

In other words: "it comes natural to some humans to pass blame", and there are common reasons to it.

For starters, negative experiences. The brain responds more strongly to bad experiences than good ones and retains the memory of bad experiences longer. There's a ratio that depends on your mental health, emotions and age. The ratio between positive and negative effects is three good experiences for a negative experience ². Assigning direct blame, without constructive outcomes, leads to negative experiences, which leads to more blame. Criticism and reprimanding naturally make people averse to taking responsibility.

This negative feedback loop starts to form, where staff see themselves and other teams as cogs in the machine as opposed to human beings. "It's that other team of faceless people that I never interact with that are to blame, I acknowledge non of their circumstances, and have no incentives to understand them". This is called the Knobe effect ³. We perceive the goodness or badness of the actions of other people based on the intentions' of the people who took the action. Obviously when it comes to the "faceless people that I never interact with", their intentions are bad.

As a result organizational chaos ensues. Confused roles and responsibilities within the organization contribute to its blame culture, and solidify through the organisation's communication structures. Assigning blame becomes the modus operandi of teams. Blame in modern organisations takes many forms.

We've started to acknowledge that blame culture is toxic ⁴. If you're in tech, you might have heard of blameless postmorterms ⁵. Worth noting that in sectors like aviation and patient safety another methodology is currently being promoted, just culture ⁶. In this form, the analysis starts with identifying intent.

Like the Knobe effect mentioned above, and unlike blameless postmorterms, an assumption that everyone involved has good intentions is not the default position of the analysis. Just culture aims to start by identifying whether there was gross negligence or malice, in order to identify further actions.

Perhaps the most common misconception in tech, is that Root Cause Analysis (RCA) ends in a single node. Notice the singular form of cause. No matter whether we try to operate within blameless, just culture, or otherwise, the belief that there is a single source of all that is to blame. Perhaps the word "root" is to blame 😉 .

"It's always DNS" is a common adage in RCA, but is it only DNS. Dekker talks about causal meshes and webs. "A root is simply where you stop looking any further".

Cause is not something you find. Cause is something you construct. How you construct it, and from what evidence, depends on where you look, what you look for, who you talk to, what you have seen before and likely on who you work for.
-- Sidney Dekker

Combining Dekker's ⁷ and Douglas' understanding of RCA, and blame, respectively, we can be confident in saying that if you want to cast blame, you must be able to assign the root cause. In the examples above, the teams did exactly that. They assigned the root cause of the issue, blocker, vulnerability, etc. to another team.

They transformed a problem, into a root cause. Not many root causes, just one, that other team, and in certain organisations we allow this to be the most efficient way of solving a problem.