Efficiency is the enemy? (2021)

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.

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."

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...

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.

Efficiency is the opposite of redundancy, and both are needed in particular situations. The question is always, what are you optimizing for?