Ask HN: Have we confused efficiency with "100% utilization"?
22 comments
I’m constantly arguing for more slack in the system. Too many managers treat knowledge work like it’s a factory.
I ran a team for about a year and was constantly pushing them to do less. The team were the ones trying to pile on more work, a force of habit I think.
I noticed that when we planned less, people finished faster (probably due to greater focus and a quick finish in sight), then they pulled more into the sprint and ended up getting more done. We actually went faster when we tried to do less. I’m hoping that being told to slow down all the time meant it wasn’t actually stressful for them either. I always wanted to have slack in the system so we weren’t having to perform heroics and pull all-nighters to meet arbitrary deadlines. If something came up, we could fit it in, because we weren’t overloading ourselves. And when nothing came up, we flew.
I stepped back into an IC role, as I didn’t really enjoy running things. The person who took over was skeptical of how I had done things, but was told to try going with it, since we had been so successful. Overtime there was some regression. After a couple more management changes, we are the polar opposite. Everyone is stressed and it seems like very little actually gets done, because everyone is stretched so thin on too many projects at once. Everyone looks really busy though, I guess that’s all that matters anymore.
I ran a team for about a year and was constantly pushing them to do less. The team were the ones trying to pile on more work, a force of habit I think.
I noticed that when we planned less, people finished faster (probably due to greater focus and a quick finish in sight), then they pulled more into the sprint and ended up getting more done. We actually went faster when we tried to do less. I’m hoping that being told to slow down all the time meant it wasn’t actually stressful for them either. I always wanted to have slack in the system so we weren’t having to perform heroics and pull all-nighters to meet arbitrary deadlines. If something came up, we could fit it in, because we weren’t overloading ourselves. And when nothing came up, we flew.
I stepped back into an IC role, as I didn’t really enjoy running things. The person who took over was skeptical of how I had done things, but was told to try going with it, since we had been so successful. Overtime there was some regression. After a couple more management changes, we are the polar opposite. Everyone is stressed and it seems like very little actually gets done, because everyone is stretched so thin on too many projects at once. Everyone looks really busy though, I guess that’s all that matters anymore.
> Everyone looks really busy though, I guess that’s all that matters anymore.
This is a dangerous tide incoming. I once had a conversation with a new exec as to why a certain team doesn't "look busy". In their mind people are just "coasting" and need to pull up their socks and improve delivery. The concept of being proficient and streamlined about your work simply didn't strike a chord. That place went downhill pretty fast.
This is a dangerous tide incoming. I once had a conversation with a new exec as to why a certain team doesn't "look busy". In their mind people are just "coasting" and need to pull up their socks and improve delivery. The concept of being proficient and streamlined about your work simply didn't strike a chord. That place went downhill pretty fast.
Yeah, I’m already seeing it. Firefighting is rewarded, while actual planning and proactive work that avoids the need to firefight is viewed as lazy and people not doing anything.
People who write code with a lot of bugs end up looking like heroes, because they are always jumping in to fix their breaking code, while someone who takes the time to properly test and write solid code is seen as slow and less capable.
The house of cards just keeps growing, and everyone is on the verge of walking out.
People who write code with a lot of bugs end up looking like heroes, because they are always jumping in to fix their breaking code, while someone who takes the time to properly test and write solid code is seen as slow and less capable.
The house of cards just keeps growing, and everyone is on the verge of walking out.
COVID and WFH pumped the volume on this. I had very senior person tell me all about the coasters and slackers.
It was in the bar of a beach hotel at 11AM on a Tuesday, of course. I think he was on two Teams meetings the whole time as well.
It was in the bar of a beach hotel at 11AM on a Tuesday, of course. I think he was on two Teams meetings the whole time as well.
Yes, and it’s now up to us as managers to engineer that ebb and flow as part of the process. Don’t assign too much work all the time. Make sure that the employees feel excited and rewarded for their hard work (don’t just dump another pile on their desk). Make sure their work is diverse enough so they are not stuck doing the same slog all the time.
Make sure the employee sees the big picture of the company - this is how your work is contributing to our mission (the janitor at nasa isn’t sweeping the floor, he’s helping put a man on the moon). When boring work must be done tell them you know it’s boring but all of us have to shovel gravel sometimes, it’s just part of life, but there’s a bit of fun on the other side of it. Be interested in the employees - what are their personal goals over the next 12 months? Learn their dogs name, learn their hobbies, be interested in them as a human and then TRY HELP THEM get to their personal goals. If they want to get fit then block out an hour gym time and send them off to it. Encourage them to bring you new ideas, support them to try out the new ideas - if it doesn’t work out then “hey no problem” but if it does work out tell everyone in the company very publicly and make a lot of noise about it. Don’t criticise them in public, take them aside and help them be better. And lastly, is someone isn’t working out, or is causing cultural problems - get rid of them, it’s harming more than you think. Don’t micromanage - assign the work, support them and then get the hell out of the way.
Good managers will do all of this simultaneously.
Bad managers just try to cram as much work in as possible. Because they are so poor at evaluating the quality of what their employees are doing, the only thing they understand is maximise throughput at the expense of all else. If your manager is like this, leave asap
Good managers will do all of this simultaneously.
Bad managers just try to cram as much work in as possible. Because they are so poor at evaluating the quality of what their employees are doing, the only thing they understand is maximise throughput at the expense of all else. If your manager is like this, leave asap
its like the c-suite and level below them lost all empathy and now its on the line managers to pick it up, among everything else they do.
This is an old discussion. Goldratt wrote an entire book largely on this topic, The Goal. One of the early chapters (it's been a decade since I read it, not going to track down a copy to get precise pages or anything) is addressing confusion over the utilization of a machine in the factory vs the efficiency of the factory. It's also not new in software. I had a manager tell me I didn't spend enough time typing (he'd never written a line of code after college), even though I'd written quite a bit but not enough code apparently. He liked heroic coders, the sort I usually ended up cleaning up after because they spent too little time thinking and too much time typing, producing products that couldn't be maintained because they had multi-thousand line functions and grotesque for loops containing the bulk of the logic.
The trade off between utilization and latency is rarely understood in organizations. Little’s law should be mandatory (management) reading. Unused capacity is not waste, but buffers that absorb variability, and thus keeps latency down.
This is the exact mental model I was looking for.
It reminds me of Kingman's Formula in queueing theory: As server utilization approaches 100%, the wait time approaches infinity.
We intuitively understand this for servers (you never run a CPU at 99% if you want responsiveness), yet for some reason, we decided that a human brain—which is infinitely more complex—should run at 99% capacity and still be expected to handle urgent interruptions without crashing.
It reminds me of Kingman's Formula in queueing theory: As server utilization approaches 100%, the wait time approaches infinity.
We intuitively understand this for servers (you never run a CPU at 99% if you want responsiveness), yet for some reason, we decided that a human brain—which is infinitely more complex—should run at 99% capacity and still be expected to handle urgent interruptions without crashing.
I saw it 20+ years ago in the US airline industry. At the time, the pilots and the flight attendants were considered a unit; they were scheduled as a unit and worked the same flights and overnighted at the same hotels. Most US airlines started scheduling the pilots and the flight attendants separately. The tradeoff is yes, this usually results in more efficiency or cost-savings. But when there is a severe snowstorm as happened to Southwest a few years ago; Southwest lost track of the pilots and the flight attendants and it made a bad problem exponentially more difficult.
Yes, it's sad.
For a couple of years I helped develop scheduling software for supply chains in process industry. We frequently optimized for throughput or resource utilization, but also for just in time or minimal latency. So goals differ, but it kind of works in industrial context.
Now, there has always been a tendency to also frame knowledge work like software development as though it's just industrial production. Hence (mostly futile) attempts to make things predictable, reproducible and "efficient". Where efficiency is bluntly taken to mean optimal utilization.
For a couple of years I helped develop scheduling software for supply chains in process industry. We frequently optimized for throughput or resource utilization, but also for just in time or minimal latency. So goals differ, but it kind of works in industrial context.
Now, there has always been a tendency to also frame knowledge work like software development as though it's just industrial production. Hence (mostly futile) attempts to make things predictable, reproducible and "efficient". Where efficiency is bluntly taken to mean optimal utilization.
That distinction between Industrial Production and Knowledge Work feels like the root cause.
It seems like modern Agile has mutated into a tool for Manufacturing Predictability rather than Software Discovery. We are so obsessed with making the velocity graph look like a straight line that we stopped asking if we are even building the right thing.
Do you think that shift happened because non-technical management needed a metric they could understand (tickets closed), or did we do this to ourselves?
It seems like modern Agile has mutated into a tool for Manufacturing Predictability rather than Software Discovery. We are so obsessed with making the velocity graph look like a straight line that we stopped asking if we are even building the right thing.
Do you think that shift happened because non-technical management needed a metric they could understand (tickets closed), or did we do this to ourselves?
There's often a tension between efficiency (say maximising throughput, or minimising latency) and robustness (being able to cope with shortages of inputs, demand shocks, work around failures). The world got to experience a bunch of logistical examples of this around COVID-19, but there's examples everywhere. Having a whole 2nd engine on a passenger plane seems wasteful, until the first engine fails.
When attempting to apply a process optimisation perspective from supply chains or manufacturing to software delivery, one way the software delivery problem space differs is that the software delivery process isn't a process that produces a stream of identical units that are independent of each other.
Suppose we abstract the software situation, we can tell ourselves that it is a repeatable process that produces an endless stream of independent features or fixes (weighed in "story points" say) that get shipped to production. This mental model maybe works some of the time, until it doesn't.
In reality, each software change is often making a bespoke, one-off modification or addition to an existing system. Work to deliver different features or fixes are not fungible and delivering the work items may not be independent -- if changes interfere with each other by touching overlapping components in the existing system and modifying them in incompatible ways. A more realistic mental model needs to acknowledge that there's a system there, and its existing architecture and accumulated cruft may heavily constrain what can be done, and that the system is often a one-off thing that is getting changed in bespoke ways with each item of work that ships.
When attempting to apply a process optimisation perspective from supply chains or manufacturing to software delivery, one way the software delivery problem space differs is that the software delivery process isn't a process that produces a stream of identical units that are independent of each other.
Suppose we abstract the software situation, we can tell ourselves that it is a repeatable process that produces an endless stream of independent features or fixes (weighed in "story points" say) that get shipped to production. This mental model maybe works some of the time, until it doesn't.
In reality, each software change is often making a bespoke, one-off modification or addition to an existing system. Work to deliver different features or fixes are not fungible and delivering the work items may not be independent -- if changes interfere with each other by touching overlapping components in the existing system and modifying them in incompatible ways. A more realistic mental model needs to acknowledge that there's a system there, and its existing architecture and accumulated cruft may heavily constrain what can be done, and that the system is often a one-off thing that is getting changed in bespoke ways with each item of work that ships.
Yes, I completely agree but it’s not as dire as it sounds. The people most capable of thinking will create their own gaps as necessary to continue thinking, which is inefficient but it’s also a preference. The more busy these people become the more they will work to drive that thinking time and that friction is the basis of innovation. That value is logarithmic.
For everyone else you need to occupy their time with tasks as much as possible because their value is linear.
For everyone else you need to occupy their time with tasks as much as possible because their value is linear.
The thing is, for management, they don't use the product or deal with reality, so for them, the JIRAs _are_ reality, and the more that get done, the better, and any gaps are a problem to be solved.
Idle time can still be incorporated, it just has to be _in_ the tickets, not between the tickets, then everyone is happy.
A ticket for one day to add a new button, then an idle day is bad. A ticket for two days to add a new button keeps everyone happy.
Idle time can still be incorporated, it just has to be _in_ the tickets, not between the tickets, then everyone is happy.
A ticket for one day to add a new button, then an idle day is bad. A ticket for two days to add a new button keeps everyone happy.
Yes. Resilience is an unexploited opportunity for short-term gains, and in the U.S. anyways it’s not legal for most corporations to prioritize their long-term health over the short-term gains demanded by most shareholders (thus the private equity industry).
there's a lot written on the topic - e.g. [1]
My ELIengineer take is that no bearing works without some slack - it gets stuck. But that still needs some understanding, and that is less and less available, esp. at management levels.
[1] https://fs.blog/slack/
My ELIengineer take is that no bearing works without some slack - it gets stuck. But that still needs some understanding, and that is less and less available, esp. at management levels.
[1] https://fs.blog/slack/
Genx here. Yes that is accurate.
What are you talking about?
Up to 80% of a typical dev time these days (depending on the company and the project) is idle waiting for a build to fail again, deployment to finish, all teammates showing up to another useless meeting, writing stupid performance reviews, arguing about secondary yet unavoidable issues on slack and pr comments, etc etc.
Up to 80% of a typical dev time these days (depending on the company and the project) is idle waiting for a build to fail again, deployment to finish, all teammates showing up to another useless meeting, writing stupid performance reviews, arguing about secondary yet unavoidable issues on slack and pr comments, etc etc.
How can that be? Don't you have powerful computers?
people are the weak link, not computers
> We treat Developer Idle Time as a defect to be eliminated by JIRA tickets
It would be very valuable to the community if you name-and-shame the company and manager that would evangelize such an obviously dogshit idea.
It would be very valuable to the community if you name-and-shame the company and manager that would evangelize such an obviously dogshit idea.
He described how they measured atomic hand movements (reach, grasp, orient) in decimal seconds to balance the line. But he made a distinction that stuck with me:
Back then, the goal was Flow (smoothness), which inherently required some slack in the system. Today, he argued, the goal of modern management is Utilization (removing every micro-second of downtime).
His quote: "We deleted the 'waiting,' but we forgot that the waiting was the only time the human got to breathe."
I feel like I see this exact pattern in Software Engineering now. We treat Developer Idle Time as a defect to be eliminated by JIRA tickets, rather than the necessary slack required for thinking.
Ask HN: For those who have been in the industry for 20+ years, do you agree?