The Habits and Tools of Effective Remote Teams
- Hire for Remote
- “Rubber Duck” Channels
- Have An RFC Process
- Optimize for Quality of Meetings
- Publish A Company Directory
In 2017 I was living near Boston, and I joined a startup founded by two friends of mine who had recently moved to New York. On the rare occasions that we would meet in person, it would be in one of the smallest sizes of offices that WeWork offered. The rest of the time, we’d be a remote-first company.
That company eventually grew from 4 people to over a hundred, got acquired, achieved a huge valuation, and along the way, I learned a lot about how to do remote right.
I would be working from a condo that I had selected specifically for working remotely. It had one bedroom more than we needed, which would become my office, gigabit fiber internet service, and access to the basement. I installed gigabit Ethernet throughout. I bought a standing desk, a whiteboard, a good mic and camera, and an ergonomic monitor stand and keyboard.
Remote work allows us to be truly present in our lives.
As I would learn, a great home office setup is necessary but not sufficient for success as a 100% remote employee. The team itself must have habits and composition which foster remote success.
Hire for Remote
For a remote team to succeed, every member must have excellent written communication skills, and the ability to work asynchronously. Filter for these in the interview process.
Having been on both sides of the technical interview recently (both as hiring manager and as candidate), I can report with pleasure coding-on-whiteboard-style interviews are fading out. And for good reason: The experience of someone watching you type can add unnecessary anxiety to an already high-stakes situation. That style of interview also bears little relationship with the day-to-day experience of building a product. It amounts to little more than shibboleth to identify people with a very particular kind of education. Worse, it actually selects against candidates who work well in an async, remote workplace.
Many companies that do remote well have adopted a code screen as a take-home exercise: candidates receive the exercise as a PDF (along with any necessary data files) and submit their answer as a private GitHub repo. Alternatively, hired.com has a comprehensive assessment bank that can be completed by candidates ahead of time, before employers even see them, saving both parties lots of time.
When I do a live technical interview, I like to structure it around three questions:
- Why do you want to work here, specifically? This question tells you a lot about the candidate’s motivation and market knowledge.
- What’s something you’ve built that you’re proud of? This question is about ability to articulate problems and solutions, as well as their breadth and depth of experience.
- Here’s a hypothetical feature, how would you build it? This requires some creativity on the part of the employer, but it serves as a simulation of what working with this person would be like.
At the end of an interview process like that, I can usually give an emphatic yes or no answer about the candidate/role match. When evaluating your interview process, if you cannot get an emphatic answer from it, you still have work to do.
“Rubber Duck” Channels
There’s an old trick in software engineering where you literally put a rubber duck on your desk and explain the problem out loud. It’s surprisingly effective, and we can supercharge that trick with Slack. Here’s how it works:
Create a new Slack channel called
#rd-yournameand invite some colleagues. When you start your workday, say “Hi” and write down your intentions for the day. Each time you take a ticket, create a branch, or ship a feature, say so. After you meet with a colleague, thank them for their time and write down any takeaways. Run into some bad developer experience, talk about it. As you work, explain your thought process step by step. When you decide to conclude your workday, announce it.
When I first encountered this idea, I felt it in my wrists. “You want me to type even more?” But then I started to notice the impact this practice had on my team.
Folks could ask for help, but often help would find them organically.
Our standup meetings were fast and efficient. Most blockages had already been resolved by the time standup started, and participants could easily refresh their memories about what had been accomplished the day before.
Interruptions are the enemy of all software engineers, but keeping a sort of “engineers notebook” in Slack was helping us recover from them better. Did we just solve the doorway effect?
Rubber ducking clarifies intent, especially for complex or delicate operations
See also Why Japan’s Rail Workers Can’t Stop Pointing at Things. This was a boon for deep technical work, but where it really shined was during incidents: people instinctively brought their deliberative, methodical RDing “voice” into incident response channels.
This habit creates an excellent information radiator, on par with GitHub Pull Requests or a well-groomed issue tracker. Having thoughts and process in public creates an effect similar to walking down a hallway lined with open office doors. Peers and managers alike could casually absorb goings-on. One can, at a glance, know who was working and on what. Unlike DMs or private messages, Rubber Duck channels are searchable. Slack’s AI summarization features are still new and not very good, but they will most likely improve.
But like anything, there are tradeoffs. Rubber duck channels can result in “channel fatigue.” People will have to visit a lot more channels to clear the “Unread” notices, and at the same time may feel pressured to join more channels than they normally would. For this reason, it’s important to turn off join/leave notices and announce that this has happened.
You also need to break the DM habit. Private, direct messages should never be anything of substance. DMs should be reserved for “psst, you’re late to the 10am” rather than “what do you think of using a bloom filter for this feature?”
Credit goes to my friend and former colleague Duncan Malashock being the first the try this. Read more about their experience in “Building in public”.
Have An RFC Process
The first thing I missed when I went fully remote was whiteboarding. There’s nothing like the thrill of frantically drawing lines and boxes all over a wall with your team while designing a feature. I tried to replicate that experience a few different ways:
- A physical whiteboard, Zoom, and some awkward camera angles. This was fine for presentations but not collaborative at all.
- A Wacom tablet and various online whiteboard apps. The tablet was too much of a learning curve for me, and nobody else had one.
- One year, every employee received Meta Quest 2 as an end-of-year bonus. A few of us tried using them for meetings without success.
Unfortunately, Meta is more invested in Zuckerberg’s idea of the “metaverse” than a functional whiteboard experience. All I want is a few disembodied hands drawing on an infinite whiteboard, but instead we got skeuomorphic conference rooms, creepy avatars, and NFTs.
Frustrated, we let the remote whiteboarding dream die.
At its core, whiteboarding is collaborative, visual, and synchronous. But remote teams are asynchronous.One startup I worked at had almost a 1:1 ratio of employees to time zones. Eventually, somebody realized that the form of collaboration that created the Internet itself was ideally suited to collaboration over it: RFCs.
An RFC (Request For Comments) is a public document that goes through a “draft” phase where comments are solicited and consensus is built. Once declared complete, they serve as specifications and documentation, and the comments can serve a role similar to Architecture Decision Records.
I recommend reading A Thorough Team Guide to RFCs by Juan Pablo Buriticá. I won’t try to improve on it here, but I will replicate links to the author’s RFC templates in case there’s a paywall on the article.
Choose the format best suited to your team. I personally like Markdown documents in GitHub, especially with Mermaid diagrams, with one caveat: it can disenfranchise members of your team who are not deeply comfortable with GitHub and Markdown. For that reason, Notion is probably the best default (and does support Mermaid).
RFCs are not quite the same as whiteboarding, but that they always result in artifacts is invaluable. This is where remote success requires a different approach, and yields different benefits.But I always bring my preferred whiteboard markers and eraser to in-person events just in case there’s a chance to whiteboard again.
Optimize for Quality of Meetings
Zoom is a lot like email. It’s ubiquitous, and well-established. Everybody has an email address, and thanks to the pandemic, everybody has installed Zoom already.
Like email, Zoom is fine for inter-organizational communications, and one-to-many broadcast communications. And like email, Zoom kind of sucks.
Zoom fatigue is real. The urge to keep looking at one’s self to make sure you convey the right attitude, and the discomfort of posing and smiling for hours at a stretch. The echos, the latency, the “can everybody see my screen?”
When cameras are on, the visual information channel carries more than just your profesh background. The relatively higher latency and semi-half-duplex nature of Internet video calls mean that posture, position, and facial expressions all begin to matter more than perhaps even in real life. Interrupting with a head nod is more polite and more practical than interrupting with a word.
It’s not great for collaboration or pair programmingSee also Tuple’s Pair Programming Guide. For those kinds of meetings, I strongly prefer Tuple.
Tuple lets two people use the same screen at the same time. All participants can type, draw on the screen like a whiteboard, and highlight exactly where the other person should click. Giving each participant simultaneous control of keyboard and mouse is a total paradigm shift compared to Zoom. Importantly, cameras are off by default while mic and screen sharing are on. This is a tool for collaboration, not just communication.
Publish A Company Directory
In a “real” office, you can get a sense of the larger team by just walking around the office and glancing at the names on the doors (if you’re lucky) or the desks. You’ll at least see and hear the people you don’t directly work with, maybe even have a spontaneous conversation with them.
Not so if remote, and don’t wait for the quarterly offsite to remedy that. Publish a list of everyone in the company, including job titles, and where they work from (or at least time zones).
The two most popular modern HRIS“Human Resource Information Systems”, which generally encompass payroll, benefits, time off, etc. solutions, Gusto and Rippling, have built-in company directories. If you don’t use one such system, Slack profiles are a good option. Slack admins can customize the available profile fields to include things like name pronunciation, core hours, and pronouns.
Looking back, these habits and tools address the core demands of a remote organization: clarity of communication, shared context, and collaborative processes that transcend time and space (sort of). Hiring well, communicating well, and establishing a strong culture all pave the way for frictionless teamwork. When coupled with thoughtful meeting tools and a company directory that empowers everyone to connect, remote teams can achieve remarkable velocity without sacrificing the human elements of collaboration.
The important thing is to stay deliberate about remote practices. It is fundamentally different than in-person work, with different advantages and challenges. With the right structure, you’ll find that “office” isn’t a physical location but a culture of steady, supportive, and self-driven progress.