Hacker News new | ask | show | jobs
by NotPavlovsDog 1961 days ago
> Instead of measuring some approximation of engineering output, software teams should measure actual, observable metrics that directly correlate to effectiveness.

I prefer to measure value created and partially tie it to compensation, directly and indirectly.

For a dev team for a trading platform, we had an index of income created by product, approved by team and stakeholders, that affected total compensation paid to team.

This is a specific example. The general principle is let tech teams make decisions and compensate them for value created, at least partially.

Otherwise, when you don't want to share your money, "measurement of productivity / effectiveness" comes in. Because when you measure money, people ask, "why am I not getting more when I make you more"? But if you're not measuring money, why do a business?

2 comments

Because measuring money is hard and it's not easy to apportion credit.

Person A has an interesting-but-not-exceptional idea and gets Person B to fund it. People C, D, and E code it.

For most interesting-but-not-exceptional ideas you could replace all of these people with others.

If you actually ran this an experiment in a Monte Carlo-but-real kind of a way, you'd find some collaborations would do well, some would do badly, some would fail completely, a few might explode (in a good way).

How do you quantify the value of the relative contributions?

We've run a variety of experiments that worked for us. What is important is implementing the question in a way that works for the organization.

How shall we quantify value, and how much of that index will affect compensation.

It's answering the question "why do some people get paid more" in a transparent way.

> I prefer to measure value created and partially tie it to compensation, directly and indirectly.

How does this apply to team that maintains your source control and continuous integration systems?

That's what you discuss in the organization.
What were the conclusions of that discussion in your organisation?
See my parent comment. One of the agreements we arrived at was not to have non-product-facing teams.

The teams also decided on how and who would be allocated to the tasks that could be placed as similar to what you describe.