Sign in Subscribe

Don't be an asshole with a spreadsheet

By Rick Faaberg —
Don't be an asshole with a spreadsheet
Photo of CSV of doom by Mika Baumeister / Unsplash

I recently saw some chatter on The Website Formerly Known As Twitter around this post from Cory House with some advice for engineering managers:

He got a fair amount of grief for it, with the chief objections falling into these buckets:

1) Engineers on your team would start gaming the stats.

2) This metric could very easily be misleading.

3) This is just management-by-spreadsheet, you should talk to your engineers instead.

These can be a problem with any metric, but it's not worth throwing out all metrics. Metrics can help uncover problems below the surface and, as Cory mentions, help inform a conversation. Metrics can help you be a better manager given the following:

1) You assume that all metrics are fallible. If your metric says that Pam on your team doesn't leave many comments on PRs, you need to be open to perfectly legitimate reasons that point to a fault in your metric, such as Pam does a lot of pairing so code issues are resolved there instead of on the PR. If you believe the metrics more than you believe your people, you're an asshole.

2) You aren't using metrics on their own to drive major decisions. If you are solely staring at spreadsheets and sorting people by various metrics to make major decisions that affect their lives like promotions or firings, you're an asshole.

3) You actually talk to your people. Metrics can point to potential issues that could be hidden from view, but they shouldn't substitute for actually holding regular 1:1s and talking to your team. You should come to these conversations with humility, with more a tone of "Hey it seems like our test coverage numbers have been dipping, does that seem accurate to you?" rather than "Our coverage number is down by 2%, please explain."

Metrics are a signal, but they should be one of many signals you use as a manager, and you should be fully aware of their potential to be inaccurate and not encompass the full picture. At the same time they're not useless and can give you a hint of where some folks on the team might be contributing more than they're getting full credit for, and where there might be an opportunity for other folks to step up.

If metrics are in the spotlight, your team will naturally optimize for them, since at that point they'll reasonably have more trust in the metrics than in you. The metrics have become their manager at that point, which is a terrible place to be. You also want to make sure you're looking at how the team is functioning as a whole, filling in each other's gaps and working cohesively as a unit (or not, as the case may be).

Remember: metrics are one tool in your toolbox, and relying on them exclusively makes you an asshole with a spreadsheet.

Related reading:

  • The Worst Programmer I Know from Dan North - I love the point about tying metrics to business outcomes. If they're ambiguous or even counter to meeting your business goals, there's a problem.
  • Measuring Developer Productivity from at Pragmatic Engineer - a detailed response to the measurement framework pushed by McKinsey, a huge consulting firm.