The truth is, no one really likes being measured, especially devs. But business leaders like looking at numbers, so they grab what’s easily available - # of code changes, agile velocity, individual developer metrics. These types of metrics are unbalanced, exclude context, and hurt engineering culture as a whole.

Measuring should start by answering the question “What is the most valuable outcome?”

Why? Because what you measure is what your team will produce. If you start measuring the number of code changes as a key performance metric, you are going to see coding time, PR size, and Cycle Time all increase.

Don’t fall into this trap.

In this session I discuss which team level metrics are most significant, the outcomes they produce, and strategies that will help you avoid the mistakes I’ve already made.