Hacker News new | ask | show | jobs
by DoofusOfDeath 3038 days ago
My background: Worked many years in offices, and the last ~4 years remote.

Understand that companies hiring remote developers, especially for the first time, might not be aware of things they need to do for success. These include:

(1) The manager needs to be above-standard.

(2) They need to be ready to treat communications challenges as first-order, high-priority problems.

(3) They need someone onsite who will advocate for you, particularly w.r.t. challenges that are specific to you working remotely.

(4) They need to understand the challenges posed by distributed teams, particularly if the team isn't entirely remote.

As far as what you can do, I'd suggest:

(1) Learn everything you can about the challenges of being a remote employee.

(2) Address those challenges as best you can at your end.

(3) Be ready to educate your employer about those challenges as well.

(4) Recognize that the employer just might be incapable of properly handling a remote employee. I'd suggest screening employers carefully if possible, and be prepared to move on to another job if they're not able to do what they need to do to make remote work.

2 comments

You mention it, but I want to harp on it -

There is a huge, huge difference between being a remote employee on a mostly colocated team, and a fully distributed team.

I would NOT take a job that had me be remote to a colocated team, unless you have experience doing that, and the team in question has experience with remote members already.

Transitioning from an onsite to a remote role on the same team is different, as you already have carved out what expectations you have with your team, and going remote doesn't change those. But starting out like that makes it so only -you- have the communication difficulties. That conversation that changed all the priorities this sprint that happened in a hallway? You missed it. No one thought to tell you. Etc. That sort of thing -happens-, and it's very hard to solve.

A fully remote team, however, hard as it may be, at least doesn't suffer from that. Everyone -has- to be cognizant of who is involved in a conversation; every conversation requires a bit of effort, be it on Slack, email, the phone, video conferencing, etc. That little extra effort that is required for any conversation ensures all the relevant parties get looped in (unlike a conversation at someone's desk or in the hallway).

That's huge.

So, if you haven't worked remotely before, look for a fully remote team, or look to transition from a colocated job to a remote one. I would seriously consider staying clear of being a remote employee on a colocated team.

"I would NOT take a job that had me be remote to a colocated team, unless you have experience doing that, and the team in question has experience with remote members already."

yes! That is very good point and can't be overstated. Being the only remote worker on an otherwise face-to-face team takes an almost peerless manager and team. Even if it starts off well i've seen it devolve to where the remote team member is left out of all discussion and becomes just a place to park tasks.

As somebody doing this now I am absolutely out of the loop on certain discussions but while it's often challenging, it can actually be helpful in certain cases. Many of my teammates end up being roped into meetings and ad-hoc tasks as backup but ultimately provide little or no input and just waste their time. Meanwhile, I'm protected from a lot of the distracting, low-value work and am left to focus on things I'm leading and anything important enough to be communicated to the group as a broadcast or call to action. Additionally, my group has become so accustomed to working in a way that accommodates remote work that the colocated team members have started working from home more often, encouraging further adjustment to support remote work. That being said, I don't think my arrangement would have been successful without having my manager and a couple of colleagues acting as my advocates on the ground.
Good management will also avoid including people unnecessarily and encourage a culture where people can depart when it's obvious they're not needed. I tried making an early exit from meetings more acceptable with humor. But ultimately everyone has to buy into the idea.
Where were you when I took my first remote job?! I had the misfortunate of working on a team that was mostly colocated ANDDDDD in a completely different time zone. 11 hours ahead.

North America vs Asia.

Talk about isolation. Don't do it folks.

IMHO there needs to be at least two hours of overlap for remote teams in different time zones to be feasible. This can work if one of the teams adjusts their schedule to fit, but otherwise it leaves the remote team out in the cold.
That is all exactly right. It is really hard to overstate just how important this is.

Even just having one or two workers collocated can create strange cultural problems and weird duplications of work due to communications breakdowns.

I couldn't second this statement more. I've been on both. Remote with a colocated team is a special kind of hell. You are out of the loop on so much and the isolation is overwhelming.
Hell? I'm out of the loop a bit for sure, but in two hours when we do our sprint planning.. their backdrop is a tiny windowless office while mine overlooks the pacific ocean.
> They need to understand the challenges posed by distributed teams, particularly if the team isn't entirely remote.

Out of all of the fantastic points listed this is by far the most critical because it most likely will be the root of every other problem.

The thing is, it's not entirely the challenge of being distributed, it's the challenge of having an inconsistent team dynamic where the needs of the colocated team members aren't aligned with the needs of the distributed members. Without strong leadership, discipline and culture it's all too easy to try and patch over the communication and collaboration issues with all kinds of workflows, Slack bots, and tools that ignore the essense of an interpersonal problem and turn it into a technical one.

For example (in my own experience):

- The expectations around availability aren't clear so individual flexibility takes priority over team flexibility and it's hard to set some healthy boundaries on it (e.g. remote or not the team wants to hear how it's going at 10.30 to see if expectations for delivery need to be adjusted)

- There may be an isolated/individualistic mentality where you're building code on a production line (which is counter-productive for budding startups that need business/dev collab)

- Colocated colleagues are privy to far more information than remote colleagues unless they remember to share it in public channels (e.g. Slack), _or_ it's all done through private channels and nobody is on the same page about anything

- Half your work day is scanning productivity tools for updates (github, jira/pivotal/asana/trello, dropbox, slack integrations) instead of having a conversation

- The remote side will almost _always_ be scapegoated or be the reason for something being more difficult than it normally would be

- There might be an absense of serendipity that makes the space for creative and interactive problem solving because the connections aren't quite there for it

It's pretty much the sort of thing that becomes a problem once the team or company matures beyond petty blame and starts to treat the remote part of the team as first class. The issue in a nutshell is that you might initially be dealing with an over-correction so rather than striking the balance that gets the team working well together whether they're in the office or not, you get one that stifles colocated activity.

The fact it happens to be a clash of remote and colocated dynamics is irrelevant, it's the failure of leadership to bring the team together as one while also respecting its occasionally incompatible requirements that's important.