[ejb999]

It is no surprise to me - I have been 100% remote my entire IT career (decades), almost always working with 100% onsite people.

With lots of newly-minted remote workers I have seen HUGE drops in accountability and performance, including many, many folks who just seem to 'disappear' for hours and days at a time, and nobody knows that they are doing.

Yes, you can be unproductive in the office - but the temptation and opportunities to do next to nothing on a daily basis are too big a temptation for many people, and becomes a nightmare for the people that are supposed to manage the slackers.

Some people are just as productive at home, some people are more productive, but in my experience, the number of people that have become unproductive outweighs the benefit of the relatively smaller number of people who either stay the same, or are more productive.

It's unfortunate, but if you have ever had to manage large numbers of people, you know not all folks will work just as hard when nobody is watching.

[codegeek]

The challenge with remote work is that it requires more discipline and the ones that can truly work remotely are totally worth it but it does attract bad apples who frankly won't do anything (they wouldn't be a good fit in office as well but it is a lot harder to hide in office)

In our team, we have some great remote workers but I had my share of some real bad ones including outright liars. I am very careful if hiring fully remote because frankly, it sets the barrier high and you need to demonstrate that you are dependable to do shit on your own. One person was most likely working 2 jobs concurrently even though I cannot prove it for sure. However, they did not deliver a single thing in 3 weeks and were hired as a senior 10+ PM. When asked why, I was told that I am "too much". Whenever we will message on slack asking a question, they would respond 10-15 mins later almost 90% of the time.

[znpy]

> Whenever we will message on slack asking a question, they would respond 10-15 mins later almost 90% of the time.

in fairness tough, i do that too sometimes, but it's because i'm in the middle of something and i don't want to lose the focus.

when i see the slack notification if it's not about an outage or something similar, i try to finish the thing i'm doing (or at least reach a state where i can commit to git) and then reply.

and by the way, remote work should exploit asynchronicity. forcing people to always reply within 15 seconds is going to burn them out (and would do the same in an office)

[nikonyrh]

"Whenever we will message on slack asking a question, they would respond 10-15 mins later almost 90% of the time."

I thought that was really good, I was expecting more like 30 - 60 min delay on average. That chat isn't real-time communication afterall, personally I have all notifications turned off.

Well for us it is very rare that your progress would be blocked by not having a question answered, that is why we (try to) have well-specified tasks and daily meetups in the morning.

[toomuchtodo]

I purposely respond with a delay (~15 min) to IM messages to not encourage the expectation that you’ll get an immediate response, otherwise I’ll never get anything done with constant interruptions. Boundaries are important, and when set, must be enforced.

Unless it’s an emergency, an IM doesn’t require an immediate response, and I'm unsure how anyone would get focus work done with an expectation of <5 minute responses to IMs consistently.

[BergTheBold]

My company has let at least a couple people go since the start of the pandemic - people who would just disappear for hours, would spend hours/days working with very little to show. I'm curious - do you think that time management is a learned skill? Is working from home biased towards people who are inherently better at managing time? When the pandemic started we had a drop off on productivity as a whole, but we've since improved and have reached levels at least equal to where they were 2 or 2.5 years ago.

[afarrell]

> Do you think time management is a learned skill?

Time management is mostly about emotion management. For example, procrastinating on asking for help overcoming a roadblock on is often a symptom of fear of appearing stupid or annoying. In-person interactions often help smooth over these sorts of problems. For example: If you are having lunch with someone, it is easier to trust him to be non-judgemental about you running into a package management error.

[tra3]

> people who would just disappear for hours, would spend hours/days working with very little to show.

Were they productive in the office? It feels like "being in the office" is a form of productivity. You didn't actually have to do very much as long you were visible.

[khyryk]

We went from people disappearing at Starbucks to people disappearing on Slack.

[ejb999]

I don't think it is just about time management - all skills can be learned - but sadly there are a non-trivial percent of people in any organization who will simply get away with anything they think they can.

These people, for the most part, aren't any better when forced to work onsite - but it is harder for them to hide from their managers and co-workers.

[codegeek]

Working remotely is not just about time management. It requires a level of discipline and most importantly, Integrity and Honesty. Unfortunately, some people take advantage of the situation and try to game it. I have hired many people over the years including remotely and I have some of our best employees that work remotely (I never worry about them) and some real bad apples who were outright liars and cheats.

[strikelaserclaw]

you sure they weren't working 2 jobs?

[ejb999]

I suspect several were.

[slavapestov]

> Yes, you can be unproductive in the office - but the temptation and opportunities to do next to nothing on a daily basis are too big a temptation for many people, and becomes a nightmare for the people that are supposed to manage the slackers.

It seems if you have a large number of employees who are unable or unwilling to do their job, asking everyone to work from the office isn't the optimal solution to the problem.

[ironmagma]

The work either gets done or it doesn't... how is this so hard for managers to observe?

[PragmaticPulp]

Manager of remote teams here.

Like any sane manager, I don’t pick an arbitrary bucket of tasks at the beginning of each week and declare “Finish these by Friday” and not care if it takes 10 or 100 hours.

Instead, we work with the team to do things like sprint planning with input from the team’s velocity. We target a reasonable workload assuming people are at their desks for a normal workday amount of time.

The problem is that for some people, individual velocity plummets when they go remote. Their estimates skyrocket because they either know their productivity is down or they think it will be easier to get away with if nobody can physically see them.

Obviously this doesn’t apply to everyone as I have some great remote teams, but I’ve also churned through some otherwise good engineers who were great in office but admitted that they just couldn’t focus at home.

Also, if you have anyone WFH with school age children then velocity drops come summer time like clockwork. We work around it and plan it in, but it’s another reminder that remote is hard for even the good remote workers.

Finally, not everyone’s work is 100% isolated and asynchronous. More often than not, people have to work together on things and be available to answer questions, fix things, or otherwise stay in the loop with updates. When people are disappearing for hours every day during the team’s core working time, this all gets slowed down immensely. I don’t care if two people who work together agree to work together at 3AM or noon, but the teams have to be present and available to cowork on things.

[ironmagma]

> I don’t pick an arbitrary bucket of tasks at the beginning of each week and declare “Finish these by Friday” and not care if it takes 10 or 100 hours.

I’d say that’s your first problem. Isn’t this the whole (popular) idea of creating a sprint, then not modifying the sprint as it’s ongoing?

> velocity drops come summer time like clockwork

I don’t see how this makes things harder to measure. The very statement of it implies you have measured it and know it to be true.

> Finally, not everyone’s work is 100% isolated and asynchronous

This is true of in-person work too. If anything, someone being at a desk means that the collaborative work is probably not getting done in that scenario.

[slavapestov]

> Also, if you have anyone WFH with school age children then velocity drops come summer time like clockwork.

Why?

[ejb999]

Use your imagination, maybe you can figure it out.

[muzani]

Real world example: iOS team has one guy who gets it done in a week. Android team has two guys who get the same work done in two weeks. All of them work remotely and are known gamers.

Is work getting done or isn't it? How do you tell?

[gregmac]

First off, don't judge on one task like that, there's just too many variables (for example: Maybe it's something built-in to iOS while Android requires writing a custom library or working around a broken API). Assuming this is a pattern, though, there's lots of ways to get more insight.

For example, next time, have the iOS guy work with the Android team, and vice-versa. It'll help cross-train and promote different ways of solving problems, but also give great insight into what's actually happening. This could just as easily apply to someone from the backend team or whatever.

Another way is daily standups. Is the Android team getting stuck on something for days a time? Are they constantly blocked by another team or bad process? Are they making progress on whatever tasks they are doing?

Looking at commit and PR history is another way to judge, provided it's someone who can code who's looking and judging. Is the amount of work accomplished for the velocity of check-ins reasonable? If people are consistently only doing a couple lines a day that's a good hint something's going on -- and is worth having a discussion about. I want to emphasize though this needs to be a pattern. Some of the hardest bugs I've fixed that have taken days to narrow down are basically a single-character change (< instead of <= for example).

Depending on the situation, it might be possible to get regular demos, eg: every few days. One way to do this is break down feature work into smaller iterative chunks/stories. Beware though, it's a thin line to becoming an obnoxious micro-manager.

[ironmagma]

Wait until one of them takes vacation, see if productivity gets cut in half. Alternatively, ask one of them if the other guy isn’t doing anything.

If you bring on a new teammate and they can do double the work of the other two, then you start asking questions.

Also, this is why managers need to be able to do work themselves. The amount of work a task is should not be a mystery, especially in retrospect.

[ejb999]

not all jobs are as simple as counting how many widgets did you make today.

[ironmagma]

Nevertheless, one does not get hired to sit there, they are hired to do a work. If a job’s output is totally unmeasurable/unobservable you probably shouldn’t have hired a person to produce that output.

[rapjr9]

Five years ago I worked on implementing a custom Bluetooth interface to act simultaneously as a Central and Peripheral for a smartwatch. The first several months of the work was spent reading the massive documentation and reading the driver source code and spec sheet and example programs from the chip vendor and getting the development environment set up. Some work has absolutely no real observable measurable output.

[ironmagma]

And the last several months? Hopefully you can see what I’m getting at. A job doesn’t exist if there is no observable output to it, at least not for long. Your manager would know if for those months you were supposed to be reading docs, that you were actually slacking off, because come time to implement the thing, you wouldn’t have been able to do it. Thus needing to spend another few months reading documentation, and there definitely is a cutoff point where if you have been reading documentation for many months and producing no output, you just get axed.

Incidentally, another reason for managers to be capable ICs. If your manager was getting frustrated with your speed at executing, he/she could always step in and “show you how it’s done,” or at least teach you about Bluetooth details themselves to spare you from having to spend time reading the docs.

Otherwise, they don’t really have a leg to stand on and it’s just shouting into the void like Vizzini yelling at his giant to climb up the cliffs faster.

[Xenoamorphous]

How has being remote in a non-remote first company affected your career?