78 ms·
Efficiency Is the Enemy
- Pet_Ant 5y agoMaximising utilisation usually means an increase in latency. You don't want your ambulances or fire fighters at high utilisation.
- cogman10 5y agoIt's a balance. If 10 firefighters don't see high utilization, you don't want to increase the staff to 20, just in case. That's just a waste of money. The rule of thumb is that you want utilization to be where there is an acceptable latency depending on some percentile of cases. For a firefighter, you'd probably look at p99 latency. For a hamburger joint, p50 on order time would be good enough.
- jschveibinz 5y agoGreat interchange of comments.
- Yeroc 5y agoSeems like the original article/book and your comment tie back to Little's Law from queuing theory which is used as justification in Kanban for minimizing WIP.
- ErikVandeWater 5y agoI doubt you will ever see even firefighters with low utilization. They can use extra time to do inspections to make sure there aren't any fires, or put on presentations at neighborhood association meetings teaching the public about fire hazards. If they aren't doing those things and there aren't any fires, they're just lazy.
- burnished 5y agoAbsolutely not. Not that those things aren't great, and hopefully already being done, but there is zero need to ask firefighters to be at 100% utilization at all times. There is value in having some one perform busy waiting in the event of an emergency. Did you know thats a training drill they perform? How fast they can be out and on their way from the moment of getting a call.
- ErikVandeWater 5y ago> there is zero need to ask firefighters to be at 100% utilization at all times. That's why I didn't call for it.
- omginternets 5y ago>you don't want to increase the staff to 20, just in case. That's just a waste of money. I believe OP's point is that you do want the staff of 20, for the once-in-a-lifetime fire that requires 20 people. See also: the recent Texas power grid debacle, or the saturation of ERs due to COVID.
- wott 5y ago> you do want the staff of 20 No, you don't. Resources are not infinite, and at some point the budget has to be taken from other services which are more useful than a once-in-a-lifetime event. Or you do want the staff of 20, but then it must be a volunteer and/or on-call duty system. Otherwise it is not sustainable. In my country, the shift/switch to professionalisation that started 30 years ago has gradually become a big problem. Despite the fact that they still represent only 20% of the firemen, they are killing the budgets, and they always want more (lots of strikes); apart from 'standard' raises, the most common thing they ask for, is that on-call hours should be paid full-rate, as active hours. Which, beside being extremely costly, is absurd when they are 'working' 24h shifts! It contains a few hours of training and, depending on location, a few hours of duty; the rest is on-call (at home or on premises depending on the type of station), the number of service calls is limited, and 1 in 4 shifts happen without a single call (even more for 12h shifts). There are plenty of other problems which surround this professionalisation, but they are not directly related to this subject.
- slfnflctd 5y agoOn-call at home should definitely pay less than active duty. That way, when a call comes in, the annoyance of being interrupted is offset by knowing you're getting paid more for responding. If you get paid the same, responding to a call just becomes an annoying interruption ("I could be at home making the same money if this person I'm helping had just been more careful!"), leading to a worse experience for everybody.
- omginternets 5y agoI think we’re getting hung up on specific numbers. The general point, I think, could be summarized as: you want some idle resources to handle surge capacity. Whether that’s 5 or 20 firefighters is of course the next question.
- the-dude 5y agoIn The Netherlands it is more like our IC beds.
- NotSammyHagar 5y agoWhat does ic bed mean?
- SunlightEdge 5y agoIntensive care
- deleted 5y ago[deleted]
- pegasus 5y agoIC = Intensive Care
- jdauriemma 5y agoAt 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. "Creativity is the residue of time wasted" - probably not Albert Einstein but it's attributed to him
- Jtsummers 5y agoTL;DR: Author has discovered another author who has written about a topic that's been known since queuing theory and statistical modeling were explicitly applied to businesses some time last century which merely revealed what many people already understood intuitively (but probably couldn't quantify or articulate). 100% utilization is moronic, you need slack in your system or you will introduce the risk of a severe backlog of work that may never finish (or will finish because clients cancel the requests and go elsewhere). See also The Goal.
- deleted 5y ago[deleted]
- kiba 5y agoThis may be obvious to others but it serves as an "ah ha" moment. I like being efficient in doing work to get things done. I also like slack because I want to enjoy life. I also recognize increasing workload doesn't mean being efficient, just that you do more work.
- nine_k 5y agoWork has negative utility. It's something that you spend, actually the irreplaceable time of your life. Increased efficiency means more money (or joy, or other things with positive utility), or less work :)
- bumby 5y agoIff you consider your work a net-negative or just a means to an end. There's certainly a case to be made for optimizing for work that is an end in itself where more work may increases positive utility in some areas (joy, fulfillment, whatever) and possibly decreasing it in others (money, status, whatever).
- bluGill 5y agoI hope work isn't a net-netagive, but there are always things that must be done that you don't want to do. Sometimes you can hire someone else, but often you cannot.
- bumby 5y agoI was probably too sloppy in my wording. I interpreted the OP to mean work may have negative utility for the individual person, but not in the aggregate. I don't know that the idea that work is essential individual sacrifice for some end goal is particularly healthy.
- bluGill 5y agoI would hope for your own health you clean your dishes after you eat. There are a number of distasteful jobs that have to be done.
- trias 5y agoI agree totally. It matches my learnings in my career as well. But how much slack is the right amount? What do you think?
- carlosf 5y agoNice read. As a sysadmin / DevOps / SRE / whatever, I also realized at some point that being constantly busy is actually a state of extreme fragility. Nowadays I try spending a significant part of my day just trying new stuff and reading, not being micromanaged helps a lot.
- hinkley 5y agoI did some refactoring work a few months ago, replacing the old way we did something with the new. I didn’t have to do it, I could have punted like the creator did. But I was used to the new thing and I wasn’t about to write new code that was already deprecated. Nobody called me out on it but it wouldn’t have been the first time in my career. But now I find out belatedly that we’re changing our auth system, and now that work is going to save me from having to drop everything to get it done on time.
- loopz 5y agoIf there's something you feel you can do, it'd be good, you absolutely should investigate that path. If it turns out it didn't work out, someone stomped on it or you get pulled elsewhere, it wasn't meant to be. You feeling that goal within your grasp, is anyways valuable as learning exercise. No matter your efforts, there's a time for everything.
- tetha 5y agoI was about to write that. This is very visible in operational teams. Depending on what is going on, an operational team will spend 20 - 40% of their time firefighting or at tightening screws and oiling wheels - maintaining systems. Sometimes it's a good week and it's just 10%. Sometimes you launched a new product, and it's 60% because everything is failing. As a conclusion from there, it's not a good idea to schedule more than 50% - 60% of deliverables with deadlines, because the right outage is going to toss those estimates really quickly. That's in itself the definition of sufficient slack. If you don't have that, prod fails and no one is around to fix it. If you do, someone can usually start poking at it quickly.
- 5y ago
- PartiallyTyped 5y agoSimply, the system becomes significantly less responsive the more utilized it is. Isn't this one of the most important discoveries of Queuing theory?
- RcouF1uZ4gsC 5y agoI am worried most about how our system pushes efficiency to the detriment of resiliency. 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. 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. Often business efficiency is a way to privatize the gains from efficiency, but but have the public bear the losses from lack of resilience. 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).
- matheusmoreira 5y agoAgreed. Businesses optimize profit generation. Providing good products or services are merely the means to such an end. Increases in efficiency often means sacrificing some quality they view as superfluous but is likely valuable.
- raman162 5y agoI'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.
- jrs235 5y agoBut the MBAs have already done the [creative] thinking. They just want to throw the spec over the fence and have coders code it. /s
- loopz 5y agoYour job is to make their wishful thinking the thundering success they deserve. To counter the original point, I find removing obstacles and latency-inducing loops helpful, to start seeing what the work really should be. Gaining efficiency through simplifying is a good thing, and can be creative too. The goal is not efficiency though.
- carbonguy 5y agoI think you're on to something important here - the word "efficiency" is used to describe optimization in two different mental regimes: one, "how to meet a given quality of work with the minimum of friction/wastage" vs two, "how to perform the maximal work within a fixed resource allocation." They sound similar, which is probably why we use the word "efficiency" to describe improvements in both regimes, but the fundamental constraint is different: in the first case, it's the standard of work that must be achieved; in the second, it's the resources allocated to the work. I'd summarize the first "do enough with enough" and the second as "do more with less." What you describe sounds like "doing enough with enough:" given the work to be done, how can we remove resource-draining obstacles, idle loops, etc. and identify "what the work really should be?" - is that a fair assessment or am I off the mark?
- loopz 5y ago
- Scarbutt 5y agoTL;DR Take walks
- SketchySeaBeast 5y agoThat still seems efficiency focused - adding a deliberate "off time" to try to be more effective.
- nine_k 5y agoAh, "Antifragile" done quick? Nice. Even shorter: there'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.
- bumby 5y agoDoesn't this just imply that the cost function is over simplistic rather than there is "no single absolute optimum"? E.g., maybe a more appropriate cost function factors in both resilience and efficiency. It reminds me of working a scheduling problem that failed to factor in union concerns. It was a bad solution because it didn't factor in all the dimensions of the actual problem and only originally concerned itself with "management's" cost concerns, not the "union's" cost concerns. Tbf, I never finished "Antifragile" as I felt like it just kept going over the same concept from different angles without introducing anything new after the first 50 or so pages.
- nine_k 5y agoIndeed, I meant that a simplistic approach which wants to have every dimension of utility turned up to 11 simultaneously does not work. You not just need to factor in more dimensions than efficiency, you have to trade gains in one dimension for losses in another. The scalar utility function you can reasonably optimize here is some weighted combination.
- deleted 5y ago[deleted]
- choeger 5y agoIn retrospect, yes, this is absolutely true. One is much 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.
- Jtsummers 5y agoYou get slack by not delaying on the things that can be done immediately (with no or minimal planning), and then planning the rest so that you tackle it in an appropriate fashion. If you don't plan it, you'll end up creating additional work on top of the desired work to fix the issues produced by skipping planning.
- deleted 5y ago[deleted]
- moksly 5y agoI 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. 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. 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. 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.
- mumblemumble 5y agoJust throwing peanuts from the gallery, is it possible that process optimizers' hands-on efforts have been confounded by the Hawthorne effect?
- tonyedgecombe 5y agoIt reminds me a little of a story I read about Alcoa, the Aluminium manufacturer. They had been have issues with improving productivity. One of the issues was the workforce and unions were reluctant to accept any change. New management came in and rather than pressing on productivity issues they decided to double down on safety. They hadn't been particularly bad but not great either. Obviously staff and unions are never going to complain about making their workplace safer. What also happened was as soon as process were open to change to improve safety they were also open to change for productivity. I wonder in cases like yours whether the pandemic just unstuck a lot of things because all the previous excuses floated away as soon as someone says "because covid".
- giantrobot 5y agoJ. R. Dobbs approves.
- h2odragon 5y agoAs usual, prophets aren't really understood 'til later.
- seem_2211 5y agoWe'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.
- jfim 5y agoIt's easier to prove that one "saved" the company money by removing a support position than to evaluate the amount of money wasted yearly by engineers having to buy paperclips and figuring out how to expense them in the horrible expensing software.
- steveBK123 5y agoyes and there is also often departmental budget arb going on here Devs in engineering org now have to spend more time on self-service portals & chasing tickets because the manager of the infrastructure org laid off a bunch of sysadmins. I once worked at a bank where even replacing a physical disk in a US datacenter involved a ticketing system which dispatched tickets to India. The remote guys would then, presumably, raise some sort of internal ticket so the guy physically in US could you know.. replace a bad disk. Turnaround on bad disk swaps went from hours to weeks. As the hardware aged, we started to have enough disk failures pile up on RAID arrays that data losses occurred. Somewhere someone in infra cut his budget though!
- seem_2211 5y agoIt’s a very human tendency: we can see the downside so obviously, but the upside is a lot harder to see. Open offices: another amazing example of enormous value destruction in the name of saving a little bit of money.
- thesuitonym 5y agoI never thought open offices were about cost savings, I always thought it was about someone reading that we spend too much time isolated and need more interaction or some such BS.
- deleted 5y ago[deleted]
- carbonguy 5y agoOne of the quotes suggests that DeMarco (the author of the book under discussion in this post) himself views 'slack' somewhat negatively: > “Slack represents operational capacity sacrificed in the interests of long-term health.” [emphasis mine] Quibble it might be, but nevertheless: surely if the goal is to appreciate the value of 'slack,' it would be better to describe it as an investment in long-term health, rather than a sacrifice for it? To be fair, I suspect he was trying to implicitly refer to "opportunity cost" - every investment implies a "sacrifice" of the alternatives. But it seems to lead the blog post author into a similar dissonant frame of thinking: > Slack consists of excess resources... Slack is vital... Here I quibble with the use of "excess." 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 "excess" at all, but indeed "vital!" In other words, they are fundamental to the continued existence of the operation. Why imply anything else?
- bumby 5y ago>Excess compared to what? I was reading this in the operations research sense of optimality. From this standpoint, they are excess in the current set of constraints but may be vital (an non-excessive) if those constraints change in the future.
- myfavoritedog 5y agoSome 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. But also beware the easy seduction of the idea that you don't have to work hard to have a good chance of success.
- Paradox0 5y agoCounterpoint (kinda): https://efficiencyiseverything.com/ https://efficiencyiseverything.com/
- antod 5y agoheh > Saving 4 minutes a day on a process, over the course of your lifetime you will save 1200 hours. That’s a half year of vacation. If I had to micromanage my personal life that way, I'd need a lot more than half a year of extra vacation in my lifetime to stay sane. I value not having to think too hard about running my personal life higher than saving a few minutes here and there. Let alone wondering if those saved minutes are really fungible enough to translate into bulk time or money savings elsewhere.
- benlivengood 5y agoIn other words 99th percentile latency is what matters, not utilization. Anyone who's tried to get things done with batch-class resources has probably noticed this as well. There's a similarity to the overall economy as well. Just in time inventory is certainly efficient but it's incredibly fragile. Just look at how much "damage" is being claimed for a boat that made other boats two weeks late.
- marcosdumay 5y agoJust to add, 99th percentile latency to the institution processes is an ok metric, but 99th percentile latency to personal or departmental processes is a naive and bad one. If you are not making an effort to be complete on what you are measuring, you'll probably want to put more 9s there.
- pjungwir 5y agoThe 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.
- mauvehaus 5y agoAnd this is why you schedule flights in the morning: there's so damn little slack in the system that if things go wrong at 10:00 AM at O'Hare, flights for the whole rest of the day are screwed up owing to the cascading delays. At least in the morning the airlines have had the overnight to unsnarl the previous day's mess because of the reduced revenue traffic overnight and the corresponding slack that accrues as a happy side effect. This is also why things like the healthcare system, transportation network, and postal system shouldn't be run for maximum utilization/efficiency under normal load: if there isn'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. When it's national or global scale event, you're left leaning on whatever slack was in the system. As we're all painfully aware, there hasn't been enough. The public health and healthcare systems have been doing heroic work, but if they weren't stretched so tight in the name of efficiency beforehand, there'd be less need for the heroic efforts. [0] https://en.wikipedia.org/wiki/Merrimack_Valley_gas_explosions https://en.wikipedia.org/wiki/Merrimack_Valley_gas_explosion...
- Jtsummers 5y ago> This is also why things like the healthcare system, transportation network, and postal system shouldn't be run for maximum utilization/efficiency under normal load: if there isn't any slack in the system it gets real ugly when things get squirrelly. A couple years before the pandemic, the counties neighboring mine (where I lived at the time) cut out most public medical services (mind you, these aren't free, just publicly funded, people still paid for them). There wasn't enough money for a private hospital to bother so this was a critical piece of infrastructure. They kept emergency and urgent care clinics in each county, but directed people to the other (more populated, higher income) counties like mine for many services. Last year was not a good year for those counties as people were now being shuttled 40+ miles if they needed to be treated (at a hospital) for COVID. Lean means cutting the fat, not the meat. They didn't just cut the fat and meat, they cut to the bone. This is when organizations find themselves in trouble and fail their clients/customers: eliminating things they don't think they need because they're "underutilized", only to discover later there was a sound reason to have that capability to begin with.
- arthurjj 5y agoI'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's relatively more expensive. Focusing on the cult of efficiency can distract you from the real causes [1] "Fully Grown" goes into exhaustive research of every possibly cause of the productivity slow down. https://amzn.to/3nN1ZrR https://amzn.to/3nN1ZrR
- Shadonototro 5y agono, it depends if it is to do things only just for yourself, the nobody gives a shit if you work on a team, and do things with other people, then efficiency is your friend, same for performance by default thinking the opposite is lying to yourself, worse, it is very selfish, you basically waste everyone's time and ressources
- feoren 5y agoIf it's true that "Slack represents operational capacity sacrificed in the interests of long-term health", then who exactly is the target audience of this article? Corporations have not cared about "long-term health" 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!?
- carbonguy 5y ago> Who exactly is the target audience of this article? If I had to guess, it would probably be most useful for those companies that have not yet reached the stage where they can serve as the venue for the executive-musical-chairs stage of management you describe. My assumption is that when the company is small enough, that which "makes me look the best" and that which "is in the long term interests of the company" are probably mostly aligned due to the higher visibility of those early executives and managers. Not that this stops the ladder-climbers, of course - it's just more obvious when they personally contribute to wrecking a company if the company is small, which presumably the personal-brand-conscious executive would try to avoid. > Eating up all available slack is one of the more mundane ways to cannibalize the company for your own benefit. Otherwise known as "maximizing shareholder value."
- diragon 5y ago> > Eating up all available slack is one of the more mundane ways to cannibalize the company for your own benefit. > Otherwise known as "maximizing shareholder value." It can also be done by the employees by slacking off on surplus.
- carbonguy 5y ago> It can also be done by the employees by slacking off on surplus. Can't argue with that, given that we're having this conversation while I, at least, am on the clock. However, I suspect my bosses have a much greater capacity to benefit from cannibalizing the company than I do.
- bonthron 5y agoJ. R. "Bob" Dobbs taught us the importance of Slack years ago.
- robbmorganf 5y agoI had an off-topic thought that the ideal of Slack (the chat service) is actually very well explained by "slack" as defined in this article. This article holds "slack" 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. However, executives clearly aren't quite getting the benefit. They expect employees to respond immediately to every new need and new task, but they didn'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) and employees getting burnt out quickly.
- markus_zhang 5y agoI 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't need that much of time to slack (he seems to use "researching how to do difficult things" and programming retreats as a way to slack from daily programming jobs) but most of us need it.
- mtalhaashraf 5y agoI see slack in my personal life as having unplanned periods of time. I think it's really important for improvement to have some free time everyday that is not dedicated for a specific thing. Because there are so many things we don't know and also many things we don't know that we don't know. So I make sure that I have enough slack in my day to allow some random digressions
- therouwboat 5y agoI 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+/h machines stop, than see some worker not being 100% busy all the time.
- allenu 5y agoSomething that I've noticed recently is that in my work life, I'm finding there's more bureaucracy in what I do, mostly in the name of "efficiency". When you encounter a problem to solve, there's often a process already defined that is most efficient (or at least thought to be most efficient), when accomplishing tasks, there's a pre-defined way of laying out the tasks (i.e. tickets), updating them, reviewing them, and organizationally figuring out what's best to do next. In my opinion, these processes are an attempt at organizational efficiency. However, the flip side is it reduces personal agency for the worker. There's little room to diverge or think about what you'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 "costs" something. In a sense, you're punished for doing things differently. 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.
- Laarlf 5y agoOverregulation and bureaucracy are the downfall of the west. The sooner we realise that, the sooner we can fix it.
- enkid 5y agoWhat does this mean? I'm pretty sure the main alternative- China - is both over regulated and is very bureaucratic.
- SuoDuanDao 5y agoYou might be surprised. Enforcement is certainly draconian, but there are not absurdly many regulations, and it is also surprisingly (to westerners) Feudal - personal relationships and high agency in a narrowly defined area are very important to the system functioning.
- quixoticelixer- 5y ago
- renewiltord 5y agoThat 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's not a bottleneck. We have an intuitive understanding of this as engineers. If you've got a program that's CPU-bound then you don't optimize the IO. If you've got a program that's IO-bound you don't optimize the CPU.
- thesnide 5y agoThis is HN, and no-one yet mentionned the "Boimler Effect" ?
- bluGill 5y agoEfficient 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.
- redisman 5y agoI 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.
- Litost 5y agoThis 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 "the right thing wrong" and the "wrong thing right" 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've not managed to find a good link to that, I'd be interested if anyone has? The whole talk is quite interesting, but I've linked to the relevant segment: [1] https://youtu.be/OqEeIG8aPPk?t=591 https://youtu.be/OqEeIG8aPPk?t=591
- ehershey 5y agoThere’s this, a close match: “There is surely nothing quite so useless as doing with great efficiency what should not be done at all.” From hbr in 1963. https://hbr.org/1963/05/managing-for-business-effectiveness https://hbr.org/1963/05/managing-for-business-effectiveness
- betwixthewires 5y agoThe 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. This actually made me think about somewhere I might be wrong. I just got the book the article references and I'm going to read it. I've always been about efficiency, and still am where things can be automated. But the idea that you're less effective if you cram your life with tasks is intriguing, and maybe a little enticing. I'd like to explore the concept further.
- whall6 5y agoHere’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. 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. 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.
- jl2718 5y agoThe value of your employees voluntary contributions are capped at the least valuable thing you put on their list of things to do. If your employee’s best chance at success are in the success of your business, they’ll do great things without being asked, that you don’t even know about. If not, it doesn’t matter what you ask them to do.
- whall6 5y agoI can’t really see how the value of employee contributions are capped at the least valuable thing they have the responsibility to do. As for the second part of your reply, I entirely agree. When employees catch the vision of the company as a whole, it makes sense that they would be motivated to bring something to the table on their free time. Much harder to do within larger orgs.
- rsj_hn 5y agoI think this is only true if you create a workplace environment that encourages this. If you micromanage your employees with metrics, they will adjust their behavior to maximize the metrics, and you will know exactly what they are doing (but not if they are doing what they should be doing).
- jl2718 5y agoNo. You will expect them to maximize the metrics, but they will do the minimum, and think you’re an idiot, and the quality of their work will be terrible, and they won’t say a word. Every new hire is an opportunity to let that person do their best work for the company. Your opportunity to screw up because you think you know better. If that doesn’t make sense to you, you’re probably in the 60-90% that HBR classifies as negative value managers. We have this idea that management is just a bunch of simple processes, and it is, in the same way that building a bridge is just welding together steel beams. Every struggling engineer wants to be a manager because they think it’s easier work with more power over other people and higher pay, which it is, and this incentive structure creates this reality no matter how hard you fight it. Think about the opposite. What would happen if each engineer had a budget and they decide how much they want to pay whom for management services? How would your role as a manager change in that situation? To earn a salary, you would have to have an extraordinary competence in helping people to be more effective, or just play politics downward. And the engineers, well, they could choose to be lazy and incompetent, or they could be aggressive and incompetent, or they could be ambitious and disciplined, or whatever they want to be. So you see how the situation is not that different with the roles reversed.
- dfilppi 5y agoThis combined with the mirage of multitasking are effectiveness killers
- jdashg 5y agoFor a more macro/systemic discussion of slack, I liked this SSC article: https://slatestarcodex.com/2020/05/12/studies-on-slack/ https://slatestarcodex.com/2020/05/12/studies-on-slack/
- 29athrowaway 5y agoOptimizing for individual productivity is different than optimizing for team productivity. Writing code as fast as possible does not produce readable code. Code with low readability is not productive at scale or over time.
- jl2718 5y ago>> Imagine if Tony decided to assign her more work to ensure she spends a full eight hours a day busy. Tony invents “agile/scrum”.
- GuB-42 5y agoIsn't that a well studied problem, applicable to many fields? 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. So how can we expect people to be 100% efficient if even machines can't be 100% efficient?
- bumby 5y ago>So how can we expect people to be 100% efficient if even machines can't be 100% efficient? The article addresses this, I think, in the "Total efficiency is a myth" section: "it is impossible to keep everyone in the organization 100 percent busy unless we allow for some buffering"
- hinkley 5y agoOne of the uncomfortable conversations we're going to have to have soon is about how 'Flow State' is efficient but ineffective. One of the characteristics of Flow State is a diminished sense of considering the consequences of an action. Exactly the "so busy figuring out if they could do it that they didn't stop to think if they should do it". In particular I'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, "how could anything that made me feel that good really be bad?" to "I got three days of work done in one day you are crapping all over it instead of congratulating me? Fuck you!" I know that the efficacy of my code tends to be higher when I 'come up for air', 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'm tempted to violate them. Pomodoro might be a little to structured for many of us, but as a starting point it might be a reasonable antidote. I think in general that programmers have an easier time entering Flow State, but if you'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.
- rocqua 5y agoVery interesting idea, and honestly quite scary. I love my flow state, but I do recognize the defensiveness. Not sure I have run into making bad decisions "in the flow" yet, but I could see how it happens. If true, the bad decisions coupled with defensiveness could be a potentially really toxic combination.
- pfraze 5y agoI think you’re completely right and one way to counteract it is to bake in “non work” or “idle work” time regularly. This doesn’t have to be a vacation, but it does mean staying out of flow and reflecting on the project as a whole. This can also be a good time to fix little boring things like individual UI elements.
- megameter 5y agoI agree with this. Flow is a useful adaptation for something like learning muscle memory - practicing athletics or performing music. But when we're talking about intellectual pursuits like programming, if what you've done by entering flow is convert thinking into muscle memory - a cycle of mashing edit and debug keys - you may have just "laborized" your work. And this has some implications for what kinds of software can be sold to people, as well as how software is created. The norm of programming is really to flip between "trivial 5 minute task" and "requires a day off to contemplate". And in the industrial context, it's evident that most of software is built to restate a preexisting belief - this is good, if we make an app that does it, it's better. This means disengaging from the philosophical problem of whether it's actually "good" and contemplating it until the resulting belief structure has grown so unwieldy and contradictory that it is a technical challenge to maintain it. But selling a preexisting belief is one of the best markets to be in: if you're selling to artists, you sell software that looks like a paint canvas. If you sell to musicians, you sell software that looks like studio gear from 50 years ago. If you sell to investors, you sell a thing that looks like money. What you can't sell(easily) is: new ways of making visuals, new ways of describing and performing music, new ways of explaining credit and value transfer in an economy. Hence there is an awful conundrum; if you are experiencing a lot of flow, a lot of "wind in your sails", the whole thing is almost certainly on the wrong track and you'll only wake up to it later, because it means your ability to contemplate went out the window. The problem is not just that you can write something bad this way, you can even be praised and given access to more resources if your wrong belief is shared! That is probably why software has this underlying tendency towards mysticism and cargo cults, in fact; "It's a good practice." "Why?" "It makes me feel good and the customer likes it." "What's the benchmark?" "I get paid, and it hasn't failed yet."
- feralimal 5y agoThis is the problem of collectivised solutions from experts. They cannot allow the individual to work out how to do his business in the most efficient way for him, oh no. Technocrats and their ilk insist they know best for everyone! And we as technologists are their enablers. If you don't like the present bureaucracy, you won't enjoy the coming years at all, as bureaucratic processes will swell, with vaccine passports, environmental constraints, more health and safety BS, etc, etc. You'll do about 5 mins per day of something that is actually useful. In fact, even those 5 mins will be on a project that any sensible person could have called as a sure fire failure from the start. As we apparently we want a communistic/socialistic approach to be governed by, we will get it.
- austincheney 5y agoThe problem isn'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/from you are both more productive and more efficient. 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: * Do you have to go to multiple locations for project documentation? * Do you have to configure a bunch of tools and steps in a certain order for your project to work? * Do you have to jump through a bunch of meetings to know what's going on? 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.
- grouphugs 5y agonazis are the enemy, efficiency matters when it matters
- swayvil 5y agoWe place more faith in authoritative ideology than personal judgment and observation. So when authority (be it boss, consensus, convention or propaganda) says "be more efficient" (or whatever), we do it. Despite any observed mountain of evidence to the contrary. And despite our feelings on the matter. As a rule, that's people. Little goddamn robots.
- seoaeu 5y agoThere are two subtly different kinds of efficiency: 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. 2) What fraction of resources aren't used productively at all. The "slack" from the article, or wheat that gets grown but not eaten. Improving the first kind of efficiency is usually a good thing. The second can also be positive, but only in moderation. If you try to reduce slack too much then you'll end up with systems that are brittle and have serious failure modes (like famine caused by wheat production being lower than expected)
- lbacaj 5y agoNearly every system in nature has some slack baked into it. 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/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. 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/7? 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. 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: https://louiebacaj.com/what-happens-if-we-squeeze-too-much/ https://louiebacaj.com/what-happens-if-we-squeeze-too-much/
- jjk166 5y agoI 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.
- andrewflnr 5y agoThis 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 "a system that's highly optimized for one environment is correspondingly unoptimized for any other environment", 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.
- treeman79 5y agoWhile 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. “Then instead of shovels, why don’t you give them spoons and create even more jobs?” Friedman inquired.
- mhb 5y agotldr: Just In Time makes systems brittle. https://en.wikipedia.org/wiki/Just-in-time_manufacturing https://en.wikipedia.org/wiki/Just-in-time_manufacturing
- cratermoon 5y agoSome companies value "busyness". 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. But busyness is not productivity.
- 1ncorrect 5y agoEfficiency 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.
- dreamcompiler 5y agoMoshe Vardi gave a talk on this idea recently as it applies to the COVID-19 crisis. His word for slack is "resilience" but it's the same concept. He quotes William Galston: "Efficiency comes through optimal adaptation to an existing environment, while resilience requires the capacity to adapt to disruptive changes in the environment." You cannot maximize one without sacrificing the other. https://learning.acm.org/techtalks/covid https://learning.acm.org/techtalks/covid
- reader_x 5y agoI’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.
- stretchwithme 5y agoSeems like some of the same ideas in Donald Reinertsen presents in his books and videos. He thinks in queues and the cost of delay. The cost of delay when you try to keep everyone busy all the time. I'm reading his book The Principles of Product Development Flow.
- fallous 5y agoOne problem is that we've turned "efficient" into some sort of noun that is self-referential, rather than the actual definition which is constrained to a particular result. "We must be efficient." should beg the question "to achieve what?" 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. 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. 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'd laugh at a commercial site that got slashdotted because it was incapable of handling burst demand.
- ChrisMarshallNY 5y agoWhen 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. When I get back to the task, I tend to get it completed in no time at all, or solve the problem quickly. 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.
- TeeMassive 5y agoThis 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 "everyone has something to do". In fact it's very common. It's important that your bottlenecks are never waiting for a task to complete. It's important that firefighters of your organizations are ready for anything that could block important processes or bottlenecks. It's important that certain tasks are ready to accept a new job so WIP doesn't accumulate and lead times are kept low.
- a0zU 5y agoThis might be a bit pedantic but it seems that this article is arguing against business as a technique for ensuring increased efficiency, it isn't arguing against efficiency itself. This post's whole ethos is that slack creates higher efficiency due to an increased reaction time from workers.
- allurbase 5y agoMost 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. For non programmers, of course, the idea that someone valuable is doing something that they have no control over is absolutely terrifying.
- rwoerz 5y agoBasic 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 / (1-u), where t is the average processing time per job. So, from a client's (job) point of view, maximizing resource utilization is bad.
- ex3xu 5y agoReminds 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's what many of us are fostering in our own lives and businesses. What Shane calls slack, you could also call the margin of safety.
- runeks 5y ago"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." — Osho
- collaborative 5y agoThis 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'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/dept I can't help those who need me because that would set me behind on my urgent tasks. But others can't help me in my urgent tasks because it would set them behind on theirs' Circle of doom
- Siira 5y agoGoing straight to the mouth of the horse is better: https://www.greaterwrong.com/tag/slack?showPostCount=true&useTagName=true https://www.greaterwrong.com/tag/slack?showPostCount=true&us...
- davidhyde 5y agoThe title should rather be “Having no free time is the enemy”. The article confuses being busy with being efficient.