7 simple ways to make remote work feel less lonely
… and check why 5600+ Rails engineers read also this
7 simple ways to make remote work feel less lonely
4+ years ago I joined Arkency, a remote-first company. It was so remote that I didn’t even see my teammates’ faces for almost half a year. The most surprising thing about the new job, was that, even though it was remote:
- I felt I have more connection to other teammates than in my previous non-remote job
- I had way more insight into what’s happening in other projects in the company (that I’m not actively participating in)
Nowadays most of us need to work remotely. I guess not everyone is happy about that, partially because of all that accidental human interaction lost.
Here’s how we’ve always dealt with that:
1. Set up personal off-topic channels on Slack
Let’s say your name is Dorothy. Now create a channel named: #dorothy
. Treat this channel as your own blog, which is just published internally in your company, with your teammates comments inlined. Post anything related to your life: going on a hike, read something interesting, buying a piece of hardware and needing help — post it and let others chime in. Good place for occasional photos, too.
2. Overcommunicate
When working on a project, don’t defer communication until you’re stuck or until you achieve something noteworthy. Turn yourself into --verbose
mode and keep actively communicating whatever you’re doing to progress with your task at hand. The benefits are threefold:
- You’re helping yourself, because you’re effectively rubber-duck debugging
- You’re helping your teammates to stay updated with your progress, without waiting for the daily standup
- You’re helping yourself, because if you’re encountering a problem for which a teammate knows a quicker solution, he can just jump in.
Example: one day I had to set up assets compilation on CI. I would probably do it sooner or later with more or less googling and that was the plan. I just kept communicating what I’m doing step on a channel where everyone has access, but I didn’t expect anyone to read. I didn’t even assume anyone is around. By default I’m just communicating my moves for the purpose of rubber-duck-debugging. But perhaps someone is around, has already dealt with that and doesn’t mind being interrupted at the moment — in such situation they can offer to help and this is what happened in this particular situation and I probably saved an hour or two. It wouldn’t happen though, if I weren’t overcommunicating, i.e. turn myself into --verbose
mode. The default was just to keep doing it myself and no one would be offended if there wasn’t any response to my messages.
3. Less scheduled meetings, more one-off 1-1 calls
We’ve shared a lot of content on why meetings are suboptimal in most situations. We mostly mean meetings that are large, compulsory and regularly scheduled.
But we fancy a lot any ad hoc calls, with 2-3 participants max, whenever someone feels like they need it and the other one doesn’t mind. It can take anything from 5 mins to 3 hours. We sometimes ask one another: “Got a good interrupt for a call?”.
4. Pair program
Whenever you think it makes sense and the other party doesn’t mind it. Especially when exploring a new area. Often it can save you a lot wrong turns and you can build the context together. After such a session both of you are ready to continue working in this area on your own.
If you’re not comfortable with working on a teammate’s environment via a remote-control tool just try switching after commiting to a branch.
If you’re not comfortable with full-blown pairing style like TDD ping-pong, just go for anything on the spectrum between proper pairing and plain voice consultation. Even passive watching is fine, provided you pay attention to the moment when your partner is losing attention.
If you don’t feel like pairing all the time, try intermittent pairing. Jump in and out of pairing mode whenever you think it makes sense.
5. Prefer channels over private messages
This may blow your mind, but 83% messages on our Slack are sent to public channels, only 17% in DMs. This is completely different from most other companies, where percentage of public messages can even be a single digit.
In particular we keep most of project-related communication on a channel and let everyone see it (even people that aren’t assigned to this project currently). This way it’s easier to see what other folks are up to and jump in to help on a good occasion.
Our dedication to communication via public channels helps many things. It’s so much easier to be a part of a project you’re not directly assigned to.
6. Voice channels on Discord
This is a recent experiment we’re running and it’s going great so far. We’ve started using a Discord server alongside Slack, just for the purpose of using its voice channels. It’s like walkie-talkie. Voice channels are way more async-compatible because you don’t have to synchronize the moment when you jump on the call. You just enter a voice channel whenever you don’t mind company and just mute yourself (or enable push-to-talk). Probably you’ll be alone for some time, but at some moment someone else may join with random interactions happening. More in these tweets: How Voice Channels are changing the way we work, Another hopefully game-changing thing in the way we work, Discord-to-Slack bot.
7. Join a community of learners
Here’s the one we’re building: Arkademy. You’re getting access to courses like Rails Architect Masterclass, Blogging for Busy Proggrammers and you’re joining a community because it can be a game changer. As a part of this, you’re getting access to Arkademy Discord server, where you can try some of these techniques — overcommnicating your steps on your personal channel, joining voice channels — especially if you cannot do it at your regular workplace.