Bureaucratic processes typically involve a person new to the process

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.

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)

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.

Many people had this fantasy in the 80s and 90s that automation would reduce work.

In practice, automation just means that we do more work.

This applies to bureaucracies also.

Are you a journalist? I’m curious what you submit them for.

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.

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.

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.

Many bureaucracies took "throughput, latency, user friendliness" personally.

So, out of sheer spite, they decided that should mean "the slowest, least responsive, least friendly thing ever so people give up and piss off" :D

Also helps a lot of "fixers" who work in the system, get paid government wages and want to make some actual money.

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.

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.

- user friendliness: yeaah.

(Author here.) Yes, I ignored that concept in the model. I referred to that as "transfer learning" in the post.

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.

To counter, you need brakes to make a car go fast.

Some bureaucracy are random stops, others are brakes.

You can extend your rail network overtime, a few stops at a time.

> If you want the same results from every run ...

That's not how "bureaucracies" seem to actually function in the real world though, regardless of the theory. ;)