Be a better management with transparent performance reviews and quick feedback with on focus areas. To effectively measure software engineers, a manager needs to ask why they are measuring, agree upon on what to measure and then land on how to measure.
There are a few different reasons why a software engineering team lead would want to track each software engineers individual performance.
A manager would want to give out the right amount of compensation to each member of the team year after year, not just to do what is right but from a recruitment standpoint as well.
Each manager should want to retain and attract the brightest and most effective software engineers.
A new software engineer can feel overwhelmed when first starting their career. In our knowledge profession there often aren’t operating manuals on what to do each day. Measuring performance can be a team lead’s opportunity to signal what an engineer should focus on. For each skill area an effective manager leads the engineer on what they should do more of and what they should not do.
As software engineers our goal is to create products that solve problems in a way where people enjoy using them. To create products we rely on an engineers ability to work independently to create key components of that product. The faster an engineer creates a high quality component the more successful the business unit is in accomplishing a its goals.
The Lake Wobegon Strategy famously coined by Google and Peter Norvig claims that you should always hire above your team average. Doing so increases the quality of your team. https://ai.googleblog.com/2006/03/hiring-lake-wobegon-strategy.html
While hiring above the team average increases the quality so can managing out a poor performing individual who brings the quality down.
After coming to the conclusion that a team lead needs to measure an individuals performance, you need to agree upon within your organization what key skill areas to measure. This can be made easier if your organization provides job profiles and outlines explicitly on the key responsibilities of the role.
However, if you are like me and manage individual contributor software engineers there are some common skills that you should consider measuring.
Writing code is the name of the game, I often refer to this as coding. Is the engineer able to complete an individual feature or bug fix on their own that follows the design put forth by the team?
A few factors to look for proficiency in this skill include: completing the task, ability to take directions, working independently, level of quality, taking constructive criticism.
Code reviews are probably the first thing a new engineer can start doing in a new role. Each team member needs to be looking at each individuals pull requests before allowing them to merge and deploy. Code reviews are proven to increase the quality of the product and every team needs to them. They need to do them so much that it should be recommended to block off time each day to do code reviews.
Areas to look at while assessing: are they putting their code up for review, are they looking at others code reviews, are they leaving comments, are the comments meaningful, do the comments show deep understanding of the internal workings of the products components.
Not all code is going to be defect free, humans make mistakes or underlying dependencies change. Software engineers will need to be able to troubleshoot a defect that exists in a production environment to understand the underlying issue to recreate in a development environment and then resolve.
It is not realistic to give an early software engineer defects within the first few months of a project assignment. So this skill area might not apply until a little later in their career.
An engineer who shows proficiency in troubleshooting knows how to identify an issue by knowing what log files to look at, they are able to recreate an issue in a development environment, they can propose different resolutions and can explain the pros and cons of each solution.
As software engineers not only are we building systems for our clients, we build systems for ourselves so that we can deliver faster and at a higher quality. This category includes systems such as continuous deployment and continuous delivery systems that allow us to put more focus on our customers.
Showing proficiency in this skill can be seen through different examples such as implementing a new Jenkins job, improving a log file system, setting up automation around common human tasks that need completed.
Once a set of skill areas for a role is landed and agreed upon you will want to make sure your team knows in advance what they are being measured on. This gives the engineer a chance to ask questions around the skill area and give hem the opportunity to sharpen their skills throughout the year.
You will want to measure their skills to track how they are improving or declining throughout the year. To gather examples for all members of your team it will take open communication.
Here are a few ways to gather the information below