HACKER Q&A
📣 vsareto

What are your war stories for converting teams to remote?


Stories for starting remote teams also welcome!


  👤 muratk Accepted Answer ✓
We had a colocated team in Cebu, Philippines. Turns out, not too many Go devs in Cebu, so went remote. Now UTC+1 to UTC+8. Bigger challenges:

- the utter unfairness that some people are really effective (possibly because experienced) remotely and can just do it while others are not. The latter we gradually “released” into remote work, with a lot of feedback.

- Biggest skill to be learnt, of course: communication. so much patching up is possible by just noticing someone is in a bad mood, or switching to a live discussion. Doesn't work with remote.

- hard to support juniors: they need to learn both work skills and communication—and often even don't realize it.

- learning to take responsibility. You're Internet at home doesn't work today? Too bad—I'm not fixing it for you. You're remote, you figure it out.

- currently: the realization that most things are _not_ urgent. Going more and more async.

edit: late-night formatting


👤 MatekCopatek
Disclaimer: not an intentional fully onsite to fully remote conversion, but a gradual transition of existing and addition of new, fully remote members.

- People miss socializing in the office. We've addressed it by actually drinking coffee and chatting on camera for about 15 minutes after the daily. Also considering regular team-based video game sessions, though the question here is whose time they're on (the company isn't too excited to fund weekly counter-strike time and team members aren't to happy to spend their free time to improve work relations).

- Daily meetings become way more valuable, as you can no longer just turn to people and go "Hey, Julia, what was that flaky integration test you were fixing yesterday?". It takes a lot of adjustment to figure out when it's worth interrupting people and when you should just write something down and ask on the daily.

- It's more difficult to effectively manage people. You notice everything on site - sighs, high fives, facial expressions, keyboard rattling, all the things that can help you recognize whether people are happy, stressed, bored, productive etc. Being remote, you need to develop processes to get that information "manually" and in a way that respects your team members (i.e. without constantly breathing down their necks).


👤 jnwatson
The company I work for is 100% remote. 100% remote is far easier than 10% remote, because all of your processes must evolve around that.

My general observation is that the worse your processes are before your transition, the worse the conversion will go. "By the skin of your teeth" and informal processes are less efficient. Communication must be documented and asynchronous.

We use a typical scrum process. We do daily (short!) standups to keep in touch with each others' stuff.

We're all expected to be on voice chat during work hours. (We have multiple channels for side discussions, meetings, etc). This helps a lot with the feeling of isolation.

We get together in meat space twice a year.

The biggest challenge going forward is growth. We're now too big for one scrum. Even the voice chatter has lessened now, because radio discipline is more important te


👤 mmastrac
I've built (not converted) and managed two NA-wide remote teams of high-performers in the last decade (once at my own startup DotSpots, second time here at FullStory). I don't have any particular stories, but happy to answer any questions.

👤 toyg
My war stories are only about remote-first teams slowly perverted into office-based ones... sadpanda.jpg

👤 s1k3s
I didn't start a remote team myself but for the past few months I've been trying to get into one.. Honestly the worst thing that I'm facing at the moment is lack of trust. I've passed interview tests, showcased code, showcased apps already running in production, went through dozens of meetings and for some reason people still think I'm there to scam them.

👤 gtirloni
Lack of trust by management quickly turning into micromanagement which turns into resentment. It's really hard to stop it once it starts.

👤 planetzero
I've been working remotely for the past decade. Some issues I think any company will deal with:

At most places, I never felt connected to the company. Since I didn't have that social aspect of talking face-to-face every day.

The amount of discipline it takes to work remotely is the same as starting your own company. You need to be able to keep working, knowing that there isn't someone watching you all day. Most people can't handle this and end up getting very distracted at home. One company where I worked went through many employees because of this.

Communication is key and you need a manager that can communicate very well. In my experience, introverts were the worst remote managers. Passive aggressiveness and poor communication went hand-in-hand with introverted managers.

One manager was poor at communicating, wouldn't take the blame for issues with his own code, and I had to initiate all communication regarding projects and tasks because there would always be something intentionally or unintentionally missing.

I would complete a task/project and then after it was completed, the manager would reprimand me because something was missing. I always try to fix these situations, so in future tasks, I would have a voice call and go over everything that needed to be completed. This really didn't change anything.

I left the company over frustration and within 6 months, it went out of business.


👤 znq
We started as an "office company" in 2011, turned partly remote in 2014 and fully remote in 2018. Being all in an office worked great. Fully remote worked great. Anything in between is difficult. Remote workers are just not fully integrated, no matter being it things happening spontaneously in the office or social events.

Also in confirmation of one of the sibling comments these have been for us the main issues as well:

• Communication is a skill that most engineers don't possess and have difficulty learning.

• We stopped working with junior people. It's just too time-consuming grooming them remotely.

• Teaching team members that they are responsible for their own working environment. Shitty Internet and working from a loud coffee shop is just not acceptable. Still, they do it.

To onboard new team members and even as guidelines on a daily basis we've written and published an extensive company handbook (used to be a not so visually appealing internal wiki): https://mobilejazz.com/company-handbook-pdf/


👤 mnm1
We went from partial remote to full remote with zero issues. Our team was half or more remote by the time of the transition. Everyone worked remotely at least part of the time before the switch. We already had remote processes in place. Frankly, it doesn't have to be a war story. It can be a smooth transition.

We don't force socialize people. We don't force video on people. We don't force schedules, other than a daily and weekly meeting, although even that early forced start time leads to lost productivity from the engineering team members that prefer to start later. But we had the same problem before the change. The managers run the scrum meeting simply for their own benefit to the detriment of the team. So just like everywhere else. Other than that, it works great. Few meetings outside of this. A lot less time wasted lollygagging around the water cooler, playing games, going to lunch, and so many other useless activities that chew up a typical day on site.

I will never go back to an on-site company if I can help it.


👤 bitL
A good manager is one whose absence doesn't affect performance. Most managers are there for power, game of control, therefore hate remote work. At best they micromanage - "Did your Slack status turn to 'Away' for a few seconds? Here is an urgent message from me!"

👤 nojvek
I’ve been working remote for over 5 years. Here are my lessons.

1) work from home is really hard. Home is home, work is work. You need either a fully isolated work room where you only work or go to some co-working space which is work. Dress like you’re going to work. No pajama work days. Best is when you have couple of folks in same city that make a remote satellite office. I’ve seen great success with many satellite offices.

2) ensure you have good internet connection, a good headset with noise cancellation mic and speakers, a good camera that works in low light. A good powerful machine. MacBook pros are prolly the most popular.

3) Out of sight, out of mind is a real thing. Reply to messages within a certain timeframe, say an hour. I used to have morning hours which was reviews and discussion. I replied immediately and was open to any interruptions. Evening hours I liked to get 3-4 hours of in the zone focus.

4) write things down. Google docs, slack, wikis are great tools. For every project I used to have a team doc with overall eagle eye plan + weekly notes. What happened last week? what metrics/impact we moved? What we’re gonna do this week, why we’re gonna do it and what metrics/impact we think will be made. Anyone could look at the doc and had a good idea where things were headed. Documenting progress is just as important as actually making the progress.

5) There’s usually some work timezone where everyone is expected to have at-least 4 hours in common. Make use of that. Set 1:1s, talk about feelings, ideas, overall health of business, kitchen sink conversations etc.

6) remote folks sometimes end up being over worked. Know when to shut off and switch to “non-work” mode. It’s important.


👤 jwsteigerwalt
In an office setting, A lot of personality tendencies (To excel or slack off) are tamped down. I’ve caught myself more than once in a position where I waited too long and let too many red flags pass by telling me that a team member could not cut it as we reorganized with more or all remote work. I wish I had cut them or decided to make the difficult investment to coach back towards success earlier.

👤 dnautics
Does anyone have a concrete set of requirements before going remote? My managers want to do this but I'm not convinced we have the right stuff, in terms of process.

Stuff like:

How should we/should we not set up our git repo? How should we organize our slack channels, meetings, team documentation, etc.


👤 hef19898
My favorite anecdote is from adding an on-site intern to a remote team. So, it started with my team being split accross three locations, including the main office where I was. Then we finally got a working student / intern as support who was placed at the main office. As luck would have it, the project he could best support the team was handled by one of the remote team members.

long story short, I was so used to manage the team remotely, that it took me almost two months to realize the intern, as far as HR was concerned my intern, was remotely managed by someone who was remotely managed by me. despite the intern sitting right across my desk. Embarassing when I realized it, but it showed what a damn good team it was.


👤 tonicb
I love this question so much and have been thinking about it for the past few days (especially as I just put out a four-part guide on remote work).

Here are a few stories I picked up in the past five years:

I was an executive at a tech company which had a HQ in California. I joined to lead our European expansion so from the outset it was clear that I was going to be defacto ‘remote’. Although, at the time it wasn’t discussed as such. What was very obvious was that at the start the responsibility was very much on me to get in front of the people I needed, be heard, aggressively communicate what I wanted/needed, wake up early, stay online late, set reminders to ping people before I would go to bed...

Then in order to acquire the best talent, the company decided to become remote-friendly (and later remote-first). And more or less immediately I felt the burden of responsibility lifting form our small European team because I (and the European team) was no longer alone in the remote work situation.

The moment the company was clear on its intention, the habits started to settle in and everyone seemed to get on the same page. It was quite impressive to watch. But this shift was absolutely intentional and top-down driven.

One interesting impact the shift to remote-friendly (which lead us to become remote-first) was the following:

An increasing number of people took advantage of this shift, the HQ office slowly started to empty and lost the upbeat and busy atmosphere it once had. The remote attitude also started to extend to people working at HQ and remote became synonymous for ‘Work from home’ and making this a recurring habit was tempting. Seeing as the default was starting to be remote, it mattered far less if the HQ people were physically in the office because all those habits necessary for remote work had settled in.

I would certainly avoid the blend of remote work and centralised office because right from the outset it creates two separate cultures. I would advocate for going all in if you are doing in. While we were transitioning we certainly had two cultures.

Common mistakes: - not being explicit and intentional with the decision - not knowing why you are doing this shift in the first place - seeing it as a perk rather than a fundamentally new way of working - not preparing for such a shift - being very clear on what 'remote' means for your company (how are you defining it)


👤 dominotw
I've worked with teams in india and employees there ( rightly) feel no involvement/empathy for the project. They just wanted to write software to spec, go home, get paid. And writing software specs doesn't really work. I don't see why someone getting paid to write software to spec doesn't do exactly that.

👤 marcinzm
Converting a team is difficult because you:

a) Already have ways of communicating that aren't particularly friendly to being remote

b) Presumably have a lot of people on a few locations so remote employees outside those areas can feel left out of the loop

The question I have is, why do you want to convert to remote? What is the drive and goal?