4 ms·

Hi, author here! I think it's a risk you have if your company culture encourages working long hours. We never did that tbh and people know we don't have that ex

Hi, author here! I think it's a risk you have if your company culture encourages working long hours. We never did that tbh and people know we don't have that expectation. We also didn't couple strong incentives (e.g. money) with this process, we always kept it at a "fun" level. It's been more than enough to keep people engaged

latortuga 6y ago
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.
- lucaronin 6y ago
  I understand what you say — we never judged anyone on such metrics, but I agree I didn't do a great job at elaborating on that. Like you said, the metric is very simple, it's just an indication that is useful to understand bottlenecks, and to have some fun in a tight-knit startup team (that doesn't work long hours) where people don't like that much fixing bugs :) Like others have said, I think the line between this being healthy and useful, and this becoming a nightmare is fine, and it gets probably harder the bigger the company is. Thank you for your feedback anyway!
  - jdmichal 6y ago
    > we never judged anyone on such metrics I think you need to be aware and selective in who "we" is here. Do you mean management-"we", peer-"we", personal-"I"? The post you're replying to did a great job of calling out that all of these (and more) could have very different viewpoints on this.
pseudalopex 6y ago
Do the developers think it's fun? Or do they know the boss thinks it's fun?
ep103 6y ago
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.

latortuga 6y ago

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.

lucaronin 6y ago
I understand what you say — we never judged anyone on such metrics, but I agree I didn't do a great job at elaborating on that. Like you said, the metric is very simple, it's just an indication that is useful to understand bottlenecks, and to have some fun in a tight-knit startup team (that doesn't work long hours) where people don't like that much fixing bugs :) Like others have said, I think the line between this being healthy and useful, and this becoming a nightmare is fine, and it gets probably harder the bigger the company is. Thank you for your feedback anyway!
- jdmichal 6y ago
  > we never judged anyone on such metrics I think you need to be aware and selective in who "we" is here. Do you mean management-"we", peer-"we", personal-"I"? The post you're replying to did a great job of calling out that all of these (and more) could have very different viewpoints on this.

pseudalopex 6y ago

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

ep103 6y ago

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.