I'm old enough to remember bureaucracy before computers were a big part of the process. The rules were simple, to the point of cruelty at times, but simple.
After computers, the rules became far more complex and it seemed no clerk I dealt with actually understood them. Their solution was to lie - to select and misinterpret a few of the actual rules to create a fantasy rule system that made their interactions simple; but also utterly false. Very frustrating, and so far as I can tell, that's how things still are. The police are maybe the worst 'cause they are hard pressed and forced to cut corners (while managing a lot of rules); but it's everywhere.
I work in government IT, and before that I worked on enterprise workplace management software. I have noticed that when processes get moved into software the people involved in describing the requirements make the same mistakes over and over:
- making the digital process more complicated than the paper process, because the software will simplify the complexity (it does until it doesn’t and then everyone involved needs to figure out the real process anyway)
- assuming correctness of the software (all software has bugs, all digital processes eventually get into a broken state, there should be a way to force the system back into an intuitive “right” state better than some dev running random sql statements on a production database)
- assuming correctness of the software’s users (all people make mistakes, and mistakes happen often, there should be a clean and reliable way to force a process into a state matching reality when someone misclicks, but often the only way is to “lie” to the system and take an odd path through it)
- trying to capture the process end to end in software rules causing it to become set in stone (only the labor intensive parts should be automated, leaving room for flexible adaptation of the process without requiring a new software release)
When the only computers were mainframes, only the biggest bureaucracies had computers.
As computers became more widespread, unfortunately some tried to emulate this approach at smaller offices, regardless "progress" was made until computers are everywhere.
Somewhere along the line from the depths of bureaucracy came the saying "To err is human, to really screw things up takes a computer".
And this maxim has been emblazoned on coffee cups for decades now.
This is really spot on. I find myself helping a lot of friends and acquaintances with digital bureaucracy, and it is so counterintuitive. I, as a person who is used to buggy software and weird, complex rules, manage somehow to move through that, but I am always under the impression that the rules are applied in a way that actively (and sometimes, I suspect, intentionally) disincentivizes participation/use of a service.
It is not nostalgia for paper: technology was applied badly to bureaucracy, widening the divide between the physical, in-person bureaucrat and the person using their service. When things were not digital, at least, it was easy to deal with things in person, talk, get explanations.
Absolutely. I submit a lot of FOIA requests and one of the biggest limiting factors in access to the records I need comes from people new to the job who haven't been given full training on how to get records. It very much feels like as a FOIA requester, we're training them ourselves.
This is the experience for many in the Navy trying to navigate broken personnel pay processes. Due to cost cuts and failed IT efforts, a lot of the staff at personnel offices that have to process things like pay transactions and travel reimbursements are entry level, and the organization suffers from high turnover to boot.
This means that Sailors with enough experience in the Navy are usually better off bringing copies of pertinent references and Navy instructions, especially if they have any kind of unusual case, so that they can hand-walk the clerk through the process that needs to be followed.
The same is common in Britain’s National Health Service (NHS). Doctors frequently complain about incorrect pay. Some I’ve spoken to claim their pay is wrong most months! (Usually due to picking up extra shifts, especially overnights.)
I suspect it’s a big contributor to the low morale in the NHS. Hard to feel valued when a regular conversation is “They don’t even pay me correctly.”
Experienced customers training new-to-the-process participants is a surprisingly common aspect of bureaucratic processes. The peer participants or management are the other possible sources of training, but those stakeholders are not as incentivized to train the new member.
FOIA was a fascinating experiment from the start. Expecting agencies and individuals to go out of their way to pull dusty old records so they can self-incriminate? Honestly, it's a wonder it works at all.
I mean, it's not like it's without its issues. I currently have something like five ongoing FOIA lawsuits, every one coming from a place of frustrated nonsense.
It doesn't work too well at the federal level because it's turned into a weak system filled with layers of legal nonsense for literal years, but some states (like Illinois) are pretty good about making it easy to litigate, and laws that are... surprisingly favorable for requesters. I got to witness a lawyer, who litigated FOIA at the the federal level, read the statute of Illinois FOIA for the first time, and he was jaw-droppingly gobsmacked by how much the law favors requesters.
It's hard to talk about the FOIA litigation online, but [1] is some litigation I've been plaintiff for, for the database schema of Chicago's parking ticket database. The idea is to figure out what can be requested prior to submitting requests, but the city argues that its release would compromise network security. Even though we won the appellate case, it got raised and accepted by the IL Supreme court, so it'll be another long while until we know how it pans out.
- accountability. We need to know who did what, so we need to store a bunch of information about access and authorization. We want to know who is responsible for stuff, so some gatekeeping is necessary.
- fairness. It shouldn't matter who approaches the org, they need to be treated according to the merits of their case and not their status.
- throughput. We have a bureaucracy because a bunch of people need to be served. Read between the lines and we also mean cheaply.
- latency. They need to be served soon, otherwise what's the point?
- longevity. We don't want the system collapsing just because one or two civil servants leave. It needs to not be fragile.
- user friendly. People come to the desk, they want a driver's license, they don't want to do a bunch of stuff with forms.
As Bender said, gimme your biggest, strongest, cheapest drink.
On the fairness point, having a thick bureaucracy allows those within it to help those outside navigate the maze, or outright expedite the process for a fee or favor down the line.
Bureaucracy is the reason long term congressmen and senators are all multi millionaires. It's also the reason why people who work on the military procurement programs end up getting coshy jobs at firms like Raytheon after they are done servicing the public. I rarely go a day without seeing an example of this effect in action.
Haha yeah, this would be funny were it not so sad.
- accountability: bureaucracies allow people to hind behind process and anonymity to shirk basically all responsibility.
- fairness: bureaucratic systems are usually designed with a particular type of person in mind and if you don't fit that mold, it will be hard to accomplish anything.
- throughput and latency: I don't even have to write anything here.
- longevity: this is something bureaucracies are actually good at -- propagating themselves.
Bureaucratic processes are about the process and not about single individuals. Such a process is anonymous by definition. It doesn't care about what type of people is involved. If the typr of person were important it would be a flaw, a bug in the system. Look up under corruption, bribing, injustice etc.
How it should probably be done: some high ranking civil servant is ordered to plan for a process centered around management of _X need_. If _X need_ means having a system to administer social security numbers, then it's fair to assume the process should be simultaneously widespread, short, easy to handle, and extremely reliable.
If it means delivering some checks to single mothers in sparsely populated neighborhoods citywide, it could be done with something as simple as a spreadsheet. The only common requirement to both task is the need for safety, accountability, and compatibility with /between parent and /or parallel systems.
How it's done in real life: some IT contractor creates an overly complicated stacked platform that does it all (ordered by some IT uneducated but ego infatuated ill informed client with a budget), excepted for the fact that the system is a smokescreen and does not all at all. The contractor then sells more platform access to some other like minded clients, which all have wildly different requirements. In the end, the do-it-all platform becomes a giant mess nobody understands, _X need_ budget allocations dissolves in contractor's hands, social security numbers are scrambled, and single mothers never get their checks.
How about "correctness" as a goal? The idea being that it's harder to miss something out or get something wrong if it has to be checked multiple times by different people as part of the process.
I wonder if this calculation ignores a bit the effects of "meta knowledge". I.e., many of the "new" people may be new to this particular process, but may already have expert skills in the general domain of buerocratic processes - and therefore may be able to adapt much more quickly than a "real" newbie, i.e. a person that works in s buerocracy for the first time.
I imagine this similar to how software developers may be new to a particular project or codebase but may still bring with them general domain knowledge which lets them understand the project requirements or the intricacies of the codebase relatively quickly.
I think the point of bureaucracy is spelling things out so that "anyone can do it" in lieu of hiring talented competent people who cost more. The goal certainly isn't to have a fast or high quality process.
I used to work in desktop support. One of our supervisors insisted that we have documentation on everything, even simple things like how to install a printer on a windows 95 workstation. The documentation had to include screen shots.
So rather than employ people who either new how to install printers on windows or could work it out (follow the prompts in the wizard) for themselves we employed people who would happily follow the step by step instructions in our documentation.
Everything fell apart when we migrated to Windows XP, where the instructions no longer worked, the screenshots were out of date and those support personnel who used to rely on all the documentation for step by step on how to install printers were left scratching their heads.
Documentation is great, but its main aim should be to detail the outcome required, why it's required and any unique situations that the reader should be aware of.
It is a bit like Kubernetes, you end up needing 3 chiefs and 12 workers to run something that a single one was doing before. Then you realize that anyway you can't reuse that process for something new you are trying to do and need another team of 3+12...
If they want to do that then why not run it like an assembly line? That’sa proven technology that allows you to create a complex output with minimal training of each employee. Both setups probably require a similar number of people but the assembly line would be less prone to failure since you wouldn’t have to maintain a byzantine codex of conflicting rules and procedures.
CE0 of BeauroDisruptor here. This is exactly the problem. We are building a hiring platform to connect organizations with top clerical telent using the latest in ML. Come and join us.
Bureaucratic processes are the repeatable builds of government decision making. If you want the same results from every run, you have to dehumanize the process
But it goes wrong very often actually (meaning the outcome is non repeatable). Most of the time you don’t find out, but if there’s two or more people doing the exactly same process (application for getting something out of say a government institution). You just need the forms to end up with different clerks to get two different outcomes.
This is why in Germany the common wisdom is for say claiming disability, you will always have to reject the first ruling, no matter what. You will get a better result the second run through (maybe even reject that, too).
Imho it’s the curse of complexity. But there is little incentive for bureaucratic institutions to „refactor“ their processes, as it would mean less headcount.
I am not convinced it goes wrong a significant percentage of the time, compared to the volume. I don't have the data one way or the other though.
Regarding headcount, I don't contend the issue, but then keeping more people employed is not that bad of a goal in itself.
It is very frustrating that different clerks can result in different outcomes. IMO it's the lack of clearly defined procedures. However, I don't follow this bit:
> You just need the forms to end up with different clerks to get two different outcomes...You will get a better result the second run through (maybe even reject that, too)
What if you get a worse outcome and you have just rejected the friendlier clerk's work?
IMVHO doing things demand or to know them up front or to carefully design them and correct the design as long as you advance, because no matter how well you design something up front, it will change, perhaps substantially in some parts.
At a certain point things seems to work and became habits, a newcomer might understand them, might not, might spot illogical/inefficient aspects that are assumed as normal due to the initial evolutionary process and ANY confrontation is such stages typically generate frictions and uncertain feelings where many choose to contour with extra rigidity.
Said that, play network analysis that way seems a bit a nonsense to me. We try to simply things, reduce them to something we already know but... We actually know companies/works paradigms and policies MUCH more than network theory in general.
I have a problem with the name bureaucratic. It fails to capture the essence of the problem. The problem isn't the involvement of "desk" related items (i.e. paperwork), but an unequal distribution of power in the process.
After computers, the rules became far more complex and it seemed no clerk I dealt with actually understood them. Their solution was to lie - to select and misinterpret a few of the actual rules to create a fantasy rule system that made their interactions simple; but also utterly false. Very frustrating, and so far as I can tell, that's how things still are. The police are maybe the worst 'cause they are hard pressed and forced to cut corners (while managing a lot of rules); but it's everywhere.