Everyone who has ever worked in the corporate world knows what a chore the annual performance review is, both for managers and for employees. It starts with defining the goals at the beginning of the year which for the most part (barring a mid-year course correction) are sacrosanct almost as if they were written in stone. At the end of the year, managers have to figure out a way to keep track of all the hits and misses that an employee has had over the course of the last year. They have to identify goals that have been achieved and those that haven’t as well as demonstrations of company values and behaviour by their employees. They need to also identify the strengths and areas for improvement of the employees and come up with suitable guidance that can be translated into action plans in the coming year.
Employees too need to keep track of all the work that they have done over the past year. The year-end exercise almost becomes like a battle of wills between the two protagonists with managers trying to justify the performance rating that they have given to the employee and the employee pushing back against, in their opinion, being shortchanged by the manager. Since year-end conversations also consist of feedback from the manager to the employee as well as other feedback that an employee typically solicits from her colleagues, the process can tend to move rapidly from the convivial to the unfortunately far too frequent, confrontational.
The crux of the problem, as I look at it, is the infrequent conversations on performance that the typical process entails. If managers and employees talk to each other about performance-related issues more frequently and all of it gets documented, then year-end conversations can quickly become redundant and may even be done away with. In fact several companies like GE, Adobe, Google and Netflix to name a few have done away with annual reviews. The analogy that best captures this change is the move from traditional “waterfall” models of software development to the more modern “agile” methodologies. In the traditional model, designs and specifications for a software product are laid out at the beginning in great detail and then are followed to the later in coming up with the product. Any changes in product features or design have to go through a laborious process of approvals.
Agile methodologies, on the other hand, are based on the concept of “sprints” wherein, small pieces of work/feature sets are worked on by teams for brief periods of two-three weeks each. This enables changes to be incorporated into software features at a much faster pace as programmers are able to analyze and set right design flaws on a near real-time basis. Borrowing from this, continuous performance appraisals with more frequent say bi- or tri-weekly check-ins along with continuous 360-degree feedback, can go a long way in course corrections being made so that the overall performance of the employee increases.
So can we expect more companies to join the continuous performance appraisal bandwagon?