I think that this can sometimes be the case, but I think it's mostly due to a couple of factors that end up making this sort of analysis not very useful at a smaller timescale. First, tasks that end up requiring a large number of lines of code changes (e.g. a large new feature or a giant refactor) will be more likely to be done by people on the team who are the most experienced and successful, whereas smaller scoped tasks tend to be assigned to junior engineers or new team members. This makes the association between lines of code and productivity for an individual engineer a bit circular; if you're the one assigning tasks as their manager, the engineers you think are more productive will be assigned the larger scoped tasks, so of course they'll have more lines of code. The other factor is that summing up changes over a long period of time pretty much by definition ends up being biased towards people who have been on the team longer; even if two engineers made the same number of per unit of time, the one who will has been on the team longer will obviously been the one who has made more changes, and that's not even taking into account the fact that people's productivity should ideally increase over time given the increased familiarity with the codebase, the tooling, the problem domain, etc. If the longest tenured team members are the most productive, you'd expect them to have the most changed lines of code based on that correlation alone.