3 ms·

There's some blatantly missing metrics here. First off, there's no allowance made for mentoring and answering technical questions. If you go head-down and soci

There's some blatantly missing metrics here. First off, there's no allowance made for mentoring and answering technical questions. If you go head-down and socially punish anyone who disturbs you - even for good reason - you'll get more done and get a raise. On the other hand, if you annoyingly ask questions that further your project at the expense of distracting people around you, that also shows up in your project metrics and not your coworkers'. This will likely end up resulting in a really dysfunctional, non-collaborative culture. Second, technical debt. There's two casual factors here. First is that hacking together stuff helps your projects in the short run, while hurting the organization as a whole in the long run. Basically, another example of externalizing the costs of shipping your features. Also problematic is that working with lots of technical debt in the code base will stretch out your estimates, since there's tons of tech debt and making slow progress is the new normal. You'll "hit your feature development targets", but those targets will be a fraction of what they'd be with a better culture. Third, and related to the above, is deadline inflation. Your organization ends up rewarding people who are better at convincing management to give them more time to ship things. Yeah.

solatic 9y ago
1) Not so sure this is true. You may get more done individually in the short-term, but over the long-term, your anti-social behavior will cause the rest of your team to shut you out in turn, and your lack of visibility and understanding into what your team is working on will affect your future productivity and earnings. This is a Nash equilibrium at work, and good management will explain how the Nash equilibrium of co-operating on teamwork serves everyone's best individual long-term interests, even if the metrics naively seem to favor short-term action. 2) You don't need to adjust feature development metrics to get technical debt paid down. You set a target (e.g. 20% time to paying down debt), build a backlog of technical debt you know about, and either add the tasks to your sprint/version target (rewarding the team for completing them, like any other task) or come up with some other manner of getting them done, like Boy Scout code reviews (i.e. leave the codebase cleaner than you found it or fail review). 3) If you think you can ship better code by forcing arbitrary deadlines, then I hate to break it to you, but if the beatings continue, morale will not improve. And if you think you can substitute metrics and cash bonuses for good management skills to get people to work long hours so that you'll ship by the start of the holiday season (or other real deadline), then you don't understand how metrics is a tool for management and not a replacement for management.
- ThrustVectoring 9y ago
  I think I phrased my third point poorly, since I seem to have conveyed exactly the opposite effect that I intended. What I'm saying is that if you tie pay to performance against arbitrary deadlines, you're effectively paying engineers to pad their estimates. Estimation is definitely a pretty major game as it is, and we do ourselves no favors by paying people to play it more aggressively.

solatic 9y ago

1) Not so sure this is true. You may get more done individually in the short-term, but over the long-term, your anti-social behavior will cause the rest of your team to shut you out in turn, and your lack of visibility and understanding into what your team is working on will affect your future productivity and earnings. This is a Nash equilibrium at work, and good management will explain how the Nash equilibrium of co-operating on teamwork serves everyone's best individual long-term interests, even if the metrics naively seem to favor short-term action. 2) You don't need to adjust feature development metrics to get technical debt paid down. You set a target (e.g. 20% time to paying down debt), build a backlog of technical debt you know about, and either add the tasks to your sprint/version target (rewarding the team for completing them, like any other task) or come up with some other manner of getting them done, like Boy Scout code reviews (i.e. leave the codebase cleaner than you found it or fail review). 3) If you think you can ship better code by forcing arbitrary deadlines, then I hate to break it to you, but if the beatings continue, morale will not improve. And if you think you can substitute metrics and cash bonuses for good management skills to get people to work long hours so that you'll ship by the start of the holiday season (or other real deadline), then you don't understand how metrics is a tool for management and not a replacement for management.

ThrustVectoring 9y ago
I think I phrased my third point poorly, since I seem to have conveyed exactly the opposite effect that I intended. What I'm saying is that if you tie pay to performance against arbitrary deadlines, you're effectively paying engineers to pad their estimates. Estimation is definitely a pretty major game as it is, and we do ourselves no favors by paying people to play it more aggressively.