I assert that a lot of value can be achieved by categorizing systemic failures into four broad categories.
For the sake of pithiness, I will name them “bugs”, “dragons”, “bullshit mountain”, and “the cloud of doom”.
A Bug is the simplest kind of failure: you have a single cause, and a single symptom. Fixing a bug is pretty easy, compared to other modes—you just fix the cause, and the symptom goes away. Bugs aren’t even really systemic failures, since they don’t involve any cross-talk between multiple causes or effects, but they are included here for completeness.
A Dragon is like a Bug, except that instead of a single symptom, there are multiple seemingly independent symptoms. Because the symptoms seem large and diverse, a Dragon will often seem far more daunting than it actually is—although most Dragons are still pretty large and significant causes. Dealing with a Dragon simply involves some particularly Heroic-type identifying that there’s a Dragon, hunting it down, and slaying it.
Bullshit Mountain is basically the opposite of the Dragon. There is one huge, unbearable, painful symptom, that everyone knows about and everyone wishes would just GO AWAY. But no one can get any traction on it. This is because that symptom is actually being contributed to by a thousand little causes, all of which only contribute a little—so making progress on any one of them feels like it doesn’t help much, if at all. The only way to solve Bulshit Mountain is for everyone in the org to roll up their sleeves, get a shovel, pick some little corner of Bullshit Mountain to work on, and start shoveling—and not stop until the problem gets noticeably better, even if their work doesn’t seem to be doing much to contribute to the improvement.
Finally, we have the Cloud of Doom. The Cloud of Doom is where you have a thousand tiny causes, each of which meaningfully contribute to each of a thousand little symptoms, which together make the whole system feel unworkable. The only way to fix the Cloud of Doom is to pour an ungodly amount of Slack into the system, and hope the cloud shakes loose and blows away—otherwise, everyone needs to just throw up their hands and abandon the whole mess.
A good question to ask yourself, when trying to tackle a seemingly insurmountable mess of problems, is: is this a Dragon, Bullshit Mountain, or a Cloud of Doom?
Slaying Dragons
If the problem is a Dragon, are you the one qualified to slay it? If you are, what further information or resources do you need? Do you need a team? Are you the right person to lead that team?
Because Dragons are single-cause problems, they respond well to a single person and a single plan. Most organizations hope (and therefore pretend) that most of their problems are Dragons, and most organizational problem-solving is dedicated to finding Dragons (or making problems look like Dragons) and then paying a few core Heroes big bucks to slay them.
Basically, slaying Dragons is a Solved Problem in the organizational world; most apparent lack of success involves mis-identifying Bullshit Mountains and Clouds of Doom as Dragons, in the naive hope that they’ll turn out to be Dragons anyways and therefore can be solved by a process that the system knows how to implement.
Shoveling Bullshit Mountain
If your problem is Bullshit Mountain, do you have enough buy-in to get enough people to start shoveling? Are you the right cheerleader to keep people motivated? Does the team still care enough to even want to solve the problem? These are way harder problems to tackle than the Dragon problems listed above, so expect a lot of people to handwave and convince you that the problem is a Dragon (if they want to signal buy-in for solving it) or a Cloud of Doom (if they don’t).
Dealing with Bullshit Mountain as if it was a series of Dragons is what causes “death marches” in the tech industry. It’s what makes transformative “business culture” experiments seem to work temporarily (by clearing out the mountain and replacing it with a new system, which then begins accumulating its own Bullshit). It’s the biggest contributor to low employee morale that a mid- to large-size “healthy” organization can have. (In fact, the transition from Bullshit Mountain into a Cloud of Doom is probably the tipping point for an organization becoming unsalvageable.)
Surviving The Cloud of Doom
Finally, we have the Cloud of Doom. Every organization has one. Some are big, some are small, some are more toxic than others. But an organization with 0% of its problems in a Cloud of Doom is an organization that has not yet had to do anything actually real.
So, you live with it. And the organization begins to develop other problems—mostly bugs, but some Dragons and a few Bullshit Mountains here and there. And as the Dragons get bigger and lay waste to more countryside, and as the Bullshit Mountains tower higher and higher overhead, they start to interweave and correspond, feeding the Cloud of Doom.
Eventually, the Cloud of Doom begins to actually choke the life out of your organization. That’s when you have a single choice: inject lots and lots of Slack, or leave.
Injecting lots and lots of Slack basically means “doing less with more”, which almost no one believes is the correct choice. But if you aren’t burning everything down and starting over somewhere else, it’s the only choice. If you can’t live with your Cloud of Doom, and you won’t flee it, you’re going to have to stop feeding it and let it blow away.
Harnessing the Cloud of Doom
One thing you CAN do, if you’re particularly vicious, is convince people that your Cloud of Doom is actually just Bullshit Mountain, and use that to extract work from your subordinates. You need to be exceptionally clever (in a Raoian sociopathic sense) in order to pull this off, because you basically need to manage both sides of the information and effort flow: you have to keep everyone believing that there’s a Bullshit Mountain that they’re biting into, AND you have to re-direct and manage their actual efforts so that they benefit your covert goals. Note that this is doable whether the actual problem is in fact a Cloud of Doom or merely Bullshit Mountain, and that applying this very process to Bullshit Mountain is one of the more common things that turns Bullshit Mountain into a Cloud of Doom in the first place.
If I catch you doing this within any organization that I am aligned with, I consider it within my rights to destroy you.
Dragonslayers are Gryffindor, Shovelers are Hufflepuff
Noticing what kind of problem you have the right temperment to solve is key to avoiding burn-out. Dragonslaying is glamorous, high-praise work; shoveling Bullshit Mountain is thankless and grueling, and the person who finally gets the praise is usually the guy that did the least actual work. From my perspective, Project Hufflepuff was in many ways a direct attempt to train up people who could handle the Rationalist-and-EA-community’s Bullshit Mountain before it turned into a Cloud of Doom. (Whether it’s too late now or not is a matter for the Slytherins to convince you; I will say no more on this today.)
One big problem with shovelers is that they still expect praise and reward for shoveling Bullshit Mountain; no one seems to be telling them that it ain’t gonna happen. (The smart ones figure this out on their own, and either go away or grit their teeth and get to work anyways.) As a system for motivating people to shovel, anything like Project Hufflepuff is doomed to fail from the beginning. What you need is a way to identify the people who are already doing the work, and make sure they stay funded and supported and nurtured. (Whether this problem itself is a Bullshit Mountain or a Cloud of Doom is, again, left as an exercise for the reader. A Dragon it ain’t, or Project Hufflepuff would have worked.)
Conclusions
So, anyway, yeah. Here we are. Do what you will with it. Or don’t; I’m not your dad.
An Ontology of Systemic Failures: Dragons, Bullshit Mountain, and the Cloud of Doom
Core Claim
I assert that a lot of value can be achieved by categorizing systemic failures into four broad categories.
For the sake of pithiness, I will name them “bugs”, “dragons”, “bullshit mountain”, and “the cloud of doom”.
A Bug is the simplest kind of failure: you have a single cause, and a single symptom. Fixing a bug is pretty easy, compared to other modes—you just fix the cause, and the symptom goes away. Bugs aren’t even really systemic failures, since they don’t involve any cross-talk between multiple causes or effects, but they are included here for completeness.
A Dragon is like a Bug, except that instead of a single symptom, there are multiple seemingly independent symptoms. Because the symptoms seem large and diverse, a Dragon will often seem far more daunting than it actually is—although most Dragons are still pretty large and significant causes. Dealing with a Dragon simply involves some particularly Heroic-type identifying that there’s a Dragon, hunting it down, and slaying it.
Bullshit Mountain is basically the opposite of the Dragon. There is one huge, unbearable, painful symptom, that everyone knows about and everyone wishes would just GO AWAY. But no one can get any traction on it. This is because that symptom is actually being contributed to by a thousand little causes, all of which only contribute a little—so making progress on any one of them feels like it doesn’t help much, if at all. The only way to solve Bulshit Mountain is for everyone in the org to roll up their sleeves, get a shovel, pick some little corner of Bullshit Mountain to work on, and start shoveling—and not stop until the problem gets noticeably better, even if their work doesn’t seem to be doing much to contribute to the improvement.
Finally, we have the Cloud of Doom. The Cloud of Doom is where you have a thousand tiny causes, each of which meaningfully contribute to each of a thousand little symptoms, which together make the whole system feel unworkable. The only way to fix the Cloud of Doom is to pour an ungodly amount of Slack into the system, and hope the cloud shakes loose and blows away—otherwise, everyone needs to just throw up their hands and abandon the whole mess.
A good question to ask yourself, when trying to tackle a seemingly insurmountable mess of problems, is: is this a Dragon, Bullshit Mountain, or a Cloud of Doom?
Slaying Dragons
If the problem is a Dragon, are you the one qualified to slay it? If you are, what further information or resources do you need? Do you need a team? Are you the right person to lead that team?
Because Dragons are single-cause problems, they respond well to a single person and a single plan. Most organizations hope (and therefore pretend) that most of their problems are Dragons, and most organizational problem-solving is dedicated to finding Dragons (or making problems look like Dragons) and then paying a few core Heroes big bucks to slay them.
Basically, slaying Dragons is a Solved Problem in the organizational world; most apparent lack of success involves mis-identifying Bullshit Mountains and Clouds of Doom as Dragons, in the naive hope that they’ll turn out to be Dragons anyways and therefore can be solved by a process that the system knows how to implement.
Shoveling Bullshit Mountain
If your problem is Bullshit Mountain, do you have enough buy-in to get enough people to start shoveling? Are you the right cheerleader to keep people motivated? Does the team still care enough to even want to solve the problem? These are way harder problems to tackle than the Dragon problems listed above, so expect a lot of people to handwave and convince you that the problem is a Dragon (if they want to signal buy-in for solving it) or a Cloud of Doom (if they don’t).
Dealing with Bullshit Mountain as if it was a series of Dragons is what causes “death marches” in the tech industry. It’s what makes transformative “business culture” experiments seem to work temporarily (by clearing out the mountain and replacing it with a new system, which then begins accumulating its own Bullshit). It’s the biggest contributor to low employee morale that a mid- to large-size “healthy” organization can have. (In fact, the transition from Bullshit Mountain into a Cloud of Doom is probably the tipping point for an organization becoming unsalvageable.)
Surviving The Cloud of Doom
Finally, we have the Cloud of Doom. Every organization has one. Some are big, some are small, some are more toxic than others. But an organization with 0% of its problems in a Cloud of Doom is an organization that has not yet had to do anything actually real.
So, you live with it. And the organization begins to develop other problems—mostly bugs, but some Dragons and a few Bullshit Mountains here and there. And as the Dragons get bigger and lay waste to more countryside, and as the Bullshit Mountains tower higher and higher overhead, they start to interweave and correspond, feeding the Cloud of Doom.
Eventually, the Cloud of Doom begins to actually choke the life out of your organization. That’s when you have a single choice: inject lots and lots of Slack, or leave.
Injecting lots and lots of Slack basically means “doing less with more”, which almost no one believes is the correct choice. But if you aren’t burning everything down and starting over somewhere else, it’s the only choice. If you can’t live with your Cloud of Doom, and you won’t flee it, you’re going to have to stop feeding it and let it blow away.
Harnessing the Cloud of Doom
One thing you CAN do, if you’re particularly vicious, is convince people that your Cloud of Doom is actually just Bullshit Mountain, and use that to extract work from your subordinates. You need to be exceptionally clever (in a Raoian sociopathic sense) in order to pull this off, because you basically need to manage both sides of the information and effort flow: you have to keep everyone believing that there’s a Bullshit Mountain that they’re biting into, AND you have to re-direct and manage their actual efforts so that they benefit your covert goals. Note that this is doable whether the actual problem is in fact a Cloud of Doom or merely Bullshit Mountain, and that applying this very process to Bullshit Mountain is one of the more common things that turns Bullshit Mountain into a Cloud of Doom in the first place.
If I catch you doing this within any organization that I am aligned with, I consider it within my rights to destroy you.
Dragonslayers are Gryffindor, Shovelers are Hufflepuff
Noticing what kind of problem you have the right temperment to solve is key to avoiding burn-out. Dragonslaying is glamorous, high-praise work; shoveling Bullshit Mountain is thankless and grueling, and the person who finally gets the praise is usually the guy that did the least actual work. From my perspective, Project Hufflepuff was in many ways a direct attempt to train up people who could handle the Rationalist-and-EA-community’s Bullshit Mountain before it turned into a Cloud of Doom. (Whether it’s too late now or not is a matter for the Slytherins to convince you; I will say no more on this today.)
One big problem with shovelers is that they still expect praise and reward for shoveling Bullshit Mountain; no one seems to be telling them that it ain’t gonna happen. (The smart ones figure this out on their own, and either go away or grit their teeth and get to work anyways.) As a system for motivating people to shovel, anything like Project Hufflepuff is doomed to fail from the beginning. What you need is a way to identify the people who are already doing the work, and make sure they stay funded and supported and nurtured. (Whether this problem itself is a Bullshit Mountain or a Cloud of Doom is, again, left as an exercise for the reader. A Dragon it ain’t, or Project Hufflepuff would have worked.)
Conclusions
So, anyway, yeah. Here we are. Do what you will with it. Or don’t; I’m not your dad.
[Epistemic status]