XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Employee Performance and Salary Appraisal

Thursday, July 11th, 2013

I’ve managed (small and large) teams for some well known companies (including a couple of my own companies.) And through this experience, I’ve learned that mixing “Performance and Appraisals” is like mixing “Drinking and Driving.” In layman’s terms, it’s a stupid idea.

Drink n Drive

Sounds strange? May I suggest the following video from Daniel Pink, which takes a peak into what motivates individuals and what actually leads to poor performance.

I’m sure you’ve heard these stories before and deep down even agree with it. Yet, everyday we go out of our way to measure the performance of individuals and teams in our organization to decide their salary appraisal at the end of the year.

I’ve yet to meet a single individual how understands how to effectively measure performance. For a creative, problem solving field like software product development, how do you even measure such a thing? Remember output (code, features, bugs, products, etc.) is a lame measure of performance. Outcome and Impact is what matters. But that is hard to measure, so we simply measure what we can, output. And in most cases, output that someone else decided on your behalf.

Unfortunately this a very broadly used management philosophy that kills employee’s motivation everyday. To make matters worse, the employee feedback process is also tightly coupled with the appraisal process.

Why just drink and drive, let’s drink, smoke and fly!

At the beginning of my career, many times my manager would give me some feedback during the appraisal process and this would be the first time I was hearing about it. Indeed an excellent way to motivate and improve employees!

And I still remember the horrors of “Goal/Target setting” at the beginning of the year. My salary appraisal would be based on how well I met my targets. And guess what, I flunked every single time. I’m the only unfortunate person who does not possess a third-eye to see the future and decide what targets would be important. I kept blaming myself until I read Goals Gone Wild.

So what’s the alternative?

Its simple: Don’t mix performance, feedback and salary appraisals. This is what I’ve successfully implemented in a few companies.

So how does it work?

If someone is not performing, they are simply not meant for the job at hand. We can help them by mentoring and guiding them. We can let them select a different project. But after the best of our efforts, if they can’t cut it, they should leave. Its best for both; the organization and the individual. I really mean the last sentence.

At some companies, I was responsible for firing the largest number of employees in the history of the company. By now you must have made up your mind that I’m this evil guy who goes around firing people. Here is the best part, most of the guys I fired, still keep in touch with me and look up to me for advice. I’m really happy seeing them grow in their new organizations. In our organization, they were stagnating and probably feeling an inferiority-complex by high performances around them. So it was best for them to leave and find a place where they can really shine.

In fact, on many highly collaborative teams (like Agile teams) poor performances can’t find a place to hide. They very quickly realize they can’t survive in such an environment. Even before anyone does anything, they are gone.

So once we’ve got rid of the employees who don’t fit into the team/organization from a performance point of view. We are left with a bunch of high performers. Remember there will always be a range in terms of performance. But the range should be too small to be worried about it.

Given that we have a team of high performers, we set up a 360 degree feedback process in the teams, which ensures that every individual is constantly getting feedback to improve. Nothing discussed in a feedback meeting with your reporting manager should be a surprise. It should be something that was discussed on the shop-floor with folks working closing with you on the floor. I call this the “Rule of least Surprise“.

Lastly we need to handle salary appraisals. To me there are 2 parts to salary appraisals:

  1. Market Correction – inflation, job market, demand, etc. decides this portion.
  2. Profit your product/service is making – Out of the profit, a pre-determined percentage is fixed, which would be shared with the employees. Each team decides how they want to split this percentage amongst themselves. Some teams I’ve worked with, rate each other and then based on the rating the percentages for each person is decided. Some teams just want to equally distribute the profit. Note: The distribution is based on a percentage of their current salary. Which means not everyone gets the same net amount. Employees with higher current salary will get larger amount.

One thing I learned early in my career, when it comes to vitamin M, no matter what you do, you can never make everyone (sometimes none) happy. So instead of you deciding the numbers, fix the high-level numbers based on a transparent process and let the employees take care of how they are going to split the amount.

Last, but the most important learning for me has been around tying salaries with product/service’s profit. This goes a long way in empowering the team to take total ownership and responsibility of what they are working on.

Key Attributes of a Metrics

Tuesday, June 9th, 2009

A good metrics:

  • Guides/Drives me. When I look at it, I know what to do (how to react to the data highlighted by the metrics)
  • Positively influences (motivates) me to take steps towards improvement
  • Has no ambiguity regarding how the data can be interpreted
  • is Visual: Once understood, it should take less than 3 seconds to get the essence of the metrics
  • Tracks real data; not something else which is easy to measure
  • Is Automated: Eliminates waste and reduces the feedback latency
For example, xUnit report is a good metric. When I look at the results, I know what to do. If I have a failing test I know that needs to be fixed. It drives me positively to fix the test. If all tests are working, then it motivates me to add more tests. There are no 2 different ways to interpret the data. A failing test means program did not meet the expectations and a passing test means everything is working as expected. Also we are tracking real data generated automatically instead of guesswork. 
In my experience focusing on 3 metrics at a time, is very effective. Once we start tracking more than 3 metrics, we loose focus and clarity. 
How do you know which 3 metric to watch?
Usually, I use ToC to figure out what is the biggest bottleneck in my system. Based on the bottleneck, I define 2-3 metrics that we want to measure as we try to address the bottleneck. Hopefully soon, something else will be the bottleneck and we’ll start measuring things related to that.
This is a main reason why I think we cannot have a set of metrics across the organization. Every team has different bottlenecks and they are at a different stage of evolution. Metrics should be dynamic and they should keep evolving. 

Agile Coaching Value System

Tuesday, May 26th, 2009

What do we, as agile Coaches, value? What is our value system?

I value:

  • Respect and Trust
  • Transparency and Open communication
    • This works both ways. As a coach you want to show them that its OK not to know something. You certainly don’t know everything. But you are willing to learn.
  • Safe-fail experiments
  • Being hands-on and in the groove 
    • Second-hand information and knowledge can only take you so far
  • Down-to-earth, humble attitude
    • Being one amongst them.
  • Joy of improving things one baby-step at a time
  • Motivation and self driven
    • Lead by Example
  • Continuous learning and putting ourselves out of our comfort zone
    • I care, I’m here to help make things better and learn in the process. I’m not here only for the money.
  • And so on…
    Licensed under
Creative Commons License