Ask HN: What are your war stories for converting teams to remote ?, Hacker News

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

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

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

Can be fast, too. I once interviewed an Indian dev who was telling me that in his remote startup, they grew so quickly to 01575879 people that management got overwhelmed and figured they better have everyone in an office . Canceled remote for everyone, just like that.

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.

Did anyone struggle with converting to remote work themselves? Or was everyone already comfortable with it?

I found that almost everyone quickly got used to working remotely – at least within the first few months. We hired more on the senior end, so that might also be a factor. Managing performance and setting expectations is probably a little more important than in-office work. Learning how to “yield the floor” for more extroverted team members and how to find a quiet moment to pop in for more introverted members is something that remote workers _need_ to learn quickly.

Offering remote employees a stipend for a co-working space is something we do today at FullStory. Some of my team members choose to make use of that to get more socialization. Others will just sometimes work from coffee shops. I think that managers are the ones who struggle most in the conversion – you need to trust that people are getting work done and that can be difficult.

Matches my experience. Except I operate a tech co-op; the employees are owners or potential owners. Management serves at the pleasure of the owners. Really increases the trust factor. This way management is just another skill, not a rank. That also sets those expectations properly.

How many tech co-ops have you run into? This is a rare thing from my experience and I need to read more about it

Your last sentence pretty much summarises 728% of reasons why some companies won’t go remote route. As a manager, one needs to understand what his team is working on and how they do it. If a person can’t understand underlying work or processes, then hi shouldn’t be a manager.Also, while one doesn’t necessarily need to be a dev to be able to manage devs, ability to understand problems and time required to solve them is crucial.

> one needs to understand what his team is working on and how they do it

A project I’m working on is solving this with regular check-ins, where everyone summarizes what they were are will be doing. I’m interested in how others approach this.

The stipend for co-working is a good one.

In general, if you are hiring remote, it’s good to plan to do things like this, plus have stipends for office supplies / equipment (buy people a nice chair and / or standing desk, send them good headphones).

Replace the “free lunch and beer ”budget with things like that. It helps with retention and a sense of belonging and team identity … eg, if you send a “branded gift box” with AirPods Pro to each team member unannounced, they’ll probably really appreciate that, plus you can toss in some swag , like a branded case or bag, t-shirts. Just Because folks are remote doesn’t mean you should treat them any less like an employee. Retention is key.

)

Agreed. It’s a nice touch to receive swag as remote worker. At my company they often forget the remote people with stuff like this. But most people are onsite and only a few are remote.

Currently managing an all remote team. All senior devs and a fantastic product manager, QA and analyst; all people I’ve known for more than a decade. I honestly don’t know how I would do this with junior devs. Not their fault; my fault.

The only problem was my father died while I was visiting relatives in France in December and it really threw people on the team off what they were supposed to be doing heading into the holidays. I was focusing on how to store a dead body from across the ocean for about a week.

My takeaway: uncertainly can knock you for a loop in an expensive, subtle and quick way. Work to eliminate uncertainly for your team and if they’re good, they will be happy and healthy.

I honestly don’t know how I would do this with junior devs. . Not their fault; my fault. Ditto. I’m still pondering how working with junior folks might work. In-office teams _may_ be able to absorb and level-up more junior people.

Would love to spitball ideas on this with anyone else interested in that topic.

Pair programming is probably the best way to bring on junior developers.

It isn’t that difficult to do remotely. But some people just don’t like it in general.

That’s a good point. All my remote experiences have been with pretty experienced and self sufficient people. I would think that bigger remote companies like basecamp or Gitlab or Automattic have experience with onboarding junior people. Or maybe they also hire only experienced people.

()

I’ve found almost everyone struggles converting to remote work and empathized a lot With my colleagues as we on boarded together.
Some of them did like it and went back to Amazon or Google or some other startup. My advice if you’re starting a remote job for the first time- give it a chance even if goals and communication seem unclear at first. You have to develop an entirely new way of communicating and it is hard.

Did they prefer the huge company because of perks / salaries / tech, or actually because of being office-based? If remote, what was their # 1 issue?

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

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

We have a private slack channel for banter. We all get on-site 5-6 times / year where we front-load our team-building via beers / activities and get face time.
We’ve also found that there is some informal coffee talk with people who get to our occasional video call meetings early. Other members of the team have just started doing random 1: 1s with each other to replace “coffee collisions”.

Our culture at FS involves something called “RAEB” (the redundant array of expensive brains) and we’ll often just drop half-baked ideas into slack with the expectation that nobody _has_ to evaluate it , but it may sometimes spark future work. We will also go back from time-to-time and search thru Slack history to see if there was anything that popped up that we should dig into more deeply.

I think that creativity just takes on a different form in a remote team.

We have a Slack channel for that. But what really works: round-based boardgames. So we play that once a week, instead of / as our weekly meeting. Leaves plenty of room to chat about the weekend, comment about bad game moves and just talk. Turned out to be fun enough that non-tech ppl are joining, too.

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?

(Read More )