Let’s face it, our industry is obsessed with the idea that more is better -multitasking, working long hours, hustling, getting many things done.
However, as we embrace a new way of working, remote work, distributed environment, we, engineering managers, need to let go of things from the past that no longer work. This includes using vanity metrics and old-fashioned ways to measure productivity.
Because more isn’t always better, especially when it comes to measuring the performance of a software engineer.
Don’t: Use story points completed to measure the performance of a software engineer
The use of story points has always been a huge topic for debate. Some say it is useful for Agile software development teams, others say it is of no use for business. Both of them are correct. But here is where I have a strong opinion, as someone who has worked in many software development teams, both as a software developer and an engineering manager in the last two decades of my career. Story points are a bad measure for a software developer’s performance.
Why is the story points a bad indicator for performance?
Not all story points are equal
Story points are the measures of complexity relative to the knowledge of the person or team giving an estimate. Therefore, one team’s story point of 3 might not equal the other team’s story point of 3. Therefore, when you’re comparing multiple engineers from different teams on their delivery, story points are not the right metrics to be measured against.
Larger story points don’t mean a bigger impact
In software development, simple is beautiful. Often, large story points are a result of complex code paths, and rewarding large story points indirectly encourages software developers to think complex and over-engineer their solutions. The best way for an engineer to know how productive they are is to look at what outcomes they are delivering and the impact they are making to customers. Not how much code they are writing or how complex their code is.
Story points give away too much flexibility and encourage less accountability
Story points do not tell us how accountable and reliable a software engineer is. Sure, they may work on the most complex (relative) stories, but that doesn’t mean they are doing their best, delivering on time, and embodying the right behaviours. The worst thing about story points is that it enables software engineers to avoid committing to any date. I understand many software engineers do not generally want to commit to a deadline in case they discover any unknowns but not setting expectations on when something will be done, or not having any milestones is purely irresponsible.
Senior engineers may have less coding time
As an engineer progresses in their career, they might find that actual coding / development work is less and less as they will be doing other things require more seniority such as planning, story breakdown, mentoring, onboarding, code reviews, etc. This is especially true if they are working for a large tech company as there is a lot more coordination and knowledge sharing required. In terms of percentage, it will be close to or more than 50%, depending on the size of the company, the complexity of the project, and seniority.
Do: Measure the performance against the competencies expected at their level
Firstly, let me get this out of the way: an engineer’s performance should never be measured by the number of hours worked or line of codes written. They should be measured by the outcomes produced.
However, this sounds a bit abstract so let me explain further.
Tech companies tend to measure the performance of their engineers and software developers against the competencies expected for their level and role. And large tech companies like FAANG (Facebook, Amazon, Apple, Netflix, and Google) have documented information about this expectation, so in a way, it’s very objective.
Common competencies (in order of expectation by junior -> senior) are:
- Technical skill
- Planning work skill (breaking down a large problem into manageable tasks)
- Estimation skill
- Communication skill
- Stakeholder management skill
- Influencing skill
- Mentoring skill
Junior developers would not necessarily be expected to have stakeholder management skills and influencing skills but as they move up the career ladder, they would be expected to demonstrate more of the skills from the bottom of the list.
Do: Obtain qualitative feedback, eg: 360° feedback, on the software engineer
Working as a software engineer in this day and age where the complexity of software development has increased, it’s not enough for them to keep their heads down and code. Being able to work well with others to deliver results is an important part of a software developer’s role. Therefore, it’s important to get 360° feedback on the software engineer from people they collaborate with to understand how effective they are at delivering results as part of a team. Brilliant jerks have no place in today’s work environment.
Measure what matters
In short, there are both qualitative and quantitative measures when thinking about the performance of software developers. Qualitative metrics like 360 feedback and quantitative metrics like the impact of features released are often looked at, but looking at other vanity metrics like lines of code, story points completed should be steered away from.
- Don’t: Use story points completed to measure the performance of a software engineer
- Do: Measure the performance against the competencies expected at their level
- Do: Obtain qualitative feedback, eg: 360° feedback, on the software engineer
📩 Sign up for the author’s newsletter to receive regular advice and resources for your career in tech. You will also immediately receive a link and password to download freebies for your career growth.
