Performance of a software engineer can most definitely be measured by some simple, objective metrics. The work has inputs and outputs and everything a programmer does leaves a nice trail that you can evaluate as closely as you care to allocate time for that

As a very rudimentary approximate suggestion for how to do it:

1. Number of work items completed (bugs, user stories, features). you could come up with some sort of scoring metric, where bugs are worth 1, user stories=2, and features=5 (since features take longer than typical bugs). Tally the score and compare with others.

2. Number of Slack/internal discussion posts. Participation is a good thing. Over-participation isn't. You could have just the number there, then 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-evaluations. Ask everyone to rank on a scale of 1 to 5 gold stars, Person's: a) friendliness when interacting with others. are they open, responsive, conversational about issues etc b) helpfulness during code reviews c) general programming skill

Sum that all up and get a score.

To be able to decide whom should be promoted, without necessarily sharing all the information, I think it is very important that you compare scores between peers. That allows you to have a relative sense of whom is your top performer.

Let's not fool each other here. We don't live in a communist society where everyone gets the same wage. The reality is the capitalist workforce is competitive, and you don't need to lull everyone into a false sense of comfort by refusing to compare performance between peers.

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.

Performance of a software engineer can most definitely be measured. The work has inputs and outputs and everything a programmer does leaves a nice trail that you can evaluate as closely as you care to allocate time for that

As a very rudimentary approximate suggestion for how to do it:

1. Number of work items completed (bugs, user stories, features). you could come up with some sort of scoring metric, where bugs are worth 1, user stories=2, and features=5 (since features take longer than typical bugs). Tally the score and compare with others.

2. Number of Slack/internal discussion posts. Participation is a good thing. Over-participation isn't. You could have just the number there, then 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-evaluations. Ask everyone to rank on a scale of 1 to 5 gold stars, Person's: a) friendliness when interacting with others. are they open, responsive, conversational about issues etc b) helpfulness during code reviews c) general programming skill

Sum that all up and get a score.

To be able to decide whom should be promoted, without necessarily sharing all the information, I think it is very important that you compare scores between peers. That allows you to have a relative sense of whom is your top performer.

Let's not fool each other here. We don't live in a communist society where everyone gets the same wage. The reality is the capitalist workforce is competitive, and you don't need to lull everyone into a false sense of comfort by refusing to compare performance between peers.

Performance of a software engineer can most definitely be measured by some simple, objective metrics. The work has inputs and outputs and everything a programmer does leaves a nice trail that you can evaluate as closely as you care to allocate time for that

As a very rudimentary approximate suggestion for how to do it:

1. Number of work items completed (bugs, user stories, features). you could come up with some sort of scoring metric, where bugs are worth 1, user stories=2, and features=5 (since features take longer than typical bugs). Tally the score and compare with others.

2. Number of Slack/internal discussion posts. Participation is a good thing. Over-participation isn't. You could have just the number there, then 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-evaluations. Ask everyone to rank on a scale of 1 to 5 gold stars, Person's: a) friendliness when interacting with others. are they open, responsive, conversational about issues etc b) helpfulness during code reviews c) general programming skill

Sum that all up and get a score.

To be able to decide whom should be promoted, without necessarily sharing all the information, I think it is very important that you compare scores between peers. That allows you to have a relative sense of whom is your top performer.

Let's not fool each other here. We don't live in a communist society where everyone gets the same wage. The reality is the capitalist workforce is competitive, and you don't need to lull everyone into a false sense of comfort by refusing to compare performance between peers.