You say that now but what about Mary dev who consistently pulls high effort tasks and does not finish them in the right timeframe because she goes home on time? When someone consistently shows up in the bottom of the chart because they work regular hours instead of overtime, it will be demotivating, cause your employees to resent those at the bottom for not working hard enough, and will creep into performance reviews.

I'm in the same boat as other posters, I am a hard no on this idea and would never subject my employees to it. When you build employee-facing metrics like this, you end up judging your employees by those metrics. Build smarter metrics.

ETA: "your company culture" is dictated by things like this. So the incentive it creates in your culture is to work longer hours so you can get to the top. This is literally building company culture, and trying to say you can avoid the negative incentive by having a better culture is missing the point.

Do the developers think it's fun? Or do they know the boss thinks it's fun?

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.