TL;DR: It is the wrong thing to measure. By measuring and increasing utilization in employees across the board, you create problems in the system and reduce overall throughput.
Throughput Accounting
What you actually want to measure is throughput, inventory and operating expense all together and try to reduce inventory and reduce operating expenses while at the same time maximizing throughput. This method is known as throughput accounting.
In software development, inventory is the work in progress that is not bringing benefits to the customer yet. Anything that has been done, but not released. Throughput is the amount of work useful to the customer that is being released. Any work done that is not directly useful to the customer is accounted as operating expense.
Simple system
In a simple system with single human or multiple humans working independently with independent equipment as much as each one does will directly increase the throughput of the whole system. This leads to the common misconception that is basis for this question that increasing human utilization will lead to increased throughput in all systems. But you still measure the throughput of the system, inventory and operating expenses.
Complex System
In a complex system, even with as little as two dependencies, increased utilization of one part of the system can directly lead to decrease of utilization in the bottleneck, which decreases throughput of the whole system. Any increase in productivity outside of the bottleneck is a mirage.
Example: Team of software engineers has all code reviewed by the software architect, who also makes plans for new features. This person is a bottleneck, code not reviewed by the architect will simply increase inventory, if the architect does not have time, no new features will be properly planed. If you start measuring utilization of software engineers, they will each try to make more changes, rather than better changes. The time the architect will need to spend on each change will increase and the total time spent reviewing will increase further by the increased amount of changes to a point where no time would be left to plan new changes. Eventually the whole system grinds to a halt. If on the other hand they decrease utilization, even spend time idling, they spend longer on each change or peer reviews, this could lead to decrease in time required for reviews and eventually increase in throughput. This is just single team with 2 dependencies. Engineers depend on architect for new changes to be planed and for changes to be reviewed.
Clearly the benefits are to be gained in properly managing the bottleneck and trying to gain productivity at the bottleneck, where hour gained, is hour of throughput of the entire system.
This is the real message of The Phoenix Project and comes directly from the Theory of Constraints by Eliyahu M. Goldratt. You might also read an article on utilization thinking vs throughput thinking. I would also suggest to read more on Critical Chain Process Management.
Remember: What you measure is what you get. And you definitely DO NOT WANT to get increased individual utilization. A road to Hell is paved with good intentions.
