Hacker News Reader

Comment by holidayacct | Hacker News Reader

Never believe stories like this, measuring productivity is an impossible problem. Microsoft spend something in excess of 3 billion dollars trying to quantify productivity in the 90s and they couldn't do it. One of my college professors worked on this exact problem for the Army in the 80s, they created a formal domain specific language for quantifying employee productivity it took them 20 years and several hundred million dollars before they finally realized it wasn't generalizable. They had to scrap the entire project.

It isnt possible to measure employee productivity because its impossible to properly quantify the relative importance of a task. Properly scoping problems is a massive task and finally its impossible to adjust for employees gaming the system, collusion or simply malicious behavior.

Employees always figure out how to abuse productivity metrics.

View on HN

> Never believe stories like this, measuring productivity is an impossible problem

I want to start off by saying that I don't completely disagree with you, but all of us should take a step back and realize how an absurd of a position this is for us to be in a society.

This immeasurability is inversely proportional to the tangible, real value created. You can, for example, absolutely measure to the dollar the productivity of a plumber and you can easily compare two different plumbers, and see if environmental factors improve or decrease their productivity.

If you own a factory making screws you can unquestionably measure the valued added and therefor productivity of each and every employee. If you have a farm and you hire seasonal laborers to help you harvest, again you can easily measure the exact productivity of each worker, determine if a hot day makes them less productive etc.

Software engineers are a step removed from this in part because the things we make are of questionable value (especially in the extremes). Front-end contract engineers certainly seem to have measurable productivity. If someone can build you a working store front in 40 hours, you can compare this to another one how can do a worse job in 100 hours at the same rate.

But as software products grow more complex and the actual value more vague, then software engineer productivity likewise gets harder and harder to measure. And I think a real question every engineer who has worked at a large company has asked, even if they work their asses off, is "do I really create any value?"

Software engineers, again, are still closer to the side that you can measure real productivity because in at least most cases software itself is important. When you move on to other "office workers", those who are really struggling now, that value again is very hard to measure and therefore so is productivity.

The question that we need to ask more often is, if productivity is so hard to measure, maybe it is possibly because we might not be creating as much value as we have largely tricked ourselves into believing we have.

>The question that we need to ask more often is, if productivity is so hard to measure, maybe it is possibly because we might not be creating as much value as we have largely tricked ourselves into believing we have.

at a very low level productivity is hard to measure because it's tacit and implicit rather than explicit. The reason why we can measure the productivity of a business is because it responds to price signals and you can put a literal number on what they put out.

You can try running some sort of market scheme within your company but at some point the trade-offs are bad and it adds too much complexity and creates strange incentives.

For software in particular if anything the opposite of your assumption is likely true. It adds a lot of value without necessarily being able to put a price tag on it. It's pretty hard to measure what wikipedia or vim is worth in terms of productivity as long as they're not charging, but that doesn't mean it's not worth anything.

This. The productivity of a business is its ROI, roughly its profit + reinvestment. The productivity of a salesperson is also easy to measure: sales / compensation and travel costs. It's much harder to measure the productivity of an individual employee who is not a salesperson or directly supporting sales. Some are rockstars, and these you know when you see them. But the rest... it's harder to tell. Metrics can only do so much, and often they are easily gamed -- they just aren't directly related to the bottom line because these aren't salespeople, but you can't only have salespeople either. Take sprints: if you really want employees to hit every sprint then they'll work hard to hardly load their sprints. As you say, there isn't really a market inside a business, so it's hard to just look at the "bottom-line" for every non-sales force employee.

> The productivity of a salesperson is also easy to measure: sales / compensation and travel costs.

It's not that simple, because most companies don't perform inter-departmental cost accounting. A salesperson might seem to be very productive, while actually selling made-up solutions that are very cost-intensive to implement. To get a real number on how productive they are, you would need to measure:

([sum of sales * price] - [sum of solutions sold * implementation cost]) / compensation

or even:

customer price * weighted average of per-deal profit margin / total compensation

The cost to implement isn't added value. This kind of internal debiting would also change how management looks at IT. If they can solve the problem for less than the estimated cost by the salesperson, they're turning a profit. If they're taking longer due to "science fiction" products being sold, the blame lies squarely with sales. As it is now, salespeople are mainly incentivised for units sold and total price for deals made. You can be a rockstar salesperson while simultaneously mainly causing huge problems downstream.

> But as software products grow more complex and the actual value more vague

most popular software tend to decrease in quality with time... engineers are just looking for something to do and add stuff that can sometime be of negative value

> You can, for example, absolutely measure to the dollar the productivity of a plumber and you can easily compare two different plumbers

I'm curious about this idea.

What if plumber A shows up, quickly fixes something using existing, on-site materials, and ends up charging much less (no parts + 'quick' labor), and then the plumbing breaks again in X months.

What if plumber B shows up, takes more time and replaces a part of the plumbing, and ends up charging more (part(s) + more labor) but then the plumbing lasts for Y months, where Y >> X?

Which plumber is more productive? How does one convert the productivity to dollars?

Productivity in this case is fairly simple to calculate = Cost/Duration.

You can factor in the time (presumably that’s paid for so you should have a real number) and cost of materials (On-site use historical or replacement cost) yourself.

Your points holds more generally though, especially when there aren’t clear prices paid.

That isn't productivity, productivity is value/duration.

You're absolutely right, but in "Agile" teams this is exactly how they measure productivity: story points (cost)/sprint (duration)

And that is exactly why management shouldn't be looking at or comparing burndown charts. It's too tempting to see IT as a cost centre instead of an enabler.

Define value. Now that's a rabbit hole. Marxist definition? Ricardian?

Doesn’t happen to the same degree as in software. With plumbing or painting, yes there are good jobs and bad jobs, but if the water gets to where it’s going and there’s no moisture, you’re pretty much done. If the paint is on the wall and not on the ceiling or the trim, and you can’t see roller marks, it’s a good job. With software, there seem to be endless layers of nuance between good or bad, finished or unfinished.

Also, it should take X hours to paint a room of Y size with this many windows or doors. There are clearly established timelines for a job and any big deviation from that will get you fired (or not hired again by the same builder). There’s no “due to this manager’s lack of experience with agile, a project that should have taken 2 weeks took 4 and a half months, and the test coverage is poor”.

Doesn’t happen to the same degree as in plumbing. With front end or back end, yes there are good jobs and bad jobs, but if the data gets to where it’s going and there’s no bit rot, you’re pretty much done. If the data is in the db and not on the paper forms, and you can’t see it decrypted at rest, it’s a good job. With plumbing, there seem to be endless layers of nuance between good or bad, finished or unfinished.

Also, it should take X hours to code a feature of Y size with this many fields or inputs. There are unclearly established timelines for a job and any big deviation from that will get you fired (or not hired again by the same builder). There’s no “due to this plumber’s lack of sobriety with the world, a project that should have taken 2 weeks took 4 and a half months, and the connections on the joints are poor”.

It doesn't happen as much in plumbing or painting because these fields have not had rapid change in the last few decades, so common practices have stabilized. Plumbing also has standardized code and inspections which pretty much make sure that everyone is doing the same thing the same way. And still there are differences in quality. Look at what two painters will do to a piece of shitty material like an oil-painted unprimed piece of plywood. One will sand it down to the wood and prime, the other will just slap a coat on top, and you'll have flaking in a few months.

That is another distinction. All the example jobs do routine, repeatable things. Everything a programmer does is either novel or trivially replicable. There is no equivalent to "painting a room of certain size", to do that you use a copy of already existing painted room.

With all due respect, you probably know more about software than plumbing, maybe leading you to simplify a bit. Because the same logic could be applied to plumbing, but any plumber might see more variables, the way you do with software.

Quality is the conformance to requirements. If you (the client) wanted a quick and cheap solution then A is for you. If you wanted a robust and you are willing to pay the premium to get the B, you're in luck!

Mega big banks in the USA suffer from tech debt A LOT. The number one reason for operation disruptions is software errors, and with a large difference to reasons 2-3-4.

An additional point could be that large USA banks have a higher (imho) ratio of sociopaths in their ranks. Perhaps the sociopaths lost the ability to whip their minions, and the minions started working under normal/human speeds 40h a week instead of 60-70h per week that is the typical expected work while under the influence of a sociopathic boss.

Also lets not forget that JP Morgan CEO is THIS guy: https://www.theguardian.com/us-news/video/2019/apr/11/jp-mor...

I think that, although imperfect metric, the bottom line will speak of performance. I take it that there are multiple criteria that affect the bottom line, but the management of JPM cannot be trusted, again, sorry for repeating, is not the most decent in the planet.

Edit: apologies for the rant-y beat down of the mega-big US banks, but yeah.. not sorry really.

One thing that has stuck with the after many years of working with IT is that the big projects with resources to spare, the few that really gives you time to do the work properly for once, are often the one that ends up with the most tech debt.

It is completely contrary to my own feeling that debt is created by external pressure to deliver too fast. I can see why that would create perverse incentives should a project manager make a similar observation.

Great art breaks constraints, but there is this symbiotic relationship where art is nothing without constraints. I'm starting to think there are similarities with other creative endeavours too, which I absolutely consider programming to be.

Not sure where I wanted to go with this, just reflecting on your rant with one of my own.

What I’ve found over the last 20 years: Tech debt scales with amount of code written, regardless of other factors.

If you write the minimum amount to validate the business need, you have minimum debt. :)

You are conflating very different issues. So yes, it does come across as a rant.

My perspective, as someone who worked for JPMorgan in technology for 8 years, and for several other banks, is that JPMorgan is way above most other banks in the quality of their systems and their dev teams.

Likewise the top management. Jamie Dimon is very impressive. You don't get to stay CEO of a bank with 250,000 employees for more than 20 years without being seriously good at it, very consistently.

Whichever one earns more dollars is more productive in terms of dollars. If you want to do this right, pick a good metric (plumber dollars is fine), then optimize your workforce for that metric. Do not reward them for that metric or it will be gamed. Consider other metrics that are important (e.g. customer satisfaction) and set constraints on the processes that set a standard that must be met.

Not objective, not right 100% of the time, but let's not pretend its impossible to improve processes with some sort of goal in mind.

> This immeasurability is inversely proportional to the tangible, real value created.

I don't think that's true at all. Certain kinds of value are more easily measured, sure, and if that's all you mean by tangibility, what you say is a rather trivial tautology, but there's times when the value is real and tangible and easily qualitatively described (e.g., reduced workload), but tricky to measure because to accurately measure the increase you'd have to measure against a set of hypotheticals (e.g., cost/performance using best alternative of continuing with the status quo ante or competing automation options, including alternative custom builds.) For certain types of value, this is irreducibly true for many of the same reasons intellectual work is well established to be difficult to estimate accurately (this actually converges to an identical reason when what you are doing is building automation to support intellectual work.)

And even when productivity is measurable, it's often not easily measured at the time of delivery ; where the problem is measuring hypotheticals but the only problematic hypothetical is performance with the software, it may take considerable real use before the actual value is clear.

But, it also can be unclear the value of any individual contribution even when the aggregate product value is clear. Telling the value of what the team delivered is different than trying to peel out the value Bob created.

"This immeasurability is inversely proportional to the tangible, real value created".

Although I understand your view,Financial sector and banks in particular is a very regulated sector which means that significant number of people working there have their job almost entirely related to making sure the company comply with the rules from the different jurisdictions. From your perspective, they do add no value to the company ( actually there are cost center) but are crucial to ensure company can operate legally. To add an additional layer of complexity, new rules from different countries, authorities, committees are updated/ amended quite regularly ( last one is the LIBOR demise which will have a huge impact on the market where no clear rules,have acknowledged nor agreed). So even you would try to quantify those costs ( legal issue with new rules implementation which lead to update the system or create one from scratch while making sure this will comply with internal task,etc...), it is quite difficult to assess what is the optimal allocation the company needs to allocate. As an illustrative example, it took 2 years to validate some components of the google cloud features (some are still pending) because of all the intetnal rules set out.

More globally, yes there are people adding no value to the company but the can be hardly spot on from top management view.

There is a big problem in knowing when to measure and what to measure. For example, today my work looks to have similar value to the work of my dog Mr. Biscuits, yet I cost 10x. However, move to tomorrow and it turns out that Mr. Biscuits' code has locked up the cluster and Q3 results are gone. Suddenly I look cheap (I am cheap, but that's a different thing).

Also there is zero agreement on what is good; maintainability, robustness, ease of use -> all subjective at the minute.

Incorrect. A plumber can spend 10 minutes to fix a leak, but the same plumber can spend 4 hours on apparently the same leak but a slightly trickier one. The same for farm - how much of the output depends on workers and how much on the environment and other factors?

This misses the mark by quite a large margin. It's hard to measure the "productivity" of an individual who worked on the polio vaccine, that doesn't mean that it was a worthless product.

The fact that productivity is hard to measure has very little to do with the value of that work, but rather the difficulty of drawing boundaries around people, objects, and time in the functioning of a complex product.

You cannot measure the value of a software engineer without assessing how their work impacted the work of other people, whether it needed refactoring in the future, whether it took into account future requirements that wouldn't be known for five years, etc. You can't even do that with plumbers! One plumber's work may fail in 10 years while the other's is going strong 20 years later, and you may have thought the first one was more "productive."

Another complexity with measuring software productivity is the value of reliability and maintainability which can take years to manifest. Also there is the multiplier effect of having a team player who brings up the whole team’s productivity but might not be obviously measurable.

The real problem isn't measuring the productivity of doing work in its entirety. Installing plumbing is a job. Since only one person is doing the plumbing and that person only does plumbing you can measure the productivity of that job and attribute it directly to a single person.

Once you have a group of people all working together on the same job or the inverse where you have a single person do a variety of jobs everything is different.

You split the big job into smaller jobs and distribute them to people. Some jobs are easier and bring in more money and therefore are more "productive" than others. But all jobs have to be done, no matter how productive they are. So you end up handing easy and difficult work to people. When you start to measure individual productivity of each team member you start noticing that there is a huge variance in productivity. Some people are "useless" while others are highly productive. When you remove the "least productive" people from the job then you notice something odd. Suddenly the productivity of everyone else goes down as well. Your productivity measurements were actually just measuring the way you distributed the jobs.

I remember a machinist talking about how he spends all his day fixing his coworkers mistakes. They kept breaking $100 tools (tool as in endmills) which jammed the machines and he's the only one who did the thankless job of making the machines usable again. He made fixtures that his coworkers broke and then he made them again.... Oh and he had a quota of how many parts he has to make per day. After all, measuring the productivity of a machinist should be pretty easy. Just count how many parts he makes per day. Of course the coworkers always exceeded the quota while he was always well below the quota.

So you actually believe that if we imagine two plumbers A and B doing exactly the same jobs at exactly the same speed, A charging 70$ an hour and B 35$, A is twice as productive as B ?

It's in line with GDP based reasoning but that's generally done on aggregated data which tend to smooth out these kinds of oddities. As a direct comparaison, it is probably at odd with what most people envision when they think of productivity.

Great background info; it reminds me--albeit on a greater scale--of an earlier HN thread to the effect of "how hard could possibly be to show street names on maps at with globally correct-seeming detail at arbitrary zoom level," which does sound kind of simple, if you've never tried to do it for real, but which has frustrated many smart people for a long time.

At Sun we experienced a new metrics fad every other year. Once they tried to use bug report clearance rate, so a friend said "I'm going to code myself a minivan" at a meeting. That metric didn't last.

You have to have a great deal of sympathy for the management of software-heavy companies. They've no idea how to manage software development. Nobody really knows how to. It sucks. Oh, well, I suppose there is a way: mind the bottom line, do not over-hire, and have good managers of the old sort: the type that know how to keep tabs on their direct reports without being overbearing. Business schools won't go for that.

Dilbert had this punchline in 1995: https://dilbert.com/strip/1995-11-13

It's possible one of Scott Adams's moles was at this meeting, since they seem to be omnipresent and omniscient.

Ahhh, I'd missed that. Thanks for setting me straight!

Goodhart's Law in action: "When a measure becomes a target, it ceases to be a good measure.”

https://en.m.wikipedia.org/wiki/Goodhart%27s_law

This sounds true and I've seen it in action. But I always wonder about the implications.

Must we keep our most important measures target free? That sounds insane, although I can see how it would improve the measurement.

So the questions is how are we supposed to set targets without our most important measures?

> "I'm going to code myself a minivan"

Could you explain this term? I thought i was a native English speaker but this has lost me.

"I'm going to get myself a large bonus by clearing many bugs".

The Dilbert strip has the additional suggestion that the programmer could introduce bugs in order to clear them, in an example of the Cobra Effect.

Or the AI vaccuum cleaner problem. If the target is to scrape maximum amount of dust then it would clean-dump-clean to maximize efficiency.

On the other hand, everyone in the office knows who the productive and unproductive people are.

It's also true that many people have a very different assessment of their productivity than their colleagues do of them. I've seen some pretty massive disconnects there, which usually lead to trouble.

> Never believe stories like this, measuring productivity is an impossible problem.

While I do agree that many productivity metrics are useless and even counterproductive, measuring productivity in a useful way is most certainly possible. For example, sales organizations measure sales per unit time for each sales person. I doubt you will find a successful sales organization not doing this.

Even then, what if one salesperson builds up better longer term relationships (e.g. by not pushing options the customer doesn't really need) and thus their future sales will be better but their initial productivity looks poor?

Or a team player who is good at opening conversations but not closing? (I know, always be closing)

But yes, with a quantifiable and accurate and business-orientated metric, you can measure some form of productivity. It is still hard for most roles in most organisations.

Modifying a now trite-but-true saying from the statistical modeling world: “All productivity metrics are wrong, but some are useful.” I imagine there will always be an infinite number of ways an employee could add value that would be inadequately reflected in any finite collection of metrics, but that does not eliminate the usefulness of good metrics. Managerial judgement is always needed to account for exceptions that require accommodation.

Metrics will never be perfect, they are an approximation of the real world. And some things are unknowable. Maybe a customer goes bankrupt 3 months into a project and you never collect the full revenue. One metric shows that a salesperson closed that deal and another metric shows that his revenue per customer isn't good.

A successful team structure will make it difficult to measure individual productivity because team members spend some time on shared team priorities rather than just individual priorities.

I enjoy team work and I push hard against managers focusing on individual performance metrics because it destroys team work.

We can't measure productivity of creative workers to the cent, but we of course can use various proxies to assess the productivity. This often can lead to unwanted outcomes (like Uber's criteria of being innovative led to microservices hell), but in general you can't dismiss those proxy measurements as totally irrelevant.

I don't agree that measuring productivity is impossible. It's obviously possible for some roles, especially sales, which seems to be the focus here. That said, it's dubious whether or not they've got anything real here. They say productivity fell, especially on monday and friday. Probably implies they're looking at:

* Login time on the VPN

* Number of meetings or some other proxy for activity

* Sales numbers

The first one might be right. People might be spending less time working, when working remotely. The mistake is in assuming that they would be contributing any sort of value if they were in the office and logged in 100% of the time.

The second one might be right too, but again, may not correspond to anything

The third one, if true, probably has less to do with the productivity of the workers and more to do with the economic situation.

But who knows? They may have something real.

> Never believe stories like this, measuring productivity is an impossible problem.

I totally disagree. That's the whole point of your manager and reviews.

In addition, JPMorgan isn't just programmers. It's a lot of people who talk to people and process paper--a LOT of paper. And they can quite clearly measure how much paper is being processed per person.

> Employees always figure out how to abuse productivity metrics.

That's a different problem from being able to see that productivity is up or down.

Now, the larger question is whether productivity is down because of work-from-home or productivity is down because the economy is in a complete shambles.

Working somewhere where it's thought that 'whole point of my manager' is measuring my productivity sounds like a real nightmare.

The review process is a complete sham. If you honestly believe it’s a measure of your productivity and not a post-hoc rationalization based on a restricted promo and bonus pool I have a bridge to sell you.

Most managers will think an employee who spends 10 hours working and 30 hours schmoozing/promoting their work is more productive than someone who spends 60 hours grinding the tasks given to them.

It's smart for an employee to let the manager know what he's been doing. It's just like a business has to do some promotion or the business will fail - even great products don't sell themselves.

> The review process is a complete sham.

It's a complete sham--up until the moment it's about to fire you.

Yeah, I've been in the "Look, that deadline is HARD. If you don't figure out how to do something useful by it, the whole GROUP, including me and you, are fired. So, are you gonna figure something out or should I fire you now and get someone else?"

That can wake you up, reeeaaaal quick.

> Most managers will think an employee who spends 10 hours working and 30 hours schmoozing/promoting their work is more productive than someone who spends 60 hours grinding the tasks given to them.

And you know what? The "schmoozer" might actually be more productive.

One of the articles on HN recently was about how senior people tend to avoid work that might get thrown away.

"Grinders" are useful, but they can also go grinding in the wrong direction or keep grinding on something that no longer needs to be done because conditions changed and they aren't paying attention. This is especially true if they get too irascible so nobody wants to talk to them.

The "schmoozer" might see that the assignment given doesn't quite match up with what the end customer (either internal or external) actually needs and adjust things appropriately. Or, perhaps, just delivers something "close enough" but takes a lot less time and makes the recipient happier.

As I became increasingly senior I spent far more time "schmoozing" than getting concrete engineering done.

>"Look, that deadline is HARD. If you don't figure out how to do something useful by it, the whole GROUP, including me and you, are fired. So, are you gonna figure something out or should I fire you now and get someone else?"

The only sane reply is: "You can't fire me, I quit". First of all, this working env is toxic. I don't need this kind of stress and I can freely quit because I have life savings, like any other sane person. Second, now that deadline becomes impossible without me, not merely hard, good luck to the rest of the team. Third, I might not quit if you apologise right now.

But then again, I'm in Europe, where we have more rights than the Americans. YMMV.

Your narcissism is showing.

>That's the whole point of your manager and reviews...process paper--a LOT of paper. And they can quite clearly measure how much paper is being processed...the economy is in a complete shambles.

And in one HN comment the whole problem with late stage capitalism is laid bare.

It doesn't surprise me that your friend failed on this project but it isn't obvious a priori that measuring productivity is futile. But in my current job they're trying to create KPIs for us, so I've thought about this a bit and can certainly recognise the difficulty.

As an engineer in general how can you quantify the value of maintenance? On paper it's just a cost and it's impossible to know what would have happened without it.

The worst strategy is just to measure easy things like story points or number of tasks completed because it ruins the work culture. In those cases you're not going to take time to review pull requests carefully, advise colleagues, propose new projects or work on difficult tasks. It seems impossible to measure these, at least to me.

I would argue that measuring productivity is only possible if you’re trying to detect the lack of it. Ie it’s definitely possible to see if someone’s slacking behind the rest if whatever output they’re expected to create is way less than the average of all colleagues, but at some point you have to accept that the confidence intervals are pretty vague.

In a situation where workload is at least sort of randomly distributed, which it normally is given time, there’s no other good explanation for statistical deviancy than simply less “work” being done.

But again, this only works for detecting problems. As you point out, and I agree with you, as soon as you attempt to measure “change in productivity” you’re on very thin ice.

This is what makes me so uncomfortable with hiring software developers. I don’t know how good of a job they’re doing, or what’s taking them so long, or whether another group of developers would do a better job faster.

If I hire painters, I can tell if they’re doing a good job by looking at it. I know what’s taking them so long. They’re using slower drying drywall compound, or they’re having to mask off because they’re not good with a brush.

There are fields of work where it’s easy to gauge productivity, but software development is not one of them.

>> There are fields of work where it’s easy to gauge productivity, but software development is not one of them.

I manage a team of developers / analysts and it's straightforward (though not always easy) to measure this over several six-week blocks of time for the team. It is not, however, easy to measure it for any single developer or analyst, and there's a lot of variance when you try to look any more granular than the team.

I suspect it's doable for small groups that work together. Or even larger groups. (I have no experience here.)

But for individuals? I agree. No shot.

If I hire painters, I can tell if they’re doing a good job by looking at it.

It's easy to make a job look good for a day, but on some jobs if you skip the prep work, lining, filling, priming, undercoat, additional coats, clearcoat, and finishing the paint job is going to look pretty bad after a year. You can't tell how good a painter is unless you know a bit about painting things.

The same is true of software. In order to know if a developer is productive you really need to know quite a lot about the domain they're writing software for.

And if you were going to believe a company's metrics on productivity, JP Morgan is almost certainly not the place to start.

This is hyperbole. There are many ways to measure productivity depending on the task, and often you can simply ask managers who have a good feel for how much progress is being made. It may be that remoters are 'trying hard' but that the limitations of remote are not overcome, but this is still a lack of productivity.

Management is part of the social sciences, and there there was a big shift away from the quantitative methods (e.g. measuring productivity) towards qualitative methods, where one can better understand why managers are now saying that the productivity fell. And what is behind those reasons.

> Employees always figure out how to abuse productivity metrics.

Yes, and working from home makes it even easier. Your post basically says that any measured productivity gain from WFH can't be trusted but I don't understand why it would apply to a measured productivity decrease.

Just because it cannot be measured to a high precision does not mean it can't be measured. People clearly have some sense of when they are and aren't productive.

That doesn't necessarily mean it's quantifiable, rather than qualifiable.

A subjective sense that fails to account for the productivity of the organization over all or the productivity of the team they are in as a whole.

Quick correction, this problem is far from impossible. A multivariate model and about 5/10 years of data and you can easily get an answer to that.

That seems like way too strong a claim to make, since it would also mean that you can’t claim anyone is just as productive after going remote.

> Employees always figure out how to abuse productivity metrics.

Targets aren't the same things as measures. Measures of productivity are easy, but targets are not.

For example, for a sufficiently large group of people (e.g. all young developers at JP Morgan), you can measure their productivity with how many lines of code they write on average. As long as you aren't using lines of code for performance evaluation, there is no reason any developer will perform needless large refactors or find other means for increasing their delta.

Edit: changed metric to target

Yes, but that proves OP's point. If the productivity metric was equal to the measure of lines of code, then they would figure out that they can abuse the metric by artificially adjusting the output of the measurement.

Oops. I meant target rather than metric.

Lines of code on average is a terrible measure of productivity.

I’ve solved problems with 6 lines of code that took me a week to think of. Other days I write 600 lines of code.

I would argue that the former 6 lines I wrote is much more productive than the 600 lines.

For an individual, lines of code is a bad measure. Some problems are harder than other and some people do more design or leadership work. However, for the collective this all should average out.

No, the problem is that, in general, the more lines of code you have, the worse your program is. Perhaps people working at home feel less pressure to just code, and are thinking more about the problem and writing less code to solve the same problems - a massive win in productivity, which would appear as a loss by your measure.

On the other hand, perhaps people are indeed writing the same old code that they always were, just writing less of it.

So lines of code are not a good metric. Average number of features/user stories/tasks delivered may be a decent metric (at the group level, not for individual developers), as long as it doesn't become a target. Delivery VS estimate could also be OK, in the same way.

The top comment started off with the argument that you can't know the relative importance of the work. 6 lines of code can do a lot. 600 lines of code can do little. To measure productivity you have to measure how difficult the job is compare how valuable the job is. Most of the time both value and difficulty are unknown.

Across JP Morgan as a whole, the "relative importance of the work" isn't going to change significantly over time. It definitely has nothing to do with WFH. It's far more likely that a drop in LOC is caused by an increased difficulty of mentorship, slower time to resolve blockers, etc.

100% correct. If it were possible to measure productivity, the Soviet Union would have won the Cold War and cleaned the capitalists' clocks.

> Employees always figure out how to abuse productivity metrics.

If people can abuse your productivity metric, then it's a bad measure of productivity - not a fault of the worker.

Parent agrees, and further observes that all measures of productivity are "bad".

Parent does not agree, if parent agreed, then parent would not have used the word "abuse", which implies that the worker is the one at fault.

There are many nuances to the English language that are difficult for non-native speakers to pick up.

> There are many nuances to the English language that are difficult for non-native speakers to pick up.

Being condescending is bad, but being condescending whilst also being clearly wrong is doubly so. Get out.

English as first language speaker here. Your comment at the end was rude.

And I think you’re wrong. I think your parent post agrees with you. Not every conversation includes the requisite specificity of language to make declarations of perfect understanding of original writer’s intent.

We will need OP to confirm.

I think the parent comment reads like it was written by a native speaker.

I don't see how the term abuse means that the parent doesn't agree?

Is there a word for the pedantry of an uninformed idiot?

I nominate parent: "honeycombing".

Strongly disagree, by definition it's the abuse that compromises the metric not the abusability. The distinction is important because it means that with a large and rapid enough rotation of obfuscated targets you can find out what you need while mitigating the bulk of intentional metric abuse.

Reply on news.ycombinator.com