Remote-First Communication for Project Teams | Hacker News Reader

Remote-First Communication for Project Teams

spin.atomicobject.com

58 pointsenglishm14 comments

Based on my 10+ years experience of working remotely, I agree 100% with this article. My observation has been that distributed teams work well when the majority of the team is remote. It makes written communication inevitable. However when I was the only remote person in a team of 4 or more people, I felt left out. Conference calls with everybody else on one side and me on the other were quite frustrating. I missed out on the informal watercooler talk and conversations in the team office. I never felt that remote work works well in an asymmetric situation.

On the other hand, I think every team benefits from clear written communications. Having a remote team enforces this best practice where having a co-located team lets communication practices slip and become sloppy.

As someone with far more experience with this than me, I'm interested in your perspective on a couple things that I've noticed: It seems to be more difficult to come to consensus in purely written communication, and more awkward for decision-makers to assert themselves. I'm not sure why this is true, or if it is only my anecdotal experience and outside the experience of most, but I've been in many long github/irc/whatever threads where parties seem to only grow increasingly intransigent, and many phone and in-person meetings where the same topic is dispensed with in less than 10 minutes of actual discussion. Is this phenomenon real in your experience? If so, have you found any good techniques for controlling it?

> It seems to be more difficult to come to consensus in purely written communication

I agree that some conflicts are much better handled via synchronous voice conversation. And I think that's acceptable, if not desirable. However, I make sure that after the call we write down some notes what decision we made, and why we decided the way we did. This makes sure that parties not present at the meeting (i.e. other developers, and our future selves) can pick up the context quickly and save us the pain of working through the decision process again.

And then there is always the issue of dysfunctional team communications where the channel doesn't matter. In asynch conversations poor/obstinate communicators don't need everybody in the room to keep adding to a controversial conversation. So you just can't stop them..

And I just learned a new word: 'in·tran·si·gent': unwilling or refusing to change one's views or to agree about something. Thanks.

> more awkward for decision-makers to assert themselves

That has probably more to do with team culture than the communication channel used. I'd think that a capable and respected decision maker can assert themselves easily via written word.

> However, I make sure that after the call we write down some notes what decision we made, and why we decided the way we did. This makes sure that parties not present at the meeting (i.e. other developers, and our future selves) can pick up the context quickly and save us the pain of working through the decision process again.

In the same way that you should comment your code with the "why" and not just the "what" you also should comment your non-code decisions with the "why" and not just the "what". Otherwise someone in the future will try to overhaul a process without knowing about some of the previous pitfalls that were discovered.

Thanks for your comment, and glad to be able to teach you a great word!

I've honestly never run into a person who is persistently obstinate in in-person conversations, but I've met many (including myself) who sometimes are in asynchronous text.

> That has probably more to do with team culture than the communication channel used. I'd think that a capable and respected decision maker can assert themselves easily via written word.

I think the second sentence of that is true, but that my point stands that it is more difficult for them to do so. I believe that's because facial language plays a large role in interactions, and even more so in potentially tense ones, and it can be very difficult to strike the right tone textually. It is much easier to get across "I've heard your point of view, but I'm taking my prerogative to make a different decision this time" without hurting feelings in person than it is in text.

It's very possible that it's just harder to run a remote-first team effectively and that's the trade-off you accept for the myriad benefits. That has been my perspective on it for awhile, but I'm always curious if there are ways to alleviate that cost.

The biggest nugget from this piece seems to be this:

> Remote-first communication that clearly documents problems encountered, ideas proposed, and decisions reached works best in organizations with strong no-blame cultures.

I like the idea that remote-first encourages a number of best practices, including a no-blame culture.

It does not encourage such a culture, this post is just suggesting that no-blame is a requirement to sustain a remote-first policy. You can more easily have a no-blame culture without artificial conditions like remote-first.

Actually, you're totally right. Thanks for the correction!

I worked on a team in IBM's Linux Technology Center that worked like this. We had people in several sites, and even those in the same site were spread across half a floor, not sitting anywhere near each other. So, in general, conversations occurred via IRC or mailing list, not in person, even between people at the same site. If a problem-solving session occurred in-person (often with a whiteboard), a specific person in that session (identified before the end of the session) would be responsible for writing up the result for the mailing list.

The only thing we'd ever handle primarily in person was going out to lunch as a group, which for obvious reasons only mattered to one site. And we almost never talked about work at those lunches.

I like the idea; it makes a lot of sense. In practice though, there are a LOT of times that it's much, much faster to communicate verbally. I feel like trying to really stick to this remote-first style might be more difficult/frustrating than it sounds.

Yes, it may make sense to talk on the phone, but I don't find that's a good strategy for first contact. Especially if people don't answer their phone or like to small talk.

there are a LOT of times that it's much, much faster to communicate verbally

If I want an answer now (if it's something that has an easy answer), and selfishly don't care about the flow of the other party, this may be true: You can prioritize a request by forcing it through synchronous voice mediums.

But even if we exclude that possible friction, it has been my experience that the belief that voice is more productive is often based upon superficial results (much as with meetings). People say some vague, uncertain things and both leave with a great feeling of accomplishment. Written communications, on the other hand, often requires more precision (if we wrote the way we spoke in such calls, the result would often be meaningless) -- you need to actually think about what you're asking, and give specifics. Not least because the medium demands it, but because this is a written, referenced, liable record, versus a call where each party can just vaguely claim miscommunication.

It's incredibly hard to study something like this, but my gut feeling (with the caveat that it's biased) is that the belief in the efficiency of voice communications is often based upon superficial results.

I work for a company that has two locations and a number of workers (including the CEO, who is quite hands-on) who work remotely the majority of time.

When I joined and introduced Basecamp which managed to de-siloed a whole lot of information, but required breaking old habits. The key change was ensuring the discussions and decisions which were being made offline either happened inside Basecamp, or were at least minuted there.

Recently this has had an interesting side-effect where some rebels are intentionally making decisions "off piste" for the avoidance of prolonged discussions.

Fantastic article and in the past seven months, we've been a basecamp user, then former basecamp user, as we switched to Trello. Ironically that was for cost, like switching from 3rd party to (finally) a home grown php tool to replace the Saas $200 fee.

Essentially, what we're seeing from my team's perspective are the culmination of a few trends that started being bigger back in 2003, when I first worked from home full time for about six months, prior to joining Yahoo at giving up the lifestyle for a few years. With nearly ~6.5 years in WFH experience; I've done it nearly half my professional career.

Those who can make it work, do it the way in the article, there's no option, only pain, to that process. It broke up a 12 year business partnership I had, in the end, written goals were broken, therefore, I ejected. Simple, straightforward and asynchronous. There's a movement, tempo to when a team is producing. My CTO and I are incredible partners this way, and we spend less than twenty minutes per session "Talking," because he's even more introvert than me, it seems.

At the end of the day, team's ship something. Marketers should be shipping business models, spreadsheets, powerpoints, Adwords copy, Blog Posts, Social Posts, Images, Videos and more. Engineers ship code, so, they rock and should have it a bit more straightforward.

Designers ship design. If the "Business monkey," isn't playing secretary, documenting things and helping others ship, OR shipping something with their fingerprints all over it, something is broken. For a production oriented individual, remote, WFH work is the most empowering kind.

Freedom. Run at your own pace, if the team gets slow, develop new skills, a new hobby and explore. The digital world is a vast place; for example, I'm building free, open source SaaS, running two blogs, a team, built two visual novels this month, learned Daz3d, Carrara, Gimp for animation & more.

I ship what and how I want, when I want & where. The team does the same, as a group, we have aligned objectives. So the business moves at one pace, and as an individual, I carve my own lane. Run ahead, scout, explore, learn and grow. Then perhaps, those skills in animation & 3d become useful to the business. Or not. Time will tell.

Great article, and thanks for posting your experiences. I love learning.

Reply on news.ycombinator.com