[jimbokun]

I think there's only one metric that is really effective for measuring and evaluating software teams.

Tie their compensation to the product's financial success.

This means, to the greatest extent possible, everything relevant to the product's success must be owned by the team and become their responsibility. Maybe there are some cross cutting concerns that should be the responsibility of a group separate from any product team, but those should be rare and require a strong justification.

This will have an amazing effect of clarifying prioritization of what to work on and figuring out how to deliver it as quickly and reliably as possible. Suddenly the whole team will be in the loop about what features are most important to the customers. Suddenly the things blocking new features demanded by the customers from shipping will be cleared away.

I think for any other metric you can devise, either intentionally or unintentionally, employee behavior will be optimized for satisfying the metric, and not customer satisfaction with the product.

[Rooster61]

> Tie their compensation to the product's financial success.

This is an atrocious idea in anything much larger than a start-up. It leaves the engineering team beholden to bad decisions made in other facets of the company (sales, marketing, upper management). It's exceedingly frustrating to write a solid, stable, performant program only to have marketing or sales push it as something that it is not and nosedive the company due to customers calling bullshit.

Start-ups are somewhat immune to this because of the lower barrier of communication between departments, as many people will be wearing multiple hats due to there being more things to do than people to do them.

This is very visible when executives begin choking off benefits across the board. Nothing kills morale quite like losing your bonus because another department isn't doing its job properly. I've seen more than one mass exodus from a company as a result of this.

[jimbokun]

> It leaves the engineering team beholden to bad decisions made in other facets of the company (sales, marketing, upper management).

I mean, you're screwed anyways if those people can't do their jobs. No sales means no revenue means engineers taking a pay cut or getting laid off.

So the sales and marketing and product management responsible for your project, need to be on the same product team as the engineers, and have their compensation tied to the product's success.

If the engineers see themselves as the natural enemies of sales and marketing, the product is probably already doomed.

[sytelus]

Very bad idea. This almost always incentivizes to exploit for short term financial results at the expense of long term sustainability. For example, you can cut down customer support department to save money which would increase your profit (and therefore bonus for an employee who made that decision). In longterm you probably won't have customers. Executive pays often follow this rule and you can find vast number of stories how they ruined companies for short term gain and bonus cashouts.

[jimbokun]

OK, but if you substitute "product's long term financial success" for "product's financial success", I think the point still stands.

Could add in factors for customer retention and customer satisfaction, for example.

Everyone on the team should share responsibility for figuring out what will make the customer's happy with the product and how to deliver on those things.

[sytelus]

The criteria "product's long term financial success" doesn't have a lot of meaning. Does it mean my bonus is withheld until 5 years? What if something else goes wrong in such long time frame (like economy tanks) which wasn't my fault? What if someone unrelated contributes to 5-year success and I get to share the glory?

The point is that measuring performance off of single metric is incredibly tricky. In the field of reinforcement learning this is known as reward function engineering and its one of the hardest thing to get right for even well specified problems. Employee actions would need to have short term as well as long term focus (exploitation vs exploration). Most actions have consequences that won't reveal itself completely until sometime in future. The current "state of the art" technique is to use stock vest schedule with hope that employee would care to grow his/her future stock vest.

[januzis]

This doesn’t solve the issue of individual team member performance evaluation, even if it improved the overall performance of the team, you still wouldn’t know who are under and over-performers.

[jimbokun]

Because that is counter productive to increasing productivity.

Having team members focused on getting themselves ranked higher than their teammates, means incentivizing them to not help each other or do something they might not get credit for, even if it's in the best interest of the product or the team.

[januzis]

Even if you've tied team compensation to the results of the company, you still have to decide how it will be shared among the team members. So how do you go about compensation, bonuses, etc.? The same for everybody?