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.

For everyone else you need to occupy their time with tasks as much as possible because their value is linear.

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.

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/

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.

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