The productivity of software engineers is difficult to measure. Metrics like the number of tickets closed, pull requests merged, tasks completed, bugs fixed, or builds created can provide some insights; however, this data should not be used to make decisions about an engineer's performance.
More valuable and experienced engineers play an important role in project communication, product decision-making, and helping and mentoring peers. All of which have a greater positive impact with less quantifiable actions.
Using quantitative data should only be part of a larger qualitative assessment, where managers and colleagues can take a more holistic view of an engineer's performance. Companies should also be mindful of how reward systems that prioritize quantitive metrics may create an environment where developers shift their focus from product to trying to artificially boost their metrics at the cost of a project's success.
Are there good approaches for qualitative assessment of engineer productivity?
Top comments (1)
Spot on. Productivity is not measurable by any metric, in software development; knowledge work can't be measured or estimated in definitive units.
Let's look at Agile, it had to come up with estimation points to have some degree of measuring work in a given time, to have some way of predicting throughput, for the same team, for a span of. time. But even those points are volatile, and relative to.. barely anything (time, team, project). But hey, let's salute the intent of measuring complexity.
Best one can do, is have teams with at most 5-8 individuals reporting to one qualified leader. One leader (not manager!) that can tailor, in 1:1s, custom development plans. And have the performance measured towards the agreed plan: how much did the individual manage to improve oneself, given all her/his particularities (obstacles, point of the career she/he's in, distractions, goals, requirements).