Today I’m going to delve into why anybody and everybody who claims to have a way to measure the performance of an IT professional is basically lying. To be fair, it’s probably not their fault.

Why Employers Need to Measure Performance Link to heading

So let me start off by saying this: I understand why employers want to measure the performance of their employees. I also like having my performance measured… but only in situations where the system is capable of accurately measuring performance. The purpose of this post isn’t to rail against employers for attempting to measure the performance of their IT staff but rather to skewer them for adopting half-ass methodologies that do not even come close to accomplishing that.

The long and short of why employers need to measure performance is that it is in their best interest to be able to identify their high performers, their low performers and determine who occupies the in-between. I firmly believe that employees should also take a strong and proactive interest in understanding how their performance will be measured because ultimately that is the standard against which they will be judged. That standard determines what raises you’ll get, promotion opportunities you’ll receive and ultimately whether or not you survive your employer’s next culling.

How Should IT Performance Be Measured? Link to heading

I don’t have the slightest fucking clue and neither do you. The only good news here is that the employers don’t know either so we are all in good company. Oh wait… I guess that’s actually bad news.

The primary reason is that IT people basically live within a world composed of abstract systems. We enforce, create, modify and in some cases bend the rules that govern the behavior within these systems. However the issue here is that because we spend our days tinkering with the more abstract facets of the organization we work for, we tend to acquire a very good understanding of these abstractions and what the real world limits are when it comes to bending and / or ignoring the rules setup around these abstractions.

This is what we do for a living. So naturally when we are presented with an abstract system that defines how our performance will be measured, our IT brains go to work and figure out what the most efficient way to interact with that system. Of course that’s just a fancy way of saying that we’ll figure out how to game the system. We don’t do this because we are bad people. We do this because being good at our job requires us to do it.

Let’s talk in terms of a Software Engineer: How should their performance be measured? Let’s attack a few of the more obvious options:

  1. Commit Count

    Yeah this doesn’t work primarily because the number of commits it takes for an engineer to add a feature or fix a bug has nothing to do with the complexity of the issue or the value of the work. In fact the number of actual commits it takes to do anything says more about the style of the engineer than anything else. In reality, an engineer can easily create more or less commits by simply changing their behavior around commits while still accomplishing the exact same thing.

  2. Lines of Code

    Yet another metric that’s easy to game because as with the number of commits, the lines of code is basically more about the style of the engineer than anything else. Work can generally be refactored to occupy more or less lines of code and often is.

  3. Tickets Closed

    This assumes that all tickets are created equally. They aren’t.

  4. Sum of Story Points associated with closed tickets

    Story points are meaningless so metrics built around them are by definition also meaningless.

  5. Bugs Created

    So this one is a bit different as much like in golf, lower numbers make for a better score. Nevertheless the risk in a system like this is that you end up creating a disincentive around tackling complex features and changes as those would heighten the risk of creating bugs.

    In addition, it also follows that the less code you write, the less bugs you create. It doesn’t take a rocket scientist to see how that ends.

There are other possibilities we could tackle, but those are the most obvious ones that tend to come up at the start of any performance related discussion in Software Engineering. Measuring the performance of a Software Engineer is very difficult. When I work with individual Engineers I tend to know which ones are reliable and competent and which ones will likely create more problems than they’ll solve.

But that’s the thing. My gut feeling is good enough for me as a professional to know which engineers are good and which ones are not, but you can’t build a measurement system on “gut” feelings. That doesn’t scale and it doesn’t result in any kind of decent accountability on the part of the people measuring the performance and developing performance reviews based on those measurements.

So this leads us to the most touchy part of this discussion:

How is IT Performance Currently Measured? Link to heading

In a word: Poorly.

I have never worked at a place that has managed to get this right, which is a big part of the reason that I don’t have many good ideas around how it should be done. Typically as a mid to high level performer (once upon a time a high level performer, but probably more mid level nowadays if I am being completely honest) I score well on the technical aspects of performance reviews. Over time it has been my personal experience that reviewers tend to even that out by dishing out negative feedback relating to the non-technical aspects.

Most of this negative feedback is around my soft skills, or lack thereof. That’s something that I have been trying to work on for a very long time, but progress has been slow. That’s not to say that some of this negative feedback isn’t legitimate, but that once you inject these kinds of things into a performance review, it basically demands the inclusion of gut feelings and allows reviewers to place them on a pedestal of sorts. For as hard as it is to measure IT from a technical aspect, its infinitely harder to measure soft skills.

At my current employer the situation is even worse. They were basically looking for a reason to keep from giving raises so they concocted reasons to make that happen. While I did get a pittance of a raise, it didn’t even match inflation over the course of 2023. In addition they also “unofficially” culled a bonus program in the beginning ot 2024 which basically augmented my income by the amount of the raise they gave me.

So once you account for inflation, I took a hit whereas from their perspective they can backhandedly claim they gave me a rise. Given the level of frustration I experience grappling with the raw incompetence exhibited by my current employer on a daily basis, that basically just made a bad situation worse.

It’s now at the point where I’m willing to take a pay cut just to get out of here. Of course even that approach hasn’t yielded great results for me.

So yeah this topic matters. Doubly so to me at this particular point of my career.

So What Can We Do About This? Link to heading

I have no idea. Since I doubt I’ll be working as a Software Engineer for much longer, unless I happen to get lucky and stumble on a position with a reputable place where I will be able to bookend my multi-decade career and get my post-IT career affairs in order, this isn’t a problem that I really need to expend my dwindling mental energy to focus on solving. In addition my lack of soft skills basically guarantees that I won’t be offered or accepting any management related positions anytime soon.

But since most of the people reading this are presumably in IT, my advice is simple: Keep thinking about the problem. Keep grinding away at it. Somebody will someday figure this out. Meanwhile MBAs will make the situation worse by asking ChatGPT for advice and blindly following whatever semi-randomized idiocy it sputters out as part of its response.

The irony of this situation is that it while it would be in the absolute best interests of the employers to figure this out, it is also in our best interests to help them figure it out.

Conclusion Link to heading

I am glad that concerns of this nature won’t be my problem for much longer. But with that being said, IT is hardly the only industry that suffers from problems like these and I can’t imagine other professionals in other areas aren’t also faced with similar issues.

Perhaps the entire idea of performance measurement needs to be revisited as a whole. I believe an ex-coworker of mine once referred to a system of working that starts with changes like this using the term “Developer Anarchy”. I didn’t agree with the idea then and I don’t now… but I won’t lie.

No more performance reviews sounds pretty tempting just so long as our compensation is adjusted on an annual basis. But I suppose the whole capital versus labor constraint of our current economic system precludes adopting a solution of that sort, doesn’t it?

Damn shame, that.