The Performance Management Formula

For engineering teams, like any team, managing performance is critical, especially regarding annual reviews. The truth is that individual performance matters a lot. Think about it - when someone misses a deadline or their code isn't up to par, it's not just their problem. It affects the entire team. It's like a domino effect; one piece falls, and it can set off a chain reaction. If one team member isn't meeting their goals, it can jeopardise the whole project.

Navigating the complexities of measuring developer performance presents a unique challenge. The key question is, what metrics can you rely on to maintain objectivity? Solely focusing on the pace of feature releases can be misleading. Developers frequently collaborate with others, such as product managers or fellow developers, to transition code into production.

Similarly, metrics like the number of lines of code written or the volume of merge requests can be equally unrepresentative. Elon Musk's actions at Twitter highlight that a simplistic or one-dimensional approach to evaluating developer performance can lead to misjudgments and oversights. Therefore, finding a balanced and comprehensive method to assess performance is essential to reflect a developer's contribution and capabilities truly.

Defining Performance in Software Engineering

To find an objective, fair and measurable of assessing developers' performance, I've come up with the formula below:

In this context, Output refers to a developer's tangible contributions - these are the skills, behaviours, and competencies they bring to the table. Output encompasses everything from their technical abilities and coding proficiency to their collaborative skills and problem-solving capabilities. It's about what they do and how they do it.

Output = expected competencies (Knowledge, Skills and Behaviours)

Output revolves around the expected competencies a software engineer at a specific level should possess. These competencies include knowledge, skills, and behaviours. Each of these pillars plays a crucial role:

• Knowledge - the necessary information a team member should possess (or access) to do their job correctly–for example, knowledge of the codebase, their industry, or the application's data model.
• Skill - the actions a team member should perform at the expected level to do their job correctly—for example, python programming, code refactoring, and communication.
• Behaviour - the character traits a team member should demonstrate to fit their organisation's culture and values—for example, proactivity, curiosity, and risk-taking.

You can use a competency matrix to list the desired Knowledge, Skills and Behaviours expected from team members for a specific position and level.

On the other hand, Outcome is about the results achieved from these efforts. It's the end product or the impact of the developer's work. The Outcome includes successful project completions, achieving set targets, and contributions to broader business goals. This dimension of performance measures the activity's effectiveness and relevance to the organisation's objectives.

Outcome = expected results (related to individual objectives)

Examples:

• Design and get approval for 25 new Minimum Viable Products during the quarter.
• Reduce the average number of new bug reports from 72 to 60 monthly.
• Increase application speed by 20%.

By combining the elements of Output and Outcome, the performance equation provides a holistic view of a developer's overall contribution and impact. This approach ensures that both the process and the results are valued, creating a comprehensive and fair assessment of performance in the technological and software development landscape.

Relationship between Output and Outcome

Understanding the relationship between Output and Outcome is critical. Consistent positive Output often leads to successful outcomes. However, discrepancies between the two can indicate issues in the definition of Output (like setting wrong expectations) or the clarity of outcome objectives.

IF Output ✅ and Outcome 🛑 two quarters in a row OR Output 🛑 and Outcome ✅ two quarters in a row, THEN either:

• Output is poorly defined (wrong expectations or wrong benchmark)

OR

• Outcome is poorly defined (unclear objectives or not aligned with Ouput).

Performance Reviews in Engineering Management

Ongoing performance reviews

Too often, performance reviews end up being this annual chore where the only thing at stake is the team members' salary increase. However, transforming performance reviews from an annual obligation to an ongoing dialogue is crucial for fostering a dynamic and responsive team environment. Frequent and regular discussions about performance allow for real-time feedback and adjustments, ensuring developers remain aligned with team objectives and personal development goals.

As a manager in the tech industry, your mission extends beyond setting objectives. It's about empowering your team to excel.

This is achieved through:

• Quarterly Reviews: Where you assess performance, set objectives, and update training plans.
• Monthly KPI Check-Ins: To monitor progress towards objectives and training.
• Weekly One-on-Ones: Crucial for discussing performance and objectives and providing coaching.

This proactive approach helps identify and address challenges promptly, rather than waiting for an annual review where feedback might be too late to be effectively actionable. Moreover, continuous performance conversations build a culture of openness and trust, encouraging developers to engage more deeply with their work and take ownership of their growth. It also enables leaders to better understand the individual strengths and areas for improvement within their team, leading to more targeted and practical support.

In essence, by making performance an ongoing conversation, engineering leaders can create a more agile, engaged, and high-performing team, where development is a constant process rather than a yearly event.

The Annual Evaluation Process

The mandatory annual review process becomes a formality when performance becomes an ongoing discussion. It doesn't prevent having a structured approach, especially if you want to use the annual review to discuss salary increases or potential contract termination.

A structured approach should encompass several steps:

1. Anonymous Manager Feedback Survey: This is an opportunity for team members to provide candid feedback about their managers. Accompanied by a competency matrix evaluation, it allows team members to assess managerial performance in various dimensions, fostering a two-way feedback culture.
2. Managerial Evaluation: Similarly, managers evaluate each team member using a competency matrix that mirrors the one used by the team. This ensures a balanced and objective assessment of each individual's skills, behaviours, and contributions over the year.
3. The Evaluation Meeting: This crucial gathering is where the insights from surveys and evaluations converge. It provides a holistic view of each team member's performance, combining self-assessment, peer feedback, and managerial evaluation. This meeting is instrumental in painting a complete picture of the past year's achievements and areas for improvement.

This annual evaluation process does more than summarise performance; it cultivates a culture rooted in continuous improvement and open communication. Providing clear insights into individual and team performance sets the stage for targeted development plans and reinforces the value of regular feedback. This process ensures that the annual review is a retrospective look at the past year and a forward-looking session that guides future growth and development.

You can use the below flowchart as a guide to perform your annual performance review process in a structured manner.

The idea here is to have a performance review process that balances objective assessment with opportunities for improvement and development. It emphasises the importance of aligning individual performance with organisational standards and the consequences of consistently failing to meet them. The approach detailed in the flowchart appears to value constructive feedback and personal development while maintaining the need for accountability in performance management.