Ask HN: How to solve remote engineers appearing lazy to other departments?
A recurring issue I've seen throughout my career is engineers wanting to have more remote flexibility. Often the upper technical leadership is in favor of it but concerns throughout the company come up that other departments will think that product/development is lazy and never does anything if they often work remotely. These concerns eventually kill the initiative to allow more remote work and sometimes any remote work at all.
How can these concerns be resolved to allow certain teams to work remotely without upsetting other departments?
10 comments
[ 3.3 ms ] story [ 34.1 ms ] threadThe culture at this company must be really difficult if "upsetting" other departments is the reason to prevent remote work.
Anyway, just do it and let the results speak for themselves.
One thing to keep in mind: When I went remote, "everyone" in the company was in the habit of interrupting me for trivial matters. At the time, I was trying to get my manager to run interference. Me going remote acted as a bit of a forcing function for my manager to be more aware of the problem.
I can't say this is happening for OP, but when the ratio is a hundred workers to one, the "other departments" are going to determine HR policies.
Tech companies aren't necessarily exempt from this. Many companies hire thousands of content moderators or tech support, many of whom are uneducated and lack self-discipline. There are the types who simply don't show up for work, take 2 hour long cigarette breaks, fake illnesses and weddings to skip work, steal toilet paper, and bully colleagues into doing the same.
Lots of tech companies bootstrap from there, and it's difficult for them to change workflow that's their bread and butter.
There will absolutely have to be pre-defined sync times, and a "mostly available" synchronous-ish times, but outside of that mgmt and other teams need to trust workers to do their jobs. This will probably require a change in communication styles and communication tools.
Another way to look at it is git commits - if remote workers are committing just as often as local ones, they're doing equal work.
This might end up with more busywork, but such is the side effect of anything where managers try to monitor work rate.
The recruiters I work with know that I don't entertain non-remote work at any salary.
Do the same. Join the revolution. Succeed.
When any engineer can demonstrate a strong track record of shipping, any idea of "laziness" goes away pretty quickly.
I think one of the reasons why "laziness" comes up is because remote engineers aren't physically in the office to be shoulder tapped for questions (though so many questions now go in Slack anyway).
A somewhat opposite problem I've seen is that when people work remote, they kind of "forget to stop" and end up working way more than a standard workweek.
A start to solving both of these issues when working remote is to establish a clear schedule of your working hours and your "availability for questions" hours. I.e., make it clear 1) when you're working and when you're not 2) when you're available for answering questions vs reserving your time for working in flow.
Can use something like a Slack status to remind colleagues.
These are weasel words coming from BS-land. A strong leader will crush them immediately. Proof should be the only true currency.
Someone complaining about your process? Walk them through every step and explain every decision until they see they're out of their league and stop complaining.
That's what I'd do.