Metrics and Management

Even metrics proponents note that metric based development is hard1. DoubleLoop is an app for building metrics that translate into strategy. Bundling a metric / progress tracking plan with a strategy plan is a powerful idea2.

Metrics and Pressure

Counter points to managing by metrics

Goodhart’s Law implies that any metric you create will lead to perverse incentives. Scrum evangelists particularly abhor management by metrics3.

  • In order to manage to objectives, we must assume that incremental progress can by made. If things are changing dramatically, an easy baseline will be difficult to establish.
  • Individual managers will optimize locally while ignore global contribution.
  • Metrics can fail to capture the real utility. E.g. example of a metric for weight of nails produced in a day results in one gigantic heavy nail being made4.

Metrics should be used when they are causal factors are well understood, or when an experiment can be designed to understand them better. For other scenarios, you have to run data science or econometrics. Richard Marmorstein argues that these situations appropriate for metrics are rare, not common. Therefore, metrics must back a good argument, but a good argument does not require metrics5.

Metric Management Anti-patterns :anti_patterns:management-by-metrics:metrics:

Will Larson offers a handful of anti-patterns in metrics6:

  • Measuring individuals rather than the group
  • Trying to get perfect data: data collection is difficult, settle for the level that allows your to make accurate decisions. This in itself is difficult to know, but don’t let perfect be the enemy of good.
  • Worrying about how metrics will be miss-used. Certainly, you should be diligent about the metrics you present, but treat miss-understandings as a chance to bring the outsider into alignment
  • Operating in isolation: bring in stakeholders and team members to metric creation
  • Using optimization metrics (e.g. SDLC metrics) as a report for value creation. Use value creation metrics for stakeholders that need it. Don’t report your internal improvements as if these are valuable in and of themselves to the org. There is particular danger in this mistake with other executives or higher ups (board).
  • The number one measurement risk is measuring nothing because you’re trying to measure everything

Executive Dashboards

Too often dashboards focus on what has happened in a business (e.g. revenue, contracts signed, etc). These are referred to as output metrics or results. Input metrics, or metrics that drive those results, are much more useful to learn about the business2.

  • Dashboards are incentive design and also a source of power struggle (it frames the focus of the business)2
  • Dashboards need to provide context and differentiate from valuable information to make decisions7.
  • Good dashboards show performance against goals in the simplest possible terms. It “draws the shortest possible line from ‘I see it’ to ‘I get it.’”. A good dashboard is opinionated and defines terms8.

Engineering Metrics

6

  • Look to metrics to align discussion on specific contracts with other parties. There may be initial friction in how the metrics are used or understood, but work through those discussions towards a shared understanding.
  • Measure for planning your goal is to support project selection and prioritization
  • Measure for operation, what do you need to know to be confident that your

software and teams are operating effectively on a day-to-day basis?

  • tracking the number of incidents (each connected to an incident review writeup), minutes of user-facing API and website downtime, latency of user-facing APIs and websites, engineering costs normalized against a core business metric (for example, cost to serve your most important API, calculated simply by dividing API requests per month by engineering spend for that month
  • Measure to optimize what do you need to know to effectively invest

time into improving engineering productivity

  • Measure to inspire and aspire: how can you concisely communicate engineering’s transformational impact to the business?
    • When you speak at company meetings, anchor on these kinds of generational improvements, and try to include at least one such improvement into every annual planning cycle.
  • Finance metrics and capitalization
  • Get alignment with finance on the way engineering costs allocated across business priorities.

Metrics selection process

Some things are difficult to measure, only measure those if you’ll actually incorporate that data into your decision making. Some things are easy to measure, be willing to measure those to build trust with your stakeholders, even if you don’t find them exceptionally accurate. Whenever possible, only take on one new measurement task at a time .6.

  • Review the data on a weekly cadence. Ensure that review looks at how the data has changed over the last month, quarter or year
  • Maintain a hypothesis for why the data changes. If the data changes in a way that violates your hypothesis (“cost per request should go down when requests per second go up, but in this case the cost went up as requests per second went up, why is that?”)
  • Avoid spending too much time alone with the data, instead bring others with different points of view to push on the data together
  • Segment data to capture distinct experiences
  • Discuss how the objective measurement does or does not correspond with the subjective experience of whatever the data represents.

References

1.
Schmidt, D. Metrics-driven product development is hard. at https://blog.doubleloop.app/metrics-driven-product-development-is-hard/ (2021).
2.
Critchlow, T. Some notes on executive dashboards. at https://tomcritchlow.com/2022/05/06/executive-dashboards/ (2022).
3.
Holub, A. KPIs, Velocity, and Other Destructive Metrics. at https://holub.com/kpis-velocity-and-other-destructive-metrics/ (2018).
4.
DeMarco, T. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. (Currency, New York; London, 2002).
5.
Marmorstein, R. Be good-argument-driven, not data-driven. at http://twitchard.github.io/posts/2022-08-26-metrics-schmetrics.html (2022).
6.
Larson, W. Measuring an engineering organization. at https://lethain.com/measuring-engineering-organizations/ (2023).
7.
Butler, C. Building dashboards is cowardly. at https://medium.com/hackernoon/building-dashboards-is-cowardly-73a141f2b517 (2017).
8.
Bartholomew, A. Good dashboard, bad dashboard. at https://www.abartholomew.com/writing/good-dashboard-bad-dashboard.