A few weeks ago, my post on bureaucracy got a lot of discussion on Hacker News.
A lot of it was extremely interesting and helped refine my ideas about organizations and systems! I’ve highlighted some of the few more interesting threads below:
“blameless culture” // accountability
There was a long discussion thread about how individual blame/accountability interfaces with bureaucracy in organizations. Some argued that individual accountability is necessary to prevent organizations from strangling themselves with more and more systems:
When you treat every negative outcome as a system failure, the answer is more systems. This is the cost of a blameless culture. There are places where that’s the right answer, especially where a skilled operator is required to operate in an environment beyond their control and deal with emergent problems in short order. Aviation, surgery. Different situations where the cost of failure is lower can afford to operate without the cost of bureaucratic compliance, but often they don’t even nudge the slider towards personal responsibility and it stays at “fully blameless.”
Some argued that blame culture is worse for organizations:
Just one tiny problem: I've played the blame game before. I've worked there. You can't sell me the greener grass on the other side of the road because I've been to the other side of the road and I know the grass there is actually 90% trampled mud and goose shit.
The blame game drives the exact same bureaucratization process, but faster, because all of the most capable and powerful players have a personal incentive to create insulating processes / excuses that prevent them from winding up holding the bag. Everyone in this thread at time of writing is gleefully indulging in wishful thinking about finally being able to hold the team underperformer accountable, but these expectations are unrealistic. Highly productive individuals do not tend to win the blame game because their inclinations are the exact opposite of the winning strategy. The winning strategy is not to be productive, it's to maximize safety margin, which means minimizing responsibility and maximizing barriers to anyone who might ask anything of you. Bureaucracy goes up, not down, and anyone who tries to be productive in this environment gets punished for it.
"Blaming the system" doesn't prevent bureaucracy from accumulating, obviously, but it does prevent it from accumulating in this particular way and for this particular reason.
Thank you! A blame focused culture rewards the least amount of risk taking, the most ass covering, and so much useless bureaucracy because you naturally accumulate systems to convert individual blame to collective blame like change review boards and multiple sign-offs for everything. Folks do the bare minimum because that's the safe subset.
This also multiplies with hierarchy. In a blame-based culture, your manager is partly to blame for what you do. Their manager is partly to blame for what your manager does. Therefore everyone in a reporting chain is incentivized through fear to double check your work. That means more sign-off and review and approval processes so that people can avoid any kind of fuckup, and it also often means a toxic environment where everyone is spending at least 20% of their brain power worrying about internal optics which in my experience is not a good thing for people engaged in creative work.
By gawd, I felt the pain in these responses. I agree with all of them though; I don’t think these two perspectives are incompatible with each other!
Sometimes the root cause of a mistake is a poorly designed system, and sometimes the root cause is an agent failing to execute their responsibility adequately in a well-designed system. Most of the time it is both. Organizations that effectively combat bureaucratization probably prioritize effective diagnosis over anything else. I agree that treating every negative outcome as a system failure is a limited way of thinking, but so is thinking that having agents take responsibility will inevitably lead to a blame-focused culture in which people will find ways to shield themselves from owning up to their mistakes.
I think blame-oriented cultures have more to do with poorly designed incentive structures around individual failures than anything else. I think it’s unrealistic to assume that everyone will do their job perfectly all the time. We’re all human! Everyone’s days and job performances fluctuate significantly from day to day (probably falling along a normal bell curve distribution). It’s perfectly reasonable to expect that even the best performers will drop the ball from time to time. I think the most effective cultures are ones that prioritize speed to correction instead of reactiveness to failures. This means that people shouldn’t be afraid of taking individual accountability; if that’s truly the cause of a negative outcome, then the people involved with quickly diagnosing and correcting that should be rewarded for it! If your systemic response to that is to punish those individuals, then I can completely see how that will drive the blame-oriented bureaucratization process described above.
Some also said there’s another option besides blaming someone or adding process:
This might be true if your only options are "find someone to blame" or "add more bureocratic process", but in a lot of cases you also have the option "fix the technology"
Even in aviation and surgery, improving the technology tends to be more effective than firing the pilot/surgeon or adding more paperwork. If you find there's a button that crashes the plane, fix the button. Don't fire the pilot or add another hour of education on how to not press that button.
Facts! I think this applies in a lot of low-tech areas too, even as simple as basic project management or communication. A lot of process complexity can be eliminated by using better tools that are more suited to what you’re trying to do.
pernoulle’s law
Someone brought up Pernoulle’s law:
Pournelle's take on part of it seems pertinent to me: https://en.wikipedia.org/wiki/Jerry_Pournelle#Pournelle's_ir...
John Ousterhout explained "it's easier to create a new organism than to change an existing one...": https://web.stanford.edu/~ouster/cgi-bin/sayings.php :
So true that it’s easier to create something new than to change something that currently exists.
I had never heard of Pournelle’s law before, so here’s some more detail on it:
Another "law" of his is "Pournelle's iron law of bureaucracy":
In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals that the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely.[83]
He eventually restated it as:
Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people: First, there will be those who are devoted to the goals of the organization. Examples are dedicated classroom teachers in an educational bureaucracy, many of the engineers and launch technicians and scientists at NASA, even some agricultural scientists and advisors in the former Soviet Union collective farming administration. Secondly, there will be those dedicated to the organization itself. Examples are many of the administrators in the education system, many professors of education, many teachers union officials, much of the NASA headquarters staff, etc. The Iron Law states that in every case the second group will gain and keep control of the organization. It will write the rules, and control promotions within the organization.[84]
This is related to the iron law of oligarchy and to the Self-licking ice cream cone.[citation needed] His blog, "The View from Chaos Manor", often references apparent examples of the law.[85] Some of Pournelle's standard themes that recur in the stories are: welfare states become self-perpetuating, building a technological society requires a strong defense and the rule of law, and "those who forget history are condemned to repeat it".
This is wild. And I think it’s completely accurate! It’s certainly been the case for every organization I’ve been in, and I think it largely explains why I’ve spun out of almost every organization I’ve been part of. The thought “Well, we might as well try to do something interesting while we’re here” has generally not been well-received by bureaucratic leadership. Had I known, I probably would’ve employed a different strategy.
*Side note: The self-licking ice cream cone is an example of a self-perpetuating system that has no other purpose than to sustain itself. This is an incredible example and I’m definitely adding it to my bag.
Pournelle doesn’t explain the mechanism behind this, but I’m extremely curious. I’m going to try to figure this out sometime.
After reading about his law, I went down a rabbit hole of some other stuff he had said. This is his commentary on teachers:
Teacher’s Unions are very powerful, and dedicated to protecting the jobs of all teachers without regard to their competence. There have been several studies indicating that you can just about double the efficiency – measured by the competency of the students at year’s end – simply by firing the worst 10% of the teachers. Not replacing them; simply firing them and parceling out their students into other classes. This has consistently had better results than reducing class sizes, or raising teacher pay across the board. As to who are the 10% worst teachers, come now: in every school I have visited, the other teachers know, and so do the students. Obviously this technique has not been tried in good schools with outstanding results; it’s hardly needed. Better to reward those schools. But that’s not allowed by the unions, either. You reward by tenure and length of service, not for good results. Of course that system has for generations produced a system of education indistinguishable from an act of war against the American People, but that’s no matter.
If a foreign government had imposed this system of education on the United States, we would rightfully consider it an act of war. — Glenn T. Seaborg, National Commission on Education, 1983
Certainly did not mince any words here. He continues:
The problem is that some government employees do what they want, not what the President wants. An Iron Law of Bureaucracy takes control. In every bureaucracy there are those devoted to the interests of the public whom they in theory serve, and those devoted to the interests of the bureaucracy itself. A good example is teachers: there are those who want to teach, and those who want “released time” to attend to union affairs and other administrative work. In any bureaucracy, the second group always gets in control, and serves the interests of the bureaucracy – and its leaders. Over time an establishment is built. Employment becomes a property right. We have built a ship whose first mission is to service its crew. Sometimes, like bunny inspectors, it has no mission that anyone but the crew wants. If we took a national vote on whether stage magicians ought to have a Federal License before they can have a rabbit in their act, and they must provide an emergency evacuation plan for that rabbit in the event of fire or earthquake or hurricane, how many votes – other than those of bunny inspectors – do you think such a measure would gather? Yet it seems to matter not who is President: we have had bunny inspectors for decades, and we will have bunny inspectors forever and aye
I had never heard of bunny inspectors before, so I again researched and came across this article:
Agriculture Department tells magician to write disaster plan for his rabbit
By Jessica Chasmar – The Washington Times – Monday, July 1, 2013
Magician Marty Hahne didn’t think things could get any more harebrained after the U.S Department of Agriculture harassed him for using an unlicensed rabbit in his magic shows two years ago.
Now, the agency is demanding he draw up a disaster plan for his furry friend.
The Ozark, Mo.-based magician contacted blogger Bob McCarty via email to explain his plight.
"You won’t believe what the USDA has come up with now," Mr. Hahne wrote late Friday afternoon. "If this wasn’t so stupid, it would be funny!"
"My USDA rabbit license requirement has taken another ridiculous twist," he continued. "I just received an 8 page letter from the USDA, telling me that by July 29 I need to have in place a written disaster plan, detailing all the steps I would take to help get my rabbit through a disaster, such as a tornado, fire, flood, etc. They not only want to know how I will protect my rabbit during a disaster, but also what I will do after the disaster, to make sure my rabbit gets cared for properly. I am not kidding–before the end of July I need to have this written rabbit disaster plan in place, or I am breaking the law."
Mr. Hahne also detailed the guidelines the USDA reportedly gave him:
• The new regulation became effective Jan. 30, 2012.
• The written plan must be completed by July 29, 2013.
• Mr. Hahne and his wife, Brenda, must be trained to implement the plan as written.
• The written plan must be available for review by USDA inspectors by Sept. 28, 2013.
http://www.washingtontimes.com/news/2013/jul/1/agriculture-department-tells-magician-write-disast/
What the fuck is this LMAO. If I ever come across someone unfamiliar with the idea of regulatory overreach, this is the first thing I’ll send them.
industrious idiots
There was an interesting side thread on employee matrices:
There’s a quote from a German general:
“I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent — their place is the General Staff. The next lot are stupid and lazy — they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent — he must not be entrusted with any responsibility because he will always cause only mischief.”
There’s a 2x2 matrix you can put employees into with one side being smart/idiot and the other being lazy/industrious. There is no greater threat than the industrious idiot.
This is so true. I’ve been in so many organizations where people are rewarded for their “work ethic” and their “commitment to the organization” above all else. There really isn’t anything else that they’re evaluated on; I’ve rarely seen people rewarded for driving organizations toward the metrics or goals their organization is supposed to be oriented towards. And I certainly agree with the conclusion that there is no greater threat than the industrious idiot.
systems designed for certain levels of expertise
There was an interesting thread around establishing “competency bands” around systems, or at least a baseline level of understanding that helps people operate effectively within specific systems.
I’ve encountered a similar phenomenon with regard to skill as well: people want to ensure that every part of the software system can be understood and operated by the least skilled members of the team (meaning completely inexperienced people).
But similarly to personal responsibility, it’s worth asking what the costs of that approach are, and why it is that we shouldn’t have either baseline expectations of skill or shouldn’t expect that some parts of the software system require higher levels of expertise.
Conversely, what’s too simple or too difficult is very specific to the person. Somebody who’s coming to a junior developer role from a data science background might have no problem reading 200 lines of SQL. Somebody with FP background might find data transformation pipelines simple to understand but class hierarchies difficult, and so on. So the "easy to understand for anyone" guideline proves less than useful for establishing an upper bound on allowed complexity as well.
Therefore, I find that it’s more useful to talk about a lower and upper bound of what’s required and acceptable. There are things we should reasonably expect a person working on the project to know or learn (such as most language features, basic framework features, how to manipulate data, how to debug etc.) regardless of seniority. On the other hand, we don’t want to have code that’s only understood by one or two people on the team, so perhaps we say that advanced metaprogramming or category theory concepts should be applied very sparingly.
Once that competency band is established, we can work to bring everyone into the band (by providing training and support) rather than trying to stretch the band downwards to suit everyone regardless of experience. — source
I think this is the best way to look at onboarding processes. Before onboarding, the team/org needs to establish a competency band for all of the systems that people need to know, and the onboarding process should get people up to the lower bound so that they’re ready to meaningfully contribute.
The below comment is just a funny story lol:
Reminds me of a dev team I once encountered where they stated they wanted to be expert C programmers and that they didn't understand pointers, so they avoided them.
I told them it was hard to become a C expert without understanding and using pointers and they didn't like that answer. https://daedtech.com/how-developers-stop-learning-rise-of-th...
examples of gross bureaucracies
Defense department:
In order to publish a research paper, it has to be reviewed for suitability for public release. This process is more than a little silly, because it requires seven levels of review, of which exactly one - my immediate supervisor - will have any idea what the paper is about. But fine.
There used to be a paper form. You'd fill it out and either route it around for signatures, or if you had a time crunch, walk it around yourself. Eventually they replaced the paper form with a web form, so now there's an automated queuing system that emails people when they have a paper waiting to be reviewed.
The web form has all of the same info as the paper form, with one addition. They scanned the paper form and turned it into a pdf, and they make you fill out both the web form AND the pdf version of the original paper form. So to sign off on a paper, you now have to download the pdf, digitally sign it, upload it again, and hit the "Approve" button on the web form.
Because God help us if anybody does an audit and we don't have all of the forms correctly signed.
Medical device manufacturer:
At a medical device manufacturer I worked at, it’s even worse: you print a copy of the thing to sign and sign it, then upload that to the digital system and digitally sign there too. You end up with several people printing huge documents, not just the signature page, and each signing a different copy which is uploaded then thrown away. That’s right, one paper copy per person is signed, scanned, then shredded.
Hahahaha no fucking way.
siloes as a contributing factor
In my experience, the more siloed an organization, the more bureaucracy you end up with.
We've all had those experiences where, the problem we are trying to solve isn't inherently difficult - it's difficult because three separate teams are in charge of parts A, B, and C of the problem, and getting them to talk to each other, align their roadmaps, change their processes, etc. is impossible, unless you can go above their heads and force them to do it.
So true. This is what happens when you give “stakeholders” ownership over different slices of the pie. It becomes impossible to make meaningful improvements that horizontally affect many different groups.
imposing costs on others
This is just an incredibly insightful comment:
A key feature I see that rampantly grows bureaucracy: the ability to impose costs upon other teams without accountability. This takes many forms, but common ones include the following. People don't say the following outright, you spot these a mile away when actions speak louder than words.
"I don't have to know how what I tell you to do fits into the overall flow of what you want to accomplish between multiple different teams. That's your problem, go talk to all the different teams you have to work with to get approvals and figure it out yourself, that's not my problem."
"I acknowledge absolutely nothing has changed, and I will never use what you create, but format A has changed to format B because everything new is in format B, and thus you must spend time to re-create everything in format B so everything in my filing system is consistent."
"Yes, this is recording the information twice in two different ways. By hand. And with no enforcement to keep it up to date. But I'm only measured on recording the information, and as long as Number Go Up on the recordings, it is not my problem."
"Yes, the new form has not been published. Yes, the new requirement for these approvals have not been put into existing processes that take months to grind out a decision, much less the processes debugged. But in six months, everyone must follow what we publish in several months leaving only two months for you to implement in 3-4 months a new, untried process. No, we will not talk about this possibly creating a bottleneck and exacerbating the flow, that won't happen."
If there was a chargeback of effort to this kind of mindset and decisions, then a different political battle would emerge, but at least it would make these kinds of unilateral, unaccountable decisions in their aggregate form visible to the organization. A tremendous amount of this friction goes away if organizations had the capacity to automate many processes, but the cost hurdle is currently too high for most organizations. I'm hopeful LLM's in the hands of non-technical staff can mitigate that, but I'm likely dangerously naive there.
There absolutely needs to be a more detailed accounting of the costs that certain decisions have upon others and the organization overall.
navigating bureaucracies
You haven't seen anything until you've spent a career working in and around measurement & testing bureaus which go back to the 19th century themselves :\
Which are only involved with much bigger institutions harboring their much larger, dissimilar but more dysfunctional and less-professionally-developed "inadvertent" bureaucracies which are most often layered on under emergency conditions.
Hint, the key word is work around.
Don't even think about it until you've spent however many years it takes to "master" the bureaucracy itself, working from within.
Before you even attempt your first workaround, or you could be shot down in flames without a parachute.
I've said it before but you can't herd cats unless you're a cat already.
“You could be shot down in flames without a parachute” — as someone who’s been shot down into flames several times without parachutes, fully agreed. Navigating bureaucracies is a skill in and of itself.
the principal-agent problem
> I think it's because organizations can only work at scale if they minimize the variance of each individual business unit, and malleability threatens that.
It's because of the principal agent problem.
As organizations grow, people inside it become less and less oriented towards the organizational goal. The rigidity appears to fight that.
Always true. But how do we combat this? Is it even possible or desirable?
Very insightful. When an organization is small, the individuals protect the org, and are incentivized to. The org cannot survive without strong alignment between individuals. At some point, when sufficient scale has been achieved, the org crystallizes to protect itself from certain actors that prioritize the individual over the org. The rigidity is a defense mechanism, an immune system of sorts.
“An immune system of sorts.” This is a remarkable way of looking at this! In the early stages, there’s a higher hit rate of people who prioritize the organization over the individual (since only those types of people take risks at smaller ventures). As organizations grow, there’s a lower hit rate on those kinds of individuals, and it becomes a survival imperative to minimize the harm that those individuals can do to the organization.
There is a school of thought about management by intent that tries to address this, following the ideas born out of the Prussian army in the early 1800s.
But many of our current problems are more directly related to Taylorism and an intentional separation of design from production.
GMs failure to learn from Toyota at the NUMMI plant is a well documented modern example, with Japan intentionally targeting the limits of Taylorism to basically destroy the US industrial market is another.
The centralized command and control model also ignored the finite congitive ability and assumed the relational omniscient actors.
The funny thing is that multiple Nobel prizes have been awarded related to some of the above, and we know that Taylor faked some of his research and most business tasks are not equivalent to loading pig iron onto train cars anyway.
Even TOGAF and ITIL recently made changes after the Feds changed the Klinger act, moving away from this model and every modern military uses mission command vs C2, but management is still teaching the pseudo scientific management school of thought and not addressing the needs modern situations.
The incentive models are largely a reason for this and recent developments like 'impact' scores push things back even more.
You can still have a principal-agent relationship, but delegate and focus on intent and avoid this trap, but it requires trust and bidirectional communication.
Really IMHO, or comes down to plans being safe feeling, high effort and compatible with incentives.
Those plans never survive the real world, because of the actors bounded rationality and knowledge.
A book that is potentially a useful lens into this is 'The art of action', but it is just a lens.
Organization 'goals' are often poorly communicated and useless because 'planning' is insufficient and not durable enough.
Being way past any horizon that can be planned for, actionable concepts of shared intentions and purpose are not communicated.
Toyota gave teams concrete goals to obtain, allowed them to self organize and choose how to deliver.
GM meticulously copied what those teams had done and forced Detroit teams to follow those procedures and it failed.
It was allowing the teams, which understood the context and constraints of their bounded problems that worked, not the procedures themselves.
Amazon's API mandate resulted in a product mindset and scaled better than almost everyone until culture erosion killed that.
Delegating works, but centralized process needs to be restricted to the minimum necessary.
Unfortunately the negative aspects of bureaucracy seem artificially successful in the short term, but the negative aspects of setting things in concrete are long tailed.
The growing disengagement problem is one of those long tails IMHO.
Many gems in the comment above!
general comment
Shooting a specific problem with general solution together with obscuring the feedback loop are perfect recipe for making bureaucracy
mhmmmmm yep.
final thoughts
The discussion was really cool! This is the first time something I’ve posted has sparked the kind of discussion that it did, and my thoughts are much more developed as a result of what everyone else shared.
I do think there was a general negative sentiment in the discussion towards working in large organizations which tend to be bureaucratic and inefficient, with some people saying they hope their organizations never grow to that kind of scale.
And this is true! Larger organizations will always be less efficient than smaller ones. I think there are some scaling laws at play. If there’s a team of 1 person, then 100% of their effort is focused on raw output. If there’s a team of 10 people, then, for example, 1 person's worth of work is just focused on coordination, so there’s a maximum of 90% of effort that can be focused on raw output. If there’s a team of 100 people, then maybe there’s 30 people's worth of work required that is just focused on coordination, so there’s a maximum of 70% of effort that can be focused on raw output. These are completely arbitrary numbers, but the point remains; smaller teams by definition have a higher ceiling of efficiency than larger ones.
However, even if larger organizations are less efficient in terms of raw output, they are still capable of creating solutions at a dramatically different scale than smaller organizations; they’re able to tackle a different class of problems. Think about the COVID-19 vaccine; it’s not possible to get something created as quickly as it was without large groups of people operating really effectively in tandem, and it’s clearly miraculous what happened when they were able to coordinate effectively.
Large groups of people working effectively together can move mountains, which is something that individuals and small teams simply are incapable of. This is why I’m obsessed with figuring out this coordination problem.