> Apparently they had so many problems with remote employees (and their managers!) barely getting any work done

This was most likely also happening in the office, it was just masked with the appearance of work in the form of in-person meetings and people zoning out at their desks. When you have a bunch of people in a room together progress grinds to a halt because it becomes completely about performance.

> This was most likely also happening in the office

Not in this case. They even had a chart showing the sharp decline in several different metrics when they let people go remote.

If you subtracted out the outliers, most of the company was fine going remote. About 20% of people dropped their productivity to a fraction of before, though.

Some people can't handle remote work. I think it's time we stopped pretending like everyone handles remote work just fine. That lie is making it harder to get companies to admit that they need to differentiate between employees who can and cannot successfully work remote.

Unfortunately, rapidly falling metrics for a minority of remote employees is immediately obvious. The reduction in burnout of top performers due to working remote is much harder to measure since it is in an entirely different frequency domain.

Why would in-office work lead to more burnout, as opposed to remote work? I’m thinking that remote work would be much more conducive to burnout - nothing to stop you working too long, no segregation between work environment and home…

How were they measuring productivity per employee? I see that bandied about for a lot of RTO arguments, but it's extremely hard if not impossible to do, so it's important to talk about the methodology driving the decision making.

> How were they measuring productivity per employee?

Productivity was ultimately measured by talking to the people and asking what they've been working on, what the challenges were, and why it was taking so long. When we'd talk to some of these people, they could barely come up with a story for what they had been doing all week.

The metrics were used as an indicator of where to investigate, not as an ultimate measure of productivity. The key metrics were actually entirely in control of the teams themselves: We would estimate our own story points and could even close our own tickets as completed if we wanted.

When some employees go from doing 20-25 story points per week down to 3-5 and the only change was that they started working remotely, something is wrong.

Remember, these were people rating their own story points!

IMO, they could have gamed the system if they wanted to by inflating story points and churning tickets (though this would only delay their managers catching on, not avoid it). These people weren't even doing that. They just... stopped working more than a couple hours per week and assumed nobody would notice.

I know this cuts against the Reddit, Twitter, and Hacker News narrative that everyone is more productive remote, but I watched it happen in real time. It wasn't just a few people, it was a significant number of people who couldn't handle it.

Not everyone can handle remote and the number of people in this category is a lot higher than the internet suggests. I don't know why that's controversial for some people.

"Story points" are exactly the kind of theater that is enabled when working in-person. Every in-person office I've worked at has been addicted to planning and estimating, because being in a meeting looks like work and is less stressful than pretending to work at your desk. It's an environment not conducive to actually shipping things that impact business success.

Was your profit negatively impacted? Because if it wasn't and people shipped less story points, it should tell you that metric has no value.

Managing Jira and tasking out stories and estimating story points drives me insane and I swear sometimes it's like 75% of my day. Everyone loves to brag about how "agile" we are but we'll spend like an hour discussing how we're going to do a task that will be 2 minutes of work.

And then non-developers are shocked/confused when things don't pan out as exactly how they were written on Jira because we were spending all our time trying to guess our way through how to task things out and how long they'll take instead of just doing the work to figure out what needs to be done. And then we have to go back and fix up the Jira board later, causing even more work. It's insane.

>because being in a meeting looks like work and is less stressful than pretending to work at your desk

Right, and who knows if their metrics were actually measuring meaningful work? If they are measuring in-office rituals like this that changed during the remote transition but they ultimately didn't lead to more tangible work being completed, then their metrics are worthless.

Story points must be calibrated by the team for themselves which seems to be the case based on statements from the original poster. If the velocity goes down, the team is getting less work done.

Using profit to measure developer productivity on the other hand is utter nonsense; not even the most clueless manager would come up with such an idea.

Then you fire those people. You don't punish everyone else for a few people who are dead weight

I found my current employer prior to COVID, and they had been almost exclusively remote since their inception in the early aughts. Companies with remote-first culture that predate COVID are far better equipped for the cons regarding remote work (IMO), of which there are plenty.

Remote work was far less common pre Covid though. And its not like it was leas desirable.

> Remote work was far less common pre Covid though.

That was my point: Remote work was a unique benefit given to those who could handle it.

During COVID everyone started pretending that remote work was for everyone. Companies shifted a lot of people remote and then learned the hard way that many people can't be productive remote.

Now the pendulum swings back, with companies pretending that nobody can work remote because they let the bad apples spoil the whole batch.