[HN Gopher] Efficiency is the enemy?
___________________________________________________________________
Efficiency is the enemy?
Author : ivanvas
Score : 107 points
Date : 2022-05-06 14:10 UTC (8 hours ago)
(HTM) web link (fs.blog)
(TXT) w3m dump (fs.blog)
| TimSchumann wrote:
| I really dislike blogs/articles/publications that don't have a
| publication date prominently placed for the reader. This, at
| least according to the wayback machine, is from at least October
| 31st, 2021 -- Although I seem to remember reading it before this
| date.
|
| It really does the reader a disservice by not giving them the
| temporal context in which the words were written.
| takiwatanga wrote:
| Previously on hn: https://news.ycombinator.com/item?id=27036695
| chrchang523 wrote:
| See also https://thezvi.wordpress.com/2017/09/30/slack/ , which
| makes the point that slack and efficiency are _not_ opposites:
| "Slack prevents desperation. You can avoid bad trades and wait
| for better spots. You can be efficient."
| jrm4 wrote:
| Efficiency is the opposite of redundancy, and both are needed in
| particular situations. The question is always, what are you
| optimizing for?
| dgan wrote:
| I guess like optimizing for throughtput != optimizing for latency
| michael1999 wrote:
| The real enemy is optimizing for utilization which people think
| is the same as optimizing for throughput. Anti-slack is exactly
| this error.
|
| Optimizing for latency will often improve system throughput,
| and maximum throughput almost never shows 100% utilization.
| bena wrote:
| The article can be summed with with a link to the book it itself
| links:
|
| https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...
| hammock wrote:
| Pick the right tool for the job, based on its sheer ability to
| perform, not on its efficiency at performing.
|
| Once you have a process that works, _then_ you can focus on
| driving more efficiency out of it.
|
| AKA watch out for premature optimization.
| analog31 wrote:
| It's interesting that if labor units were replaced with money,
| the concept would be intuitively obvious to everybody: Having a
| certain amount of money that isn't earmarked for anything is
| practically the Singularity of personal finance.
| bumby wrote:
| Slack is great for resiliency, but it obviously can't be
| unbounded. The CEO in the article can't have 100 secretaries just
| in case. One of the great things about approaches like linear
| programming (programming in the sense of industrial engineering
| and not CS) is that it helps quantify how much that slack is
| worth. It can then be put into context of whether the risk
| tradeoff is worth the extra slack.
| bee_rider wrote:
| In a world where CEO time is apparently worth like 300X worker
| time, how many secretaries is the right number? I guess it is
| however many it takes to keep the CEO completely saturated with
| work...
| bumby wrote:
| That's exactly what my GP was commenting on. Instead of using
| heuristics like "however many it takes the CEO completely
| saturated with work" or assuming the CEO worth is 300x the
| secretary, you can quantify it. As soon as the value of the
| additional slack (organizational value or risk balance) is
| outpaced by the slack cost (secretary salary), you know
| you've added too much slack.
| hkt wrote:
| Assuming salary maps to value add, let's say if the CEO is
| worth 300x the secretary, he needs 300 secretaries.
| bumby wrote:
| I'm not sure if this comment was meant tongue-in-cheek, but
| wouldn't this assume the administrative overhead scales on
| a linear 1:1 ratio with the CEO's value? If a engineer's
| value is 2x another's, it doesn't necessarily mean the
| former uses, say, 2x the electricity/copier machine/office
| space. But maybe that was your point and I'm being dense.
| kixiQu wrote:
| let me recommend
|
| https://www.tbray.org/ongoing/When/202x/2020/07/05/Too-Effic...
|
| on this topic. Tim Bray's writing is always worth reading, but I
| think he's really valuable on this specifically.
| h2odragon wrote:
| Excellent rationalist restatement of the central Mystery of the
| Church of the SubGenius
| ddingus wrote:
| Efficiency by what measure?
|
| I like this piece. It speaks to an efficiency measure very often
| overlooked!
|
| The way I see this is everything comes with costs and risks. Good
| systems manage those.
|
| But they are not entirely eliminated.
|
| And that's the game! Running full capacity is more expensive than
| some reduced capacity, and what that number is depends on what an
| organization has incoming.
|
| Low latency responses to high priority events very seriously
| reduces overall costs. Having some degree of capacity to deal
| with it makes a ton of sense.
|
| Invariably, someone else sees that as an unused resource.
|
| The argument will be made that Gloria could actually be doing a
| lot and simply drop it when Tony ends up needing stuff.
|
| And while true, task switches are not free, nor is basic human
| readiness. For Tony, he values knowing Gloria has command of the
| details and has good processes she has likely used idle time to
| conceive.
|
| For Gloria, jumping into action is expected and normal. She is
| not haggard into a crappy state every day.
|
| Efficiency has different measures.
|
| I have seen similar in manufacturing where any capacity left
| unused seems like money left on the table. But the truth is
| people are often employing ideas to make their jobs easier, bring
| quality up, and the like.
|
| Sometimes parts need rework. Stuff happens. Doing that may well
| be transparent to others given there is some capacity to get the
| rework done.
| steve_adams_86 wrote:
| I wonder if this could be summarized as something like:
|
| Efficiency is only useful until it imposes on some degree of
| slack, or spare resource, which allows you to respond to
| aberrations which (inherently fragile) efficient systems can't
| accommodate very well (Although you could argue that an efficient
| system would accommodate systemic aberrations well, but then I
| wonder if it would be a semantic argument).
|
| Sort of like with finances. You could optimize your spending and
| investing as though economics are totally determinate, but they
| aren't, so you keep some cash as slack to accommodate cases where
| the shit hits the fan.
|
| When working on a project, you could schedule your time down to
| the wire and work as hard/smart as possible to hit the deadline
| perfectly, but it's not going to work out well every time (or
| often at all in software). So you figure alright, it seems like
| something that should take 3 days, I'll bank on 5. If you come in
| over or under, it works out well for everyone. There is not point
| in trying to max out on efficiency in these cases.
|
| In determinate environments where things really do work exactly
| as you'd expect, well, it's a different story. But human beings
| aren't that.
| petercooper wrote:
| Reminds me of https://en.wikipedia.org/wiki/The_Goal_(novel) a
| bit.
| Jtsummers wrote:
| Probably because that's pretty much the introductory chapter(s)
| (been a few years since I read it, but the topic comes up very
| early). Running everything at full capacity even when they
| can't do meaningful work for the sake of "efficiency" is a
| great way to accomplish a lot of wasted effort. It can go in
| several directions:
|
| 1. You have a lot of wasted work. You're making 100
| widgets/hour that the next station can only consume at 20/hour.
| Inventory piles up and what happens when that work product is
| no longer needed or expires (if it can expire)? Now you've
| spent more (on the inputs to production) and have spent money
| you can't recover in full.
|
| 2. You cut to the quick. You look at that previous situation
| and say, "Let's sell 4 of the 5 machines, we _only_ need 20
| /hour so why are able to make 100?". Turns out that the extra
| capacity helped you deal with maintenance downtime, tool
| changing, quality control issues (low quality parts, which
| should itself be addressed anyways), or meet customer needs for
| spare parts (infrequent, but large orders like at one former
| employer of mine).
|
| (2) is what happens when a lot of people learn of JIT but don't
| comprehend JIT (or Lean). They don't understand, by analogy,
| that cutting your arm off to lose a few pounds is probably not
| the best idea out there.
|
| My prior employer learned this, they cut out the travel and
| finance teams (about 8-10 people in total) and moved all that
| load onto the engineers who traveled, individually,
| infrequently but as a group very often (1500 of us). Problem:
| They did it infrequently, with a crappy web app. You went on a
| trip that lasted 1 day? It took you 4-8 hours in advance to set
| up everything, and 4-8 hours after to put in your vouchers. So
| a single day trip could take 3 days of total time. And for the
| _first_ time someone used the system, or if they had anything
| unusual in their voucher, it could take days (worst I saw was a
| week of 3-5 hours a day spent on their voucher dealing with the
| back and forth on getting it approved and amending the
| voucher). They brought back the "idle" travel and finance
| teams, and, huh, suddenly we weren't wasting so much time on
| it. They were experts in the system and could get those complex
| vouchers done in a couple hours, and the simple ones in
| minutes.
| bumby wrote:
| Isn't the example in your last paragraph more about
| specialization than cutting out slack?
|
| It seems to me like they misunderstood the value stream. The
| specialized added value by reducing the average
| administrative overhead of the engineers, which enabled the
| engineers to focus more on where they add the most value to
| the system. Not unlike the secretary and CEO in the article.
| Jtsummers wrote:
| It's both, their specialization provided slack (both to
| themselves and the engineers). And yeah, the value stream
| was grossly misunderstood, and the work was undervalued.
|
| Because of their specialization they were _fast_ with
| broken systems (they used the same crappy web apps as us,
| but they understood them). Because they were not
| _engineers_ and they got the work done fast, there was no
| perceived value in their role (classism and other biases at
| play here), it was thought (bad assumption) that the
| engineers could do it just as well themselves. And since
| the engineers had more than enough slack anyways, they
| could lose 15-30 minutes before and after a trip to dealing
| with the paperwork.
|
| And _if_ that assumption had been correct, _maybe_ it would
| have been the right call. But the assumption was incorrect,
| and it was a very stupid call. We didn 't charge the
| customers for that overhead, so any time the engineer spent
| on it (hours, sometimes days) was revenue lost. The
| dedicated team cost _much_ less than the lost revenue so it
| was overall a net loss.
| kkfx wrote:
| The enemy is the concept of money with a value, substrate of
| everything vs money as a unit of measure, that's because if money
| have a value "efficiency" is about making money, if money
| represent a value it's the represented value the target.
|
| That's the core. Once understood that the rest start to be
| obvious.
| ngvrnd wrote:
| Ultimately, pursuit of perfect efficiency results in crystalline
| systems which are fragile.
|
| Slack is the ur-antifragility.
|
| (efficiency pursued for itself is AN enemy)
| srean wrote:
| That's because the risk of fragility is typically not priced
| in.
|
| If risks werent treated as an externality this failure mode
| would be taken care of. Of course some unanticipated failure
| modes would always come and surprise us. I would be one happy
| person if the failures we see around us were all of this
| 'inconceivable' variety. Very few are, except when one buries
| one head in the sand and refuses to consider the fairly obvious
| risks.
| AlbertCory wrote:
| The "risk of fragility" is bankruptcy, or death if we're
| talking about a biological organism.
|
| For example, the financial entity that makes tons of money
| speculating in a worthless asset, then goes belly up when its
| worthlessness is exposed (I won't name the asset(s) to avoid
| a flame war).
|
| You can't "price that in." You just avoid it.
| srean wrote:
| One sure can, by engineering a more robust system. This
| will cost you some though. One can buy insurance, one can
| make tail hedges. The right mix of mitigation strategies
| depends on the nature of the threat.
|
| Avoiding it falls in the same spectrum. It is equivalent to
| assigning an infinite cost to the risk .
| rektide wrote:
| Fragility & simply the deadening of exploration. Assuming you
| know what you are doing & only ever intend to do exactly that,
| better, is the ultimate horse blinders for humanity, preventing
| all other options than "go forwards".
|
| Slack is time & permission to consider, reflecr, grow, enables
| finding new ways to thrive.
| dqpb wrote:
| The author is confusing efficiency with utilization.
| mikkergp wrote:
| Yeah I see the criticisms of efficiency brought up alot lately
| it's click bait. Efficiency is always good. efficiency is the
| percent of time I spend on the hobby(practicing piano) rather
| than shuffling books around or making my space comfortable. Not
| maximizing the hours of my day spent "productively".
| pdonis wrote:
| The article's central illustration actually contradicts the
| claimed point. In the illustration, the secretary, Gloria, has
| slack, but the purpose her slack serves is not to enable change,
| which is basically what the article claims slack is for. Gloria's
| slack is just to make sure that Tony, the CEO, _doesn 't_ have
| any slack: he's working all the time on whatever he thinks is
| highest priority, and never takes a break. And Gloria is not
| using her slack to think about ways to reinvent the organization
| to make it better. In other words, this central example is
| actually _not_ an example of the benefits of slack: it 's an
| example of _efficiency_ --Tony works at peak efficiency and has
| no slack. So if Tony is doing good things as a CEO, the
| conclusion should be that efficiency is good, not that slack is
| good. Paying a secretary to have plenty of slack to support Tony
| is just part of the most efficient way for Tony to operate.
|
| A much better example of the benefits of slack would be a CEO who
| _delegates_ the day to day work to subordinates (which _includes_
| "making decisions", the thing the article says Tony's main job
| is), to give _himself_ slack--more time to think about big
| picture things and consider ways to change the organization to
| make it better.
| oicU00 wrote:
| If the roles are both equally necessary, why does the CEO make
| so much more than the secretary?
|
| The CEOs entire enterprise is due to others. If anything
| explicitly highlighting that undermines the myth they're the
| experts.
|
| Both of your models rely on the CEO delegating to focus on the
| right state change for the business, so I'm not sure why you
| create two scenarios with squishy ideas of a CEO being
| efficient or slacking. Some CEOs have casual demeanors, others
| addiction to Adderall energy; neither is slacking if that's
| just the vibe they need to "make it better."
|
| You seem to be circling the core meme it's the CEOs job to
| improve the company and wrapping it up in subjective modals for
| doing so. Not sure how this refutes the article.
| margalabargala wrote:
| > If the roles are both equally necessary, why does the CEO
| make so much more than the secretary?
|
| Most jobs don't set salary based on the necessity of having
| _someone_ in that role, it 's usually based on how difficult
| it is to find a capable person in that role.
|
| If there are 100k people capable of doing the job of the
| secretary, and 5k people capable of doing the job of the CEO,
| then the CEO will be able to negotiate a higher pay rate.
| oicU00 wrote:
| Right, the old supply and demand; a heavily accepted model
| drilled into us.
|
| It's not the only viable one to the species.
|
| Given automation and first hand experience building
| analytics systems for VCs and investors; they're not that
| much more capable. They're humans at the same edge of
| knowledge as any grad of a decent university, of which
| there are millions.
|
| Teaching "stay in your lane" tacitly props up apathy and
| disbelief in the proles.
| ip26 wrote:
| It's both - an example of how slack in one system (Gloria)
| enables higher efficiency in another (Tony) and surmisably
| higher overall output.
| jrs235 wrote:
| Correct. Individual slack (available capacity, aka not
| running 100% efficient) enables and allows for organizational
| efficiency, higher output, and agility (the ability to
| respond to things).
|
| Just like running 100% lean (just in time efficiency) reduces
| overall resilience when snags occur. Having SOME slack
| (available capacity) allows for agility when things go awry.
| sidpatil wrote:
| This is essentially Little's law.
|
| https://blog.danslimmon.com/2016/08/26/the-most-important-
| th...
| thaumasiotes wrote:
| > A much better example of the benefits of slack would be a CEO
| who _delegates_ the day to day work ... to give _himself_ slack
| -- more time to think about big picture things and consider
| ways to change the organization to make it better.
|
| That's not slack. As you _just pointed out_ , that's his
| regular job. Slack is unscheduled time, not time that's devoted
| to performing your duties. The point of slack, anywhere, is
| that it lets you respond to situations that arise, by
| converting the unscheduled time into time in which you respond.
| If you're fully scheduled, that's difficult to do.
| tinalumfoil wrote:
| I don't think Tony necessarily has to be working at full
| efficiency for this. Say Tony is taking a break when he gets a
| text from support, "Big Client X is really unhappy, looking for
| your help on this". He texts Gloria, "grab me previous
| interactions with X". Maybe he needs financial info that Gloria
| doesn't have a record of. "Dan, Tony needs to know Y, send me
| the info?". A chain like this could easily form a graph of tens
| of people, and will require back-and-forth.
|
| You could imagine a scenario where everyone at the company is
| taking a break when X has their issue, _and that 's the best
| case scenario_. Instead of everyone off doing their own thing,
| they're slacking off but ready to help. The combined context
| switching in an extreme case like this could be hours or days.
| WJW wrote:
| It always reminds me of a fire brigade or an army. You _want_
| the firefighters to have lots of slack so that they will be
| available when there is a fire. On the other hand, having
| people sitting around "being ready" is costly and there is
| some optimum amount you need.
| [deleted]
| Retric wrote:
| The timescale makes a huge difference here. Firefighters
| need to be next to their equipment to respond to an
| emergency. US army reservists "One Weekend a Month, Two
| Weeks a Year" is understating things, but they can hold
| down a full time job when not called up.
| WJW wrote:
| What I meant was that both professions are good examples
| of "slack-full" professions. They can still be considered
| to be doing their job well even if they're not actively
| fighting (either fires or the enemy). If they're
| consistently inactive they may get a reduction in
| numbers, but I've never seen anyone seriously suggest to
| abolish the fire brigades.
| manachar wrote:
| I think the challenge here is that efficiency is always
| relative to the position the observer is measuring it from.
|
| In the case of Gloria, she should have some amount of slack to
| figure out how to do the big picture items of her job better,
| which include how better to help Tony.
|
| Where things get tricky is when looking at the whole
| organization there's been a long tendency to see "slack" as
| "fat" that's to be trimmed. So, if a organization has two
| Glorias who both have some slack time, the argument is the
| organization would be more efficient and profitable having one
| Gloria with less or no slack time.
|
| This has worked for corporate profits, but it leads to the
| humans in these positions unable to have the slack time needed
| to improve those positions.
|
| Sometimes, this is fine and you can build a very profitable
| business off of it. For example, McDonald's isn't looking for
| their frontline staff to do any thinking.
|
| In general, if a position can exist and doesn't need "slack"
| time, it is probably a position that should be automated as
| soon as it's cost effective.
|
| If you really need a human to do it though, you should stop
| trying to treat it like machine and realize the importance of
| slack time and build it in to the schedule.
| hinkley wrote:
| > For example, McDonald's isn't looking for their frontline
| staff to do any thinking.
|
| They tend to punish it. I say that I learned from fast food:
| how to mop a floor, how to remove burnt coffee, and the value
| of an education/career.
|
| I think because they work with a lot of teenagers, they tend
| to get away with belittling people and getting because you're
| two back-talks from fired, and you're not sophisticated
| enough yet for the subtle burn they can't write you up for.
|
| "Give a man a little power" was never more clear to me. They
| have their little empire of dirt and they are going to defend
| it.
|
| The biggest asshole had a brother who was a pro baseball
| player. As if what your brother does makes you important (my
| own brother hated that idea). Congratulations, you sell
| burgers all day. Your parents must be proud.
|
| The best of them had a mild case of impostor syndrome he
| tried to cover. Told too many dad jokes, but still top 3 for
| managers in a clutch situation. I hope he did something with
| himself besides ace school field trips dropping in on us
| unannounced.
| Ozzie_osman wrote:
| Tom Demarco's Slack book is one of my favorites. I re-read it
| every 3-4 years to remind myself of the core arguments and avoid
| getting carried away with efficiency and busy work.
| andrewla wrote:
| Related to the concept of efficiency / slack is the concept of a
| Moral Maze (from Robert Jackall) [1] or Immoral Maze (the same
| thing but renamed for clarity) [2].
|
| [1] https://www.amazon.com/dp/0199729883
|
| [2] https://www.lesswrong.com/posts/zpA2Tnp2k38qSmr8J/how-to-
| ide...
| disgruntledphd2 wrote:
| I'm not sure how Moral Mazes relates to this topic, can you
| explain the links to me a little bit more?
| andrewla wrote:
| One aspect of a Moral Maze is that it systematically removes
| slack:
|
| > A world without slack is not a place one wants to be. Mazes
| systematically erase all slack. Slack is evidence of not
| being fully committed, and given that everyone's skills are
| equal and competition is perfect, holding anything back means
| losing even if undetected. [1]
|
| And an article by Zvi on the specific concept [2].
|
| My take, and my experience, says that a lot of what makes a
| moral maze is an organization where professional managers
| engage in a large-scale effort to ensure that blame or
| negative consequences flow past them. So you advance by
| building a maze around yourself so that negative results miss
| you and you grab credit for positive results that have to
| flow through you.
|
| When people "on the line" do good work, you can leech off of
| that. And as long as your organization does good work you can
| do fine. But if your organization becomes marginal or if
| you're trying to outcompete other middle managers, you have
| to find a way to pass that downstream. As a generic "manager"
| you can't add value on the line, but it's very easy to blame
| lack of results on lack of efficiency (too much slack) so
| that's what gets sacrificed.
|
| [1] https://thezvi.wordpress.com/2020/01/12/how-to-identify-
| an-i...
|
| [2] https://thezvi.wordpress.com/2017/09/30/slack/
| darthrupert wrote:
| This is the best business-related article I remember reading
| ever. It focuses exactly on what I have been feeling being wrong
| about how we lead our businesses and more importantly, ourselves.
| In hindsight, it's obvious: I'm always at my most creative when
| I'm not trying to do something, but I only manage to achieve that
| state of mind when on vacation. Other times, I keep trying to do
| things.
|
| One would think that a life-long fascination of zen buddhism
| would have taught me that already but I guess not.
| bee_rider wrote:
| Efficiency sounds so nice, but ever since working on a safety
| based project and observing
|
| 1) Efficiency hates redundancy
|
| 2) Redundancy is, like, the easiest, most zero-thought way of
| adding robustness
|
| I've been a little suspicious of efficiency.
|
| And we see questionable efficiency optimizations all over -- here
| in an individual business, in the greater economy (Let's over-
| specialize our economies, it is more efficient. Let's JIT
| manufacture everything, buffers cost warehouse space).
|
| Just add redundancy. It'll be twice as expensive but it won't
| explode if something goes wrong.
| anon_123g987 wrote:
| If robustness is what's important to you, then your challenge
| is to do _that_ efficiently.
|
| For example, maybe you can use something like the Reed-Solomon
| error correction, which allows you to balance between no
| redundancy and full duplication, both in cost and benefit.
|
| https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_cor...
___________________________________________________________________
(page generated 2022-05-06 23:00 UTC)