Let people do nothing
That manager's desire to fully utilize their employees is understandable. After all, the company pays for the work they do. But paying to do something not directly related to a current scope of tasks or, even worse, paying for doing nothing at all, is something crazy.
I have a different opinion. Many times, it's actually better for the entire team's performance to do nothing at specific moments than to do something. Maybe I'm actually going crazy.
But let me explain first.
Hyperutilization outside of bottleneck
Imagine you have a typical team with three members: two developers and one QA.
One of the developers has finished a task. You assign them a new task from the "ToDo" list. Which makes sense because there are still plenty of tasks left on that list. The developers are expensive resources, so it's important to keep them consistently occupied with work. Nobody would think in any other way, right?
* The easiest way to get started with Theory Of Constraints is to read Goldratt's "The Goal"
No, what you didn't notice is that the tester is overloaded. Considering the current situation on the board, testing is the bottleneck. According to the Theory of Constraints, the team's performance is determined by the performance of the bottleneck. The developer can take on a new task, but it won't impact the number of features released per unit of time.
The best thing you can do is to spend the developer's time expanding the bottleneck. This can be achieved either directly by assisting with testing or indirectly by coming up with improvements to the production process in that area.
100% utilization is only justified when addressing the bottleneck. Otherwise, you'll have a lot of unfinished work waiting for the moment the bottleneck resource becomes available to complete it. The accumulated unfinished work is a premature investment. Moreover, in the case of software development, it's an investment in tomatoes that will soon rot because the code becomes outdated over time and may become unmergeable.
Hyperutilization in planning
In my opinion, production planning is pointless. It's like some kind of shamanism.
But let's imagine you have to do it. You have a Scrum team, sprints, and planning poker. You measure the team's velocity in each sprint. Based on how things went in the last sprint, you plan how much work to do (in story points) for the next one. And you make a commitment to do that amount of work (God help you).
In my experience, during planning meetings, they never talk about adding extra time for safety in the estimates. If the previous sprint didn't go well, they reduce the estimate to match what got done. If they meet the estimate, they set the bar higher.
That didn't make things more predictable. Instead it left us permanently confused about what we did wrong. But we didn't make any mistakes, it's just how software development works (and the uselessness of story points, but that's a discussion for another day).
Even in the case of computers, which are highly stable and predictable systems, managers do not utilize them at 100%, despite paying for 100%. CPU and RAM on servers (or laptops) always have some level of reserve. And no one questions "why?". It's commonly understood it's to prevent overheating and slowdowns.
Unfortunately, not many managers are willing to use the same approach with their employees.
