[hermanradtke]

> I have witnessed a dev colleague who worked from home. They were unable to document and communicate, and it screwed everyone else.

How did working in an office improve the documentation abilities of this employee?

> doing all the tickets and all the new tickets that appeared because of how badly designed for purpose their solutions on the previous ticket were.

How did working in an office improve the design decisions of this employee?

[cauch]

There was a clear difference in output when the dev was WFH or RTO, so even if we cannot pinpoint the exact reason, the facts are just there.

But in fact, there are a bunch of elements that can explain why.

For example, when remote, pressing them to answer was impossible: you ask a precise question on Slack, 15 minutes later, they answer something vague or irrelevant, you refine and refocus the question, 30 minutes later, they repeat what they've said, you ask to have a call, they complain that there is too many calls. And if you try to profit from an existing meeting to go to the bottom of that, you just ruin the meeting. In the office, you confront them, show them on the screen exactly why their answer is not helping, and they cannot really go away without answering.

There is also other cases were a question is asked to them in the office, and other people chip in, with things like "wait? what? you told me that it worked the other way around ...". Again, this is not possible remote unless you systematically add everyone to all the chat (and people stops looking at them anyway because it's too much noise).

As for badly designed for purpose, this is just the natural consequence of bad communication: the person thought they knew when they did not, and considered "yeah, whatever, details are not my problem". In the office, there are way more opportunities to notice that early and to correct the course, based on the same situations as given in example above. Again, it is just based on facts.

[hermanradtke]

It reads to me that your company lacks standards and expectations to hold employees accountable. The in office culture uses the proximity of people to work around the lack of standards and expectations.

If the standards did exist then bad design doesn’t make it through design review or code review. If expectations did exist, then the employees manager is having a conversation about lack of documentation being a problem that needs to be fixed.

Let us not blame remote or in-office for the problems of poor management.

[cauch]

That's an extremely naive view of the reality. Bad employees exist, and the mentality amongst Devs is pretty bad. This is visible in this kind of thread where the first instinct of a lot of commenters is to blame everything on management without even think if sometimes part of the problem is due to unprofessional devs.

I'm not saying that everyone against RTO is a bad employee or is biased (I'm against RTO myself). I'm just highlighting the unbalance and the strong unawareness of this aspect.

For those unprofessional devs, it is ridiculous to pretend that "a better standards" will magically turn an a*hole (to take an extreme case) into an angel. You are talking about "work around", but this is not a work around, this is a relatively efficient and pragmatical way of dealing with this kind of problem. What you propose seems to fall apart as soon as the dev has a tantrum and has decided that something is not like they like.

You seem to assume that none of what you are proposing has been tried, despite it being obvious. (and it also does not mean that we are not going to continue to do that, but it is just stupid to pretend that "working from the office" is forbidden while it helps a lot to ease the problems)

Let's also notice that supervising and controlling the standards to catch it up each time it slips is a lot of effort, it is pretty risky, and the devs hate it and then blame the management. What you are saying is that the management should work very very hard to accommodate an a*hole, and at the same time, asking the a*hole to make a small sacrifice is unacceptable.

> Let us not blame remote or in-office for the problems of poor management.

The point of my comment is "let us not blame management when they are trying to solve problems of devs unable to understand that their own comfort is not the centre of the universe".

Let be clear: I'm not supporting forcing working in the office. What I'm saying is that the large majority here are behaving exactly like my problematic colleague behaves, pretending that it is obviously a management problem when in fact maybe the management is just trying their best to find a pragmatical solution. As far as I can tell, RTO can be the result of management trying their best because the devs are not accepting that something is inefficient in the way they are working. It may not be the case, but the problem is that people here are convinced it is not the case, not because they have proofs, but because it is what they want to believe.

[thejazzman]

I sympathize with your frustration, but if your goal is quicker communication, then the employee should be given notice of this issue and subsequently let go from the company if they refuse to comply

What if they ignore you in the office? Is that behavior OK there because they at least showed up?

I mean this sounds like either a terrible employee (not working or not capable of working), terrible manager (not communicating expectations), or a scape goat excuse because someone wants RTO

Humans also tend to be more sympathetic when they remember they're working with another human. Maybe the issue here is that someone is lacking sympathy when they don't see the other human

[cauch]

Are we really reaching the ridiculous situation where someone argue that firing an employee is a better solution than trying to mitigate the problem?

If you enforce RTO, in the worst case, the employee will be pissed and will quit, leading to the same situation as if you fired him (except that it's less risky, less costly, less damageable for the reputation, ...) (the employee can also try to sabotage their work, giving you a better position to fire them smoothly).

Do you also realize that firing someone and the whole process to re-hire someone else is a big waste of time? Why would you do that if you can avoid it?

Also, my illustration is a fixed scenario. I'm talking about a dev who can work relatively efficiently when working at the office, and cannot when remote but don't understand why. It is not about an employee who will "ignore you in the office" (why the hell would they do that, they've never done that before) or "refuse to comply" (they were explained the situation, but they were truly unconvinced by it, which means they did not really change not by insubordination, but because they were not really capable of changing).

So, you talking about "terrible manager" is irrelevant. Terrible managers exist, I've said so earlier. Here, I'm giving a real life reality where it is not the management, it is not a scape goat, it is just people who truly try to make things work.

And maybe they are wrong and there is a better solution. But that's not the point. My point is that someone said "I know it is X". Maybe it is X. But I've observe several devs saying "I know it is X" and I have he proofs that they were wrong.

So, naturally, I ask: I'm ready to believe you, but there is no way for me to know if you are right or wrong, so can you give me element more objective than just "I know it is X", for example an analysis that is smart enough to acknowledge that maybe RTO is sometimes coming from a truly honest desire to make things better.