Performance Appraisals in an Agile Organization

  1. Posted on July 7, 2015 7:54:PM by John Clifford to Retrospectives

Performance appraisals are a part of life in nearly every organization, and yet no one likes them1. Bad performance appraisal processes can seriously harm your organization's ability to recruit and maintain talent. Individuals being reviewed worry about whether their contributions will be recognized, and the impact a questionable appraisal may have on their career. If they believe they are continually treated unfairly then they will move on, and the best employees will jump first. Managers dislike the appraisal process because it is tedious and cumbersome, causes tension and loss of productivity within their teams, and often results in residual effects from the ill will resulting from employees' beliefs that their contributions weren't fairly recognized. Organizational leaders find that appraisals often don't result in meaningful information that will help them make effective decisions around compensation and staffing. Yet, everyone plays the appraisal game, because everyone hopes the positives outweigh the negatives. Of course, hope is not an effective management strategy for successful organization.

I'm okay philosophically with the idea of being able to discern different levels of contribution to the organization's goals, and rewarding people commensurately with their contribution. The problem I have is, most performance appraisal systems are woefully deficient at identifying and quantifying levels of contribution because they tend to emphasize easily-measurable individual metrics, resulting in gamesmanship in order to maximize one's appraisal score regardless of the impact on contribution... a local optimization that seriously degrades global optimization (organizational performance). They don't help the individual, the manager, or the organization.

One predominant management belief that I don't like is the idea that everyone in a particular functional role is fungible... that Engineer 'A' is equivalent in terms of knowledge, proficiency, and productivity to Engineer 'B' or any other engineer. It's this thinking that persuades management to look for the cheapest engineering salary rates, often offshore, emphasizing cost over value. Even though we want to encourage 'general specialization,' or the idea that people need to be cross-functional and own developing the capability to work in different roles and across different areas of our products or projects, we also need to acknowledge that everyone is different and brings a unique mix of ability and capability to the table. Some people are inherently better than others at specific activities, and this may vary as activities vary. The administrative wiz who keeps up with all of the details may not be good at planning or envisioning; the big picture thinker who can see everything clearly and immediately cut to the core of any problem with a simple, elegant solution may also be the one who procrastinates the most on administrative work. Organizations need both types, and therefore who can say which is better? The secret to effective management is not to put people in positions that are in conflict with their strengths and skills, but instead to employ individuals in a manner that best utilizes their key strengths while minimizing the impact of any deficiencies, ideally through cross-functional, self-managed teams that are given clear objectives and then mentored, coached, and led appropriately as they collaborate to success.

How do we assess individual performance in organizations with collaborative, cross-functional, self-managed teams? First, let's consider why we want to assess individual performance. What question are we trying to answer? In my experience organizations want the highest-performing workforce they can get for least amount of money they can spend. Therefore, we are trying to determine if our spend on resourcing is allocated appropriately, in order to retain and motivate the high performers while identifying and resolving issues with underperformers... either by addressing capability gaps through training and mentoring, or addressing ability gaps through reassignment (to a more suitable role where the employee can be successful at providing value) or elimination. Every team I've ever worked on and worked with knew who the performers were, and who wasn't contributing... and everyone on the team was generally in agreement on both counts. A good performance appraisal system leverages the knowledge of the people who work with, and interact with, the employee being appraised.

Let's talk about ability and capability for a moment. I define ability as the combination of innate talent, aptitude, and intelligence an employee has. Ability is a hire-time attribute; we should only hire employees with the ability to be successful contributors to our organization in the intended functional roles. Capability, on the other hand, is the combination of knowledge, skill, and experience that an employee can bring to bear on their work. While we can improve an employee's capability over time with training, coaching, and mentoring, an employee's ability is generally fixed... it is what it is. In short, we should hire employees with great ability and then endeavor to continually increase their capability so they can grow in their careers while increasingly contributing to the organization's success over time. A good performance appraisal process should identify whether performance issues are related to ability or capability, to guide us in terms of effective corrective actions.

Many people in the Agile community are against performance appraisals, for valid and invalid reasons. Interestingly enough, W. Edwards Deming, the philosophical originator of the Agile software movement, was also opposed to performance reviews2 because he believed that performance was mostly a factor of the organization rather than the employees and therefore we should focus on improving systems, processes, and methods instead of fixing people. It's not enough to say performance appraisals stink and we ought to get rid of them. If we want to change things for the better, we need to remember that something always beats nothing. We need to offer an alternative that provides the benefit the organization expects from performance appraisals without the problems,that as Dr. Deming emphasized focused on how individuals interacted with others and with the organization’s systems. Perhaps we need to look at what matters... not only what individuals accomplish and how well, but also how well they collaborate, whether they help others or focus solely on their own work, and whether they contribute to the team or destabilize it. The way to get started is to establish a series of questions that will help ascertain performance around teamwork, collaboration, and contribution as well as individual performance, and then get the team involved in reviews along with functional managers. If we understand and embrace the concept of continual improvement through the use of feedback and the application of the Deming Cycle, we can evolve our way to a truly better approach to performance appraisals, one that works for everyone... the individual employee, the manager, and the organization.

__________

1Pozin, Ilya, “Why Everyone Hates Performance Reviews And How To Fix Them,” Forbes.com, December 10, 2014, http://www.forbes.com/sites/ilyapozin/2014/12/10/why-everyone-hates-performance-reviews-and-how-to-fix-them/

2Hunter, John, “Dr. Deming Called for the Elimination of The Annual Performance Review,” The W. Edwards Deming Institute Blog, October 29, 2012, http://blog.deming.org/2012/10/dr-deming-called-for-the-elimination-of-the-annual-performance-appraisal/ 

 

Post a Comment:

 
 

John Clifford

John Clifford is a Senior Fellow and Agile Practices Lead at Construx Software. John got his first software development job at a startup, while still in college, in the early 1980s. He started and ran a successful software company when he was 23. His career includes almost six years at Microsoft, where he was one of the original developers on the Microsoft Project for Windows and Mac team.

With more than three decades of IT experience, John has developed software across the spectrum of computing environments, ranging from desktop and mobile device applications to low-level frameworks, device drivers, and asynchronous communications protocols. Prior to joining Construx, John’s career included stints as a software development engineer, product feature team manager, group QA manager, group project manager, and development director.

At Construx, John focuses on software development, project management, product management, and team and organizational management practices, with an emphasis on Lean and Agile methodologies. As a manager, and as an external consultant, John has led numerous successful organizational transformations to Scrum and Lean/Kanban. He holds Certified Scrum Master, Certified Scrum Product Owner, and Certified Scrum Practitioner certifications from the Scrum Alliance. John was invited to become one of the charter Kanban Coaching Professionals from the Lean Kanban University, the professional association and standards group for Kanban Method training and coaching. As an adjunct instructor, John also teaches a course on applying Lean and Agile principles and practices for the University of Washington’s Professional and Continuing Education program.

Contact John