14 ms·

Gitlab's Guide to All-Remote

582 points by allie1 7y ago

wpietri 7y ago
I appreciate they have a whole section on disadvantages, but this stands out to me: "All-remote companies should consider meetings as a last resort, instead relying on asynchronous collaboration tools[...]" To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion. I know that some remote-first companies tend to group related work by timezone, so that teams can be both distributed and low latency. I take it Gitlab isn't one of those?
- tobr 7y ago
  With async communication it’s hard to know if everyone got it. If you’re in some kind of synchronous meeting, everyone knows what everyone knows, and it’s usually more clear if people are confused or come from very different POVs, or don’t have the time, attention or other resources they need to get things done. Async communication often feels like shouting into a void, hoping that the right people saw it in time and prioritized it appropriately.
  - tastroder 7y ago
    > If you’re in some kind of synchronous meeting, everyone knows what everyone knows, I feel like while that's generally true, it depends. Not only because you might underestimate my ability to sleep with my eyes open. I've seen quite a few projects where in-person meetings were either badly planned, went overboard in terms of frequency / number of participants, or people were simply inattentive for other reasons. There's lots of scenarios where communication devolves to the point of asynchronous communication despite meeting face to face. Quite a few meeting forms type up notes or minutes for a reason. Many meetings in my experience are just superfluous "I felt like talking" scenarios, which is fine but it certainly does not make for a great communication strategy. I'd say it depends on who would meet, for many groups other forms of communication like e-mail/IRC/slack work just fine for a majority of issues without introducing much friction. But sure, for others it might break down completely.
    - blaser-waffle 7y ago
      Amen. I've had meetings where 15 people showed up, and everyone walked out with 15 different recollections as to what was done. At least one of those 15 isn't going to read the meeting notes that get emailed out after the fact, so we're going to have to rehash the same shit in a week or two.
  - icebraining 7y ago
    You don't have to "hope". You can just ask them to read and reply appropriately (even if it's just with an "ok" or equivalent). Initially you might have to prod them explicitly, but people adjust rapidly and start acknowledging on their own.
- bboozzoo 7y ago
  > I know that some remote-first companies tend to group related work by timezone, so that teams can be both distributed and low latency. I take it Gitlab isn't one of those? Probably depends on the team, individuals being able to self-organize and their experience. While some companies may see timezone distributed teams as disadvantage, I believe it is an opportunity to have a continuity of work and getting things done faster than if you had a single 6-8h time slot.
  - wpietri 7y ago
    Having experienced a manager with a "sun-never-sets-on-my-empire" fixation, I'm skeptical. In theory, you can get 3 shifts in where there was one before. But this isn't a factory. For knowledge work, there's a big problem with handoffs. If somebody is going to pick up coding right where I left off, I need to transfer a lot of state from my head to theirs. At best, this takes a lot of time. But what's more likely is that things get In software our true enemy isn't time, it's error. It takes seconds to create a bug, but often takes hours or days to remove it. It takes minutes to misunderstand the purpose of a feature, but days or weeks to rework the code to match actual need. I think if we want to get more people at the coalface, the right solution isn't working in shifts. (If it were, we would already be working in shifts without regard to timezone, just like factories do.) Instead, it's to increase collaboration, which requires much more synchronous communication. E.g., techniques like collective code ownership, pair programming, frequent pair rotation, cross-functional teams, small units of work, continuous delivery, and very frequent releases (daily or more often). Since very few people work like that, I think it's reasonable to assume that faster results are not in fact a priority for most businesses. So the "distributed timezones are an advantage" to me sounds like an after-the-fact justification, not an actual solution to a problem.
- minipci1321 7y ago
  > To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. This is not an implication by all means. Low-skilled not very well incentivized junior team (let's call it so in absence of better terms) needs more/most "in-person collaboration". Team of experts to whom the goals and the overall vision have been conveyed, who knows how to put it to practice, will give the shortest latency in async flows. Don't take it as a personal attack, but people valuing high live discussions, are frequently those on the receiving end of it.
  - nhumrich 7y ago
    If that were true, why does every director/principal/VP/ceo spend almost the entire week in meetings?
    - scruple 7y ago
      The cynical take is that this is a rhetorical question.
  - wpietri 7y ago
    That's one thing that can happen, but it's not the only thing. What you're describing is a push model. Somebody on high creates a vision and assigns goals. Workers are just seen turning that into outputs. It's a common way to work, especially in "known problem/known solution" projects, but it has its flaws. See Cutler on "feature factories", for example. Or Blank's "Four Steps to the Epiphany". But what if the solution or perhaps the problem is unknown? Push systems don't work. Instead, I favor cross-functional teams that pursue outcomes (as opposed to outputs). In that context, the vision is a living thing, created collaboratively, as is the plan. Problems are explored, and solutions discovered. The speed at which a team can learn and test solutions is limited by communications latency. And of course experts aren't born that way. Even if you're in a "known problem/known solution" space, sustainable companies need to find ways to turn novices into experts. Again, that's about learning, which does not work well in high-latency environments.
- vaylian 7y ago
  > To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion. But even when you work in the same building you still have to find a time slot that fits for a meeting. Of course, you can also drop by the other's office and hope to find them ready for a chat, but there's no guarantee. And for remote companies I imagine that people actually have more time slots open for (video)chats, because people don't have to allocate extra time to travel between meeting rooms. Of course, the dynamics of a live discussion are somewhat different from a digital discussion. But I think the availability/latency issue is a misconception.
  - wpietri 7y ago
    > But even when you work in the same building you still have to find a time slot that fits for a meeting. That is definitely not the only way to work. A cross-functional team sitting together and focused on outcomes can be much more organic than that. Think of the writer's room for a show, for example. That can sound weird, but Devin's "Artful Making" does a good job explaining the parallels between knowledge work and how theater/TV/movie people work.
- mic47 7y ago
  > To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. First, it's high latency, not extremely high latency. Second, it has huge advantages: 1.) While latency (in terms of how quickly you finish task) will increase, your bandwidth will increase too. Everyone get more done. 2.) With asynchronous communication, you are not interrupted by communication, you can do it in bulk. In case there is something urgent, you always can do a call, or synchronous chat.
  - clarry 7y ago
    > 1.) While latency (in terms of how quickly you finish task) will increase, your bandwidth will increase too It has to increase to make up for the round trips you can't afford: you try to communicate more information in one batch. Whether this is good or bad really depends. On one hand, I think it just forces communication to be better, on the other hand you might waste time communicating things that you'd immediately find to be unnecessary if you were interacting live with the other party.
  - wpietri 7y ago
    It sounds like you're focused on maximizing output. I'm more interested in maximizing outcome. As to high vs extremely high, I'm not sure arguing over relative terms is useful. But just so it's clear what I mean: If I'm working in a team room with colleagues, my average latency between request and response is, say 15 seconds. But in globally distributed remote work situations, a much longer lag is not uncommon. E.g., when I was working with European colleagues, it was typical to get a response the next working day. That's about 5000 times longer, which seems pretty extreme to me.
sschueller 7y ago
I find it interesting how they achieve this and it also gives people in remote places the ability to work for such a company. What I don't agree with is the pay scale they use based on your location. If you have the same skills, you should be paid the same.
- _pmf_ 7y ago
  > If you have the same skills, you should be paid the same. That would be highly unfair.
- C1sc0cat 7y ago
  That's one of the advantages from an employers POV - and sorry salary is set by market forces.
- earnubs 7y ago
  The regional coefficients they use to set salary are a real turn off. https://about.gitlab.com/salary/data.json https://about.gitlab.com/salary/data.json
  - luch 7y ago
    This is really interesting data ! I for once would like to know why they refuse to hire contractors from Western Europe (is it a legal thing ?) : {"country":"*","contractor_factor":1.17,"entity":"GitLab BV"}], "countryNoHire": ["Iran","North Korea","Crimea","Syria","Sudan","Cuba","France","Italy","Brazil","Spain","Romania","United Arab Emirates","Sweden","Argentina","Philippines","Austria"],
    - skissane 7y ago
      I totally understand why a company won't hire from Iran, North Korea, Syria, Sudan, Cuba, Crimea – exposure to US sanctions threatens to cause severe negative repercussions. But, why single out France, Italy, Spain, Romania, Sweden and Austria out of EU member states? What problems do they have which other EU member states lack? Similarly, if Argentina and Brazil are a problem, what about Chile, Uruguay, Paraguay, Venezuela, Colombia, Ecuador, Bolivia, Guyana, Suriname, etc? Likewise, why would UAE be a problem, but not Iraq, Kuwait, Saudi Arabia, Qatar, Oman, Yemen, Jordan, etc?
esseti 7y ago
Is there a way to generate an ebook for kindle? I would love to read it all
- philshem 7y ago
  I use the "push to kindle" browser extension for online content, which seems to work fine for this page: https://pushtokindle.fivefilters.org/send.php?url=https%3A%2F%2Fabout.gitlab.com%2Fcompany%2Fculture%2Fall-remote%2Fguide%2F https://pushtokindle.fivefilters.org/send.php?url=https%3A%2... The content is sent to the Kindle via the email service: https://www.amazon.com/gp/sendtokindle/email https://www.amazon.com/gp/sendtokindle/email Depending on your Kindle settings, you may have to set the FROM address in the push-to-kindle page.
  - esseti 7y ago
    the fact is that generates the ebook fro that page only. i would love to have the whole ebook
  - ukyrgf 7y ago
    If you just go up one category you'd see you don't need a third party tool: https://www.amazon.com/gp/sendtokindle https://www.amazon.com/gp/sendtokindle
    - philshem 7y ago
      I had searched the Firefox Add-on catalog and the official tool has never shown up: https://addons.mozilla.org/en-US/firefox/search/?platform=windows&q=send%20to%20kindle https://addons.mozilla.org/en-US/firefox/search/?platform=wi... Interestingly, the link from Amazon, clicked through your link, is dead https://addons.mozilla.org/en-US/firefox/addon/sendtokindle/ https://addons.mozilla.org/en-US/firefox/addon/sendtokindle/
      - philshem 7y ago
        https://web.archive.org/web/20171010081410/https://addons.mozilla.org/en-US/firefox/addon/sendtokindle/ https://web.archive.org/web/20171010081410/https://addons.mo... seems poorly rated when it was available 3 years ago
ram_rar 7y ago
I always used to hated remote work. Nothing like in person, face to face conversations to get things done. Due to coronovirus, for the past few days have been working remotely. Its surprising that things are going smoothly. I feel, its mostly due to that fact that everyones remote right now. But I'm guessing, there has to be an inflection point in the team, where this is achievable. Not sure, what it is though.
znq 7y ago
Our Company Handbook for Remote Work https://mobilejazz.com/company-handbook-pdf/ https://mobilejazz.com/company-handbook-pdf/ Other HN members have pointed out previously, that it looks like a landing page where you need to leave your e-mail address. You don't. You can download the PDF from here directly.
- Cthulhu_ 7y ago
  Why do you have it as a PDF hidden behind a call-to-action reminiscent of a sign-up though? Turn it into a website, that'll make it a lot more accessible - assuming getting people to read it is the goal, of course.
  - znq 7y ago
    Simple cost/result calculation. Creating a PDF + simple web page was something our designer can do easily. Developing a whole website around would have been much more expensive.
wildchild 7y ago
Oh lol at that ukrainian untermensch riding hype.
jungong 7y ago
Also, Gitlab's remote work emergency plan is a good read too > https://about.gitlab.com/company/culture/all-remote/remote-work-emergency-plan/ https://about.gitlab.com/company/culture/all-remote/remote-w...
Alex_P13 7y ago
Thanks for sharing
beyondcompute 7y ago
Don’t forget firing some people based on their nationality. Gitlab’s good at that!
- Cthulhu_ 7y ago
  Isn't that because of US sanctions? Blame them.
- oehtXRwMkIs 7y ago
  Not really their fault is it? It's more of the fault of US policy in general.
- rossmohax 7y ago
  Not only that. Director of compliance resigns because she needs to explain why she advices to walk off from non compliant contracts. Yeah, and in the spirit of true openness her coment about that is deleted.
cranekam 7y ago
Any Gitlabbers here? I'm looking for SRE work and Gitlab looks great, aside from never having any job openings..
- AngeloAnolin 7y ago
  Not a Gitlabber, but they post their openings here [0] [0] https://about.gitlab.com/jobs/apply/ https://about.gitlab.com/jobs/apply/
jpincheira 7y ago
I think that what's key here, especially during the current crisis, is to support businesses as much as we can to switch to WFH in the best possible way, with a simple process, and by helping them to stay engaged, hopefully without the need to make them all jump into real-time video calls many times through the day and lose focus. At our company [1], we've been receiving an incredible amount of inbound. People really need tools that don't get in the way —we're a video-first async comm platform— and I'm happy our team is being able to help these companies switching to WFH. The team and I are happy to help anyone with setting a basic process of communication for companies moving to WFH during these weeks. Just write to me at jp@standups.io and we'll be happy to jump in a call and see how we can help. [1] https://standups.io https://standups.io
rdsubhas 7y ago
How do people whiteboard remotely? This is a big problem for many development teams. Sometimes you just want to open a blank whiteboard and scribble some boxes and brainstorm or troubleshoot some things. The whiteboard is an inseparable part of nearly every meeting. And no, remote "canvas" whiteboards don't work. They end up looking like this: https://cdn.drawception.com/images/panels/2015/3-3/jLndYAfNfR-12.png https://cdn.drawception.com/images/panels/2015/3-3/jLndYAfNf.... Is there anything good that really solves this problem?
- joppy 7y ago
  Get some kind of device with a stylus (drawing tablet, iPad, Surface, etc) and use that to whiteboard. I think remote canvas whiteboards do work, you just need the proper tools to use them.
- sethammons 7y ago
  Use a Wacom tablet or iPad with a stylus. Drawing with a mouse or trackpad is the problem. We use Zoom's whiteboard feature, but any online canvas could work. The Zoom option is interesting for us because we have the interactive boards in our office so remoties and in-office people can draw on the same thing.
- lampe3 7y ago
  The question is why do you need a whiteboard? What problem is the whiteboard solving? Drawing freely with a mouse is something that can be done but also you have tools like draw.io if you need to draw something.
  - cyphar 7y ago
    Whiteboards are absolutely indispensable for communicating ideas quickly in a small group of people. It's effectively just a bigger (and easier to erase) version of grabbing a scrap of paper to scribble something down when explaining or describing something to someone else. I'm honestly more surprised that this isn't a universally known concept on HN. Scribbling on scraps of paper is something most people in western countries have done since pre-school.
abinaya_codes 7y ago
Appreciate the guide coming from Gitlab. Gitlab is one of my inspiration to start my remote company[1] which also helps remote job seekers. [1] - https://remoteleaf.com https://remoteleaf.com
adolfoabegg 7y ago
From the manifesto: The results of work over the hours put in. How do you adapt that to the scrum process which has a burndown chart based in the time spent on tickets.
- sytse 7y ago
  At Gitlab we try to reduce the scope of tickets so that they all ship in the same sprint. We measure efficiency by measuring the MR rate, the number of merge requests in a month devided by the number of engineers. To game the number you have to split work up in smaller Parts which helps cycle time, coordination, predictability, and quality, for example smaller changes are easier to review.
- joeconway 7y ago
  Scrum burndowns should not be related to time spent at all. That’s not an actual agile technique, that’s your company not trusting you and not understanding how software works. Story points that are meant to represent unknowns and complexity, not hours, used for estimation and burndowns are one solution to this
- roneesh 7y ago
  That isn't agile. Tickets should be based on relative effort, not hours, and certainly not more hours being better.
- deleted 7y ago
  [deleted]
- xtat 7y ago
  when are we going to burndown agile
globular-toast 7y ago
Gitlab's remote manifesto speaks to me in so many ways. I'd also love to work for Gitlab anyway. But, alas, I don't know Ruby on Rails and I think it's too late for me to gain the proficiency that I'd require for my expected salary from Gitlab. Are there any fully remote companies doing Python?
- whoisjuan 7y ago
  If you know Python you can easily learn Ruby. Not hard to do that transition. Although not similar they share the same idiomatic programming principles drawn from languages like Perl. Also, Ruby was inspired by Python: "I was talking with my colleague about the possibility of an object-oriented scripting language. I knew Perl (Perl4, not Perl5), but I didn't like it really, because it had the smell of a toy language (it still has). The object-oriented language seemed very promising. I knew Python then. But I didn't like it, because I didn't think it was a true object-oriented language – OO features appeared to be add-on to the language. As a language maniac and OO fan for 15 years, I really wanted a genuine object-oriented, easy-to-use scripting language. I looked for but couldn't find one. So I decided to make it." - Matasamoto.
- dosethree 7y ago
  Ruby is easy a fuck to learn. And it’s fun! It was influenced by Python, give it a shot
rickspencer3 7y ago
Just my opinion, but based on running remote and semi-remote teams since 2008 ... fully or mostly remote engineering teams are a competitive advantage, so, by definition, organizations that choose not to adapt to this reality will have a hard time competing. Organizations can have a personal preference for co-located work, but, I think the marketplace will select those organizations out. I think this will unfold over single digit number of years. From what I have observed, most of the resistance to remote work is really driven from the top; by less adaptable leaders.
- pythonaut_16 7y ago
  I think if things flip and remote becomes the primary, and co-location becomes rare we'll also see some companies that are able to use co-location as a competitive advantage. But I agree that remote (and the practices it encourages) are currently a competitive advantage.
  - lkozloff 7y ago
    I don't think you're wrong here. Remote itself does unlock advantages that aren't accessible to colocated companies (e.g. hiring anywhere), but one of the primary things that remote-practices unlock are surrounding communication. Organizations approaching remote have a helpful speedbump that encourages them to take an intentional look at the way they disseminate information. Being fully remote is an accountability structure that helps ensure that everyone is following those practices. There's nothing that would prevent a well-run colocated company from capturing those particular advantages, but such a company would probably slowly drift remote as companies like Buffer (and GitLab!) have as they grow and look for new talent.
Shivetya 7y ago
One issue I heard coming up recently is bandwidth many companies have to support remote access is not capable of dealing with a majority doing so. Then there are those using by license VPN solutions having insufficient simultaneous access. I am used to the web ex approach for collaboration but again this is limited by bandwidth issues. if anything hopefully this shows people how many meetings are just unnecessary
aantix 7y ago
10. Pay the engineer substantially less for the "privilege" of working remotely.
motohagiography 7y ago
Regarding the principles: >> 3. Writing down and recording knowledge over verbal explanations. 4. Written down processes over on-the-job training. 5. Public sharing of information over need-to-know access. 6. Opening up every document for editing by anyone over top-down control of documents. 7. Asynchronous communication over synchronous communication. These remote work principles have the direct, or side effect of breaking organizations that are "moral mazes," and hyper political bureaucracies. The reason organizations suck is because managers just talk instead of producing data, which is basically conspiring to steal value instead of creating it for the organization. I see this today, where I make an email request, and the person follows up with a phone call, then misrepresents what was agreed to on the phone to others. At one site, I literally stopped answering my phone for anyone I didn't directly work for, because I knew those people were just using the verbal channel to create uncertainty about what was said and leverage the resulting confusion. The WIFO rule solves a lot of org problems. (write it, or f-off).
- andycowley 7y ago
  So much this. I left my last employer because of just this. A 'fat waist' of middle-management that delivered no value and created nothing but inertia. Major incidents were a shambles of managers demanding updates over a conference call while engineers couldn't communicate effectively. Ugh
- pfranz 7y ago
  > I see this today, where I make an email request, and the person follows up with a phone call, then misrepresents what was agreed to on the phone to others. I know this misses your point, but both at work and outside I've gotten into the practice of emailing immediately after a phone call with a summary of the phone call. It's kind of a lawyerly thing to do, but it's a contemporaneous documentation of the phone call you can point to later.
Joof 7y ago
Do any companies think they will keep doing remote after COVID? I have delayed sleep phase disorder (sleep-in late; fixed by camping / sunlight) and live in a van in (roughly) CO, so the perfect job for me is working remote with a team in San Francisco. I currently work in-office with a fairly major start-up.
- techbio 7y ago
  I see so many people making the point that they have some syndrome and so they need x, y, z in a job. Valid, I'm sure, personally well-considered, true and everything, but still, indicative of a person who's problems are more important to them than the ones the company is hiring for.
  - Joof 7y ago
    So, funny thing. My problems are more important to me than the ones the company is hiring for. Especially given that solving my problems makes me more productive for the company. Seems rational unless I'm actually trying to do the 'selling myself / interview' part.
    - techbio 7y ago
      Fancy name, dude, but a lot of people would rather sleep in.
danielvlopes2 7y ago
We've received a ton of questions on how to manage teams remotely this week as well. We decided to make our eBook on "Managing Remote Teams" free, to help ease the transition for teams moving to WFH. This 60+ pages book is the result of months of research and interviews with successful remote companies (it’s usually a part of our paid product). We collected tips on pretty much everything, from onboarding to communication best-practices, to tools you should consider. https://knowyourteam.com/m/managing_remote_teams https://knowyourteam.com/m/managing_remote_teams
devreps 7y ago
Based on data we collected from 297 remote managers and employees, here are 11 free chapters of best practices on how to manage a remote team. https://knowyourteam.com/m/managing_remote_teams https://knowyourteam.com/m/managing_remote_teams

582 points by allie1 7y ago

I appreciate they have a whole section on disadvantages, but this stands out to me: "All-remote companies should consider meetings as a last resort, instead relying on asynchronous collaboration tools[...]" To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion. I know that some remote-first companies tend to group related work by timezone, so that teams can be both distributed and low latency. I take it Gitlab isn't one of those?

tobr 7y ago
With async communication it’s hard to know if everyone got it. If you’re in some kind of synchronous meeting, everyone knows what everyone knows, and it’s usually more clear if people are confused or come from very different POVs, or don’t have the time, attention or other resources they need to get things done. Async communication often feels like shouting into a void, hoping that the right people saw it in time and prioritized it appropriately.
- tastroder 7y ago
  > If you’re in some kind of synchronous meeting, everyone knows what everyone knows, I feel like while that's generally true, it depends. Not only because you might underestimate my ability to sleep with my eyes open. I've seen quite a few projects where in-person meetings were either badly planned, went overboard in terms of frequency / number of participants, or people were simply inattentive for other reasons. There's lots of scenarios where communication devolves to the point of asynchronous communication despite meeting face to face. Quite a few meeting forms type up notes or minutes for a reason. Many meetings in my experience are just superfluous "I felt like talking" scenarios, which is fine but it certainly does not make for a great communication strategy. I'd say it depends on who would meet, for many groups other forms of communication like e-mail/IRC/slack work just fine for a majority of issues without introducing much friction. But sure, for others it might break down completely.
  - blaser-waffle 7y ago
    Amen. I've had meetings where 15 people showed up, and everyone walked out with 15 different recollections as to what was done. At least one of those 15 isn't going to read the meeting notes that get emailed out after the fact, so we're going to have to rehash the same shit in a week or two.
- icebraining 7y ago
  You don't have to "hope". You can just ask them to read and reply appropriately (even if it's just with an "ok" or equivalent). Initially you might have to prod them explicitly, but people adjust rapidly and start acknowledging on their own.
bboozzoo 7y ago
> I know that some remote-first companies tend to group related work by timezone, so that teams can be both distributed and low latency. I take it Gitlab isn't one of those? Probably depends on the team, individuals being able to self-organize and their experience. While some companies may see timezone distributed teams as disadvantage, I believe it is an opportunity to have a continuity of work and getting things done faster than if you had a single 6-8h time slot.
- wpietri 7y ago
  Having experienced a manager with a "sun-never-sets-on-my-empire" fixation, I'm skeptical. In theory, you can get 3 shifts in where there was one before. But this isn't a factory. For knowledge work, there's a big problem with handoffs. If somebody is going to pick up coding right where I left off, I need to transfer a lot of state from my head to theirs. At best, this takes a lot of time. But what's more likely is that things get In software our true enemy isn't time, it's error. It takes seconds to create a bug, but often takes hours or days to remove it. It takes minutes to misunderstand the purpose of a feature, but days or weeks to rework the code to match actual need. I think if we want to get more people at the coalface, the right solution isn't working in shifts. (If it were, we would already be working in shifts without regard to timezone, just like factories do.) Instead, it's to increase collaboration, which requires much more synchronous communication. E.g., techniques like collective code ownership, pair programming, frequent pair rotation, cross-functional teams, small units of work, continuous delivery, and very frequent releases (daily or more often). Since very few people work like that, I think it's reasonable to assume that faster results are not in fact a priority for most businesses. So the "distributed timezones are an advantage" to me sounds like an after-the-fact justification, not an actual solution to a problem.
minipci1321 7y ago
> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. This is not an implication by all means. Low-skilled not very well incentivized junior team (let's call it so in absence of better terms) needs more/most "in-person collaboration". Team of experts to whom the goals and the overall vision have been conveyed, who knows how to put it to practice, will give the shortest latency in async flows. Don't take it as a personal attack, but people valuing high live discussions, are frequently those on the receiving end of it.
- nhumrich 7y ago
  If that were true, why does every director/principal/VP/ceo spend almost the entire week in meetings?
  - scruple 7y ago
    The cynical take is that this is a rhetorical question.
- wpietri 7y ago
  That's one thing that can happen, but it's not the only thing. What you're describing is a push model. Somebody on high creates a vision and assigns goals. Workers are just seen turning that into outputs. It's a common way to work, especially in "known problem/known solution" projects, but it has its flaws. See Cutler on "feature factories", for example. Or Blank's "Four Steps to the Epiphany". But what if the solution or perhaps the problem is unknown? Push systems don't work. Instead, I favor cross-functional teams that pursue outcomes (as opposed to outputs). In that context, the vision is a living thing, created collaboratively, as is the plan. Problems are explored, and solutions discovered. The speed at which a team can learn and test solutions is limited by communications latency. And of course experts aren't born that way. Even if you're in a "known problem/known solution" space, sustainable companies need to find ways to turn novices into experts. Again, that's about learning, which does not work well in high-latency environments.
vaylian 7y ago
> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion. But even when you work in the same building you still have to find a time slot that fits for a meeting. Of course, you can also drop by the other's office and hope to find them ready for a chat, but there's no guarantee. And for remote companies I imagine that people actually have more time slots open for (video)chats, because people don't have to allocate extra time to travel between meeting rooms. Of course, the dynamics of a live discussion are somewhat different from a digital discussion. But I think the availability/latency issue is a misconception.
- wpietri 7y ago
  > But even when you work in the same building you still have to find a time slot that fits for a meeting. That is definitely not the only way to work. A cross-functional team sitting together and focused on outcomes can be much more organic than that. Think of the writer's room for a show, for example. That can sound weird, but Devin's "Artful Making" does a good job explaining the parallels between knowledge work and how theater/TV/movie people work.
mic47 7y ago
> To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. First, it's high latency, not extremely high latency. Second, it has huge advantages: 1.) While latency (in terms of how quickly you finish task) will increase, your bandwidth will increase too. Everyone get more done. 2.) With asynchronous communication, you are not interrupted by communication, you can do it in bulk. In case there is something urgent, you always can do a call, or synchronous chat.
- clarry 7y ago
  > 1.) While latency (in terms of how quickly you finish task) will increase, your bandwidth will increase too It has to increase to make up for the round trips you can't afford: you try to communicate more information in one batch. Whether this is good or bad really depends. On one hand, I think it just forces communication to be better, on the other hand you might waste time communicating things that you'd immediately find to be unnecessary if you were interacting live with the other party.
- wpietri 7y ago
  It sounds like you're focused on maximizing output. I'm more interested in maximizing outcome. As to high vs extremely high, I'm not sure arguing over relative terms is useful. But just so it's clear what I mean: If I'm working in a team room with colleagues, my average latency between request and response is, say 15 seconds. But in globally distributed remote work situations, a much longer lag is not uncommon. E.g., when I was working with European colleagues, it was typical to get a response the next working day. That's about 5000 times longer, which seems pretty extreme to me.

sschueller 7y ago

I find it interesting how they achieve this and it also gives people in remote places the ability to work for such a company. What I don't agree with is the pay scale they use based on your location. If you have the same skills, you should be paid the same.

_pmf_ 7y ago
> If you have the same skills, you should be paid the same. That would be highly unfair.
C1sc0cat 7y ago
That's one of the advantages from an employers POV - and sorry salary is set by market forces.
earnubs 7y ago
The regional coefficients they use to set salary are a real turn off. https://about.gitlab.com/salary/data.json https://about.gitlab.com/salary/data.json
- luch 7y ago
  This is really interesting data ! I for once would like to know why they refuse to hire contractors from Western Europe (is it a legal thing ?) : {"country":"*","contractor_factor":1.17,"entity":"GitLab BV"}], "countryNoHire": ["Iran","North Korea","Crimea","Syria","Sudan","Cuba","France","Italy","Brazil","Spain","Romania","United Arab Emirates","Sweden","Argentina","Philippines","Austria"],
  - skissane 7y ago
    I totally understand why a company won't hire from Iran, North Korea, Syria, Sudan, Cuba, Crimea – exposure to US sanctions threatens to cause severe negative repercussions. But, why single out France, Italy, Spain, Romania, Sweden and Austria out of EU member states? What problems do they have which other EU member states lack? Similarly, if Argentina and Brazil are a problem, what about Chile, Uruguay, Paraguay, Venezuela, Colombia, Ecuador, Bolivia, Guyana, Suriname, etc? Likewise, why would UAE be a problem, but not Iraq, Kuwait, Saudi Arabia, Qatar, Oman, Yemen, Jordan, etc?

esseti 7y ago

Is there a way to generate an ebook for kindle? I would love to read it all

philshem 7y ago
I use the "push to kindle" browser extension for online content, which seems to work fine for this page: https://pushtokindle.fivefilters.org/send.php?url=https%3A%2F%2Fabout.gitlab.com%2Fcompany%2Fculture%2Fall-remote%2Fguide%2F https://pushtokindle.fivefilters.org/send.php?url=https%3A%2... The content is sent to the Kindle via the email service: https://www.amazon.com/gp/sendtokindle/email https://www.amazon.com/gp/sendtokindle/email Depending on your Kindle settings, you may have to set the FROM address in the push-to-kindle page.
- esseti 7y ago
  the fact is that generates the ebook fro that page only. i would love to have the whole ebook
- ukyrgf 7y ago
  If you just go up one category you'd see you don't need a third party tool: https://www.amazon.com/gp/sendtokindle https://www.amazon.com/gp/sendtokindle
  - philshem 7y ago
    I had searched the Firefox Add-on catalog and the official tool has never shown up: https://addons.mozilla.org/en-US/firefox/search/?platform=windows&q=send%20to%20kindle https://addons.mozilla.org/en-US/firefox/search/?platform=wi... Interestingly, the link from Amazon, clicked through your link, is dead https://addons.mozilla.org/en-US/firefox/addon/sendtokindle/ https://addons.mozilla.org/en-US/firefox/addon/sendtokindle/
    - philshem 7y ago
      https://web.archive.org/web/20171010081410/https://addons.mozilla.org/en-US/firefox/addon/sendtokindle/ https://web.archive.org/web/20171010081410/https://addons.mo... seems poorly rated when it was available 3 years ago

ram_rar 7y ago

I always used to hated remote work. Nothing like in person, face to face conversations to get things done. Due to coronovirus, for the past few days have been working remotely. Its surprising that things are going smoothly. I feel, its mostly due to that fact that everyones remote right now. But I'm guessing, there has to be an inflection point in the team, where this is achievable. Not sure, what it is though.

znq 7y ago

Our Company Handbook for Remote Work https://mobilejazz.com/company-handbook-pdf/ https://mobilejazz.com/company-handbook-pdf/ Other HN members have pointed out previously, that it looks like a landing page where you need to leave your e-mail address. You don't. You can download the PDF from here directly.

Cthulhu_ 7y ago
Why do you have it as a PDF hidden behind a call-to-action reminiscent of a sign-up though? Turn it into a website, that'll make it a lot more accessible - assuming getting people to read it is the goal, of course.
- znq 7y ago
  Simple cost/result calculation. Creating a PDF + simple web page was something our designer can do easily. Developing a whole website around would have been much more expensive.

wildchild 7y ago

Oh lol at that ukrainian untermensch riding hype.

jungong 7y ago

Also, Gitlab's remote work emergency plan is a good read too > https://about.gitlab.com/company/culture/all-remote/remote-work-emergency-plan/ https://about.gitlab.com/company/culture/all-remote/remote-w...

Alex_P13 7y ago

Thanks for sharing

beyondcompute 7y ago

Don’t forget firing some people based on their nationality. Gitlab’s good at that!

Cthulhu_ 7y ago
Isn't that because of US sanctions? Blame them.
oehtXRwMkIs 7y ago
Not really their fault is it? It's more of the fault of US policy in general.
rossmohax 7y ago
Not only that. Director of compliance resigns because she needs to explain why she advices to walk off from non compliant contracts. Yeah, and in the spirit of true openness her coment about that is deleted.

cranekam 7y ago

Any Gitlabbers here? I'm looking for SRE work and Gitlab looks great, aside from never having any job openings..

AngeloAnolin 7y ago
Not a Gitlabber, but they post their openings here [0] [0] https://about.gitlab.com/jobs/apply/ https://about.gitlab.com/jobs/apply/

jpincheira 7y ago

I think that what's key here, especially during the current crisis, is to support businesses as much as we can to switch to WFH in the best possible way, with a simple process, and by helping them to stay engaged, hopefully without the need to make them all jump into real-time video calls many times through the day and lose focus. At our company [1], we've been receiving an incredible amount of inbound. People really need tools that don't get in the way —we're a video-first async comm platform— and I'm happy our team is being able to help these companies switching to WFH. The team and I are happy to help anyone with setting a basic process of communication for companies moving to WFH during these weeks. Just write to me at jp@standups.io and we'll be happy to jump in a call and see how we can help. [1] https://standups.io https://standups.io

rdsubhas 7y ago

How do people whiteboard remotely? This is a big problem for many development teams. Sometimes you just want to open a blank whiteboard and scribble some boxes and brainstorm or troubleshoot some things. The whiteboard is an inseparable part of nearly every meeting. And no, remote "canvas" whiteboards don't work. They end up looking like this: https://cdn.drawception.com/images/panels/2015/3-3/jLndYAfNfR-12.png https://cdn.drawception.com/images/panels/2015/3-3/jLndYAfNf.... Is there anything good that really solves this problem?

joppy 7y ago
Get some kind of device with a stylus (drawing tablet, iPad, Surface, etc) and use that to whiteboard. I think remote canvas whiteboards do work, you just need the proper tools to use them.
sethammons 7y ago
Use a Wacom tablet or iPad with a stylus. Drawing with a mouse or trackpad is the problem. We use Zoom's whiteboard feature, but any online canvas could work. The Zoom option is interesting for us because we have the interactive boards in our office so remoties and in-office people can draw on the same thing.
lampe3 7y ago
The question is why do you need a whiteboard? What problem is the whiteboard solving? Drawing freely with a mouse is something that can be done but also you have tools like draw.io if you need to draw something.
- cyphar 7y ago
  Whiteboards are absolutely indispensable for communicating ideas quickly in a small group of people. It's effectively just a bigger (and easier to erase) version of grabbing a scrap of paper to scribble something down when explaining or describing something to someone else. I'm honestly more surprised that this isn't a universally known concept on HN. Scribbling on scraps of paper is something most people in western countries have done since pre-school.

abinaya_codes 7y ago

Appreciate the guide coming from Gitlab. Gitlab is one of my inspiration to start my remote company[1] which also helps remote job seekers. [1] - https://remoteleaf.com https://remoteleaf.com

adolfoabegg 7y ago

From the manifesto: The results of work over the hours put in. How do you adapt that to the scrum process which has a burndown chart based in the time spent on tickets.

sytse 7y ago
At Gitlab we try to reduce the scope of tickets so that they all ship in the same sprint. We measure efficiency by measuring the MR rate, the number of merge requests in a month devided by the number of engineers. To game the number you have to split work up in smaller Parts which helps cycle time, coordination, predictability, and quality, for example smaller changes are easier to review.
joeconway 7y ago
Scrum burndowns should not be related to time spent at all. That’s not an actual agile technique, that’s your company not trusting you and not understanding how software works. Story points that are meant to represent unknowns and complexity, not hours, used for estimation and burndowns are one solution to this
roneesh 7y ago
That isn't agile. Tickets should be based on relative effort, not hours, and certainly not more hours being better.
deleted 7y ago
[deleted]
xtat 7y ago
when are we going to burndown agile

globular-toast 7y ago

Gitlab's remote manifesto speaks to me in so many ways. I'd also love to work for Gitlab anyway. But, alas, I don't know Ruby on Rails and I think it's too late for me to gain the proficiency that I'd require for my expected salary from Gitlab. Are there any fully remote companies doing Python?

whoisjuan 7y ago
If you know Python you can easily learn Ruby. Not hard to do that transition. Although not similar they share the same idiomatic programming principles drawn from languages like Perl. Also, Ruby was inspired by Python: "I was talking with my colleague about the possibility of an object-oriented scripting language. I knew Perl (Perl4, not Perl5), but I didn't like it really, because it had the smell of a toy language (it still has). The object-oriented language seemed very promising. I knew Python then. But I didn't like it, because I didn't think it was a true object-oriented language – OO features appeared to be add-on to the language. As a language maniac and OO fan for 15 years, I really wanted a genuine object-oriented, easy-to-use scripting language. I looked for but couldn't find one. So I decided to make it." - Matasamoto.
dosethree 7y ago
Ruby is easy a fuck to learn. And it’s fun! It was influenced by Python, give it a shot

rickspencer3 7y ago

Just my opinion, but based on running remote and semi-remote teams since 2008 ... fully or mostly remote engineering teams are a competitive advantage, so, by definition, organizations that choose not to adapt to this reality will have a hard time competing. Organizations can have a personal preference for co-located work, but, I think the marketplace will select those organizations out. I think this will unfold over single digit number of years. From what I have observed, most of the resistance to remote work is really driven from the top; by less adaptable leaders.

pythonaut_16 7y ago
I think if things flip and remote becomes the primary, and co-location becomes rare we'll also see some companies that are able to use co-location as a competitive advantage. But I agree that remote (and the practices it encourages) are currently a competitive advantage.
- lkozloff 7y ago
  I don't think you're wrong here. Remote itself does unlock advantages that aren't accessible to colocated companies (e.g. hiring anywhere), but one of the primary things that remote-practices unlock are surrounding communication. Organizations approaching remote have a helpful speedbump that encourages them to take an intentional look at the way they disseminate information. Being fully remote is an accountability structure that helps ensure that everyone is following those practices. There's nothing that would prevent a well-run colocated company from capturing those particular advantages, but such a company would probably slowly drift remote as companies like Buffer (and GitLab!) have as they grow and look for new talent.

Shivetya 7y ago

One issue I heard coming up recently is bandwidth many companies have to support remote access is not capable of dealing with a majority doing so. Then there are those using by license VPN solutions having insufficient simultaneous access. I am used to the web ex approach for collaboration but again this is limited by bandwidth issues. if anything hopefully this shows people how many meetings are just unnecessary

aantix 7y ago

10. Pay the engineer substantially less for the "privilege" of working remotely.

motohagiography 7y ago

Regarding the principles: >> 3. Writing down and recording knowledge over verbal explanations. 4. Written down processes over on-the-job training. 5. Public sharing of information over need-to-know access. 6. Opening up every document for editing by anyone over top-down control of documents. 7. Asynchronous communication over synchronous communication. These remote work principles have the direct, or side effect of breaking organizations that are "moral mazes," and hyper political bureaucracies. The reason organizations suck is because managers just talk instead of producing data, which is basically conspiring to steal value instead of creating it for the organization. I see this today, where I make an email request, and the person follows up with a phone call, then misrepresents what was agreed to on the phone to others. At one site, I literally stopped answering my phone for anyone I didn't directly work for, because I knew those people were just using the verbal channel to create uncertainty about what was said and leverage the resulting confusion. The WIFO rule solves a lot of org problems. (write it, or f-off).

andycowley 7y ago
So much this. I left my last employer because of just this. A 'fat waist' of middle-management that delivered no value and created nothing but inertia. Major incidents were a shambles of managers demanding updates over a conference call while engineers couldn't communicate effectively. Ugh
pfranz 7y ago
> I see this today, where I make an email request, and the person follows up with a phone call, then misrepresents what was agreed to on the phone to others. I know this misses your point, but both at work and outside I've gotten into the practice of emailing immediately after a phone call with a summary of the phone call. It's kind of a lawyerly thing to do, but it's a contemporaneous documentation of the phone call you can point to later.

Joof 7y ago

Do any companies think they will keep doing remote after COVID? I have delayed sleep phase disorder (sleep-in late; fixed by camping / sunlight) and live in a van in (roughly) CO, so the perfect job for me is working remote with a team in San Francisco. I currently work in-office with a fairly major start-up.

techbio 7y ago
I see so many people making the point that they have some syndrome and so they need x, y, z in a job. Valid, I'm sure, personally well-considered, true and everything, but still, indicative of a person who's problems are more important to them than the ones the company is hiring for.
- Joof 7y ago
  So, funny thing. My problems are more important to me than the ones the company is hiring for. Especially given that solving my problems makes me more productive for the company. Seems rational unless I'm actually trying to do the 'selling myself / interview' part.
  - techbio 7y ago
    Fancy name, dude, but a lot of people would rather sleep in.

danielvlopes2 7y ago

We've received a ton of questions on how to manage teams remotely this week as well. We decided to make our eBook on "Managing Remote Teams" free, to help ease the transition for teams moving to WFH. This 60+ pages book is the result of months of research and interviews with successful remote companies (it’s usually a part of our paid product). We collected tips on pretty much everything, from onboarding to communication best-practices, to tools you should consider. https://knowyourteam.com/m/managing_remote_teams https://knowyourteam.com/m/managing_remote_teams

devreps 7y ago

Based on data we collected from 297 remote managers and employees, here are 11 free chapters of best practices on how to manage a remote team. https://knowyourteam.com/m/managing_remote_teams https://knowyourteam.com/m/managing_remote_teams