If you’re in software, you’ve heard of iterative development. Simplified, its intent is to rapidly create a working piece of software and then continue on small cycles of improvement on that software, until the stakeholders want it released.
This isn’t a post about software development, though. Instead, I’m sharing how iterative development has changed my approach to performance reviews.
One of the goals of the iterative model is that at any time, the Business can decide it’s time to release the software, and you have something usable ready for them. In other words, you approach every long task by breaking it into smaller tasks, each of which has as its output a piece of software with business value. You do not take on a feature that takes six months to write; you break it into features which take (say) one month each to write, and do them in priority order. In doing so, you might actually have to break it into eight (or ten!) features, and not six, but those extra months of “lost time” are considered a good investment by the Business, because of the increased flexibility you give them in releasing the product at any time.
So when faced with a pile of performance reviews to write, I tried to approach it the same way. My first goal was to reach a point where I could, if my management required me to, “release” the reviews (minimum business value). Then, I took on activities which would increase the value of those reviews to everyone involved.
Before I could do this, I needed to identify the stakeholders in the process — the customers. The most obvious customer is the employee being reviewed. The next in line is probably my own management chain (who in turn represent the corporation, eventually). Finally, I am my own customer here. Done.
Next up was defining the outcome of my initial iteration. I decided on the performance ratings (the “grade” at the end). While this may seem backwards, many managers will tell you this is how they work in reality (if not in theory). Why start here? It’s the bare minimum to achieve the business goal of the performance review. The minimum business value my customers can get from my deliverable is a performance rating. If I don’t have that, I don’t really have a review.
So, I studied the requirements, refreshed my memory, aligned my measurements with those of my peers, and entered performance ratings for my entire team.
Iteration complete! It feels good to know I’ve got a piece of deliverable value ready to fall back on. But clearly I have no intention of calling this a review. I planned out my next few iterations. Here’s the rough plan I settled on:
- Define the major accomplishments for each person
- Identify the core strengths for each person
- Identify the development opportunities for each person
- Compare my version of their accomplishments to theirs, as identified on their self-appraisals, and adjust
- Fill in details on their accomplishments
- Fill in details on their strengths
- Fill in details on development opportunities
- Fill in other textual fields in review
- Compare each review with self-appraisal, look for major gaps and issues, and adjust
- Refactor each review as needed
At each point, I am performing the task for all my team members. The result is, I hope, a set of reviews which have the same level of detail and attention given them. It will avoid the problem where one person’s review gets a week’s worth of time, and another person gets an afternoon’s, because I ran out of time. If I run out of time, everyone’s review is short-changed (but they still have something valuable).
It’s still in progress, but I think I like this approach. It’s keeping the entire process fresh for me as I approach each team member, and keeps me from getting overwhelmed with any one person’s review.
(You might notice two points in the process where I review the self-appraisal. I am fairly strict about this; I review it once to make sure I didn’t forget something critical they worked on, and a second time to see how my appraisal and theirs differs. I will usually make changes after that second review, but I do not conduct it until I have a “done” review written. It’s harder, but I think the review is better, this way….)
As a techie-manager, how do you handle “releasing” the product of a performance review?
