Let's talk about performance reviews . Consistently, performance reviews have been uncomfortable for me. I feel awkward about the standard questions used in reviews and in self-assessments and don't want to go through the process because there will always be some uncomfortable moments in there which would be easier to not revisit. Yet they remain a common feature of almost all organizations of any size and they keep happening so if performance is going to be reviewed, I would like to make it meaningful. What should "performance" mean then, and what does it suggest about my career advancement?
The Problem with Performance
As a coder, my performance could take the form of having done some body of work. Let's say I built some features and I fixed some bugs. This is the 'what' of the work. Should you gauge my performance by the particular work done? Then we must ask more questions: How did the work I completed get selected? Did I choose politically sensitive work to garner recognition and did I appear to succeed in the work of did the value of the work under perform expectations? All of this can be corrupted by independant variables and any measure can be gamed which means instead of measuring my performance you are effectively measuring the weather.
For piece-work jobs this may be "good enough" but for knowledge workers the organization's primary metrics might not be what the best criteria to gague individual performance. For knowledge workers to keep your organization growing and to accelerate that growth to keep ahead of competitors you need their productivity to grow over time. The difficult fact is that given the increasing cost of maintaining software over time as feature bloat, technical debt, and code rot set in often causes a slowing of productivity . This makes it even more dangerous for your knowledge workers to be just treading water. Learning is obligatory.
Another measure of the value of my work in an organization is in 'how' I did the work. I'd like to suggest that how I do the work, specifically what I learned from doing the work, is a better indicator of performance and value to the organization. This could be a basis for performance review and considering recognition for achievements (and if your org does titles maybe this can be valuable in marking advancement in titles too ).
Learning as Performance
One of the rewards of working on software is that there are a lot of opportunities to solve new problems all the time --variety! A former coworker once observed (I paraphrase) that our job is to be struggling, to be challenged. As soon as we overcome one challenge, there is another one waiting for us and it's time to move on to that.
We are going to spend the great majority of our time struggling through that next thing. We can mark our professional development in part by our raw productivity, but the greater part of our professional growth comes from the breakthroughs: the monster bugs fixed or the finesse of implementing a feature.
If my daily routine is going to be one continuous learning process, and that learning is the function by which I increase my technical capabilities and productivity, then this is a fair measure of my increasing value as an employee to the organization. If my organization values individual capability and productivity increasing, let's think about how we can reflect that in setting career paths, marking individual and team achievements, and conducting performance reviews.
What could be gained by looking at reviews through the lense of learnings?
By including, or centering on, learned lessons in performance reviews we can discuss all of our work in non-threatening terms; finding insights and lessons and discoveries rather than letting the hard times be seen as oversights, failures, or mistakes.
In the next part I will explore ways to recognize and keep track of the individual learnings so they are available at performance review time.