[strulovich]

Ok, but then what is a way to do it?

The text gives an example to the core problem, and to argue differently requires thinking around it.

In practice. I’ve seen many attempts at measuring productivity, but once you dig into them, you see they are just abstraction mechanisms above something that is similar to lines of code.

I have yet to see an idea that sidesteps the core issue described in this post. Also, it applies to many types of work, and software is not unique in any way.

[bruce511]

Happy Customers.

All other measures are a proxy for happy customers.

Actually, happy customers is also a proxy (the real measure is profits) but measuring profits directly (in the short term) can lead to decisions that have adverse long term effects. It's too easy to increase profits in the short term by avoiding long-term expenses.

So, if you're in the business of software, the goal is happy customers. (And I use the word Customers carefully here. Not just Users who pay nothing, but Customers who spend money.)

In a business context, it's really the only thing that matters. But, of course, it can be hard to measure (are they Happy?) and relies on multiple disciplines. Production (coding), Marketing, Sales, Support, Documentation, Training- all need to be working well to make it work.

Ultimately if the big picture doesn't lead to Happy Customers (again, I stress, in a businesses context) then no-one is "being productive."

[Cthulhu_]

While customer satisfaction is a better (albeit murky) metric, value generated / profit is a better one ultimately. Of course, measuring developer productivity is a means to that end; how much did or will it cost to reach this value generated?

Anyway there's this adage that once a metric (like productivity) becomes a target it ceases to be a useful metric. But this doesn't seem to apply for value / revenue much, so I suppose it's good to keep an eye on this vague productivity metric.

[hammock]

It’s demand. How much demand is there for your product

As the other commenter pointed out, happy customers means nothing if they aren’t actively paying you

[n4r9]

Arguably the business is aiming for Paying Customers, not necessarily Happy ones :)

[virgilp]

When a measure becomes the objective, it ceases to be a good measure.

Even if you could perfectly measure customer happiness (very hard, as you note) - it's relatively easy to make customers happy by giving them more value than what they pay for. Sure, that may cost your business more money than what it makes with said customers, but hey, who cares, "profit" was not the metric...

(and as you note, if you make "profit" the metric, that has its own set of challenges - e.g. the optimization towards short-term profit in detriment of the long-term sanity, which is what we observe in a lot of corporations).

[dfabulich]

I recommend measuring job satisfaction instead of developer productivity. It's the "least bad" proxy metric I know of. https://redfin.engineering/measure-job-satisfaction-instead-...

[musicale]

The interesting corollary to this approach seems to be that productivity barriers are largely external.

A potential riske seems to be feedback systems where job satisfaction is determined by high or low pay.

[eacapeisfutuile]

As already mentioned, people measure value return by revenue gain. It is irrelevant to attribute it to some construct like a line of code.

[nemomarx]

profit generated I think is the high level one, and then you want to dig from there into how much the software development contributed to this.

[nomel]

That's very tricky thing to quantify, especially with "unsung heroes". If my work is in preventing problems, the guy that fixes problems will be seen as the one that contributes more to profit, since impact is directly observed/measured.

This is something that one of the orgs I worked for eventually realized. The people f'ing up, and then fixing their mistakes, were the ones getting promotions/bonuses/raises, because they were the ones interacting with all the execs.

[foobiekr]

Revenue per employee $ spent.