These things happen because the executives originally charged with implementation of some external compliance requirement know that they have the power to implement changes, but don’t have the ground-level information required to feed those changes. So these requirements get delegated down the org-chart, to people with ground-level information but without power; under the presumption that a response will flow back up the org-chart from said people, telling the higher-up what is needed-but-unavailable on the ground to actually implement the requirement.
In other words, the higher-up is trying to receive an error condition by installing an exception handler in their part of the system, and then expecting the ground-level routine to realize there’s a problem and throw an exception, and for that exception to make its way back to them.
But, unlike in software, where you usually feed everything as source through a single compiler at some point, and so you can force every component of the system to support exception-handling the same way; in organizational “systems”, the parts in the middle usually have no idea what to do with “exceptional” reports that cross their desks. They haven’t been informed that it’s part of their job to keep raising these reports up a level until someone sees them who can handle them. And because they haven’t been told that, they try to “handle” the exception themselves, in order to present a clean interface to their own boss—usually by just tossing the exception-report out, and chewing out their subordinate for giving it to them.
If you’re a CEO, and you think you might ever need to use “exception handling” as a way to collect ground-level information, you’ve gotta ensure every layer of your management understands this in advance—understands that they won’t be blamed for a “fault” happening below them, and in fact that this fault was expected, even encouraged by people above them; and that those higher-ups need to know when ground-level faults happen.
Sadly, even for organizations that that implement this policy perfectly... it only ends up “counting” for the types of exception-reports they were looking for at the time that they set up the policy. So, for example, retail companies know to reraise security reports; companies that employ tradespeople know to reraise health-and-safety reports; etc. But these same companies, when it comes to other types of exception-reports, are no better than anyone else. They learned a specific lesson, but not the general one.
> the parts in the middle usually have no idea what to do with “exceptional” reports that cross their desks
Or they explicitly don't want to report them because it makes it look like they don't know what they are doing, or they are afraid that it would create more work for them and they are already overworked.
Right, that’s what I meant by “a clean interface to their boss”—because they’re unaware that rethrowing these exceptions is a (perhaps implicit) part of their job description, and they certainly don’t think it’s part of their boss’s job description, they think that 1. they’ll be doing something they’re not supposed to be doing by rethrowing the exception, and 2. it’ll be their own boss’s job to handle the exception, probably by throwing out the report and then trusting them less to get stuff done on their own.
more realistically: first manager installed the system as a virtuous feedback gathering mechanism, then three turnover later as the first crunch hit faults become a metric to optimize and everyone gets incentived on reducing them, at which point gaming the system ensues
In other words, the higher-up is trying to receive an error condition by installing an exception handler in their part of the system, and then expecting the ground-level routine to realize there’s a problem and throw an exception, and for that exception to make its way back to them.
But, unlike in software, where you usually feed everything as source through a single compiler at some point, and so you can force every component of the system to support exception-handling the same way; in organizational “systems”, the parts in the middle usually have no idea what to do with “exceptional” reports that cross their desks. They haven’t been informed that it’s part of their job to keep raising these reports up a level until someone sees them who can handle them. And because they haven’t been told that, they try to “handle” the exception themselves, in order to present a clean interface to their own boss—usually by just tossing the exception-report out, and chewing out their subordinate for giving it to them.
If you’re a CEO, and you think you might ever need to use “exception handling” as a way to collect ground-level information, you’ve gotta ensure every layer of your management understands this in advance—understands that they won’t be blamed for a “fault” happening below them, and in fact that this fault was expected, even encouraged by people above them; and that those higher-ups need to know when ground-level faults happen.
Sadly, even for organizations that that implement this policy perfectly... it only ends up “counting” for the types of exception-reports they were looking for at the time that they set up the policy. So, for example, retail companies know to reraise security reports; companies that employ tradespeople know to reraise health-and-safety reports; etc. But these same companies, when it comes to other types of exception-reports, are no better than anyone else. They learned a specific lesson, but not the general one.