How can existing engineering teams that were colocated move into an all remote environment? - 2021-01-28

Proposal

I'm working on a blog post that offers insights from GitLab engineers or engineering managers that made the transition from working in a colocated, office environment to working asynchronously and remotely. For this blog post, we want to go beyond the basic tips for successful remote work (e.g., dress for work, have a dedicated workplace, etc.) to talk more specifically and in-depth about what it's like to complete engineering tasks remotely vs. in-person.

There are three key things I'd like to learn: What was it like engineering in an office? What was the transition to working remotely and asynchronously like for you? What has it been like working async and all-remote at GitLab? The more specific examples you can provide, the more useful this blog post will be to readers. Feel free to tell your own story in the thread below or answer the questions in a Q&A format. Thank you 💫 🙇

  • What do your job duties entail?
  • What does the typical day look like for an engineer or engineering manager when you are working in a co-located environment?
  • What were some of the benefits of engineering in a co-located environment? Did it make it easier or more challenging to collaborate with team members or execute specific tasks?
  • Do you have any specific examples of how engineering works in an office setting versus in a remote setting? What are the benefits of being in-person versus remote? What are the challenges?
  • How did you go about making the transition from engineering in-person to remotely?
  • What tools have made engineering remotely and async easier?
  • What are the benefits and challenges of working all-remote an engineer?
  • Do you have any tips for EMs or engineers making the transition from working in an office to working remotely?
  • What else should I know?

Checklist

  • If you have a specific publish date in mind (please allow 3 weeks' lead time)
    • Include it in the issue title and apply the appropriate milestone (e.g. Blogs October 2020)
    • Give the issue a due date of a minimum of 2 working days prior
    • If your post is likely to be >2,000 words, give a due date of a minimum of 4 working days prior
  • If time sensitive
    • Add ~"Blog: Priority" label and supplied rationale in description
    • Mention @rebecca to give her a heads up ASAP
  • If wide-spread customer impacting or sensitive, mention @nwoods to give her a heads up ASAP, apply the sensitive label, and check the PR handbook in case you need to open an announcement request instead of a blog post issue
  • If the post is about one of GitLab's Technology Partners, including integration partners, mention @TinaS, apply the Partner Marketing label, and see the blog handbook for more on third-party posts
  • If the post is about one of GitLab's customers, mention @KimLock and @FionaOKeeffe, apply the Customer Reference Program label, and see the blog handbook for more on third-party posts
  • Indicate if supporting an event or campaign
  • Indicate if this post requires additional approval from internal or external parties before publishing (please provide details in a comment)
Edited by Sara Kassabian