<p><strong>TL;DR</strong>: It is the <strong>wrong thing</strong> to measure. By measuring and increasing utilization in employees across the board, you <strong>create problems</strong> in the system and <strong>reduce</strong> overall <strong>throughput</strong>.</p>

<h2>Throughput Accounting</h2>

<p>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 <a href="https://en.wikipedia.org/wiki/Throughput_accounting" rel="noreferrer">throughput accounting</a>. </p>

<p>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.</p>

<h2>Simple system</h2>

<p>In a <strong>simple system</strong> with <em>single human</em> or multiple humans working <em>independently</em> with independent equipment as much as each one does will directly increase the <strong>throughput</strong> of the whole <strong>system</strong>. This leads to the common <strong>misconception</strong> that is basis for this question that increasing human utilization will lead to increased throughput in all systems. But you still measure the <strong>throughput</strong> of the system, <strong>inventory</strong> and operating <strong>expenses</strong>.</p>

<h2>Complex System</h2>

<p>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 <strong>mirage</strong>.</p>

<p><em>Example:</em> 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.</p>

<p>Clearly the benefits are to be gained in properly managing the bottleneck and trying to gain <strong>productivity at the bottleneck</strong>, where <strong>hour gained</strong>, is hour of <strong>throughput of the entire system</strong>.</p>

<p>This is the real message of <a href="https://en.wikipedia.org/wiki/The_Phoenix_Project_(novel)" rel="noreferrer">The Phoenix Project</a> and comes directly from the <a href="https://en.wikipedia.org/wiki/Theory_of_constraints" rel="noreferrer">Theory of Constraints</a> by Eliyahu M. Goldratt. You might also read an article on <a href="https://davenicolette.wordpress.com/2012/02/04/utilization-thinking-vs-throughput-thinking/" rel="noreferrer">utilization thinking vs throughput thinking</a>. I would also suggest to read more on <a href="https://en.wikipedia.org/wiki/Critical_chain_project_management" rel="noreferrer">Critical Chain Process Management</a>.</p>

<p><em>Remember:</em> <a href="https://www.isixsigma.com/community/blogs/what-you-measure-what-you-get/" rel="noreferrer">What you measure is what you get</a>. And you definitely <strong>DO NOT WANT</strong> to get increased individual utilization. <a href="https://en.wikipedia.org/wiki/The_road_to_hell_is_paved_with_good_intentions" rel="noreferrer">A road to Hell is paved with good intentions.</a></p>

CC BY-SA 4.0
2020-10-17T08:47:27.797Z
I definitely learnt something from reading this answer and the linked articles! I'm left wondering though, how to practically measure the throughput of a software development team.
Craig
CC BY-SA 3.0
2017-03-14T19:57:25.363Z
2017-03-14T19:57:25.363Z
Jiri Klouda
<p>In <a href="https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO" rel="noreferrer">The Phoenix Project</a> the single graph in the entire book shows that as a person's workload increases into the high 90%s the wait time on them increases exponentially. In fact in the book it claims that:</p>

<p>Wait Time = (Percentage Busy/Percentage Free)</p>

<p>So if a resource is busy for 35 out of 40 hours per week then:</p>

<pre><code>Wait Time = 0.875/0.125  = 8
</code></pre>

<p>However if a resource is busy for 39 out of 40 hours per week then:</p>

<pre><code>Wait Time = 0.975/0.025  = 39
</code></pre>

<p>This is multiplied up by the number of waits in the workflow. It's obviously something we want to keep an eye on!</p>

<p>So, given all of this it's obviously vital that we keep people's utilisation at a sensible level. Given the book's insistence of the importance of this formula it offers little practical advice on how to measure these values. My question is, how can you practically measure a person's percentage busy?</p>

CC BY-SA 3.0
2017-03-07T11:36:43.007Z
This deserves an answer that quotes the book Slack https://www.amazon.com/dp/0767907698. The myth of efficiency by burning resources at 100% is also the main topic in Theory of Constraints.
Evgeny Zislis
CC BY-SA 3.0
2017-03-07T11:38:57.540Z
@Evgeny - added to reading list, I also came across it in The Goal... I just based my question off TTP as it gives a formula but no way to measure the values :(
Liath
CC BY-SA 3.0
2017-03-07T11:41:24.940Z
Before I have time to write a full answer, I'll just add that in ToC you abandon efficiencies everywhere, to focus on efficiency only on the constraint. Because that allows everywhere else to absorb variety and avoid creating waste (quote Lean here. like overproduction, too much inventory, etc...) since that is non-value-added (quote Lean again) activities.
Evgeny Zislis
CC BY-SA 3.0
2017-03-07T12:12:25.863Z
@Evgeny I agree 100% improvements made anywhere but the constraint are wasted. But I still need to know how busy my constraint resource is surely?
Liath
CC BY-SA 3.0
2017-03-07T12:13:32.703Z
Constraint is rarely a human, even in The Phoenix Project, Bret was first a constraint - but its "his work" that is the actual constraint.
Evgeny Zislis
CC BY-SA 3.0
2017-03-07T12:14:56.347Z
@Evgeny looking forward to the full answer!
Liath
CC BY-SA 3.0
2017-03-07T16:41:34.003Z
I have to say, this all sounds clever in theory, but I've never actually seen this happen in reality (waiting time so high for people who are basically 100% busy). I've worked at 12-13 companies. So, there you go, that's my data. Not much I can say to argue the theory beyond that. I guess all the places I've been, even busy people can react and re-prioritize when the org needs it. **edit** important to note, I've only worked at startups, ever. This could be skewing my POV.
Assaf Lavie
CC BY-SA 3.0
2017-03-07T22:21:42.433Z
@AssafLavie I've worked in all kind of companies from 4 people to missions in 10k people enterprises and draw the same observations as yours. I don't think this question can have a real answer, more answer addressing alternatives and why it's a fallacy to measure people busyness.
Tensibai
CC BY-SA 3.0
2017-03-07T23:40:41.460Z
For SRE the Google SRE book suggest to not handle more than 2 incidents per shift (not average, maximum) and that is considered full utilization.
Jiri Klouda
CC BY-SA 3.0
2017-03-07T23:44:19.350Z
@Evgeny it is not Bret's work that is considered the constraint. It is Bret. His work piles up in front of him. He was the only one who could do it, he was the constraint. If work coming to Bret was the constraint, then the tasks blocking that work would be piling up. That would be different situation.
Jiri Klouda
CC BY-SA 3.0
2017-03-08T06:49:56.320Z
Re Bret see my question on Man, Method, Machine and Process!
Liath
CC BY-SA 3.0
2017-03-08T19:26:29.933Z
An answer here should also use Martin Fowler's "You Cannot Measure Productivity" - https://martinfowler.com/bliki/CannotMeasureProductivity.html
David Bock
<culture><systems><the-phoenix-project>
How to measure human utilisation?
Liath
# How to measure human utilisation?

(Asked by: username_0 on 2017-03-07)

In The Phoenix Project the single graph in the entire book shows that as a person's workload increases into the high 90%s the wait time on them increases exponentially. In fact in the book it claims that:
Wait Time = (Percentage Busy/Percentage Free)
So if a resource is busy for 35 out of 40 hours per week then:
Wait Time = 0.875/0.125  = 8

However if a resource is busy for 39 out of 40 hours per week then:
Wait Time = 0.975/0.025  = 39

This is multiplied up by the number of waits in the workflow. It's obviously something we want to keep an eye on!
So, given all of this it's obviously vital that we keep people's utilisation at a sensible level. Given the book's insistence of the importance of this formula it offers little practical advice on how to measure these values. My question is, how can you practically measure a person's percentage busy?

**Tags:** culture, systems, the-phoenix-project

> **Comments:**
> **username_1**: This deserves an answer that quotes the book Slack https://www.amazon.com/dp/0767907698. The myth of efficiency by burning resources at 100% is also the main topic in Theory of Constraints.  
> **username_0**: @Evgeny - added to reading list, I also came across it in The Goal... I just based my question off TTP as it gives a formula but no way to measure the values :(  
> **username_1**: Before I have time to write a full answer, I'll just add that in ToC you abandon efficiencies everywhere, to focus on efficiency only on the constraint. Because that allows everywhere else to absorb variety and avoid creating waste (quote Lean here. like overproduction, too much inventory, etc...) since that is non-value-added (quote Lean again) activities.  
> **username_0**: @Evgeny I agree 100% improvements made anywhere but the constraint are wasted. But I still need to know how busy my constraint resource is surely?  
> **username_1**: Constraint is rarely a human, even in The Phoenix Project, Bret was first a constraint - but its "his work" that is the actual constraint.  
> **username_0**: @Evgeny looking forward to the full answer!  
> **username_2**: I have to say, this all sounds clever in theory, but I've never actually seen this happen in reality (waiting time so high for people who are basically 100% busy). I've worked at 12-13 companies. So, there you go, that's my data. Not much I can say to argue the theory beyond that. I guess all the places I've been, even busy people can react and re-prioritize when the org needs it. **edit** important to note, I've only worked at startups, ever. This could be skewing my POV.  
> **username_3**: @AssafLavie I've worked in all kind of companies from 4 people to missions in 10k people enterprises and draw the same observations as yours. I don't think this question can have a real answer, more answer addressing alternatives and why it's a fallacy to measure people busyness.  
> **username_4**: For SRE the Google SRE book suggest to not handle more than 2 incidents per shift (not average, maximum) and that is considered full utilization.  
> **username_4**: @Evgeny it is not Bret's work that is considered the constraint. It is Bret. His work piles up in front of him. He was the only one who could do it, he was the constraint. If work coming to Bret was the constraint, then the tasks blocking that work would be piling up. That would be different situation.  
> **username_0**: Re Bret see my question on Man, Method, Machine and Process!  
> **username_5**: An answer here should also use Martin Fowler's "You Cannot Measure Productivity" - https://martinfowler.com/bliki/CannotMeasureProductivity.html  

---

## 1 answers

### Answer by username_4 on 2017-03-14. Score: 7 | Accepted answer

**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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/The_Phoenix_Project_(novel)) and comes directly from the [Theory of Constraints](https://en.wikipedia.org/wiki/Theory_of_constraints) by Eliyahu M. Goldratt. You might also read an article on [utilization thinking vs throughput thinking](https://davenicolette.wordpress.com/2012/02/04/utilization-thinking-vs-throughput-thinking/). I would also suggest to read more on [Critical Chain Process Management](https://en.wikipedia.org/wiki/Critical_chain_project_management).

*Remember:* [What you measure is what you get](https://www.isixsigma.com/community/blogs/what-you-measure-what-you-get/). And you definitely **DO NOT WANT** to get increased individual utilization. [A road to Hell is paved with good intentions.](https://en.wikipedia.org/wiki/The_road_to_hell_is_paved_with_good_intentions)

> **Comments:**
> **username_6**: I definitely learnt something from reading this answer and the linked articles! I'm left wondering though, how to practically measure the throughput of a software development team.  

---

