Measuring Individual Performance as a Manager

Right now, I’m job hunting. It’s not exactly the sort of thing you’d describe as “fun”, but as interviewers try to get to know me and how I work, they’ve thrown some interesting questions my way.

One of the ones most worth contemplating in more depth is how you measure the performance of an individual. How do you gauge whether someone is doing well or not?

Many years ago, this was done by counting the number of lines of code – a horrifyingly naive metric mercifully consigned to the bin (mostly). If micromanagement is your preferred approach, then it might be tempting to constantly review code (or even get your team to print it out – although please don’t). Given there’s rarely a right way to code, this won’t get the best out of your team.

Maybe you’d like to look at story points. After all, it’s how we measure the complexity of a task and how productive the team is as a whole. We can measure lead time and cycle time for the team as a whole, so can we measure the output of an individual engineer? In my experience, not reliably. It’s difficult enough to try to get a consistent velocity in a team, so breaking it down into a granular metric for an individual is asking for trouble. An engineer who spends a week on a tricky 4-pointer isn’t necessarily comparable to an engineer who smashes out four 1-pointer tasks in an afternoon.

Speaking of team metrics, it’s worth pointing out the fantastic DevEx framework published a few weeks ago. It outlines three areas – flow state, cognitive load, and feedback loops – that influence how well a dev team performs. I thoroughly recommend having a read through the paper – there are some great ideas in there. But I think it would do a disservice to the authors to try and apply the measurements to individuals. Everyone is different, and everyone works well in different environments.

A lot of my answers in interviews come with the prefix “it depends”, and this question is no different. It all depends on the individual and what they’re trying to do. Where are they in their career? What are they aiming to do and work on? Are they able to do their job effectively, or is something getting in their way?

Once all that’s established, there are three potential measures:

1. How do they measure up against the job description? When they joined the role, there will have been an outline of what the job entails. It’s often forgotten as a simple recruiting tool, but it can be an effective measure of someone’s performance.
2. How do they measure up against the career framework? Potentially the most useful tool in the list, a career framework allows both you and your report to track how they’re progressing. It gives a good idea of both how likely someone can progress to the next role, but also how well they’re doing in their current role.
3. How are they progressing against their own goals? Goals (SMART or otherwise) are hard. I’d much rather help an entire team of engineers set goals than attempt to set my own. Nevertheless, goals are entirely customised to the individual – a huge advantage over more generic career frameworks or job descriptions. They can reflect every conversation, skill set and career ambition that someone has. Setting and tracking goals is a pain (I specifically carve out a section in one-to-ones to keep on top of goals), but if they’re taken seriously can be incredibly powerful. We often talk about goals as managers, but really they need at least one of two drivers: a culture from the top where everyone talks about their goals with their managers or a manager who is willing to drive that change themselves. Too often, they are treated as bureaucratic detritus or left unattended until the next performance review.

All of these measures are qualitative rather than quantitative. I’ve encountered scoring systems imposed on top of certain attributes, but I’m not sold that they will ever adequately replace talking to someone and trying to get the best out of them through understanding, recognition and a shared ambition for their career.