Efficiency Is the Enemy

Something that I&#x27;ve noticed recently is that in my work life, I&#x27;m finding there&#x27;s more bureaucracy in what I do, mostly in the name of &quot;efficiency&quot;. When you encounter a problem to solve, there&#x27;s often a process already defined that is most efficient (or at least thought to be most efficient), when accomplishing tasks, there&#x27;s a pre-defined way of laying out the tasks (i.e. tickets), updating them, reviewing them, and organizationally figuring out what&#x27;s best to do next.<p>In my opinion, these processes are an attempt at organizational efficiency. However, the flip side is it reduces personal agency for the worker. There&#x27;s little room to diverge or think about what you&#x27;re doing. If you diverge, such as taking longer to do something than what was prescribed, or using a different pattern to solve a problem, there is a cost to you within the system. You must explain why, which itself &quot;costs&quot; something. In a sense, you&#x27;re punished for doing things differently.<p>That loss of personal agency is absolutely soul-sucking. You feel like a machine, again at the cost of organizational efficiency. Slack is definitely important because it lets people acquire some sense of personal agency again.

And this is why you schedule flights in the morning: there&#x27;s so damn little slack in the system that if things go wrong at 10:00 AM at O&#x27;Hare, flights for the whole rest of the day are screwed up owing to the cascading delays.<p>At least in the morning the airlines have had the overnight to unsnarl the previous day&#x27;s mess because of the reduced revenue traffic overnight and the corresponding slack that accrues as a happy side effect.<p>This is <i>also</i> why things like the healthcare system, transportation network, and postal system shouldn&#x27;t be run for maximum utilization&#x2F;efficiency under normal load: if there isn&#x27;t any slack in the system it gets real ugly when things get squirrelly. In cases of localized disturbance, we get by on mutual aid: linemen and bucket trucks from far away respond in the aftermath of e.g. a hurricane or tornado. Likewise, fire departments from all over The greater Boston area responded to the gas explosions in the Merrimack Valley[0] and companies from even further away repositioned trucks to cover the departments that responded directly.<p>When it&#x27;s national or global scale event, you&#x27;re left leaning on whatever slack was in the system. As we&#x27;re all painfully aware, there hasn&#x27;t been enough. The public health and healthcare systems have been doing heroic work, but if they weren&#x27;t stretched so tight in the name of efficiency beforehand, there&#x27;d be less need for the heroic efforts.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Merrimack_Valley_gas_explosions" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Merrimack_Valley_gas_explosion...</a>

We&#x27;ve replaced secretaries with software, and now we have people making $150k+ a year busy working on things that they should be paying someone $40k a year to handle.

One of the uncomfortable conversations we&#x27;re going to have to have soon is about how &#x27;Flow State&#x27; is efficient but ineffective.<p>One of the characteristics of Flow State is a diminished sense of considering the consequences of an action. Exactly the &quot;so busy figuring out if they could do it that they didn&#x27;t stop to think if they <i>should</i> do it&quot;.<p>In particular I&#x27;ve noticed that people get extremely defensive about code they wrote in Flow State. My working theory is that we think somewhere on a spectrum from, &quot;how could anything that made me feel that good really be bad?&quot; to &quot;I got three days of work done in one day you are crapping all over it instead of congratulating me? Fuck you!&quot;<p>I know that the efficacy of my code tends to be higher when I &#x27;come up for air&#x27;, reason out what to do next, and if I find that Flow Me is disagreeing with Planning Me, I stop and regroup. This is essentially the same skill I use to, among other things, keep from overspending at a store - setting ground rules and stopping when I&#x27;m tempted to violate them.<p>Pomodoro might be a little to structured for many of us, but as a starting point it might be a reasonable antidote.<p>I think in general that programmers have an easier time entering Flow State, but if you&#x27;re going to willingly exit it, you had better have some confidence you can find it again, so you need to have better than 50:50 odds of being able to enter it at will instead of just going with it when it happens. This seems to be a rarer skill.

I work in public sector digitalisation and have for a decade, so this article sort of rings home with me. Especially now, having passed a year of thousands of office workers working from home and having seen a rise in efficiency and quality across all our sectors. I’m not saying working from home is an all-good sort of thing, we have also seen an increase in stress and depression related sickness, but in terms of getting shit done, things have been never been better.<p>Which is sort of ironic from my department, because this has also been a year where our process optimisers and MBAs have been almost completely unable of performing their usual efficiency and benefit realisation consulting in our different departments, as that’s a hands on sort of thing. Not that they’ve done nothing, they’ve been to really good work helping managers coordinate remote work and teaching both the CEO and Political layers how to use Microsoft teams efficiently.<p>Anyway, if we’ve increased efficiency and quality more in a year or not trying to, it sort of begs the question what good trying really does. You obviously can’t really conclude anything scientific on our anecdotal measurements as we’ve seen the major change of going remote on top of it, but it is something to think about.<p>Not that we will, we’re already trying to figure out how to go back to the way things were, as the majority of our managers still seem to think people work better if they spend 7 and a half hours in an open office 5 days a week.

I&#x27;ve only been working professionally for 5 years and this is something I am only recently beginning to appreciate. Optimizing for efficiency makes you get a lot of work done but it reduces your ability to think creatively which can potentially impact the quality of ones work.

Nice read.<p>As a sysadmin &#x2F; DevOps &#x2F; SRE &#x2F; whatever, I also realized at some point that being constantly busy is actually a state of extreme fragility.<p>Nowadays I try spending a significant part of my day just trying new stuff and reading, not being micromanaged helps a lot.

Maximising utilisation usually means an increase in latency. You don&#x27;t want your ambulances or fire fighters at high utilisation.

This may be obvious to others but it serves as an &quot;ah ha&quot; moment.<p>I like being efficient in doing work to get things done. I also like slack because I want to enjoy life.<p>I also recognize increasing workload doesn&#x27;t mean being efficient, just that you do more work.

If it&#x27;s true that &quot;Slack represents operational capacity sacrificed in the interests of long-term health&quot;, then who exactly is the target audience of this article? Corporations have not cared about &quot;long-term health&quot; since the 80s. CEOs and CXOs and CYOs and Senior Vice Presidents play musical chairs both within and between companies in a neo-feudalistic Game-of-Thrones-style competition for titles, where companies and their various divisions are just pieces. Decision-making happens via primarily the Principal Agent Problem and is focused on what makes me, personally, look the best and give me the best chance of gaining a better Title in the next quarter. Eating up all available slack is one of the more mundane ways to cannibalize the company for your own benefit. Long-term health of the company? Who cares!?

In other words 99th percentile latency is what matters, not utilization. Anyone who&#x27;s tried to get things done with batch-class resources has probably noticed this as well.<p>There&#x27;s a similarity to the overall economy as well. Just in time inventory is certainly efficient but it&#x27;s incredibly fragile. Just look at how much &quot;damage&quot; is being claimed for a boat that made other boats two weeks late.

At my first tech job many of us had quite a bit of idle time. Some impactful and interesting projects were initiated during those moments of inertia.<p>&quot;Creativity is the residue of time wasted&quot; - probably not Albert Einstein but it&#x27;s attributed to him

I had an off-topic thought that the <i>ideal</i> of Slack (the chat service) is actually very well explained by &quot;slack&quot; as defined in this article. This article holds &quot;slack&quot; as the ability to respond to a new task immediately, and Slack (chat service) is built around responding immediately to tasks or questions from peers.<p><i>However</i>, executives clearly aren&#x27;t quite getting the benefit. They expect employees to respond immediately to every new need and new task, but they didn&#x27;t actually give the employees enough time availability to do so. So instead of getting faster responses from employees, the employees just get overloaded; this leads to the tasks actually being completed LATER than they would have without Slack (chat service) <i>and</i> employees getting burnt out quickly.

Ah, &quot;Antifragile&quot; done quick? Nice.<p>Even shorter: there&#x27;s no single absolute optimum; if you optimize for efficiency, you lose in other areas. But if you optimize in other areas, you lose in efficiency, of course. Everything in real life is a compromise.

In retrospect, yes, this is absolutely true. One is <i>much</i> more effective with slack. The question is how to set one up for that. Ironically, slack (the app) is really counterproductive here. It takes some effort not to react immediately to every request. While this might look like the setup of Gloria, the secretary, often the sheer amount of requests kills any slack.

Here’s a counter argument: maybe Gloria doesn’t need to have defined tasks for every hour of every day, but it absolutely could not hurt for her to make proactive decisions that fill her time when she isn’t busy tending to Tony’s schedule.<p>Ideally, an organization would be able to attract the candidates that would spend their free time doing constructive things. This _would_ be an org where everyone is busy all the time.<p>Suggesting that it’s always OK to be doing nothing when we don’t have a pressing task in the name of “Slack” is not what the author intends (in my interpretation) and absolutely a waste of the extremely powerful minds we have as humans.

Moshe Vardi gave a talk on this idea recently as it applies to the COVID-19 crisis. His word for slack is &quot;resilience&quot; but it&#x27;s the same concept. He quotes William Galston: &quot;Efficiency comes through optimal adaptation to an existing environment, while resilience requires the capacity to adapt to disruptive changes in the environment.&quot; You cannot maximize one without sacrificing the other.<p><a href="https:&#x2F;&#x2F;learning.acm.org&#x2F;techtalks&#x2F;covid" rel="nofollow">https:&#x2F;&#x2F;learning.acm.org&#x2F;techtalks&#x2F;covid</a>

This is also one of the things wrong with the global economy. Safety margin is necessary but inefficient, and insufficiently incentivized. In an older conversation here, someone phrased it along the lines of &quot;a system that&#x27;s highly optimized for one environment is correspondingly unoptimized for any other environment&quot;, including environments resulting from natural changes. I tend to think of it as an engine with all the tolerances honed down for efficiency, like a racing motorcycle, but with no room for grit or losing traction.

Nearly every system in nature has some slack baked into it.<p>Take the human brain, pound for pound it packs more neurons in it than any other animals brain on the planet. 20% of the glucose we burn goes to power the brain, in children it’s closer to 50-60%. Yet even though nature powers this incredibly powerful computer, 24&#x2F;7, we use it’s power, maybe once in a while if we’re lucky. We can’t remember more than 6-7 things at a time, we can never fire every single part at once. You might assume this is a defect, it’s not, it’s a feature.<p>The brain has so much capacity, they have found people that can literally remember every single thing that happens to them their whole lives. Guess what happened to them? They had no slack for reasoning in abstraction, the things that make us human, they could detail every aspect of a story but couldn’t summarize it, and the list goes on and on. What would happen if we ran our chips at 100% capacity 24&#x2F;7?<p>We assume we need to do more, we need more information, we need to squeeze every ounce out of our life and work but in reality this has the opposite of the intended effects.<p>This article is great because it puts it all into perspective. I recently wrote about the same topic but it’s not as good as this article but still if you are interested:<p><a href="https:&#x2F;&#x2F;louiebacaj.com&#x2F;what-happens-if-we-squeeze-too-much&#x2F;" rel="nofollow">https:&#x2F;&#x2F;louiebacaj.com&#x2F;what-happens-if-we-squeeze-too-much&#x2F;</a>

&quot;<i>In the marketplace you’re not expected to be aware, you’re expected to be efficient. Efficiency is a quality of machines. Machines are more efficient than human beings. Because efficiency is required, you become more mechanical. And as you become more mechanical, your awareness disappears. And your awareness is your real being. By efficiency and mechanicalness you may succeed in earning more money, more power, more prestige, more respectability, but you will lose yourself.</i>&quot;<p>— Osho

Efficient is very important when you are doing the same thing over and over again. If you job is to type, than the faster you type the better, and anything that gets in the way of typing is bad. If you job is to think, than the faster you think the better, anything that slows thinking is bad. If you are a programmer or manager, then you are in the later group. If you work an assembly line than it is the former.

Simply, the system becomes significantly less responsive the more utilized it is. Isn&#x27;t this one of the most important discoveries of Queuing theory?

One of the quotes suggests that DeMarco (the author of the book under discussion in this post) himself views &#x27;slack&#x27; somewhat negatively:<p>&gt; “Slack represents operational capacity <i>sacrificed</i> in the interests of long-term health.” [emphasis mine]<p>Quibble it might be, but nevertheless: surely if the goal is to appreciate the value of &#x27;slack,&#x27; it would be better to describe it as an <i>investment</i> in long-term health, rather than a sacrifice for it?<p>To be fair, I suspect he was trying to implicitly refer to &quot;opportunity cost&quot; - every investment implies a &quot;sacrifice&quot; of the alternatives. But it seems to lead the blog post author into a similar dissonant frame of thinking:<p>&gt; Slack consists of excess resources... Slack is vital...<p>Here I quibble with the use of &quot;excess.&quot; Excess compared to what? Presumably, excess compared to the resources one might assume were necessary to guarantee a healthy operation - but as the author then notes, these resources are not &quot;excess&quot; at all, but indeed &quot;vital!&quot; In other words, they are fundamental to the continued existence of the operation. Why imply anything else?

I see slack in my personal life as having unplanned periods of time. I think it&#x27;s really important for improvement to have some free time everyday that is not dedicated for a specific thing.<p>Because there are so many things we don&#x27;t know and also many things we don&#x27;t know that we don&#x27;t know. So I make sure that I have enough slack in my day to allow some random digressions

I am worried most about how our system pushes efficiency to the detriment of resiliency.<p>Businesses use just in time inventory to increase efficiency, but that means a small disruption anywhere in the supply chain can grind everything to a halt.<p>Also, instead of maintaining cash savings, businesses will rely on cheap credit. However, if enough businesses do that, any type of credit crunch results in widespread economic disaster.<p>Often business efficiency is a way to privatize the gains from efficiency, but but have the public bear the losses from lack of resilience.<p>Just like banks are required to keep a reserve (which is inefficient in some sense), I think some type of regulation or increasing the personal moral hazard for business leaders is required to make sure businesses don’t sacrifice resiliency for too much efficiency (and the profits of efficiency).

This quote “You’re efficient when you do something with minimum waste. And you’re effective when you’re doing the right something.” reminds me of a Systems Thinking talk Russell Ackoff gave a long time ago [1] where he talks about the difference between doing &quot;the right thing wrong&quot; and the &quot;wrong thing right&quot; and getting more efficient at doing the wrong thing obviously might not be optimal :). This is actually a concept that Peter Drucker came up with, but I&#x27;ve not managed to find a good link to that, I&#x27;d be interested if anyone has?<p>The whole talk is quite interesting, but I&#x27;ve linked to the relevant segment: [1] <a href="https:&#x2F;&#x2F;youtu.be&#x2F;OqEeIG8aPPk?t=591" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;OqEeIG8aPPk?t=591</a>

This is so ironic. I write this message while being chased by colleagues who need me to do something for them that is very important to them but has no merit in my manager&#x27;s eyes. At the same time, I am hopelessly chasing other colleagues who need to do something for me that is really important to my manager&#x2F;dept I can&#x27;t help those who need me because that would set me behind on my urgent tasks. But others can&#x27;t help me in my urgent tasks because it would set them behind on theirs&#x27; Circle of doom

While traveling by car during one of his many overseas travels, Professor Milton Friedman spotted scores of road builders moving earth with shovels instead of modern machinery. When he asked why powerful equipment wasn’t used instead of so many laborers, his host told him it was to keep employment high in the construction industry. If they used tractors or modern road building equipment, fewer people would have jobs was his host’s logic.<p>“Then instead of shovels, why don’t you give them spoons and create even more jobs?” Friedman inquired.

Reminds me of how civil engineers design structures to bear loads that are at least double the actual maximum load the structure is ever expected to see. Imagine the spectacular catastrophes that would come from centering bridge design around maximizing the efficiency of materials used to support the very limit of load-bearing capacity, and that&#x27;s what many of us are fostering in our own lives and businesses.<p>What Shane calls slack, you could also call the margin of safety.

One problem is that we&#x27;ve turned &quot;efficient&quot; into some sort of noun that is self-referential, rather than the actual definition which is constrained to a particular result. &quot;We must be efficient.&quot; should beg the question &quot;to achieve what?&quot;<p>The second problem is that efficiency is often applied across many small scopes of operation, ignoring the effects on efficiency at greater scope. You can be tactically efficient at the expense of strategic goals.<p>The third problem is that efficiency is often over-fitted in a chase for maximalism, which necessarily creates a rigid system that is highly dependent on little or no variation between the past and an expected future. Just-in-time supply chains fell apart due to things like the covid-19 lockdowns, which often cascaded across both vertical levels of specific industries as well as across industries.<p>From a system design point of view, building a system that has no flexibility in scaling but is instead maximally efficient based on current (and recent past) levels of demand is a disaster waiting to happen. In the old days we&#x27;d laugh at a commercial site that got slashdotted because it was incapable of handling burst demand.

When I get stuck on a problem, or am switching the module I’m developing, I’ll often take a couple of hours, and watch something on the tube.<p>When I get back to the task, I tend to get it completed in no time at all, or solve the problem quickly.<p>I will sometimes, take the rest of the day off. I did that today. I’m starting work on a fairly significant feature that will touch almost every layer of code, and I can’t afford to pooch it.

Isn&#x27;t that a well studied problem, applicable to many fields?<p>Here the article is about people, but the same reasoning can be made with computers or service centers. I mean, no sysadmin will expect their network to be a 100% capacity all the time. We have mathematical models for that, the stuff with binomial laws and Poisson distributions.<p>So how can we expect people to be 100% efficient if even machines can&#x27;t be 100% efficient?

&gt;&gt; Imagine if Tony decided to assign her more work to ensure she spends a full eight hours a day busy.<p>Tony invents “agile&#x2F;scrum”.

Some companies value &quot;busyness&quot;. In the Before Times, that was partly judged by how much time you spent in the office, but then and now there are other measures. Remote work can be evaluated on how quickly you respond to communications, or how much of the day (or night) you can be reached.<p>But busyness is not productivity.

There are two subtly different kinds of efficiency:<p>1) How little input resources are used to produce a given amount of output. Tools that let you spend one hour to do a task instead of two fall in this category. As does growing twice as much wheat on a given plot of land.<p>2) What fraction of resources aren&#x27;t used productively at all. The &quot;slack&quot; from the article, or wheat that gets grown but not eaten.<p>Improving the first kind of efficiency is usually a good thing. The second can also be positive, <i>but only in moderation</i>. If you try to reduce slack too much then you&#x27;ll end up with systems that are brittle and have serious failure modes (like famine caused by wheat production being lower than expected)

This is something that surprised me when I was reading the Phoenix Project: sometimes making quick decisions and quick actions is more important than making sure &quot;everyone has something to do&quot;. In fact it&#x27;s very common.<p>It&#x27;s important that your bottlenecks are <i>never</i> waiting for a task to complete. It&#x27;s important that firefighters of your organizations are ready for anything that could block important processes or bottlenecks. It&#x27;s important that certain tasks are ready to accept a new job so WIP doesn&#x27;t accumulate and lead times are kept low.

The title is a little sensational, and that is a good thing. Sensational titles usually do one of two things: clickbait, or playfully intrigue the target and deliver something in its vein.<p>This actually made me think about somewhere I might be wrong. I just got the book the article references and I&#x27;m going to read it. I&#x27;ve always been about efficiency, and still am where things can be automated. But the idea that you&#x27;re less effective if you cram your life with tasks is intriguing, and maybe a little enticing. I&#x27;d like to explore the concept further.

I prefer the term robustness to slack. And the concept applies to more than just time. Keeping sufficient inventory to deal with spikes in demand, having redundant systems so you can keep running while doing maintenance, programs designed to fail safe rather than leading to cascade failures, these are all ways that systems can deal with the inevitable perturbations of the real world. The reckless pursuit of efficiency leaves systems fragile, which may be fine in good times but is catastrophic in bad times. In the long run, you need robustness.

I&#x27;m sympathetic to the argument but the just-so-story at the start actually made me question it. The 60s and 70s had a baby boom entering the workforce which likely led to the productivity growth rate[1]. We have less slack because it&#x27;s relatively more expensive. Focusing on the cult of efficiency can distract you from the real causes<p>[1] &quot;Fully Grown&quot; goes into exhaustive research of every possibly cause of the productivity slow down. <a href="https:&#x2F;&#x2F;amzn.to&#x2F;3nN1ZrR" rel="nofollow">https:&#x2F;&#x2F;amzn.to&#x2F;3nN1ZrR</a>

J. R. &quot;Bob&quot; Dobbs taught us the importance of Slack years ago.

Most of the time the “solutions” to quantifying efficient production of programmers is, for the best of us, a gradual descent into frequent focus destroying forms of micromanagement - and for the worst of us this is a welcomed phenomenon. If you want to do your work, it sucks. If you don’t actually want to do your work, it’s great.<p>For non programmers, of course, the idea that someone valuable is doing something that they have no control over is absolutely terrifying.

I used to work in machining shop using saw to cut stock for big expensive milling machines. They allowed only one shift, because that was just barely enough to keep milling machines running evening and night, but often machines would stop. If we had second shift, machines would never run out, but the boss was the kinda guy who rather have 100e+&#x2F;h machines stop, than see some worker not being 100% busy all the time.

That example is actually the same as The Goal: i.e. you optimize at the bottleneck. The bottleneck in that system is the CEO. Optimizing at the secretary is pointless since she&#x27;s not a bottleneck.<p>We have an intuitive understanding of this as engineers. If you&#x27;ve got a program that&#x27;s CPU-bound then you don&#x27;t optimize the IO. If you&#x27;ve got a program that&#x27;s IO-bound you don&#x27;t optimize the CPU.

I think everyone needs different block of time to slack, to remove burn-outs and reserve more energy for next step. Some people such as John Carmack probably doesn&#x27;t need that much of time to slack (he seems to use &quot;researching how to do difficult things&quot; and programming retreats as a way to slack from daily programming jobs) but most of us need it.

Basic queuing theory: If you want to maximize the utilization (~ efficiency) u of a resource (e.g. CPU or cashiers), waiting times for jobs (e.g. processes or customers) that compete for it grow by t &#x2F; (1-u), where t is the average processing time per job. So, from a client&#x27;s (job) point of view, maximizing resource utilization is bad.

We place more faith in authoritative ideology than personal judgment and observation. So when authority (be it boss, consensus, convention or propaganda) says &quot;be more efficient&quot; (or whatever), we do it. Despite any observed mountain of evidence to the contrary. And despite our feelings on the matter.<p>As a rule, that&#x27;s people. Little goddamn robots.

I agree totally. It matches my learnings in my career as well. But how much slack is the right amount? What do you think?

This might be a bit pedantic but it seems that this article is arguing against business as a technique for ensuring increased efficiency, it isn&#x27;t arguing against efficiency itself. This post&#x27;s whole ethos is that slack creates higher efficiency due to an increased reaction time from workers.

The problem isn&#x27;t efficiency, its distraction. Efficiency can be numbed down to the movement from one focus to another without unnecessary expenditure of time or energy. If you eliminate distractions such that there is nothing to transition to&#x2F;from you are both more productive and more efficient.<p>There is quite a bit more depth and nuance to the achievement of focus versus distraction than it seems at face value. Distraction often applies to things unrelated to a given task, but also applies to the frequency of steps in a given task. Consider the following:<p>* Do you have to go to multiple locations for project documentation?<p>* Do you have to configure a bunch of tools and steps in a certain order for your project to work?<p>* Do you have to jump through a bunch of meetings to know what&#x27;s going on?<p>Efficiency is the graceful transition between the points of insanity. The problem therein is that you are busy thinking about the granular minutia of those pieces and the transition points instead of thinking about achieving the end state. You become most efficient by eliminating the need for efficiency which allows the slack time the article talks about.

Going straight to the mouth of the horse is better: <a href="https:&#x2F;&#x2F;www.greaterwrong.com&#x2F;tag&#x2F;slack?showPostCount=true&amp;useTagName=true" rel="nofollow">https:&#x2F;&#x2F;www.greaterwrong.com&#x2F;tag&#x2F;slack?showPostCount=true&amp;us...</a>

Some good food for thought in the article. You want enough slack time and energy to be able to accomplish the high priority items. You definitely want to avoid low ROI busy work.<p>But also beware the easy seduction of the idea that you don&#x27;t have to work hard to have a good chance of success.

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.

Seems like some of the same ideas in Donald Reinertsen presents in his books and videos. He thinks in queues and the cost of delay.<p>The cost of delay when you try to keep everyone busy all the time.<p>I&#x27;m reading his book The Principles of Product Development Flow.

I’ve observed that to make everything “data driven” and efficient, one must quantify it. Keeping track of ‘stuff’ (copies I made, time I spent, conference rooms I reserved, etc.) requires procedures that can look like bureaucracy.

Efficiency becomes a problem when it’s the only thing bestowed with value. Optimising for efficiency by definition removes resiliency. Disproportionately prioritising any narrow goal will produce a brittle monoculture.

I like the analog of the sliding puzzle because also if you remove one more piece it will be even easier to solve. Also if you remove too many pieces then you’re not actually getting meaningful work done.

J. R. Dobbs approves.

Counterpoint (kinda): <a href="https:&#x2F;&#x2F;efficiencyiseverything.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;efficiencyiseverything.com&#x2F;</a>

The title should rather be “Having no free time is the enemy”. The article confuses being busy with being efficient.

no, it depends<p>if it is to do things only just for yourself, the nobody gives a shit<p>if you work on a team, and do things with other people, then efficiency is your friend, same for performance by default<p>thinking the opposite is lying to yourself, worse, it is very selfish, you basically waste everyone&#x27;s time and ressources

This combined with the mirage of multitasking are effectiveness killers

This is HN, and no-one yet mentionned the &quot;Boimler Effect&quot; ?

For a more macro&#x2F;systemic discussion of slack, I liked this SSC article: <a href="https:&#x2F;&#x2F;slatestarcodex.com&#x2F;2020&#x2F;05&#x2F;12&#x2F;studies-on-slack&#x2F;" rel="nofollow">https:&#x2F;&#x2F;slatestarcodex.com&#x2F;2020&#x2F;05&#x2F;12&#x2F;studies-on-slack&#x2F;</a>

tldr: Just In Time makes systems brittle.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Just-in-time_manufacturing" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Just-in-time_manufacturing</a>

TL;DR Take walks

Optimizing for individual productivity is different than optimizing for team productivity.<p>Writing code as fast as possible does not produce readable code. Code with low readability is not productive at scale or over time.