Agile Performance Reviews

Published in General on 24-Jan-2016

It's performance review time again!

A time of year that brings dread, almost universally, to both employees and managers.

Almost every company I've ever been at has had some sort of performance review cycle and I don't recall meeting anyone that enjoyed it. It is undoubtedly useful for employers to have records of the things employees have accomplished, goals that have been set and achieved, and progress towards professional development - but are yearly performance reviews really the best way to get this information?

When performance review time comes up, you invariable see several people sitting, staring blankly at their monitors - hands posed to type, if only inspiration would strike... "What did I accomplish last year? Seems like a long time ago". You can almost see the productivity being sucked away as people rack their brains to come up with "specific situations that illustrate their demonstration of core competencies and key values" and justify their self-evaluation scores.

For most people, a performance review process that involves thinking back on the events of the past year requires too much time and too much long term memory. Reviewing the performance of employees, at least in my opinion, shouldn't be a yearly task. The best managers I've worked with constantly provide feedback and advice. That constant feedback has the advantage of being timely, in that it can be contemporaneous with the actual actions that related to the feedback. A list of things you can do to improve is only so useful when the events that inspired it took place a year earlier.

I think it's time that the performance review process takes a page out of the Agile software development playbook and eliminates big-bang performance review cycles altogether. We should constantly be trying to get and give feedback, in small incremental chunks. Managers usually have 1-on-1 meetings with their direct reports. If those 1-on-1 meetings are weekly, or bi-weekly, then there is no reason not to devote a fixed amount of time each meeting to reviewing performance. Managers can ask questions like 'What did you achieve this past week that is noteworthy?' and 'What did you do to move yourself closer to accomplishing your personal development goals?' and together the employee and the manager can come up with answers. It's not that there needs to be an answer to these questions in every meeting, but whenever something noteworthy does come up, it can be discussed and then the manager and the employee can add it to a performance review log using words they both agree with.

The net result: That performance log can be viewed every week, every month, every year - by the employee, by the manager, by the manager's manager. There are no surprises, no thinking back and trying to remember what happened months ago and no hours of productivity wasted every year. Everyone that needs it would have constant visibility into the process. If the organization wants to group those reports together once a year info a 'yearly performance evaluation' it's as trivial as copying and pasting.

Additionally, with constant input into the review process, it's easier for both the employee and the manager to change directions when it becomes necessary. When performance reviews set goals for the next year for each employee, how often do most employees look back on those goals and measure their progress? How often do employees even remember what those goals are, one, two or six months later. A continuous performance review process allows for an employee's goals to be constantly reinforced and when it becomes clear that a goal was inappropriate, or a different goal is actually more important, the goals can be updated and the employee refocused. No more waiting an entire year to defend why you didn't accomplish your goals when the goal posts got changed mid way through the year.

Software Developers figured out a long time ago that doing work in small, iterative chunks is better than big-bang waterfall approaches: Plan out a small chunk of work, do the work, and then think about how the work could have been done better so that the next chunk of work you do benefits from that reflection and improvement - continuously strive for improvement, and make small course corrections where necessary. I think it's time that other business processes, specifically performance reviews, start realizing the value of that model.

About the Author

Daniel Morton is a Software Developer with Shopify Plus in Waterloo, Ontario and the co-owner of Switch Case Technologies, a software development and consulting company. Daniel specializes in Enterprise Java Development and has worked and consulted in a variety of fields including WAN Optimization, Healthcare, Telematics, Media Publishing, and the Payment Card Industry.