Efficiency Is the Enemy
The most famous book to discuss this idea is <i>The Goal</i> by Eliyahu Goldratt, published in the days when American manufacturing was trying to compete with Japanese methods. That book inspired <i>The Phoenix Project</i> by Gene Kim and others, which applied the ideas to DevOps.<p>It&#x27;s been several years, so I don&#x27;t remember how TPP tied slack to concrete DevOps practices. But in Google&#x27;s SRE book (published by O&#x27;Reilly), they talk about how if more than half of an SRE&#x27;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 <i>Time Management for System Administrators</i> by Thomas Limoncelli for more techniques.)<p>(EDIT: I&#x27;m starting to remember more details from TPP now: One way to add slack is to find &amp; remove bottlenecks, e.g. the sysadmin who was &quot;too good&quot; at solving everyone&#x27;s problems. This is also why you may want to mix more generalists into your teams than is strictly efficient. Likewise with having &quot;cross-functional teams&quot;. They can share work so there are fewer bottlenecks.)<p>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 &quot;sprint&quot;.) 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&#x27;s 20% time is another form of slack.<p>Webdev shops struggle with this since utilization is a major driver for profitability. I&#x27;ve seen many start in-house products to fill the time between client work. You&#x27;d think these would turn out great, since they are (or ought to be) experts at building and launching new tech ventures. But I&#x27;ve only seen a couple work out. In practice they get neglected as soon as more billable work arrives.<p>What works better is a focus on internal tooling. This is much like Toyota&#x27;s continuous improvement (a connection also made in <i>The Goal</i>). You don&#x27;t get continuous improvement unless you have slack, and it&#x27;s a good way to &quot;use&quot; your slack. If you don&#x27;t have any ideas for internal tooling (ha), maybe encourage your devs to make some open-source contributions.<p>It&#x27;s notable that you don&#x27;t achieve slack by sleeping in. The secretaries still had to show up to work, even if they didn&#x27;t have too much to do. So you still need a good work ethic. This makes me skeptical of the author&#x27;s idea that you can motivate yourself with tight deadlines. I often wait until the last minute to do things, but that&#x27;s not really buying me slack.<p>On the other hand playing Counterstrike may be genuine slack, since you can always turn it off if something comes up. :-)<p>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.<p>I suspect slack is better managed in the small than in the large. I&#x27;m thinking of Hayek&#x27;s critique of central planning in <i>Road to Serfdom</i>, or Michael Polanyi&#x27;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.