Building and shipping software is something that can be done by one person. But most software is build by teams of software developers.
Measuring an individuals contribution not simple because there is not single metric that can be used that can't also be abused.
Contextual Task Variability
- How familiar is the engineer with this area of the code?
- Are you working a new version of a framework or library?
- Are you implementing ahead of finalized APIs or specifications?
- Does that task require refactoring?
- How difficult is writing unit, integration, and end to end tests for this software?
- How experienced with this programming language?
- Are you collaborating with others?
Team Variability
- Are you pairing with other developers regularly?
- Are tickets assigned or chosen?
- Are some team members required to go to more meetings or communicate more frequently because of their role or tasks?
- Are they bring value in ways that don't involve coding?
- How friendly and positive is the code review process?
- How much emphasis is on documentation?
- Are people rushed to ship code?
- Is the team too focused on code quality, technology, at the expense of the customer?
In my experience these questions and other introspection are way more important factors to dig into when evaluating team effectiveness and productivity.
Most modern work performance processes are highly flawed in my experience, because there's no way build metrics and rules to see how people are performing.
Productivity cannot be measured at the individual level in software development and most knowledge work.
PS: If you want to know more I suggest read Marcus Buckingham and the research that's been done at ADP and Gallop.