[jay_kyburz]

I've been reading this whole thread and playing my favorite game called "If I were CEO of Google this is what I would do differently"

It must be incredibly difficulty to evaluate how well people are doing, and how valuable peoples work is when only one or two departments make any money and everything else indirectly supports that work.

How do you reward people for doing boring maintenance work on existing products? How do you give people the time to build the products, but also keep them happy and well paid enough to prevent them being poached?

How to reward a talented engineer who's job it is to add some small feature to a massive product like Maps or Docs?

I can't help but think I would explode the company into thousands of tiny startups each managing themselves and their own budgets, staff, and salaries, and literately pay bounties for every little feature I wanted implemented. There is no ladder to climb, only bounties to claim.

[JohnFen]

> How do you reward people for doing boring maintenance work on existing products?

Maybe start by hiring people who don't find maintenance work boring? I've known tons of excellent engineers who very much prefer maintenance work.

[potatolicious]

This seems unlikely to work and in fact probably exacerbates a bunch of issues:

- it's impossible to collaborate across org boundaries. If each org has their own budget/staff/salaries and their sole source of income are claimed bounties, there is no incentive to contribute one iota of work that isn't related to a bounty they can claim. You can of course split bounties but a) then you have interminable fights about the exact way bounties should be split, and b) the meta-game likely still rewards only pursuing bounties that one's org can achieve by themselves, causing orgs to refuse to collaborate.

- orgs will become more and more short-term focused since claiming bounties is critical to survival. A smaller bounty that can be claimed in 4 months is better than a larger bounty that can be claimed with 2 years of work. This is extra true if the orgs compete with each other - your odds of being pre-empted is lower with a 4 month bounty than a 2 year bounty, where you can burn a ton of work only to get beat by another org. The meta-game will almost certainly heavily favor fast small features rather than long-term work, and will absolutely preclude self-disruption type projects that are both time-consuming and risky.

You can, of course, insert some layer of managerial judgment into this to offset the meta-incentive flaws in the system - so you can force investment in long-term projects and force inter-org collaboration, etc. But at that point you've replicated a traditional corporate structure, just with "bounties" in place of "promotions".

But most importantly a bounty-based system doesn't solve the core problem here: who makes decisions about the company's products?

In a bounty-based system like you describe, there would be some kind of central cabal that issues bounties - in essence determining what products and features should be built. But then you have some pretty obvious issues:

- does the central cabal know enough about the product domains to be the most qualified to make these determinations? Or will the products suffer because the cabal doesn't understand the product's domains deeply enough to make smart decisions about it? Does it not make intuitive sense that the people building the product knows more about it than a group of far-removed decision makers? How do you consider the views of those who are closest to the product and most keenly aware of its tactical needs, in balance with the views of those who are furthest, but have more inter-product and strategic knowledge?

- besides the problems of the cabal knowing what should be built, how does the cabal know what can be built? It is entirely possible for the cabal to issue bounties that are unimplementable (give me a system that can diagnose cancers with a 0% error rate!). Besides the challenges of a highly centralized product org knowing what the market wants, they would have little way of knowing what is expedient or efficient for the company to achieve.

Again, you can insert some layer of managerial judgment into this to offset the problems here, but again you'd end up replicating a traditional corporate structure.