How You Can Measure and Evaluate Performance of Software Engineers

Engineers need feedback so they can improve skills and deepen knowledge. According to the editor of the Inc. Magazine, Jeff Hayden, traditional metrics can be misleading, as they do not always offer a clear result. Evaluating the work of staff used to be difficult, before Git Analytics tools, such as Waydev came up with a data-driven approach to engineering leadership to help you bring out the best in your engineers.

It is important to measure what exactly you need and in the right way. The choice depends on the specifics of your business and the job responsibilities of each engineer.

We provide you with the algorithm that will help you to evaluate the effectiveness of engineers:

1. Setting up goals

Setting organizational goals and regularly checking that all teams follow them should be a top priority from the start of the project. Even if your software development is outsourced, the team of engineers is not an independent organization whose only function is to write code and test it. Integrating technical goals with common business goals is an essential step in your journey. Conceptualizing tasks in the early stages lays the foundation for evaluating performance in the later stages.

Each target should correspond to the general goals of the business – at the team level or the individual level.

2. Laying the foundation

Performance measurement comes down to two questions – what and how. Questions like “what” relate to actual tasks assigned to the team. They include explicit facts and implicit expectations. An example of a question like “what” can be called writing and testing code on time. Here, the timing is an explicit fact, and the excellent quality of the code is an implicit expectation.

Questions like “how” are related to the process – for example, how well the engineer worked in a team, how innovative was his approach to the problem, and so on.

An assessment of the fundamental “what” and “how” will not only show you what tasks the team is working on, but also how well they perform them. Waydev provides a bird’s eye view of your engineers’ activity with the Work Log, enabling you to see and zoom in to any commit or pull request an engineer produced in a time frame.

3. Focusing on long-term results

In software development, you should never focus on the quantitative aspect of the product being developed. Additional lines of code will simply lead to overblown software that will be difficult to maintain. Conversely, minimizing the number of lines of code written does not work either: it will lead to software that will be difficult to understand and scale.

A long-term results-oriented approach implies that instead of quantifying performance, a product is evaluated based on team performance. To assess the development and release processes, you need to analyze the stability, delivery time, and frequency of updates of the final product.

To evaluate the performance of a team, you need to understand whether it has achieved the desired results. By focusing on this, you will not only increase developer productivity but also achieve organizational goals and subsequently generate substantial profits in the long run. You can use Waydev’s Project Timeline feature to see how work focus and volume modify over time. Find out where your engineers’ work focus is. Is it on creating new code, refactoring old code or is it on helping others? View how events impacted your team’s performance and direct your data-driven decisions.

4. Preparation for evaluation

In order to have something to build on, it is necessary to have a certain standard that you can follow when evaluating. Such a standard may be the job description or the intended work plan.

View existing job descriptions, documents, records, emails, and any other data that would allow you to conclude the effectiveness of the employee.

If you are in the team recently, talk with the developer’s leader, their colleagues, and, if possible, with the loyal customers with whom they have worked.

Success or failure depends not only on the person but also on the working conditions:

• Were there any unforeseen circumstances? For example, the underestimated complexity of the task or the change of priorities? Perhaps this is what prevented the engineer from achieving his goals and showing his abilities.
• What successes did the company achieve, and what was the contribution of this engineer? Did the engineers properly use their key skills?

With Waydev’s Project Timeline, you can identify the most relevant data points according to your team’s workflows, and have a productive discussion about what learnings could be applied to the next sprint. Project Timeline​ will help you and your team quickly see signals of process blockers affecting the health of your team’s software development during conversations in your retrospective evaluations.

5. Analysis of goals and key skills

Compare the current performance with the desired or defined in the job description. If there are visible results, back up this data with specific examples and determine their significance:

• Have the desired indicators been achieved/exceeded?
• Did unfavorable working conditions prevent the achievement of the set goals?
• Were the goals achieved due to the employee working overtime?
• Was the result of the work so outstanding that it is worth highlighting this engineer?
• Has the engineer played a key role in achieving the team’s goals?

If there are no visible results, ask the following questions:

• Did success depend on this person?
• Was the failure caused by reasons such as the lack of necessary equipment, too large a volume of tasks, fuzzy task setting, or lack of required resources?
• Would a more prominent authority solve these problems?
• What are the consequences of not completing a task?

Determine how regularly and effectively the engineer applied his key skills in his work:

• Did the employee use the skills daily? Did he apply all competencies or only some of them? What kind?
• How did applying skills help an engineer achieve work goals? How did this affect team workflow and success?
• Did the engineer have difficulty working? If so, how did this affect your goals and workflow?

If the engineer is hard given the fulfillment of work tasks, and the goals are not being achieved, it is worth considering the organization of additional training or continuing education courses.

6. Discussion

All the conclusions that you managed to draw during the analysis should be discussed with the engineer himself. Focus on his successes. To describe the situation as accurately as possible, use specific examples. Start on the positive side, but be sure to mention the difficulties that have arisen. If the goals were not achieved for reasons beyond the control of the engineer, he should not think that it was only his fault.

Be sure to ask questions and listen carefully to the answers to the questions; this will help you identify problems and understand how the person relates to them: whether he wants to solve them, what solutions he sees, and what he would like to change.

7. Recommendations

Based on the data that you received during the discussion with the engineer, his manager, and colleagues, make a list of suggestions that could increase developer productivity.

How to Write Comments and Recommendations

Comments on the work done are needed to provide feedback. Based on the comments, the engineer will be able to assess their strengths and weaknesses and direct efforts in the right direction. Remember that the comments can be judged not only about the engineer but also about the person who wrote them. They must be composed professionally and objectively.

Comments should describe the following points:

• To what extent did the engineer achieve his goals?
• How often did the engineer demonstrate professionalism and key skills?
• What has improved over the evaluation period?
• What needs to be improved?

Comments should have the following properties:

• Objectivity.
• Completeness.
• Truthfulness.
• The specifics.
• Positive completion.

Aspects that need attention

Attendance

First of all, you need to pay attention to whether an engineer appears at work at all. Consider the time of arrival and departure and absences. If someone from the team arrives too late, leaves the workplace for a long time, goes earlier than necessary, or takes sick leave without good reason, he does not seek to work at full strength. Remember that poor attendance can be caused not only by commonplace laziness but also by more severe reasons – lack of motivation, health problems, or emotional burnout.

Avoiding work responsibilities can fuel a team environment. Other engineers have to take on additional responsibilities to compensate for the absence of a colleague in the workplace. The situation is aggravated if your organization does not have enough engineers, and people are already processing it. Start to deal with the problem as soon as possible: ignoring it can lead to problems in the personal life and health of your engineers.

Helpful behavior

We are all focused on helping customers, but mutual assistance within the team is also essential. Konowe & Associates believes this item is one of the key performance indicators for engineers: “We ask people the question. Who in your department (or company as a whole) was the most responsive and helped you more than others over the past six months?” It turns out this anonymously motivates engineers and allows you to identify real hard workers and not just the favorites of the leadership.”

Willingness to help each other is a crucial element of teamwork. Working on complex tasks together is far more effective than trying to turn mountains alone. The Review Collaboration feature enables you to see who shares his knowledge with others. It also provides quantifiable metrics to help you assess the health of your code review workflow.

Ability to plan

All team members must complete work on time. They must be able to manage time and resources and set priorities correctly to do the job as efficiently as possible.

Pay attention to the deadlines and the quality of work that suffered due to hasty implementation to achieve the deadline; this will help to understand how efficiently the employee works. It is also essential to consider the amount of time spent at work: if a person consistently and repeatedly processes, it is worth talking to him about time planning.

Initiative

It’s good when colleagues are interested to know if they can help you with something. Even better if they see work goals and take action to achieve them. The initiative is an indicator of involvement in work. Identification of the most proactive engineers is essential for growing companies where new jobs are continually created, and human resources need to be quickly redistributed. For the most effective work of the new department, it is better to equip it with the most initiative personnel. They will be able to quickly adapt to new conditions and work ahead of the curve.

To identify the most proactive members of your team, record every time an engineer takes the lead in the work.

Quality

Quality of work is the most important but, at the same time, the most challenging indicator of performance to measure. Engineers who stand for quality and are genuinely involved in the work process and are likely to show better results. This involvement can be a quality criterion.

Developer productivity isn’t only focusing on the quantitative feature of the merchandise being developed; this isn’t the solution. Engineers writing additional lines of code simply contributes to the progression of bloated software, which introduces maintainability challenges. You need to know if your engineers are providing you with quality work, rather than quantitative work.

HR World website experts suggest evaluating the quality of the final result by the number of works that were rejected or returned for revision. You can use this method or choose another, more suitable for the specifics of your business.

Finally

Of course, evaluating performance in specific numbers is essential, but Monster.com business trainer Cheryl Stein advises not to be limited to digital numbers. After all, team members are people, not just resources. Stein notes that some qualities, for example, the ability to find an approach to any person, are now worth their weight in gold, and such skills cannot be overlooked. Stein also writes about how important it is to pay attention to changes in productivity, as they can be a symptom of more global processes in the company.

“A decrease in productivity may indicate market changes or insufficient marketing strategy, mission, and values.”

When measuring effectiveness, it is imperative to communicate as openly as possible with the team. People need to know what you are measuring and how to report the results. Thus, each engineer will know what his position in the team is. With Waydev, you can advocate on behalf of specific team members, see how they are progressing and assist them in eliminating bottlenecks, enabling better communication up and down the organization

The article was published first on Waydev Git Analytics Blog