The ‘flawed five’ engineering productivity metrics
My favorite quantitative metrics for engineering teams:<p><pre><code>  - Avg time from code review requested to code review picked up
  - Avg time to complete code review
  - Avg time from eng done to first customer using it
  - Avg time from eng done to full production release
  - Fraction of tasks started that never reach a customer
</code></pre>
These are loosely based on the Japanese concept of Muda (waste), as personified in the physical logistics world via the acronym TIM WOOD (or TIM WOODS)[0] and are similar but not identical to the DORA metrics.<p>The time to complete a code review is there (for example) not to focus on the amount of time actually spent performing the code review but to focus on all the waiting around the actual code review, which is typically much much longer than the time spent doing the review itself. It&#x27;s not uncommon to see organizations where an engineer will submit code for review and then have to wait a day or more for someone to pick up their request and then another day or more for that other person to get around to reviewing it. If there are comments on the commit that need to be responded to, you can see additional delays. These &quot;minor inefficiencies&quot; can have huge impacts on the poor dev who is trying to get their code merged, and cumulatively they result in significant increases in feature latency, the total calendar time required to ship a feature.<p>[0] <a href="https:&#x2F;&#x2F;www.shmula.com&#x2F;28695-2&#x2F;28695&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.shmula.com&#x2F;28695-2&#x2F;28695&#x2F;</a>