I don't buy it. I mean I trust you got the numbers on whatever metrics you thought you've measured, but I don't buy that this is a well designed human experime

I don't buy it. I mean I trust you got the numbers on whatever metrics you thought you've measured, but I don't buy that this is a well designed human experiment and your conclusions sufficiently exclude alternative explanations. First systemic bias in your study is that instrumentation of only IC productivity; if IC productivity could exist in isolation, we wouldn't need managerial functions to begin with. Alternative explanation; distributed work shifts some heavy lifting from the self-organization of ICs to managers actually doing successful multi-party coordination. Most managers suck, therefore they couldn't handle the true test of their function. But having exclusive access to $product-leads@ circle, they could shift blame. To add more; if productivity was that significantly low for some folks for 6-9 months, and your managers couldn't steer it, that points to a general leadership problem than an IC problem. Second problem is not having a logical continuity between your IC metrics and business metrics. Did 40% increase in PR rejection rate of half of your developers slowed down any of your business metrics by 20%? E.g release delays, post-release bug counts, decreased reliability etc. If not, then you weren't really measuring what you thought you were measuring. Alternative explanation; the seat warming, busy work pressure is higher when at the office in the physical presence of peers, which blows up the metrics without meaningful output; WFH makes it much more easy to cut through bullshit work, bullshit meetings etc. Until you can prove that the business output suffered proportionally, metrics like "WFH devs were spending 15-30% more time in non-development tasks" is meaningless. I am not even talking about how hard of a problem it is to really measure "time on dev-task". Sometimes taking a walk in the park to think through a problem is a dev task. To get a proper picture, you'd need to be able to reject the alternative hypotheses with a greater strength. I think you also need to seriously look into the manager metrics; e.g. how do devs rate them as being able to communicate external priorities and requirements successfully, how many of them think they are working on redundant or meaningless work, that their code complexity is slowing them down etc. Not only these organizational bugs are much more expensive than small-but-easy-to-measure stuff like PR rejection rates, it is also more likely to be in your blindspot because you only interact with managers.