Hacker News Reader

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.

:mic-drop: This comment is pure gold.

This matches my experience as well: Measurably reduced velocity, noticeably higher rates of rejected PRs and broken builds, and a palpable worsening of productivity and team happiness.

The strangest part is that if you asked individual developers, they would insist that WFH made them more productive and increased their efficiency. Yet managers and the data universally agreed that the opposite was true.

There’s something about WFH that puts distance between individuals and the overall big picture reality in a way that makes these overall issues difficult to see from individual perspectives. It also slowed and dampened all of the feedback loops, giving people the wrong impression that they were working on the right thing or producing proper results until much later. We tried compensating with even more manager effort and over-the-top communication repetition to try to keep everyone informed but it didn’t really help.

There were a few exceptions of people who had identical levels of performance during WFH, but they generally achieved it with significantly more work and proactive communication. Those who struggled the most were juniors who felt like they fell through the cracks.

It’s a difficult topic to discuss on HN because few of us like to admit that WFH is, on average, a struggle for companies. No one likes the idea that WFH comes at a cost.

This comment thread is one of the most interesting I've read in a long time.

My prior bias leans toward thinking WFH is not so bad for productivity, but I think you raise a really important point that I agree with:

Developers tend to focus on individual productivity at the expense of organisational productivity.

The latter is what actually matters, and that could very well necessitate slower individual pace, more checkins with other teams, project leads changing their mind more frequently, and so on.

Interesting point about what developers prefer vs. what the data shows. Developers also prefer command-line tools even though data indicates that GUIs are more productive.

>GUIs are more productive

From my first hand experience this generalization is wrong as it comes down to each individual developer.

We have highly skilled developers using vim and editing code very fast as well as other skilled developers using VS Code of Eclipse as plain text editors. Less skilled developers usually think that text editors like vim improve their quality/speed because the very skilled developers use them whereas they‘re usually lacking knowledge for concepts and the language. This leads to a double slowdown from less skilled developers struggling now with their editor and the work they‘re supposed to do.

It usually comes down to what each individual developer is comfortable with compared to what they think they should be using regardless if text or GUI based.

> It’s a difficult topic to discuss on HN because few of us like to admit that WFH is, on average, a struggle for companies.

These are all very contradictory hypotheses from presumed earlier assertions. I strongly suspect we're not analyzing the dynamics and variables at a sufficiently granular level to synthesize any useful hypotheses. I'm trying to reconcile a set of earlier assertions out of global corporate postures from these recent pronouncements that Covid-WFH (as opposed to true-WFH) leads to productivity declines.

If WFH is an intractable hit to productivity due to lack of butts in seats, then what is the salient difference from outsourcing / offshoring? If the productivity loss of the latter is simply more acceptable due to a cost differential, then we have thus established a clearing price for that productivity loss. Or are the positions not sufficiently similar to draw that parallel?

If so much fortuitous collaboration happens when on-prem that it becomes a compelling cited factor to go on-prem, then are we making the parallel assertion all the effort for planning is not capturing even a significant fraction of this fortuitous dynamic, much of our planning is compellingly guided by Organizational Physical Brownian Motion?

I don't have a strong preference either way. Pay me enough, I'll show up and do the work. But I cut my teeth in a consulting / professional services context where the WFH discussion was very different: pay a premium (weekly round-trip flights) to put butts in on-prem seats, or less for WFH-delivered skills.

From well over a hundred client engagements by now, my personal opinion is there is no one-size-fits-all unless leadership explicitly builds the organization for it. There are definitely different workers who thrive under the different models, and those who under-deliver and abuse their working conditions. It's an incredibly tough leadership decision. I think much of that decision hinges upon how well the organization is led and coordinated. I have observed from my set of clients that WFH done well requires disciplined teams who produce more communications artifacts internally and externally with other teams, and this longer-term tends to encourage more organizational flexibility (because the published information decouples from people and disseminates deeper and faster). For various reasons, on-prem tends to lead to an over-reliance upon verbal, tribal communication modalities in most organizations.

> However, it's clear to me and the other execs that WFH absolutely does not work for us.

The "for us" part is refreshing humble for HN comments; thank you for the details of your experience.

I spent about 10 years working on the campus of a very large tech company, and then another 10+ years working for different remote development teams. The remote teams that I have managed were in teams that were built from the ground up to be remote, generally in companies built from the ground up to be remote. And when I say "remote" I really mean "distributed." Hiring the people with the best skills and letting them work from wherever they happen to live rather than relocating them.

I assume in your study that you divided TEAMS into WFM or office based, and did not have teams comprised of some people working remotes and some in the office?

I think that some people are wired to work effectively in distributed teams, some are not. Some managers have the "online social intelligence" to lead distributed teams, some do not. Taking a group of people attracted to working in an office or a high tech campus, and having them "work from home" while the rest of the company is still based in the office does not seem likely to work, though I am surprised by the starkness of your findings.

This is really interesting!

Do you know anything about the tools/methodologies of the teams that went part WFH and the adjustments they made when changing up their workstyle?

For example, do you know things like whether meetings were held at their previously scheduled times, vs. whether people started shifting them around to "meet when we're all here", or whether conversations and decisions were pushed organizationally to be more public, visible, and documented, vs made by whoever was in the office, because they could have a hallway chat?

Anecdotally, a friend of mine works at a "remote-first" company, where even when the whole team is in the office, they'll typically meet through zoom/hangouts at their desks, and I have other friends who are "the remote person" on an in-office team. There's a huge gap in the experiences of those two, which is why I ask about those kind of factors in your experience.

My company (listed in the LSE) started measuring WFH productivity as soon as Covid started. The unstated objective was to demonstrate WFH reduced productivity, to have an argument to force everybody to go back to the office once the pandemic ended. Metrics were devised by the senior leadership team to serve their purpose. We (dev managers) were tasked with collecting these metrics. After 4-5 months all metrics improved across all teams, so the senior leadership team decided to change them. These new metrics improved as well, so the project was stopped and data was destroyed (lest ICs would find out and have arguments to WFH after the pandemic). Now they’ve started talking about our great office in city center, about the gym, the gaming room, the Friday drinks, the office vibe.

Hard truth coming in: The reason it doesn't work for your company is simply poor management (don't take it personally). What you actually measured is the ability of yourself and the rest of your managers to lead your teams in a situation when actual leadership is required.

You see most "managers" aren't really managing anything. "Coordinating" might be a better word. The problem is that coordinating is really just "managing without leadership", and in a WFH environment coordination alone isn't enough. You need people driving your teams, not sitting shotgun with the map reading off directions.

I think the most revealing question is a simple one: What metrics did you come up with to measure the productivity of your managers (and yourself) during this time? None? Of course not... You've probably heard the phrase that "managers are force-multipliers!". Does that apply when the multiplier is less than 1?

I am not disputing your results or even your conclusion, but it's important to know why you got the results you did. And even more important is accurately identifying the appropriate policy going forward: With your current management team you cannot continue with a WFH policy.

It is odd that no one attempted to improve the situation when the metrics started to decline for the WFH group. The only way I could see this happening if the metrics didn't have much correlation with actual results. Presumably this is a real business after all and actual results matter.

Personally I am a little skeptical however since everything sounds so contrived.

Does your company help make remote work easier? I guess I could understand that if you took a group used to an office and then forced them to be remote there would be some struggles. I think effective remote work has a bit of a learning curve and needs some investment up front. I think you would need to believe the potential is there and worth chasing.

> and it seemed like WFH devs were spending 15-30% more time in non-development tasks

Why did it seem like this and how was it measured?

Would make a great write up. Interested in the details around what was changed in the company to support this hybrid approach. Also breakdown of devs first time WFH.

From my experience, office->hybrid doesn’t work well as the the staff don’t have the same level of support and processes don’t change to adjust to the change. My first year of WFH (nearly 7 years ago now) was a pretty rough adjustment even though I wanted to do it (glad I stuck with it).

Like most things in life, “Is WFH is more productive?”, “it depends”. Props for doing the experiment and sharing details.

What happened during covid? I assume for sometime you all went remote. Was there a difference in productivity between teams? Did the team with wfh experience lag behind?

Can you describe the kind of work?

This is exactly the experience we are having, especially on new projects.

I’m starting to wonder if this is a high/low tech issue - maybe WFH works great for tasks that are common but not particularly challenging technically. I can tell you point blank that ASIC, systems, etc. work WFH is super broken when people can’t get face to face on a whiteboard or otherwise.

The way that your particular study was conducted might be interesting from a study standpoint but it doesn't match the typically accepted ways of doing agile development. For instance if you were studying metrics but not releasing those metrics immediately back to the Developers then there is no opportunity for them to improve from a feedback loop. This seems like a strong invalidation of the study itself.

Interesting data driven approach to the problem. Would you be available to share more details about aggregate outcomes in private? Curious if you were able to slice out common patterns.