
Ask HN: What are your war stories for converting teams to remote? - vsareto
Stories for starting remote teams also welcome!
======
muratk
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

~~~
jcagalawan
Have contact info? Exploring opportunities in Cebu.

~~~
muratk
Well, we're a remote team. ;) Incidentally, I'm still in Cebu, but it wouldn't
matter where you are.

~~~
jcagalawan
I’m just a Cebuano finding excuses to visit home bai :). How’s the tech scene
over there?

~~~
muratk
Not too sure. You'll likely find stuff for PHP, but a bunch of meetups have
gone dormant AFAIK. High paying jobs here are scarce if they exist at all,
probably same as when you left.

------
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).

~~~
em-bee
i don't get why text chat message about that flaky test is any issue.

send it and let the person respond when they are free. doing that in remote
work all the time

------
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

~~~
ptcampbell
Is voice chat always on?

~~~
jnwatson
Push to talk.

~~~
dividedbyzero
What software solution and hardware are you using for this?

~~~
StavrosK
I don't know what the OP uses, but I used Mumble and it was fantastic. Super
light, and unbelievable quality.

------
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.

~~~
mnky9800n
how do you facilitate coffee break/after work beers/etc creativity?

~~~
numbsafari
Two things I’ve tried (neither of these are ideas original to me, just things
I’ve been a part of and brought with me to multiple orgs):

\- office hours: this is __not a meeting __... it’s just a team dialed into a
hangout or other voice chat for an hour. Totally optional. Folks can talk
while working, talk about work, talk about not work, whatever. Just share the
virtual space for a bit. This can be really helpful for “serendipity”,
building trust and depth in interpersonal communication, cross-training, and
otherwise just de-tensioning if you are involved in a high-stakes activity.

\- BOF/hack-a-thon/quarterly on-site... basically, everyone meets somewhere in
meatspace for a week (Monday PM to Friday AM). Good things to do during this
time: planning, team-building, demos, tech-talks, bring in an outsider or
trainer, etc. Lots of larger OSS projects do this.

~~~
mike_h
Any interesting outsider / trainer experiences?

~~~
numbsafari
I’ve generally only ever had budget for internal stuff. I’ve tried to bring in
leads from other teams to talk about the tech they work with (I mostly worry
about backend, so, eg, have client tech leads come in). I find that kind of
cross training really helpful for inter-team communication. A surprising
number of “backend” engineers don’t really know much about their OS or the
Unix environment (why this is... I don’t know), so having folks from Ops come
in and give a quick tutorial on those sorts of things is also really helpful.
I could do those things myself, but I think working with leads from other
teams helps build rapport and familiarity, it also gives those folks a chance
to emphasize what they think would be most helpful for them if we knew more
about it.

At a previous job we had good PMs who were skilled as “agile coaches”. I hate
to call them that, but I think it’s probably the closest thing that would be
generally understood. They would help organize and host some excellent
sessions on how to make our retrospectives and planning sessions go better.

I’ve also worked with sales engineers from key vendors to come in and do a
hands on about new features, if I can schedule it. It’s usually low or no cost
training. Making better use of tools you pay for can be huge.

Ps. Would love to hear more about others experiences with outside trainers
coming in for hands-on sessions.

~~~
mike_h
Hey thanks, these are great ideas and inspiration!

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

~~~
vsareto
I agree with you there.

Were there any major reasons why they were converted?

~~~
toyg
In one case, sales & admin felt “uneasy” not having a real office where to
invite customers and partners. I honestly don’t see how a crappy shared-space
office is better than no office, but I’m not in sales... Another case,
ISO-8000something about controlling infrastructure from which you access
customer sites; which is kinda stupid in the third millennium, but there you
go.

The problem is that, as soon as you have expensive real estate paid for, you
get all sort of pressure about actually using it, so new hires are placed
there 100% etc etc, until “grandfathered remotes” are effectively considered
legacy.

------
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.

~~~
muratk
Curious, how do you know that lack of trust is the reason? I mean, they
wouldn't tell you, right? Maybe it's something simpler like, salaries,
timezone, ...?

------
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/](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.

~~~
house9-2
> We don't force socialize people

That's good. I prefer to keep work and normal life separate. Of course you can
develop great friendship through work, no need to force it.

> We don't force video on people

Once you are established that seems fine, but when bringing on new members I
get a better feeling that I am dealing with another human being instead of
some random person bugging me on slack.

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

Same

------
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.

~~~
s1k3s
Honest question: why would those things be different? I mean, of course
meetings can't happen if everyone is in a different timezone, but everything
else should be just the same as with a non-remote team.

~~~
dnautics
I don't know, that's why I'm asking.

------
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?

