
Ask HN: How to solve remote engineers appearing lazy to other departments? - ngngngng
A recurring issue I&#x27;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&#x2F;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.<p>How can these concerns be resolved to allow certain teams to work remotely without upsetting other departments?
======
gwbas1c
If upper management is in favor, why are other departments dictating your
workflows? Are you the kind of company that hires people who need babysitters?
If so, then your obstacle has more to do with who your people are than
anything political.

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.

~~~
muzani
I've worked at companies with hundreds of staff and only a handful of tech
employees. Many of those companies are _exactly_ the type to hire
babysitters/overseers/foremen.

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.

------
cborenstein
In my experience, remote engineers are often some of the most productive
engineers at an organization.

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.

------
blaser-waffle
Start talking about synchronous-async communication. Most things don't need a
direct, immediate reply and can wait for a little. Like, even in the office
there were days where I only had ~3 hours of actual work + 2 hours of meetings
that I could skip without effecting anything.

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.

------
muzani
Progress reports often appease management. Jira is good at showing that
someone is doing work - every time you edit a description or add a photo, it's
marked as a notice.

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.

------
kleer001
"appearing lazy" ... "concerns"...

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.

------
wayn3
We as a community take a strong stance on the issue and categorically decline
jobs that are not fully remote.

The recruiters I work with know that I don't entertain non-remote work at
_any_ salary.

Do the same. Join the revolution. Succeed.

------
jf22
Time to move on.

The culture at this company must be really difficult if "upsetting" other
departments is the reason to prevent remote work.

------
peteradio
Other departments will continue to sit on IT as long as they are allowed to.
Not sure why they are being allowed to, but probably your upper management
does not have clout.

------
itronitron
Maybe the engineering managers can define and enforce 'no-chit-chat' zones
around the development teams to prevent distraction. After a few weeks or
months of having their social interactions dampened the socialistas will be
begging management to let the developers work from home.

