Skip to main content

How Good Are You At Blamestorming?

Blamestorming is a well-known game IT organizations spend hours playing every week. There are different leagues and names for this game. Some call it the "war room", others the "service restoration call", but they basically follow the same simple rules. The goal of the game is to figure out the origin of an IT service degradation issue and collectively identify the one person — or the team — to blame for it, then hold them responsible for the resolution and the business consequences.

It often occurs in the form of a meeting, where the players meet in a conference room or on the phone.

The game usually starts with an IT performance degradation that impacts your most critical business applications. The cause, and this is important, should not be obvious; nothing in plain sight like a load balancer or a web server being down.

And there are plenty of events that can make a great game if your company is:

- An e-commerce company and, for some reason, your payment processing system is unexpectedly slow, preventing sales from being booked online

- A manufacturer and your supply chain system does not respond, causing delays and production to stall

- A hospital and the clinicians start complaining about the system performance

- A bank servicing remote locations from where the tellers can’t access the system

Remember, the more complex the application architecture, the better — it will make the game more interesting with many different players. The reason these games are so popular is that they are most often unplanned and unforeseen.

So how do you get to play? You will most likely get invited by your boss directly. When your phone rings the game play is on.

There are some indicators that will let you know if this is going to be an interesting game.

First, is the location the usual meeting room or a different one because the former is too small? The larger meeting room means that there will be many players, which should make the game last longer.

Another sign is the attendee list: if your boss’s boss is invited, then you know it's going to be an intense game. We have heard of games being kicked off by the CIO or the CFO and hosted in a hotel conference room because they could not accommodate all the players. The number of players will give you an idea of the complexity of the mystery to be solved. We have seen teams so good that one game could last more than 24 hours.

There are different types of players and many styles you can adopt, just like playing poker:

- The guessers. They don't have a clue, but they will guess anyway. They usually don't bring anything relevant, and you will hear them say things like, “There must be something wrong with the web servers because the team in Houston can't even access the system, or maybe it's the configuration of the database, or maybe it's the network itself?”

- The fact checkers. They come to the table with some kind of evidence that they can't be blamed for the problem. We have found that the network teams are usually pretty good at this, as they are used to being suspected at the beginning of the game, "It has to be the network."

- The screamers. They will try to intimate the other players. Sometimes the loudest screamers win or at least buy some time.

- The quiet. They will stay quiet until other players question them. Then they start challenging the elements and ask for evidence.

Image removed.

Basically, decide who is to blame for the screw up, and be ready to give enough evidence that will justify a deeper investigation by the players.

The other teams, if able, will try to disprove your theory by showing you one piece of evidence that exonerates them.

And this goes on until the case is solved and all the false possibilities have been eliminated. In the end, whoever is wrong, owns the issue and resolution and loses the game!

It’s important to note that we are witnessing a trend in companies to limit the possibilities for IT staff to participate in blamestorming competitions. They claim that these games are costly for the company due to the loss of revenue involved with revenue-generating application issues. They also complain about drop-offs in employee productivity when the issue prevents end users from doing their job, such as ERP failures.

Be aware that IT directors will often try to limit the number of games and their duration because they think this activity consumes too much of the IT staff time. They feel this time could be better put to use on more strategic projects.

As a result, we have seen IT management teams put into place new generation APM solutions. These solutions provide too much troubleshooting information upfront, which eliminates the mystery and the suspense.

Recently, a large producer and distributor of eyewear reduced the average duration of their games by 85% from 20 hours to less than 3 hours today, reducing the number of players at the same time. They are just killing the game!

Comic strip by Siobhan Ohmart and Vincent Geffray

ABOUT Vincent Geffray

Vincent Geffray is Senior Product Marketing Manager of Enterprise Solutions for Compuware’s APM business and has more than 14 years of experience in the IT Operations Management industry, with specialization in datacenter performance improvement.

Hot Topics

The Latest

Edge AI is strategically embedded in core IT and infrastructure spending across industries, according to the 2026 Edge AI Survey from ZEDEDA. The research shows that 83% of C-suite and IT executive respondents say edge AI is important to their core business strategy ...

As AI adoption accelerates, operational complexity — not model intelligence — is becoming the primary barrier to reliable AI at scale, according to the State of AI Engineering 2026 from Datadog ... The report highlights a compounding complexity challenge as AI systems scale ... Around 5% of AI model requests fail in production, with nearly 60% of those failures caused by capacity limits ...

For years, production operations teams have treated alert fatigue as a quality-of-life problem: something that makes on-call rotations miserable but isn't considered a direct contributor to outages. That framing doesn't capture how these systems fail, and we now have data to show why. More importantly, it's now clear alert fatigue is a symptom of a deeper issue: production systems have outgrown the current operational approaches ...

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on." Most enterprise leaders don't expect that to be the experience ...

Ask any senior SRE or platform engineer what keeps them up at night, and the answer probably isn't the monitoring tool — it's the data feeding it. The proliferation of APM, observability, and AIOps platforms has created a telemetry sprawl problem that most teams manage reactively rather than architect proactively. Metrics are going to one platform. Traces routed somewhere else. Logs duplicated across multiple backends because nobody wants to be caught without them when something breaks. Every redundant stream costs money ...

80% of respondents agree that the IT role is shifting from operators to orchestrators, according to the 2026 IT Trends Report: The Human Side of Autonomous IT from SolarWinds ...

40% of organizations deploying AI will implement dedicated AI observability tools by 2028 to monitor model performance, bias and outputs, according to Gartner ...

Until AI-powered engineering tools have live visibility of how code behaves at runtime, they cannot be trusted to autonomously ensure reliable systems, according to the State of AI-Powered Engineering Report 2026 report from Lightrun. The report reveals that a major volume of manual work is required when AI-generated code is deployed: 43% of AI-generated code requires manual debugging in production, even after passing QA or staging tests. Furthermore, an average of three manual redeploy cycles are required to verify a single AI-suggested code fix in production ...

Many organizations describe AI as strategic, but they do not manage it strategically. When AI plans are disconnected from strategy, detached from organizational learning, and protected from serious assumptions testing, the problem is no longer technical immaturity; it is a failure of management discipline ... Executives too often tell organizations to "use AI" before they define what AI is supposed to change. The problem deepens in organizations where strategy isn't well articulated in the first place ...

Across the enterprise technology landscape, a quiet crisis is playing out. Organizations have run hundreds, sometimes thousands, of generative AI pilots. Leadership has celebrated the proof of concept (POCs) ... Industry experience points to a sobering reality: only 5-10% of AI POCs that progress to the pilot stage successfully reach scaled production. The remaining 90% fail because the enterprise environment around them was never ready to absorb them, not the AI models ...

How Good Are You At Blamestorming?

Blamestorming is a well-known game IT organizations spend hours playing every week. There are different leagues and names for this game. Some call it the "war room", others the "service restoration call", but they basically follow the same simple rules. The goal of the game is to figure out the origin of an IT service degradation issue and collectively identify the one person — or the team — to blame for it, then hold them responsible for the resolution and the business consequences.

It often occurs in the form of a meeting, where the players meet in a conference room or on the phone.

The game usually starts with an IT performance degradation that impacts your most critical business applications. The cause, and this is important, should not be obvious; nothing in plain sight like a load balancer or a web server being down.

And there are plenty of events that can make a great game if your company is:

- An e-commerce company and, for some reason, your payment processing system is unexpectedly slow, preventing sales from being booked online

- A manufacturer and your supply chain system does not respond, causing delays and production to stall

- A hospital and the clinicians start complaining about the system performance

- A bank servicing remote locations from where the tellers can’t access the system

Remember, the more complex the application architecture, the better — it will make the game more interesting with many different players. The reason these games are so popular is that they are most often unplanned and unforeseen.

So how do you get to play? You will most likely get invited by your boss directly. When your phone rings the game play is on.

There are some indicators that will let you know if this is going to be an interesting game.

First, is the location the usual meeting room or a different one because the former is too small? The larger meeting room means that there will be many players, which should make the game last longer.

Another sign is the attendee list: if your boss’s boss is invited, then you know it's going to be an intense game. We have heard of games being kicked off by the CIO or the CFO and hosted in a hotel conference room because they could not accommodate all the players. The number of players will give you an idea of the complexity of the mystery to be solved. We have seen teams so good that one game could last more than 24 hours.

There are different types of players and many styles you can adopt, just like playing poker:

- The guessers. They don't have a clue, but they will guess anyway. They usually don't bring anything relevant, and you will hear them say things like, “There must be something wrong with the web servers because the team in Houston can't even access the system, or maybe it's the configuration of the database, or maybe it's the network itself?”

- The fact checkers. They come to the table with some kind of evidence that they can't be blamed for the problem. We have found that the network teams are usually pretty good at this, as they are used to being suspected at the beginning of the game, "It has to be the network."

- The screamers. They will try to intimate the other players. Sometimes the loudest screamers win or at least buy some time.

- The quiet. They will stay quiet until other players question them. Then they start challenging the elements and ask for evidence.

Image removed.

Basically, decide who is to blame for the screw up, and be ready to give enough evidence that will justify a deeper investigation by the players.

The other teams, if able, will try to disprove your theory by showing you one piece of evidence that exonerates them.

And this goes on until the case is solved and all the false possibilities have been eliminated. In the end, whoever is wrong, owns the issue and resolution and loses the game!

It’s important to note that we are witnessing a trend in companies to limit the possibilities for IT staff to participate in blamestorming competitions. They claim that these games are costly for the company due to the loss of revenue involved with revenue-generating application issues. They also complain about drop-offs in employee productivity when the issue prevents end users from doing their job, such as ERP failures.

Be aware that IT directors will often try to limit the number of games and their duration because they think this activity consumes too much of the IT staff time. They feel this time could be better put to use on more strategic projects.

As a result, we have seen IT management teams put into place new generation APM solutions. These solutions provide too much troubleshooting information upfront, which eliminates the mystery and the suspense.

Recently, a large producer and distributor of eyewear reduced the average duration of their games by 85% from 20 hours to less than 3 hours today, reducing the number of players at the same time. They are just killing the game!

Comic strip by Siobhan Ohmart and Vincent Geffray

ABOUT Vincent Geffray

Vincent Geffray is Senior Product Marketing Manager of Enterprise Solutions for Compuware’s APM business and has more than 14 years of experience in the IT Operations Management industry, with specialization in datacenter performance improvement.

Hot Topics

The Latest

Edge AI is strategically embedded in core IT and infrastructure spending across industries, according to the 2026 Edge AI Survey from ZEDEDA. The research shows that 83% of C-suite and IT executive respondents say edge AI is important to their core business strategy ...

As AI adoption accelerates, operational complexity — not model intelligence — is becoming the primary barrier to reliable AI at scale, according to the State of AI Engineering 2026 from Datadog ... The report highlights a compounding complexity challenge as AI systems scale ... Around 5% of AI model requests fail in production, with nearly 60% of those failures caused by capacity limits ...

For years, production operations teams have treated alert fatigue as a quality-of-life problem: something that makes on-call rotations miserable but isn't considered a direct contributor to outages. That framing doesn't capture how these systems fail, and we now have data to show why. More importantly, it's now clear alert fatigue is a symptom of a deeper issue: production systems have outgrown the current operational approaches ...

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on." Most enterprise leaders don't expect that to be the experience ...

Ask any senior SRE or platform engineer what keeps them up at night, and the answer probably isn't the monitoring tool — it's the data feeding it. The proliferation of APM, observability, and AIOps platforms has created a telemetry sprawl problem that most teams manage reactively rather than architect proactively. Metrics are going to one platform. Traces routed somewhere else. Logs duplicated across multiple backends because nobody wants to be caught without them when something breaks. Every redundant stream costs money ...

80% of respondents agree that the IT role is shifting from operators to orchestrators, according to the 2026 IT Trends Report: The Human Side of Autonomous IT from SolarWinds ...

40% of organizations deploying AI will implement dedicated AI observability tools by 2028 to monitor model performance, bias and outputs, according to Gartner ...

Until AI-powered engineering tools have live visibility of how code behaves at runtime, they cannot be trusted to autonomously ensure reliable systems, according to the State of AI-Powered Engineering Report 2026 report from Lightrun. The report reveals that a major volume of manual work is required when AI-generated code is deployed: 43% of AI-generated code requires manual debugging in production, even after passing QA or staging tests. Furthermore, an average of three manual redeploy cycles are required to verify a single AI-suggested code fix in production ...

Many organizations describe AI as strategic, but they do not manage it strategically. When AI plans are disconnected from strategy, detached from organizational learning, and protected from serious assumptions testing, the problem is no longer technical immaturity; it is a failure of management discipline ... Executives too often tell organizations to "use AI" before they define what AI is supposed to change. The problem deepens in organizations where strategy isn't well articulated in the first place ...

Across the enterprise technology landscape, a quiet crisis is playing out. Organizations have run hundreds, sometimes thousands, of generative AI pilots. Leadership has celebrated the proof of concept (POCs) ... Industry experience points to a sobering reality: only 5-10% of AI POCs that progress to the pilot stage successfully reach scaled production. The remaining 90% fail because the enterprise environment around them was never ready to absorb them, not the AI models ...