8 ms·

Working remotely with 150+ people

130 points by mdeira 10y ago

jakozaur 10y ago
FWIW: The author is VP at GitLab. Somewhat similar to: http://asyncmanifesto.org/ http://asyncmanifesto.org/
dx034 10y ago
Any experience what single point of truth is useful with such a large group?
- jobvandervoort 10y ago
  In our case, we make sure that single source of truth is either a GitLab issue, for anything related to implementation or the handbook on our website for organisational matters [0]. [0]: https://about.gitlab.com/handbook/ https://about.gitlab.com/handbook/
maxxxxx 10y ago
It's a nice list but could be a little more specific. I have worked in purely remote teams and I found them to be highly functional. You need a certain type of self reliant people though and really strong leadership. Somebody has to make and have the power to enforce certain decisions that affect everybody.
- joeguilmette 10y ago
  Can you describe in more detail what really strong leadership looks like in a remote work environment?
  - maxxxxx 10y ago
    For example someone needs to decide how issues are tracked and define a process. That process then has to be followed by everybody. There can't be exceptions. In general I think remote teams benefit a lot from a central person who has final say and had the ego to push things through. Somebody like Linus for Linux. You can't have people like you see in a lot of companies that need endless meetings to make decisions.
    - k__ 10y ago
      This. I worked in a few remote teams and most had bad leadership. No process or it changed every month or it wasn't really used by anyone etc. No single source of truth. Some people write in slack, some in quip, some per mail, some in trello, some in github... I think people are trying to run remote teams like "local" ones and can't understand that they are different. "People have to sit in one room to be more productive" - "we need water cooler talk to get the word around" - blablabla They just want to be "managers" in title, but not do the work...
- jobvandervoort 10y ago
  I strongly agree about requiring self-reliant people. I actually wrote about this shortly after posting this on medium [0], but the TL;DR is that you (as manager) should make it extremely clear what is expected of everyone and that people should be very self-sufficient / independent. [0]: https://about.gitlab.com/2017/01/03/set-expectations/ https://about.gitlab.com/2017/01/03/set-expectations/
  - maxxxxx 10y ago
    They have to be independent but still flexible and not stubborn. In short you need high quality people.
    - BurningFrog 10y ago
      Sounds expensive.
      - Inthenameofmine 10y ago
        In my experience having any other type of people is generally more expensive because you are wasting higher level people on actively managing lower value tasks to get done.
        BurningFrog 10y ago
        Sure. But if you need higher quality people in a distributed team, that just means it is harder to get things done in such a team.
codingvelocity 10y ago
While i'm not 100% remote (i'm part of a small regional office that has a massive head office in another part of the country, but I can work from home). Something i've found incredibly important is jumping on video chat. There's something about seeing someone in a video while you talk to them that reminds you "hey i'm working with other humans, i should respond with a level of empathy i'd expect in return"
- exDM69 10y ago
  Are these individual or group chats? What kind of solution do you have? I work in a small office of a big company and have a 10 hour timezone difference to my most important co-workers. We chat on the phone but I don't really enjoy it. I'm not sure video chat would help, but I might be willing to try. But it would be slightly inconvenient because of the timezones. We might have 10-20 people from 5-10 locations around the world. This means that many participants call in from home before work in the morning or after work at night. That said, I'm quite happy working remotely mostly from home. I feel that travelling occasionally and meeting the people in person (and having lunch, dinner, beers together) makes it much easier to work together. There's no substitute for human contact.
  - 91bananas 10y ago
    If you're ok with the Google machine and spending way too much money on a computer that does basically nothing, there are these from Google[0] which have been great for me and my team. We have a Hangout open all day in the office, displayed on a 60" TV. Anyone that's working remote can jump in whenever and it's somewhat like they're in the office. Audio is my only complaint. Sometimes it is difficult to be heard [0]: https://chromebusinessdevices.withgoogle.com/products/1677/hp-chromebox-for-meetings-n3y38aa-aba-black https://chromebusinessdevices.withgoogle.com/products/1677/h...
    - fsavard 10y ago
      That's interesting. Are you aware of other teams using video chat like this, ie. all day long? Do you know what the Google monthly fees are? Is the bandwidth consumed a concern?
neebz 10y ago
We focussed a lot on async collaboration and unfortunately we get issues of team associations. You just miss out on any water cooler talk and struggle to build relationships with individual employees. This impacted our employee turnover massively even though we gave competitive salaries, flexible work hours and work-from-home.
- jobvandervoort 10y ago
  We do a few things to alleviate this, I'm not sure if they are enough for scale: 1. Daily call with everyone where we talk about our private lives for the most part (30m call, 28m private life talk: everyone has to tell something they did for fun last week) 2. Very active chat, with many non-work channels 3. A 'watercooler' hangout, where people join to just casually talk over video chat
  - wott 10y ago
    You're describing everything I hate, and which made me love remote to get rid of it. And you even increase the amount of time lost in those useless and horrible things.
- k__ 10y ago
  I have the feeling this water-cooler talk thing is mostly an issue if there is no focus or the management is bad. If everything is fine, I don't talk much "privately" with people at work and some "more social" individuals talk about their private things, when "at the cooler". If there are problems in management, we talk about these "at the cooler".
  - weatherstorme 10y ago
    Water-cooler talk is a way to bond with others. Some of my greatest friends were made at work, and this talk happens when we want a break. Usually getting food, coffee, or going to work out. Water-cooler talk isn't only there to bad mouth management, but to make connections/friends.
DoofusOfDeath 10y ago
After completing my CS master's degree, I was hired by my advisor as a full-time software developer. My job was to coordinate the efforts of the students contributing to his main project, keeping everything moving forward. For that job, I found that keeping things asynch was crucial. But so was keeping things lock-free. My basic premise was to never assume that any grad student would get any particular task done. So I tried to create an environment where any time they had a useful contribution, it could be merged into the main code base. But to never put one student at the mercy of another. I think that worked pretty well.
- deleted 10y ago
  [deleted]
- Inthenameofmine 10y ago
  That sounds very interesting. Could you go into more depth what techniques you exactly used?
- huherto 10y ago
  Generalizing this idea. Interdependences are big source of problems and delays in projects. Many people don't realize it, but you have to actively work on eliminating them. You see it in the form people waiting for other people. Every team should be organized in a way that they can we do their work without waiting for other teams.
  - nradov 10y ago
    Yes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams. In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.
    - brilliantcode 10y ago
      This is very interesting. Can you elaborate more on such organizational structure or know of anyone implementing in real life? To me it totally makes sense. Instead of the inevitable interdependency that arises through the component model, I can see that if teams were building features on their own than it could be completed at their leisure (in the budget & time affordable) without the multi-directional multi-disciplinary communication shitshow. I wonder if there is an official name for this feature teams model or more guide on how to implement it.
tcrews 10y ago
I've been working remotely for 2 years now and my team has people from all over the world. People mostly talk on IRC but not a lot (about important stuff) and there is a HUGE number of periodic meetings. I can't stand them. What's worse, every time things start to appear to be going off track, the initial reaction is to always set up a new periodic meeting about topic X... this is supposed to bring people together but useful interaction never happens on meetings (too many people trying to save face). It's horrible. When talking to external partners, our management brags about having a remote team with people from all over the world, but I don't think they understand how to make this work. Sometimes I feel we should all be in a single office because of this, but then I remember other companies have figured this out so I don't have to feel bad about wanting to work remotely.
- jobvandervoort 10y ago
  Periodic meetings mean the end to remote work. Avoid them whenever possible. I try to be proactive about cancelling the periodic meetings that we do have, whenever there's nothing to talk about. Traditional meeting strategies also work well: never start a meeting without an agenda, set a short and fixed time slot for it and always end when the time is over.
- dhd415 10y ago
  My team has a daily 15-minute scrum meeting that I haven't found overly burdensome. We're spread over a 4-hour time difference, so the time of day isn't really an imposition on anyone. It's also no big deal if someone misses from time to time but I've found it generally helpful for keeping up with what the team is doing.
brilliantcode 10y ago
I keep hearing the word async come in these remote working threads, what does that mean exactly in this context? What does this single source of truth look like? A google docs spec?
- gedrap 10y ago
  Async means reducing likelihood that your work will be blocked by someone else (e.g. waiting for response from someone) as it might cause big issues when someone is 10 hours away. If you can't get any work done because you are waiting for someone who is sleeping, that's really bad. Single source of truth can be google doc, wiki, github issues/wiki, whatever. As long as it's single. The problem is when critical information is scattered in slack history, github issues and PRs, wiki and some odd google doc. It makes it hard to find information and you will end up finding contradictory information. Lack of single source of truth or not updating one will reduce the async property of the whole operation, among other things.
- dsr_ 10y ago
  Synchronous methods of communication are phone calls, conference calls, in-person meetings, and anything else that requires that two or more people attend the same "event" at the same time. Async is everything else: email, IM, leaving voicemail, blog posts, git comments, tickets, bug reports...
- dozzie 10y ago
  Synchronous communication happens when one participant says/sends something and then waits for the other participant to reply doing nothing else. Exactly the same as with synchronous function call: you order some operation and wait patiently for it to return the result. Asynchronous communication is when one participant sends something and leaves things as that. For a reply, either another (asynchronous) message is sent, this time in the opposite order, or the sender checks if the reply arrived. Real-time communication, like phone calls, video conferences, and various chats and communicators are synchronous by the very nature of the activity of conversation. Everything that you may postpone checking is asynchronous; e-mail, tickets/issues, and source code commits are like that.

130 points by mdeira 10y ago

jakozaur 10y ago

FWIW: The author is VP at GitLab. Somewhat similar to: http://asyncmanifesto.org/ http://asyncmanifesto.org/

dx034 10y ago

Any experience what single point of truth is useful with such a large group?

jobvandervoort 10y ago
In our case, we make sure that single source of truth is either a GitLab issue, for anything related to implementation or the handbook on our website for organisational matters [0]. [0]: https://about.gitlab.com/handbook/ https://about.gitlab.com/handbook/

maxxxxx 10y ago

It's a nice list but could be a little more specific. I have worked in purely remote teams and I found them to be highly functional. You need a certain type of self reliant people though and really strong leadership. Somebody has to make and have the power to enforce certain decisions that affect everybody.

joeguilmette 10y ago
Can you describe in more detail what really strong leadership looks like in a remote work environment?
- maxxxxx 10y ago
  For example someone needs to decide how issues are tracked and define a process. That process then has to be followed by everybody. There can't be exceptions. In general I think remote teams benefit a lot from a central person who has final say and had the ego to push things through. Somebody like Linus for Linux. You can't have people like you see in a lot of companies that need endless meetings to make decisions.
  - k__ 10y ago
    This. I worked in a few remote teams and most had bad leadership. No process or it changed every month or it wasn't really used by anyone etc. No single source of truth. Some people write in slack, some in quip, some per mail, some in trello, some in github... I think people are trying to run remote teams like "local" ones and can't understand that they are different. "People have to sit in one room to be more productive" - "we need water cooler talk to get the word around" - blablabla They just want to be "managers" in title, but not do the work...
jobvandervoort 10y ago
I strongly agree about requiring self-reliant people. I actually wrote about this shortly after posting this on medium [0], but the TL;DR is that you (as manager) should make it extremely clear what is expected of everyone and that people should be very self-sufficient / independent. [0]: https://about.gitlab.com/2017/01/03/set-expectations/ https://about.gitlab.com/2017/01/03/set-expectations/
- maxxxxx 10y ago
  They have to be independent but still flexible and not stubborn. In short you need high quality people.
  - BurningFrog 10y ago
    Sounds expensive.
    - Inthenameofmine 10y ago
      In my experience having any other type of people is generally more expensive because you are wasting higher level people on actively managing lower value tasks to get done.
      - BurningFrog 10y ago
        Sure. But if you need higher quality people in a distributed team, that just means it is harder to get things done in such a team.

codingvelocity 10y ago

While i'm not 100% remote (i'm part of a small regional office that has a massive head office in another part of the country, but I can work from home). Something i've found incredibly important is jumping on video chat. There's something about seeing someone in a video while you talk to them that reminds you "hey i'm working with other humans, i should respond with a level of empathy i'd expect in return"

exDM69 10y ago
Are these individual or group chats? What kind of solution do you have? I work in a small office of a big company and have a 10 hour timezone difference to my most important co-workers. We chat on the phone but I don't really enjoy it. I'm not sure video chat would help, but I might be willing to try. But it would be slightly inconvenient because of the timezones. We might have 10-20 people from 5-10 locations around the world. This means that many participants call in from home before work in the morning or after work at night. That said, I'm quite happy working remotely mostly from home. I feel that travelling occasionally and meeting the people in person (and having lunch, dinner, beers together) makes it much easier to work together. There's no substitute for human contact.
- 91bananas 10y ago
  If you're ok with the Google machine and spending way too much money on a computer that does basically nothing, there are these from Google[0] which have been great for me and my team. We have a Hangout open all day in the office, displayed on a 60" TV. Anyone that's working remote can jump in whenever and it's somewhat like they're in the office. Audio is my only complaint. Sometimes it is difficult to be heard [0]: https://chromebusinessdevices.withgoogle.com/products/1677/hp-chromebox-for-meetings-n3y38aa-aba-black https://chromebusinessdevices.withgoogle.com/products/1677/h...
  - fsavard 10y ago
    That's interesting. Are you aware of other teams using video chat like this, ie. all day long? Do you know what the Google monthly fees are? Is the bandwidth consumed a concern?

neebz 10y ago

We focussed a lot on async collaboration and unfortunately we get issues of team associations. You just miss out on any water cooler talk and struggle to build relationships with individual employees. This impacted our employee turnover massively even though we gave competitive salaries, flexible work hours and work-from-home.

jobvandervoort 10y ago
We do a few things to alleviate this, I'm not sure if they are enough for scale: 1. Daily call with everyone where we talk about our private lives for the most part (30m call, 28m private life talk: everyone has to tell something they did for fun last week) 2. Very active chat, with many non-work channels 3. A 'watercooler' hangout, where people join to just casually talk over video chat
- wott 10y ago
  You're describing everything I hate, and which made me love remote to get rid of it. And you even increase the amount of time lost in those useless and horrible things.
k__ 10y ago
I have the feeling this water-cooler talk thing is mostly an issue if there is no focus or the management is bad. If everything is fine, I don't talk much "privately" with people at work and some "more social" individuals talk about their private things, when "at the cooler". If there are problems in management, we talk about these "at the cooler".
- weatherstorme 10y ago
  Water-cooler talk is a way to bond with others. Some of my greatest friends were made at work, and this talk happens when we want a break. Usually getting food, coffee, or going to work out. Water-cooler talk isn't only there to bad mouth management, but to make connections/friends.

DoofusOfDeath 10y ago

After completing my CS master's degree, I was hired by my advisor as a full-time software developer. My job was to coordinate the efforts of the students contributing to his main project, keeping everything moving forward. For that job, I found that keeping things asynch was crucial. But so was keeping things lock-free. My basic premise was to never assume that any grad student would get any particular task done. So I tried to create an environment where any time they had a useful contribution, it could be merged into the main code base. But to never put one student at the mercy of another. I think that worked pretty well.

deleted 10y ago
[deleted]
Inthenameofmine 10y ago
That sounds very interesting. Could you go into more depth what techniques you exactly used?
huherto 10y ago
Generalizing this idea. Interdependences are big source of problems and delays in projects. Many people don't realize it, but you have to actively work on eliminating them. You see it in the form people waiting for other people. Every team should be organized in a way that they can we do their work without waiting for other teams.
- nradov 10y ago
  Yes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams. In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.
  - brilliantcode 10y ago
    This is very interesting. Can you elaborate more on such organizational structure or know of anyone implementing in real life? To me it totally makes sense. Instead of the inevitable interdependency that arises through the component model, I can see that if teams were building features on their own than it could be completed at their leisure (in the budget & time affordable) without the multi-directional multi-disciplinary communication shitshow. I wonder if there is an official name for this feature teams model or more guide on how to implement it.

tcrews 10y ago

I've been working remotely for 2 years now and my team has people from all over the world. People mostly talk on IRC but not a lot (about important stuff) and there is a HUGE number of periodic meetings. I can't stand them. What's worse, every time things start to appear to be going off track, the initial reaction is to always set up a new periodic meeting about topic X... this is supposed to bring people together but useful interaction never happens on meetings (too many people trying to save face). It's horrible. When talking to external partners, our management brags about having a remote team with people from all over the world, but I don't think they understand how to make this work. Sometimes I feel we should all be in a single office because of this, but then I remember other companies have figured this out so I don't have to feel bad about wanting to work remotely.

jobvandervoort 10y ago
Periodic meetings mean the end to remote work. Avoid them whenever possible. I try to be proactive about cancelling the periodic meetings that we do have, whenever there's nothing to talk about. Traditional meeting strategies also work well: never start a meeting without an agenda, set a short and fixed time slot for it and always end when the time is over.
dhd415 10y ago
My team has a daily 15-minute scrum meeting that I haven't found overly burdensome. We're spread over a 4-hour time difference, so the time of day isn't really an imposition on anyone. It's also no big deal if someone misses from time to time but I've found it generally helpful for keeping up with what the team is doing.

brilliantcode 10y ago

I keep hearing the word async come in these remote working threads, what does that mean exactly in this context? What does this single source of truth look like? A google docs spec?

gedrap 10y ago
Async means reducing likelihood that your work will be blocked by someone else (e.g. waiting for response from someone) as it might cause big issues when someone is 10 hours away. If you can't get any work done because you are waiting for someone who is sleeping, that's really bad. Single source of truth can be google doc, wiki, github issues/wiki, whatever. As long as it's single. The problem is when critical information is scattered in slack history, github issues and PRs, wiki and some odd google doc. It makes it hard to find information and you will end up finding contradictory information. Lack of single source of truth or not updating one will reduce the async property of the whole operation, among other things.
dsr_ 10y ago
Synchronous methods of communication are phone calls, conference calls, in-person meetings, and anything else that requires that two or more people attend the same "event" at the same time. Async is everything else: email, IM, leaving voicemail, blog posts, git comments, tickets, bug reports...
dozzie 10y ago
Synchronous communication happens when one participant says/sends something and then waits for the other participant to reply doing nothing else. Exactly the same as with synchronous function call: you order some operation and wait patiently for it to return the result. Asynchronous communication is when one participant sends something and leaves things as that. For a reply, either another (asynchronous) message is sent, this time in the opposite order, or the sender checks if the reply arrived. Real-time communication, like phone calls, video conferences, and various chats and communicators are synchronous by the very nature of the activity of conversation. Everything that you may postpone checking is asynchronous; e-mail, tickets/issues, and source code commits are like that.