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