tl;dr: You have effectively instituted a grading rubric for your entire engineering team, the way a manager grades their worst engineers. As a result, your ent

tl;dr: You have effectively instituted a grading rubric for your entire engineering team, the way a manager grades their worst engineers. As a result, your entire team is now motivated to act in accordance with the way bad engineers typically perform. --- I completely agree with the other responders. At the BARE minimum, you could have changed this "leaderboard" to display only the top three, and coded the app in a way as to hide the remaining developers, as a way of celebrating the "best" developers this week, instead of ranking everyone on the team (and thereby punishing those on the bottom). Your dev team is not a sales team. If its your management team deciding task effort level, then you have compounding problems because they do not understand engineering impact. If it is your engineering team choosing engineering effort for each task, you still have created a perverse incentive. If I implemented this sort of ranking on my team, BY FAR my best developers would consistently be on the bottom of the list. And this list, would in turn, motivate them to stop working on the hard ambiguous problems I need them to solve, and motivate them to steal as many items as possible that my junior engineers could otherwise have accomplished. Even if my best engineers stuck to high-effort tasks (which they now are motivated not to do), not all high effort tasks are the same difficulty, and they now have a very strong incentive to only work on the easiest tasks in each difficulty level. If I was on your development team, the introduction of this leadership board would be a Huge, Neon sign to me that code quality and engineering decision making no longer matters, all that matters for job security is writing as much as possible, as quickly as possible. What's that? My poorly thought out code will result in numerous more bugs than if I had actually put thought into it to begin with? Well guess what? I'm the developer who best knows how to fix those bugs, so the more bugs I create now, the more I'll be able to fix next sprint too! Then I'll still be on top of the leaderboard! Sure, you might have some internal processes to prevent this, but those are now on a timeline to deprecation as this leadership board comes to define your team culture. And even if your engineering team's internal culture is strong enough to overcome this blight, the game will simply become either how to best ignore this leadership board without upsetting management, or alternatively how to most act as described in the previous paragraph without getting caught. This reeks of project management applied to engineering, without understanding the nuances of engineering.