In a discussion the other day about measuring the effectiveness of developers I looked for a document I’d written a while back for exactly that purpose. But when I opened it up I found that it wasn’t the document I thought it was. I expected something that would help the reader, as a manager, assess who was doing well and who wasn’t. What I found was a document that explained to developers what they needed to do to progress up the seniority ladder. It could also be used by a manager to evaluate developers’ progress, but that wasn’t its primary purpose.

There’s a subtle difference between the two kinds of document, as well as a lot of overlap. A “measuring” or “evaluating” document would have been biased to a manager, possibly with a ranking or scoring mechanism. A “guidance” document, such as this, explained the different developer levels in place at that time, and set out expectations in various areas as to expected behaviours of someone of that level. The tone of each such document would be different, too.

This took me back to the original discussion point, “How do I measure the effectiveness of my developers?”, and made me question it. Do we want to measure the effectiveness of our developers, or do we want to improve it? Or do we want to improve the effectiveness of our development team? There are reasons one might want to do each, but the tools we create and use for each are not going to be exactly the same.

Photo by James Jordan