5

We are a small software development company. We are currently working on having a proper performance appraisal system with incentive tied to performance however, no idea how to implement it effectively.

I would like to know like, how to effectively measure performance of software developer/ engineers / testers and how to implement the whole system that help business retain its talent with incentives and also motivate team!

How other companies are doing in this area?

8
  • 1
    This question appears to be off-topic because it is about productivity and measuring performance. That is a task specific to the management role and business processes, which makes this off topic here. Commented Jun 9, 2014 at 13:30
  • 9
    Obligatory link to Joel on Software: joelonsoftware.com/articles/fog0000000070.html Commented Jun 9, 2014 at 13:53
  • 1
    My answer to a similar question applies here I think: workplace.stackexchange.com/a/23990/105 In short: If the system can be abused, it will
    – Fredrik
    Commented Jun 10, 2014 at 10:18
  • 1
    @Chad sorry for being picky, but in your first comment you said "management role and business processes are off topic here". In your last comment you said "management questions are on topic [but] business policy questions are not". Also, as this place is called "the workplace" I'd expect questions on the workplace to be in topic :) Nevertheless, your link does say that this is not a place to discuss, but rather to present facts and that holds partially true for this question. Perhaps a rephrasing of the initial question might make it more apt for this site?
    – lorenzog
    Commented Jun 10, 2014 at 14:16
  • 1
    @lorenzog - It is not that management role questions are off topic it is that this question is about a task that is specific to the management role with specific business processes. Commented Jun 10, 2014 at 15:23

2 Answers 2

18

Short answer: you can't measure performance for engineering. No matter what metric you use, it won't fit all cases and this is more so the bigger your team becomes.

Long answer: it is a very gray area. First of all, money is not a good motivator; if you want to motivate people, let them master a skill. Secondly, what works in a small software company will most likely not work with a bigger team. People will find tricks to game the system while PM will rely on "metrics" for a false sense of security rather than personal judgment and familiarity with individuals.

You can, however, add a system to make sure performance reviews are fair: transparency. Let the engineers chose their own goals for the next period (usually six months); have the manager agree on them. Make sure to throw in the mix a bit of technical and a bit of human side, e.g. "I will learn a new technology/language/library and give at least one tech talk on the topic to my fellow engineers". At the end of the period, review the goals, let the engineer self-assess his performance and the manager double check how they did. Be aware that engineers tend to under-estimate themselves. Be fair. Record everything in written form.

Then, if the majority of the goals are met, you can talk about raises. But do not base raises solely on this, otherwise you risk lots of anger if somebody's performance fails because of other team members.

See also this SO question, or this Dilbert comic for the funny side of things. Rands has, as always, some good insight on the topic (see also this other post).

One word of advice: do not assume that an appraisal system is a way to save time. Properly done, a good appraisal system takes more time than not doing it.

UPDATE: see also this answer on the Project Management stackexchange site.

13
  • 1
    @Krunal better to forget the entire idea prp systems will be abused - normally they get captured by HR and used to drive headcount reductions and/or reduce the pay quanta - with the result of destroying morale and losing you your best people.
    – Pepone
    Commented Jun 9, 2014 at 10:33
  • 2
    @JeffO my point was that to improve performance, money is not important. It does not imply that money is not important at all. "If my grandma had wheels, she would be a bycicle" does not mean she is a bycicle.
    – lorenzog
    Commented Jun 10, 2014 at 20:01
  • 2
    @Pepone If you think your employees are lying to you then there is an issue with the trust level you have with your team. Its completely a different issue and before you thing something like this.. you need to overcome your belief and ensure the trusting environment within your business team.
    – Krunal
    Commented Jun 12, 2014 at 5:49
  • 3
    @JeffO Money is important up to a threshold (can you pay your bills? is it fair market value?). Once you have passed that threshold, it's no longer very important when compared against other motivators such as work/life balance, job appreciation, good team chemistry, etc.
    – Dan Lyons
    Commented Jun 12, 2014 at 17:08
  • 3
    Thanks everyone for your insights and comments.. we actually did it like you suggested. We worked on system where we discuss and note down the yearly goals of each team and then based on goal, define the strategy and metrics to monitor the performance of the team over time. We monitor it on monthly basis. Similarly there is a KPI for each individual in team which is very specific to the work assigned to him which helps us monitor how they are performing. Moreover, we included other personal goals like learning new technology, or writing tech papers, etc. based on which performance is measured.
    – Krunal
    Commented Jun 20, 2014 at 5:56
-12

Although you have to be careful to measure the performance of your engineers holistically, the performance of your software engineers can be partly estimated by some simple, objective metrics.

As a very rudimentary approximate suggestion:

  1. Bug Score. Raw number of work items completed (bugs, user stories, features).

    • This attempts to estimate productivity (in the same way GDP does). Not completely reliable, but if the number is 0, something could be wrong there, and that says something needs to change.
    • You could also do something like multiply the score of User Stories by 2 (since User Stories are typically larger than Bugs)
  2. Group Discussion Participation Score. Start with raw count of Slack/internal board discussion posts. This attempts to estimate participation/presence.

    • Not perfect, as it can't check DMs
    • While participation is a good thing, over-participation isn't. Have an estimate of what a reasonable number of posts to make in the 3 months/6 months (evaluation period).
      • Barometer: Calculate ActualPostCount/AveragePostCount. Want score to be close to 1.0 for most people to help normalize.
    • Post Quality: Be sure to do a bit of a spelunk into the post content to see if it's mostly work related, or simply water cooler banter
  3. Peer-evaluation of technical expertise. Ask everyone to rank on a scale of 1 to 5, each person's:

    • General programming skill (do they think this person is a good programmer or a bad programmer).
    • Demonstration of internal knowledge during code reviews (does this person display a high amount of technical knowledge of your company's products)

You should decide whom to generally promote based on these evaluations. You should not be too clear about translating the metrics to bonuses, because that will encourage gaming of whatever system you come up with.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .