3 ms·
I'm going to disagree here. It's entirely possible to work effectively with others via mostly-asynchronous communication. Open source projects, as you point ou
by dasmoth 9y ago
I'm going to disagree here. It's entirely possible to work effectively with others via mostly-asynchronous communication. Open source projects, as you point out, can be a pretty good example of this. I'd further argue that for some (I suspect many...) people work much better when they can have long stints of focus without fear of interruptions.
Two-minute responses on Slack absolutely is a model that can work, and perhaps it's the easiest transition for people who've been working in a "teamy"/open-plan on-site setup. But I'm also convinced that it's not the only viable setup.
- rpazyaquian 9y agoOpen source projects don't have deadlines, product owners, antsy investors, runways, or quarterly goals, though.
- SaltySolomon 9y agoBut open source projects have no other way so they need to work that way, also there is little pressure to meet deadlines and such.
- bluGill 9y agoOpen source projects work that way because we have to, not because we want to. Large projects have semi-regular meetups/sprints where they can all get together face to face. Small one muddle through and try to prevent the problems not meeting face to face causes.
- wolco 9y agoLarge open source projects may meet other members at conferences but rarely do you find a situation where everyone can be in the same location/country at the same time.
- shostack 9y agoI think the main takeaway is that it all comes down to expectations. If the expectation of the team and the communication medium is rapid response (minutes vs. hours/days), and that expectation is not clearly communicated and agreed upon, you're going to have trouble. Likewise, if everyone knows that due to people's different time zones, schedules, etc. that 24hrs is a typical response window via email, there should be no complaints if responses aren't received more immediately.