Every employed person, regardless of their post, grade, profession, or experience, needs regular feedback on their work performance, so they can continue to improve, grow and evolve as a professional. In this blog, I will narrow down our discussion to software engineering – my expertise – and share some thoughts on how a performance review should be evolved to get the full picture of an employee’s work. 

At VentureDive, we regularly engage as outsourcing partners with our clients. It’s our goal to make sure we fully understand their pain points to deliver impactful solutions to their business needs. To ensure the delivery of high-quality software products and solutions, I feel it’s essential to be empathetic and human about how we measure our own talent’s performance.

Contextualizing a performance review

The great debate about subjective versus objective opinion that revolves around the mathematical mindset of “measuring” everything versus the artistic approach of “feeling” the unmeasurable things has left us with a very difficult yet interesting question of what should be a good performance evaluation system.

I believe this question is too broad and deep to be covered entirely in one article. I would rather limit my words to one core aspect, i.e. how often the “contexts” are neglected or even missed altogether in performance evaluations.

So what do I mean by a “context” here? Simply put, a “context” is the specific environment or the circumstances in which a problem is solved, or a goal is achieved.

The real challenge is how to model the context (to a good degree) in performance evaluation systems.

Let me explain further by taking an example from the world of sports. 

Cricket is a game that I love to watch and play (if I am allowed!). For those of you who also follow cricket, you know there are different rankings of players like the world’s top 10 batsmen or the world’s top 10 bowlers, etc.

Now, talking about the batsman ranking system – while I do not know the exact details of the current ranking algorithm, I think they do factor in some aspects like total runs scored, overall team’s score, opponent’s bowling quality, etc. 

However, the question is, how sufficiently the context has been factored-in, in this case. As a cricket lover, I know this: to rank any batsman’s specific innings, the following factors are truly important:

  1. Total runs scored
  2. The speed of scoring
  3. Remained out or not out
  4. The team won or not
  5. Quality of opponent’s bowling attack (a contextual factor)
  6. Match condition: when the batsmen came out to bat, whether his team was under pressure (a very important contextual aspect)
  7. Whether he played with a positive intent towards winning or just accumulated runs (another important contextual aspect)
  8. Ground/pitch conditions (context)

A batsman’s inning of 50 runs which has resulted in saving a match is much more valuable than complacent innings of 100 runs.

So without going much into cricket, you can reflect from the above example that other than the simple measures, the contextual aspects are really important to truly judge the quality of an innings.

A software developer’s performance review

Let’s converge the performance review discussion to the field of software development. To evaluate the performance of a software developer in a project, usually, the number of tickets developed in a sprint, code quality (number of bugs identified), code coverage, etc. are considered. These are good measures of performance, but are these enough? Do they factor in the context? Some context-related factors could be: 

  1.  How challenging was the project in terms of requirement clarity?
  2.  Was the technical stack new for the developer?
  3. Was the business domain a different one?
  4. If the developer is a junior, was he getting sufficient guidance or he has delivered in the absence of a mentor?
  5. Was he getting sufficient support from other stakeholders in the project?
  6. Did the developer just finish his work, or did he help others achieve their goals as well (e.g. helping fellow developers, giving good suggestions to clients, etc.), beyond the call of duty?

All these factors are essential to consider when conducting an engineer’s performance review. They account for creating a human-centered work culture, where empathy is at the heart of everything. When your employees are happy and satisfied, it brings a multitude of benefits to your organization as well. Here’s how workplace compassion can be of benefit to you:

Long story short

Creating a code of 1000 lines in a relaxed environment cannot be compared to the code, having a similar number of lines, but coded under tough deadlines.

We all know, developing software when you are challenged intellectually – beyond a certain level – is tough but what if you are challenged emotionally at the same time? It makes the situation much more difficult. 

So you see, the contextual aspects are quite important to properly judge the performance of a developer. The challenge is how to model and factor these in our performance management system properly, I will leave this for some other time, but currently, just wanted to highlight that numbers without the right contexts are just insufficient facts.