The most famous book to discuss this idea is The Goal by Eliyahu Goldratt, published in the days when American manufacturing was trying to compete with Japanese

The most famous book to discuss this idea is The Goal by Eliyahu Goldratt, published in the days when American manufacturing was trying to compete with Japanese methods. That book inspired The Phoenix Project by Gene Kim and others, which applied the ideas to DevOps. It's been several years, so I don't remember how TPP tied slack to concrete DevOps practices. But in Google's SRE book (published by O'Reilly), they talk about how if more than half of an SRE's time is consumed by incident response, they push maintenance back to the developers. Reserving 50+% time for project work is a way to maintain slack. (See Time Management for System Administrators by Thomas Limoncelli for more techniques.) (EDIT: I'm starting to remember more details from TPP now: One way to add slack is to find & remove bottlenecks, e.g. the sysadmin who was "too good" at solving everyone's problems. This is also why you may want to mix more generalists into your teams than is strictly efficient. Likewise with having "cross-functional teams". They can share work so there are fewer bottlenecks.) In other software development, you can achieve slack by filling each sprint with a mix of high- and low-urgency work. (And btw, we should replace the word "sprint".) Or leaving 20% of your time for refactoring. Or practicing the Boy Scout method (and factoring it into your estimates). Or when the graybeards double any estimate before sharing it with the customer. Google's 20% time is another form of slack. Webdev shops struggle with this since utilization is a major driver for profitability. I've seen many start in-house products to fill the time between client work. You'd think these would turn out great, since they are (or ought to be) experts at building and launching new tech ventures. But I've only seen a couple work out. In practice they get neglected as soon as more billable work arrives. What works better is a focus on internal tooling. This is much like Toyota's continuous improvement (a connection also made in The Goal). You don't get continuous improvement unless you have slack, and it's a good way to "use" your slack. If you don't have any ideas for internal tooling (ha), maybe encourage your devs to make some open-source contributions. It's notable that you don't achieve slack by sleeping in. The secretaries still had to show up to work, even if they didn't have too much to do. So you still need a good work ethic. This makes me skeptical of the author's idea that you can motivate yourself with tight deadlines. I often wait until the last minute to do things, but that's not really buying me slack. On the other hand playing Counterstrike may be genuine slack, since you can always turn it off if something comes up. :-) For developers, another way to use slack time, besides building tools and playing games, is personal development: read a book, do a course, write a blog post, etc. Your greatest asset is your mind, and you must invest in it! Or engage in a community and meet new people. That is a kind of investment too. I suspect slack is better managed in the small than in the large. I'm thinking of Hayek's critique of central planning in Road to Serfdom, or Michael Polanyi's objection to centrally-planned scientific research. I knew a company once that devoted one in four sprints to refactoring. While that would be an improvement in many places, it feels a bit too centrally-planned to me. Give people slack, but let them use it how they like.