[HN Gopher] Understanding how bureaucracy develops
___________________________________________________________________
Understanding how bureaucracy develops
Author : dhruvmethi
Score : 156 points
Date : 2024-10-17 14:32 UTC (3 days ago)
(HTM) web link (dhruvmethi.substack.com)
(TXT) w3m dump (dhruvmethi.substack.com)
| robwwilliams wrote:
| Greatly enjoyed this commentary. The example of IRB approvals for
| biomedical research is unfortunately on the mark.
|
| How much of a full time researcher's time is bureaucratic
| overhead? In my case no more than 10% but it feels like 30%.
| dhruvmethi wrote:
| Thank you for reading!
|
| Even if it takes up only a small percentage of time, it
| probably takes up the majority of frustration (that's at least
| true for me)
| fuzzfactor wrote:
| 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.
| nine_zeros wrote:
| This is a very well written article. And I firmly agree with this
| from first-hand experience.
|
| Organizational malleability is key. But it wouldn't work in FAANG
| style standardized performance review style of work.
| dhruvmethi wrote:
| Agreed - as organizations scale, it's like some kind of
| fundamental law of thermodynamics that says they must become
| more bureaucratic in order to remain competitive. 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. I still think that good enough leadership and
| communication should allow for malleable units to coexist well
| together, but that may be a naive ideal.
| marcosdumay wrote:
| > 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.
| toomuchtodo wrote:
| 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.
| nyrikki wrote:
| 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.
| marcosdumay wrote:
| Well, yes to all of that.
|
| Taylorism is actually an attempt to make organizations
| flexible given that the more subordinated people are all
| completely unaligned with the organization goals and the
| management is in closer alignment. It's a very direct
| consequence of that.
|
| Of course, the irony on it is that reality is often
| closer to the other way around.
| fuzzfactor wrote:
| >the irony on it is that reality is often closer to the
| other way around.
|
| All too often the front-line workers do not have a direct
| voice that will be responded to from above in anything
| but a generic way.
|
| So without guidane from above, or in spite of it, the
| lower echelon ends up aligned most closely with the macro
| vision of what they think the company is supposed to be
| like traditionally or as a unit, and it's often quite a
| bit different than some leaders toward the top who are in
| position to identify and gravitate to directions that are
| more lucrative for themselves than the company as a
| whole.
| tomjen3 wrote:
| I have long thought that you should resist growth in people
| at all costs - there were famously a very small number of
| people working at Instagram when it was acquired.
| shadowmanifold wrote:
| I would think there is some kind of information entropy and
| scaling laws at work.
|
| It could all be represented by a graph but it is a huge
| measurement problem.
|
| Minimize the variance of what with a business unit? It is not
| clear to me there is one measure that would apply across
| business units. I suspect that is part of the problem and
| something that gets amplified with scale.
| sevensor wrote:
| 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."
| hypeatei wrote:
| I've never seen it put so succinctly but this is the issue I
| have with blameless culture. We can design CI pipelines,
| linters, whatever it is to stop certain issues with our
| software from being released but if someone is incompetent,
| they don't care and _will_ find a way to fuck something up and
| you can only automate so much.
| liquidpele wrote:
| 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.
| wffurr wrote:
| 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."
| stoperaticless wrote:
| I guess we should not take blameless to the extreme.
|
| Some feedback must exist. (calm, obective and possibly
| private) Eventually it is up to the manager or manager's
| manager to be aware what is happening and take action if
| critically needed.
| chikere232 wrote:
| Everyone, including the most competent, makes mistakes
| though.
|
| If single small mistakes have disastrous consequences, the
| system is probably too brittle. Approaching it from a
| blameless angle gives you a better chance of fixing it, as
| people will cooperate to fix the issue rather than be busy
| not getting fired
|
| You can still identify and fire/relocate/retrain incompetent
| people, but that is better done as a continuous thing than as
| a response to a mishap
| linuxlizard wrote:
| >When you treat every negative outcome as a system failure, the
| answer is more systems.
|
| Holy crap, I'm going to save that quote forever. I have a co-
| worker who treats every line of bad code committed as a reason
| to add ever more layers to CI. Yo, we caught it in testing.
| There's no reason to add another form we have to fill out.
| cma wrote:
| Why does CI require forms?
| SupremumLimit wrote:
| This is a wonderfully insightful comment!
|
| 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.
| jiggawatts wrote:
| There is the reason Haskell or F# are relatively unpopular
| and Go has a much wider footprint in the industry: high
| expertise levels don't scale. You can hire 100 juniors but
| not 100 seniors all trained up in the _same_ difficult
| abstractions.
|
| Conversely, one skilled senior can often outperform a hundred
| juniors using simpler tools, but management just doesn't see
| it that way.
| SupremumLimit wrote:
| Indeed, specialist knowledge is a real constraint, but I
| think it's possible to at least _orient_ towards building
| systems that require no baseline level of skill (the fast
| food model I guess) or towards training your staff so they
| acquire the necessary level of skills to work with a less
| accessible system. I suspect that the second pathway
| results in higher productivity and achievement in the long
| term.
|
| However, management tends to align with reducing the
| baseline level of skill, presumably because it's convenient
| for various business reasons to have everyone be a
| replaceable "resource", and to have new people quickly
| become productive without requiring expensive training.
|
| Ironically, this is one of the factors that drives ever
| faster job hopping, which reinforces the need for
| replaceable "resources", and on it goes.
| stoperaticless wrote:
| Also there is no easy way for management to know if
| somebody has required level of skill.
| fuzzfactor wrote:
| Which is why the most important qualification for a
| manager is to always consistently put in way more effort
| than the average worker, and be very, very good at doing
| things that are not the least bit easy at all.
| jjav wrote:
| > Conversely, one skilled senior can often outperform a
| hundred juniors using simpler tools, but management just
| doesn't see it that way.
|
| Management is correct, if that's the question.
|
| In some very rare bleeding edge cases it is true. Everyone
| wants to think their company is working on those areas. But
| here's the truth: your company (for any "you") is actually
| not.
|
| If you're writing code that is inventing new techniques and
| pushing the hardware to limits not before imagined (say,
| like John Carmack) then yes, a single superstar is going to
| outperform a hundred juniors who simply won't be able to do
| it, ever.
|
| Asymptotically close to 100% of software jobs are not like
| that (unfortunately). They're just applying common patterns
| and libraries to run of the mill product needs. A superstar
| can outperform maybe 3-4 juniors but that's about it. The
| jobs isn't that hard and there are only so many hours in a
| day.
|
| This is made worse today because neither quality nor
| performance matter anymore (which is depressing, but true).
| It used to be the software had to work fast enough on
| normal hardware and if it had bugs it meant shipping new
| media to all customers which was expensive. So quality and
| performance mattered. Today companies test everything in
| production and are continuously pushing updates and
| performance doesn't matter because you just spin up 50 more
| instances in AWS if one won't do (let the CFO worry about
| the AWS bill).
| aleph_minus_one wrote:
| > A superstar can outperform maybe 3-4 juniors but that's
| about it. The jobs isn't that hard and there are only so
| many hours in a day.
|
| There _do_ exist (I would even claim "quite some")
| jobs/programming tasks where superstars are capable of,
| but a junir developer will at least need _years_ of
| training to be able so do /solve them (think, for
| example, of turning a deep theoretical breakthrough in
| (constructive) mathematics into a computer program; or
| think of programming involving deep, obscure x86 firmware
| trivia), but I agree with your other judgement that such
| programming tasks are not very common in industry.
| ifyoubuildit wrote:
| You don't even need to go to rocket science for this.
|
| 3-10 juniors can make a massive expensive mess of a crud
| app that costs $x0k a month in amazon spend and barely
| works, while someone who knows what they're doing could
| cobble it together on a lamp stack running under their
| desk for basically nothing.
|
| Knowledge/skills/experience/ can have massive impact.
| jjav wrote:
| > 3-10 juniors can make a massive expensive mess of a
| crud app that costs $x0k a month in amazon spend and
| barely works, while someone who knows what they're doing
| could cobble it together on a lamp stack running under
| their desk for basically nothing.
|
| Yes! Absolutely. It will be faster and more reliable and
| an order of magnitude (or more) cheaper.
|
| Alas, I'm slowly (grudginly and very slowly) coming to
| terms accepting that absolutely nobody cares. Companies
| are happy to pay AWS 100K/mo for that ball of gum that
| becomes unresponsive four times a day, rather than pay
| for one expert to build a good system.
| fcatalan wrote:
| Programming doesn't happen in a vacuum, and experience
| and institutional knowledge can account for many orders
| of magnitude of performance. A trivial example/recent
| anecdote:
|
| The other day, two of our juniors came to see me, they
| had been stumped by the wrong result of a very complex
| query for 2 hours. I didn't event look at the query, just
| scrolled down the results for 10 seconds and instantly
| knew exactly what was wrong. This is not because I'm
| better at SQL than them or a Carmack level talent. This
| is because I've known the people in the results listing
| for basically all my life, so I instantly knew who didn't
| belong there and very probably why he was being wrongly
| selected.
|
| Trivial, but 10 seconds vs. 4 man hours is quite the
| improvement.
| jjav wrote:
| > Trivial, but 10 seconds vs. 4 man hours is quite the
| improvement.
|
| Sure. But now try sustaining that impact multiplier every
| minute, 8 hours a day for a year.
| nox101 wrote:
| I'm not sure I understand this position. What I hear is
| "obscure hard to understand code is good" but as others have
| said, code will be maintained and modified for years to come
| and not by the original author so making it easy to
| understand and follow is usually the recommendation. Even the
| original programmer will usually find it easier to understand
| their own code months or years later
|
| Did you mean something else?
| stoperaticless wrote:
| Extreme A: every team member is litterally five years old
| (born 5 years ago)
|
| Extreme B: every collegue is required to read and be able
| to recite x86, C specifications, postgre manual, and must
| have IQ 190+.
|
| What is obscure or hard to understand is subjective.
| SupremumLimit wrote:
| Yes, I meant something else, and of course I'm not
| advocating for hard to understand code. However, as the
| sibling comment suggests, what's obscure or hard is
| relative.
|
| The problem with indiscriminate application of "code has to
| be easy to understand" is that it can be used to make
| pretty much _anything_ , including most features of your
| language, off limits. After all, a junior developer may not
| be familiar with any given feature. Thus, we can establish
| no reasonable lower bound on allowed complexity using such
| a guideline.
|
| 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.
| poulsbohemian wrote:
| But there's also an element where this isn't due to system
| failure, but rather design. Companies want to make their
| processes bureaucratic so that you won't cost them money in
| support and so you won't cancel your subscription - making the
| process painful is the point. Likewise in government - it isn't
| that government can't be efficient, it's that there are people
| and organizations who want it to be encumbered so that they can
| prove their political point that government is inept. One side
| wants to create funding for a program, the other side puts in
| place a ton of controls to make spending the money for the
| program challenging so they can make sure that the money isn't
| wasted - which costs more money and we get more bureaucracy.
| schmidtleonard wrote:
| 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.
| tdeck wrote:
| 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.
| Spivak wrote:
| 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.
|
| I'm never going back to that kind of culture, it's soul
| crushing.
| yunohn wrote:
| Yep, this is accurate IME.
|
| In modern corporate blameless culture, nobody takes the
| blame. Now this has its own variety of issues, it's not
| perfect. But if you look at blame culture, then exactly like
| OP said, you have to stop building and start protecting. You
| know who has time for that? The underperforming lazy
| employee.
| scott_w wrote:
| I want to offer a mild counter which is that blameless post
| mortems shouldn't mean people escape accountability for
| misconduct. Only that we focus on how to improve systems.
|
| If, as an accountable leader, you realise that someone
| ignored the processes and protections, you still have the
| right to hold them accountable for that. If someone is
| being lazy, it's your job to identify that and fire that
| person.
|
| I won't pretend it's easy, and I fully appreciate
| organisations struggle to make that happen for the reasons
| you and the article raise.
| yunohn wrote:
| I'm not advocating for avoiding accountability for
| misconduct/malice - but in most companies, things are
| convoluted enough that individual blame is often
| misplaced, one is always juggling various limitations and
| issues trying to deliver.
|
| However, the broader problem I have with blame-focus is
| that it only applies to Individual Contributor roles.
| I've never heard of middle management being held
| accountable for any actions whatsoever. And obviously not
| for less "egregious" misconduct like toxicity, workload,
| favoritism, etc. Heck middle managers can be completely
| ignorant of their reports' actual work and survive for
| decades.
|
| In my experience at FAANG, the worst of managers will get
| reassigned to a different team, and maybe have their
| promotion delayed. Occasionally, I've seen VPs get put on
| nearly a year of gardening leave after major misconduct
| like sexual harassment - and then they leave and become a
| C level at a smaller company. And of course, CEOs are
| fired only for complete mismanagement and company failure
| - and that's a very high bar and can take forever until
| shareholders loudly complain.
|
| Basically, my point is that you can only blame the actual
| workers at the end of the chain - everyone else along the
| way is easily shielded and escapes blame.
| scott_w wrote:
| > I'm not advocating for avoiding accountability for
| misconduct/malice - but in most companies, things are
| convoluted enough that individual blame is often
| misplaced, one is always juggling various limitations and
| issues trying to deliver.
|
| I didn't think you were advocating for the situation that
| occurs. I was merely proposing that "blameless" processes
| are possibly mis-assigned blame (heh) for company
| cultures that become centred around ducking
| accountability.
| willcipriano wrote:
| People who aren't the getting blamed all the time call it
| accountability culture rather than blame culture.
|
| Some people want to be holding the bag, if the bag is full of
| money. All risk no reward won't attract accountable people.
| ryandrake wrote:
| This is why CEOs and other very senior leadership people
| have no problem accepting "blame." Because their contracts
| are set up so they get even richer no matter what they do!
| If your company does well, the CEO takes credit and becomes
| even more fabulously wealthy. If your company does poorly,
| the CEO takes the blame and leaves on a golden parachute,
| becoming only moderately more wealthy. Either way, they
| become more wealthy.
|
| If screwing up my job meant getting fired with a $5M golden
| parachute, I would be more than happy to be assigned
| individual blame!
| cyanydeez wrote:
| Geez.
|
| Someone has no idea how modern human psychology is the only
| thing creating any of these super structures and their
| frailties.
|
| We aren't ever going to be your super ant organism, get over
| it.
| jancsika wrote:
| > When you treat every negative outcome as a system failure,
| the answer is more systems.
|
| Eloquently put. Also, likely false.
|
| E.g., soft-realtime audio synthesis applications like Pure Data
| and Supercollider have had essentially the same audio engines
| since the 1990s. And users see _any_ missed audio deadline as a
| negative outcome. More to the point-- for a wide array of audio
| synthesis /filtering/processing use cases, the devs who
| maintain these systems consider such negative outcomes as
| systemic failures which must be fixed by the devs, _not_ the
| users. I can 't think of a more precise example of "blameless
| culture" than digital artists/musicians who depend on these
| devs to continue fitting this realtime scheduling peg into the
| round hole that is the modern (and changing!) multitasking OS.
|
| While there have been some changes over the last 30 years, in
| no way way have any of these applications seen an explosion in
| the number of systems they employ to avoid negative outcomes.
| There's one I can think of in Pure Data, and it's optional.
|
| IMO, there's nothing noteworthy about what I wrote-- it's just
| one domain in probably many across the history of application
| development. Yet according to your "law" this is exceptional in
| the history of systems. That doesn't pass the smell test to me,
| so I think we need to throw out your ostensible law.
| stoperaticless wrote:
| Different kinds of systems?
|
| > devs who maintain these systems
|
| What is meant by "system" here? Computer application?
| Hardware?
| gamblor956 wrote:
| A negative outcome is a system failure, even if it is a
| personal failure that drove the outcome, because that is a
| failure of the system to prevent personal failures from causing
| negative outcomes.
|
| You can't stop personal failures from happening because people
| are people. You can design processes to minimize or eliminate
| those personal failures from yielding negative outcomes.
| AnimalMuppet wrote:
| But too much system can _also_ cause negative outcomes,
| because all that system has a cost, both in money and in
| time. If you add a protection to prevent every negative
| outcome, your system will never produce anything at all,
| _which is a negative outcome_.
|
| Every check has a cost. For some checks, the cost is more
| than it prevents. Don't add those checks, even after the
| negative outcome happens.
| tom_ wrote:
| The past was allowed to play itself out. Why not the present
| too?
| throwawayian wrote:
| This approach is what's caused so many cybersecurity, privacy
| and preventable data breaches.
|
| When everyone is responsible, nobody is.
| chikere232 wrote:
| 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.
| oooyay wrote:
| I feel like this comment is emblematic of a dramatic
| misunderstanding of blameless post mortems. They're pretty
| simple; systems that fail can be attributed to teams,
| practices, systems of understanding, etc which is diametrically
| opposed to _individuals_. Blameless culture isn 't a culture
| without blame, in fact there's plenty of blame that should be
| listed in contributing factors - including the accountable team
| (if there is one). There's just no, "John Smith did x and y
| failed" because that's rarely, if ever, succinctly how systems
| fail.
| alexashka wrote:
| Modern society is wage slavery. Wage slaves respond to their
| condition with malicious compliance [0].
|
| The rest is talk.
|
| [0] https://en.wikipedia.org/wiki/Malicious_compliance
| wavemode wrote:
| 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.
|
| I think about organization design similarly to software design.
| It's tempting to think about your software design from the top-
| down, and design a hierarchy of siloed interfaces with
| encapsulated private data and strictly separated concerns. This
| looks beautiful on paper, but then in practice you now have to
| navigate through a sea of objects and abstractions and
| redundancies - getting anything meaningful done often requires
| "punching holes" through the siloes so data can be shared.
|
| Organizations are the same way. Paul Graham wrote an essay[0]
| recently about the differences between "founder mode" and
| "manager mode". In a nutshell, managers usually think about
| organizations as silos - we divide up the company into a
| hierarchy of departments and teams and levels, so that only
| directors talk to middle managers and only middle managers talk
| to supervisors and only supervisors talk to the individual
| contributors. Again, it looks great on paper, and is what most
| people are used to.
|
| But "founder mode" is when someone with a lot of political
| capital can step in and say, "you know what, I want to talk to
| the people on the ground. I want to find out what's actually
| going on below the surface in the org, not just the pre-packaged
| PowerPoint version I hear from my directors. I want to pull
| together people from across teams and across levels and across
| departments - whoever is best suited to making this project a
| success." I think that sort of "hole punching" can be really
| powerful, if the company's culture is amenable to it.
|
| [0]: https://paulgraham.com/foundermode.html
| liquidpele wrote:
| To a founder, the success of the company means their own
| success. To a manager, success is to climb a ladder, any
| ladder. Their incentives are very different, and thus how they
| approach things will be.
| dennis_jeeves2 wrote:
| The question I have grappled with is, can a manager ever be
| made to feel like he has a sake in the company it in the true
| sense? Companies do attempt to have partners and share
| purchase plans but a true ownership may be out of reach,
| unless the founder makes sincere attempts to include the
| manager in decision making etc. Even then I suspect a founder
| may fail.
| GlenTheMachine wrote:
| Here's an example from my corner of the 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.
| ok_dad wrote:
| 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.
| IIAOPSW wrote:
| At least tell me the shredded paper is recycled so that the
| next document can be printed signed and shredded on it.
| dalmo3 wrote:
| Shredchain? Veracity by Proof of Shredding.
| toomuchtodo wrote:
| Is a list or inventory maintained of research papers that
| aren't published? What happens to those papers?
| GlenTheMachine wrote:
| In my experience no research paper _ever_ gets rejected, at
| least for reasons that have anything to do with their
| content. If your paper gets rejected, it is almost always
| because you failed to put the appropriate markings on the
| paper, or filled the form out wrong, and then you missed the
| conference deadline so the whole thing was OBE.
|
| There is indeed a list of rejected papers. The system logs
| all of them. Generally they're recycled, updated, and
| published elsewhere.
| SiempreViernes wrote:
| The list is probably not very interesting, the main benefit
| of these sort of censorship systems is that every knows of
| them and thus self-censor their output ahead of the explicit
| review step.
| IIAOPSW wrote:
| I'm pretty torn about this, because I am also deeply skeptical of
| exactly the sort of situations an IRB is set up to prevent.
| Things like requiring documents to be signed in pen are an
| important part of a secure audit trail. And an appropriate audit
| trail with proper safe guards is absolutely essential especially
| given the way personal health related things are conducted in the
| inherent darkness of confidentiality. The privacy protections of
| personal health records also happens to be just as effective at
| keeping evidence of corrupt conduct within the system private as
| well.
|
| Maybe the real problem is that there is (at least to a degree) a
| trilemma between effective, safe from research misconduct, and
| respectful of individual privacy.
| underbiding wrote:
| Where does the perception that signing a physical piece of
| paper with pen is an important part of a secure audit trail?
|
| If a signature is meant to represent both intent and identity,
| what is it about the physical medium which makes it more ideal
| than a digital signature where you're prompted to enter in your
| login password or something similar?
|
| Is it the belief that its less forgable, that electronic audit
| trails are more easily duped and spoofed while signature blocks
| and paper/pen is somehow immutable (despite the decades of
| forged signatures easily traced from other sources)?
|
| Never understood this idea whatsoever, it just strikes me as a
| form of pearl-clutching over some nebulous hackers that could
| easily destroy our well-oiled pen/paper/document machines.
| IIAOPSW wrote:
| As per the article, the alternative was pencil not digital.
| For whatever reason the rule of the mental ward was there
| could only be access to pencils. Pencil marks are indeed more
| mutable and thus more vulnerable than pen.
|
| Electronic signatures are an entirely different (and
| interesting) thing to consider.
| jpeloquin wrote:
| According to the original account, the pencil/pen thing wasn't
| about an audit trail, and both the IRB and hospital admin were
| equally silly.
|
| > IRREGULARITY #3: Signatures are traditionally in pen. But we
| said our patients would sign in pencil. Why?
|
| > Well, because psychiatric patients aren't allowed to have
| pens in case they stab themselves with them. I don't get why
| stabbing yourself with a pencil is any less of a problem, but
| the rules are the rules. We asked the hospital administration
| for a one-time exemption, to let our patients have pens just
| long enough to sign the consent form. Hospital administration
| said absolutely not, and they didn't care if this sabotaged our
| entire study, it was pencil or nothing.
|
| https://slatestarcodex.com/2017/08/29/my-irb-nightmare/
| TacticalCoder wrote:
| Look at what the DIV is achieving. Look at what SpaceX and
| StarLink are achieving.
|
| When in doubt: don't imitate the DIV.
| gruez wrote:
| What is "the DIV"?
| natmaka wrote:
| Probably "The Diversity Immigrant Visa program, also known as
| the green card lottery, is a United States government lottery
| program for receiving an immigrant visa followed by a
| permanent resident card." (per Wikipedia:
| https://en.wikipedia.org/wiki/Diversity_Immigrant_Visa )
| physicsgraph wrote:
| To summarize the main two take-aways, measure ROI (return on
| investment) and be Agile.
| natmaka wrote:
| 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 :
| fcatalan wrote:
| I've always seen a dilemma with increased bureaucracy driven by
| corruption prevention:
|
| Systems too focused on defeating corruption as a main objective
| tend to miss their original intent, and become overly
| restrictive, to the point of having to rely on rule breaking to
| actually perform their function.
|
| But once a particular rule is OK to break, every other rule is in
| jeopardy.
|
| This way you end up with systems like the Spanish access to
| public jobs: extremely punishing for the participants that are
| subject to humongous nonsensical competitive examinations,
| ostensibly to select the very best strictly on their merits, but
| still rife with corruption.
| dennis_jeeves2 wrote:
| >Organizations don't just naturally become bureaucratic as they
| grow; they become bureaucratic as a result of deliberate
| decisions made by leaders who at the time believed they were
| doing the right thing.
|
| These leaders will have to be held accountable. Generally one
| want to do the dirty job. It boils down to people and nothing
| else. Any attempt at analysis the system without considering
| people's intelligence/character is premature.
|
| My partial take on it: https://quberoot.wordpress.com/partners/
| lbriner wrote:
| I have a few personal thoughts on this but I think it ultimately
| comes down to the variation between people being more complex and
| harder to measure than it seems.
|
| In a startup, there is some natural way to choose the 1 right
| person for the job, say, the Developer. They probably wouldn't be
| chosen unless they have a high level of ability, communication
| skills (hopefully) and a lot of productivity and proactivity.
| This could be directly related to the potential rewards of equity
| etc. but maybe not, maybe they are happy to be free to work at
| high and low level and to make educated decisions on everything.
| I did this job for the same money as my older job without much
| expectation of a large payout (never got one!)
|
| But as soon as you hire 1 other person, things immediately
| change. It isn't just about their ability, although we often talk
| about that both in terms of testing it during interview but also
| measuring it using some KPI but a person is much more than
| ability. You can have ability and be lazy or lack ability but are
| a quick learner. You might be really easy to get on with but your
| stuff is slightly above average, or a complete a-hole but produce
| rock-solid code. You might be reliable, you might not, you might
| be motivated all the time, some of the time or none of the time.
| As much as we like to think we can have regular performance
| reviews, you can't put numbers on those things but you can put
| process. I can arrange a daily standup and weekly progress
| reviews to get slightly better at making sure you are on-track. I
| can try and count things like tasks completed or LoC or Stories
| completed or bugs in production etc. but these are also a rich
| tapestry and after-all, do you compare them to the 10x coder that
| you are?
|
| Some people need to be told to do something properly, they need
| process, others will do it properly without being asked, they
| have passion. How can you tell? Mostly gut feel, and maybe a
| checklist! I think there is also a myth that if we only had
| tonnes of cash, we could be much more picky with hires and only
| get the best, that would remove a lot of bureaucracy but look at
| FANNG companies, they have this problem in buckets. People can
| fake their ability and passion to a point, they have 1000s of
| applications to process and they still have tonnes of meetings.
| Even if you hire someone with the same passion and ability as
| you, they will be still be different. They will be insistent on
| VueJS instead of C#, TDD instead of DDD, Unit Tests for
| everything or UI tests for some things. Each of those is OK but
| you still then create that Architect position to ensure
| consistency between teams, the Project Leader to ensure delivery
| times are balanced with technical perfection.
|
| Personally, I have never believed that a company with more than,
| say 200 employees can ever be efficient. They can be rich but
| eventually they will buckle under their own red-tape or at the
| next culling that takes place under the "new trendy CEO who had
| successes at previous companies".
| nickdothutton wrote:
| If I start another company, it is my sincere hope that I never
| have to grow it beyond 200 people. Ideally not more than 100
| now that so many functions can be automated or outsourced these
| days.
| yourapostasy wrote:
| 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.
| nineteen999 wrote:
| Just look at how Agile has turned out ... the thing is loaded
| with bureacracy from standups, retros, kanbans, scrums. It's way
| more bureaucratic and dogmatic than waterfall ever was. Y'all
| just don't notice cause the frog has been boiled slowly in the
| pot, or because you didn't grow up in the "waterfall" era.
___________________________________________________________________
(page generated 2024-10-20 23:01 UTC)