Advice for When You Apply These Ideas

Metrics, used correctly, can be a powerful tool for holding employees accountable to the desired team outcome. Ideally these metrics will be ones that can be gathered automatically (harvested, perhaps, out of GitHub or other development process tools) so that they can be configured once and visited as part of a weekly 1:1 cadence or team huddle, or perhaps even a daily standup if the metric cycle is that short. (I’ve personally never met a metric that I wanted to visit daily, and remember, standups are supposed to be short and sweet; I believe you get better results by aggregating those daily statistics into a weekly or even monthly report, and reviewing them with the individual or the team on that same cadence.)

With all that said, take careful note of the large number of metrics possible: You could easily end up spinning up dozens, or even hundreds, of metrics to watch, and end up finding yourself drowning in data. Or, alternatively, you’ll find you latch on to one metric, and use it to the exclusion of all else. Both extremes are dangerous—the ideal is what some business types refer to as “the balanced scorecard,” in which you look to measure your organization against four basic questions:

• How do customers see us? (customer perspective)
• What must we excel at? (internal perspective)
• Can we continue to improve and create value? (innovation and learning perspective)
• How do we look to shareholders? (financial perspective)

These are a little high-level for a team leader, but the idea is solid: Look for four metrics that measure how your customers/client (the product team, perhaps) see you; how you feel you need to improve as a team (better time to delivery? better time to recovery during an outage?); how you can innovate and learn (new languages, new platforms, etc); and how your team contributes to the overall goals of the organization (OKRs, NPS scorers, and so on). This helps avoid that single-dimensional focus that leads to falling into the trap of Goodhart’s Law.

Above all, avoid what’s called the McNamara Fallacy (named after the US Secretary of Defense during the Vietnam War), wherein you judge your employee’s performance based solely on the quantitative observations (aka metrics) and ignore any other source. An employees’ impact on a team can often not be measured in any quantitative way; on one team I skip-managed (which is to say, they reported to a manager who reported to me), one developer in particular was not the most technically knowledgeable or the fastest to finish her stories, but she was in all respects the emotional heart of the team. When I had a problem grabbing the code and building it on my machine, I “slacked” a message to the team chat asking for help, and she was at my desk within ten minutes, walking me through the process. Others on the team reported that she was also the first to volunteer for anything that needed to be done, no matter how boring, and was always looking for ways to improve and get better. She didn’t realize it, but she was the exemplar of what everybody else on the team wanted to be like, and as such, was quite possibly the most valuable person on that team.

And none of that can be measured using any metric.