Hacker News Reader

Comment by aaronbrethorst | Hacker News Reader

Money quote, no pun intended:

    LG had a policy in place to reward managers with
    bonuses or even promotions if their features were
    part of the final product. The result was a constant
    feature bloat, as everyone tried to add on one more
    thing.

Incentivizing the right behaviors is incredibly challenging.

View on HN

Now everything wrong about my LG tv makes sense!

Incentivizing any behavior is likely to end in ruin: http://www.alfiekohn.org/books/pbr.htm

I think avoiding behavioral incentivization is impossible. You have employees. They (hopefully) want to excel in order to get things like promotions, raises, bonuses, praise from the creator of Ruby on Rails, etc.

You're inevitably going to incentivize their behavior somehow. I think it ends up simply being a matter of mitigating the worst possible outcomes, while angling for something that seems reasonably decent.

* Incentivize number of bugs fixed, and you'll get shitty code up front

* Incentivize number of features shipped, and you'll get a hodgepodge of features jammed into a product

* Incentivize peer reviews, and maybe you'll end up with a culture of glad-handers and politicians (I don't actually know about this one...I've never been in a corporate culture that embraced this)

There are alternatives to a system of individual promotions, raises and bonuses. See Github, Valve, early Google etc.

I'd be very surprised if this policy's effects (bonuses and promotions to managers whose features appear in a shipping product, or whatever the analogue of a shipping product is) aren't in place basically all over the world, even where they're not part of an official document. As such, it seems a little tricky to blame the feature bloat on the policy...

You're right - most organizations reward managers who ship. Hopefully they're tying the incentive not to the act of shipping, but the outcome of shipping. Revenue, users, really fun launch parties, etc.

    Hopefully they're tying the incentive not
    to the act of shipping, but the outcome
    of shipping

I'd say this is true for someone who has ultimate P&L responsibility (a senior VP, for instance), but it's definitely not the case for someone multiple levels below them. If you're a software developer responsible for a single feature in a huge app with hundreds or thousands of developers, your boss isn't going to gauge your performance with how the app does in the marketplace. They're going to look at the relative "success" of your feature. No shipped feature, no success.

cf. Microsoft.

Agreed, but the example is talking about managers. Not every manager is working on features that are going to have an easy-to-measure market outcome, but work that isn't purely strategic should have some identifiable metric of success beyond whether or not it exists.

Totally agree. Unfortunately, this requires their manager to have taste, which is probably (and tragically) an impossible requirement.

I found this here, it's a really good paper that backs the idea that goals are pretty tough.

http://hbswk.hbs.edu/item/6114.html

https://news.ycombinator.com/item?id=7897662

Good incentives are hard, but not actively sabotaging yourself seems like it should be easier.

Reply on news.ycombinator.com