[{"data":1,"prerenderedAt":2542},["ShallowReactive",2],{"/en-us/blog/tags/remote-work/":3,"navigation-en-us":20,"banner-en-us":438,"footer-en-us":453,"remote work-tag-page-en-us":664},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/remote-work","tags",false,"",{"tag":9,"tagSlug":10},"remote work","remote-work",{"template":12},"BlogTag","content:en-us:blog:tags:remote-work.yml","yaml","Remote Work","content","en-us/blog/tags/remote-work.yml","en-us/blog/tags/remote-work","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":434,"_type":14,"title":435,"_source":16,"_file":436,"_stem":437,"_extension":19},"/shared/en-us/main-navigation","en-us",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":375,"minimal":406,"duo":425},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/","gitlab logo","header",{"text":30,"config":31},"Get free trial",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Talk to sales",{"href":37,"dataGaName":38,"dataGaLocation":28},"/sales/","sales",{"text":40,"config":41},"Sign in",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,185,190,296,356],{"text":46,"config":47,"cards":49,"footer":72},"Platform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"The most comprehensive AI-powered DevSecOps Platform",{"text":53,"config":54},"Explore our Platform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":60,"config":61},"Meet GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":68,"config":69},"Learn more",{"href":70,"dataGaName":71,"dataGaLocation":28},"/why-gitlab/","why gitlab",{"title":73,"items":74},"Get started with",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Developer Experience",{"href":83,"dataGaName":84,"dataGaLocation":28},"/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":167},"Product",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/solutions/",[99,124,146],{"title":100,"description":101,"link":102,"items":107},"Automation","CI/CD and automation to accelerate deployment",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/solutions/continuous-integration/",{"text":113,"config":114},"AI-Assisted Development",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Source Code Management",{"href":119,"dataGaLocation":28,"dataGaName":117},"/solutions/source-code-management/",{"text":121,"config":122},"Automated Software Delivery",{"href":105,"dataGaLocation":28,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Security","Deliver code faster without compromising security",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":28,"icon":131},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,136,141],{"text":134,"config":135},"Security & Compliance",{"href":129,"dataGaLocation":28,"dataGaName":134},{"text":137,"config":138},"Software Supply Chain Security",{"href":139,"dataGaLocation":28,"dataGaName":140},"/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Compliance & Governance",{"href":144,"dataGaLocation":28,"dataGaName":145},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":147,"link":148,"items":153},"Measurement",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":28},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[154,158,162],{"text":155,"config":156},"Visibility & Measurement",{"href":151,"dataGaLocation":28,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Value Stream Management",{"href":161,"dataGaLocation":28,"dataGaName":159},"/solutions/value-stream-management/",{"text":163,"config":164},"Analytics & Insights",{"href":165,"dataGaLocation":28,"dataGaName":166},"/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab for",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":28,"dataGaName":174},"/enterprise/","enterprise",{"text":176,"config":177},"Small Business",{"href":178,"dataGaLocation":28,"dataGaName":179},"/small-business/","small business",{"text":181,"config":182},"Public Sector",{"href":183,"dataGaLocation":28,"dataGaName":184},"/solutions/public-sector/","public sector",{"text":186,"config":187},"Pricing",{"href":188,"dataGaName":189,"dataGaLocation":28,"dataNavLevelOne":189},"/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":283},"Resources",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"View all resources",{"href":197,"dataGaName":193,"dataGaLocation":28},"/resources/",[199,232,255],{"title":200,"items":201},"Getting started",[202,207,212,217,222,227],{"text":203,"config":204},"Install",{"href":205,"dataGaName":206,"dataGaLocation":28},"/install/","install",{"text":208,"config":209},"Quick start guides",{"href":210,"dataGaName":211,"dataGaLocation":28},"/get-started/","quick setup checklists",{"text":213,"config":214},"Learn",{"href":215,"dataGaLocation":28,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Product documentation",{"href":220,"dataGaName":221,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best practice videos",{"href":225,"dataGaName":226,"dataGaLocation":28},"/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrations",{"href":230,"dataGaName":231,"dataGaLocation":28},"/integrations/","integrations",{"title":233,"items":234},"Discover",[235,240,245,250],{"text":236,"config":237},"Customer success stories",{"href":238,"dataGaName":239,"dataGaLocation":28},"/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":28},"/blog/","blog",{"text":246,"config":247},"Remote",{"href":248,"dataGaName":249,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":251,"config":252},"TeamOps",{"href":253,"dataGaName":254,"dataGaLocation":28},"/teamops/","teamops",{"title":256,"items":257},"Connect",[258,263,268,273,278],{"text":259,"config":260},"GitLab Services",{"href":261,"dataGaName":262,"dataGaLocation":28},"/services/","services",{"text":264,"config":265},"Community",{"href":266,"dataGaName":267,"dataGaLocation":28},"/community/","community",{"text":269,"config":270},"Forum",{"href":271,"dataGaName":272,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":274,"config":275},"Events",{"href":276,"dataGaName":277,"dataGaLocation":28},"/events/","events",{"text":279,"config":280},"Partners",{"href":281,"dataGaName":282,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":284,"textColor":285,"text":286,"image":287,"link":291},"#2f2a6b","#fff","Insights for the future of software development",{"altText":288,"config":289},"the source promo card",{"src":290},"/images/navigation/the-source-promo-card.svg",{"text":292,"config":293},"Read the latest",{"href":294,"dataGaName":295,"dataGaLocation":28},"/the-source/","the source",{"text":297,"config":298,"lists":300},"Company",{"dataNavLevelOne":299},"company",[301],{"items":302},[303,308,314,316,321,326,331,336,341,346,351],{"text":304,"config":305},"About",{"href":306,"dataGaName":307,"dataGaLocation":28},"/company/","about",{"text":309,"config":310,"footerGa":313},"Jobs",{"href":311,"dataGaName":312,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":312},{"text":274,"config":315},{"href":276,"dataGaName":277,"dataGaLocation":28},{"text":317,"config":318},"Leadership",{"href":319,"dataGaName":320,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":322,"config":323},"Team",{"href":324,"dataGaName":325,"dataGaLocation":28},"/company/team/","team",{"text":327,"config":328},"Handbook",{"href":329,"dataGaName":330,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":332,"config":333},"Investor relations",{"href":334,"dataGaName":335,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":337,"config":338},"Trust Center",{"href":339,"dataGaName":340,"dataGaLocation":28},"/security/","trust center",{"text":342,"config":343},"AI Transparency Center",{"href":344,"dataGaName":345,"dataGaLocation":28},"/ai-transparency-center/","ai transparency center",{"text":347,"config":348},"Newsletter",{"href":349,"dataGaName":350,"dataGaLocation":28},"/company/contact/","newsletter",{"text":352,"config":353},"Press",{"href":354,"dataGaName":355,"dataGaLocation":28},"/press/","press",{"text":357,"config":358,"lists":359},"Contact us",{"dataNavLevelOne":299},[360],{"items":361},[362,365,370],{"text":35,"config":363},{"href":37,"dataGaName":364,"dataGaLocation":28},"talk to sales",{"text":366,"config":367},"Get help",{"href":368,"dataGaName":369,"dataGaLocation":28},"/support/","get help",{"text":371,"config":372},"Customer portal",{"href":373,"dataGaName":374,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":376,"login":377,"suggestions":384},"Close",{"text":378,"link":379},"To search repositories and projects, login to",{"text":380,"config":381},"gitlab.com",{"href":42,"dataGaName":382,"dataGaLocation":383},"search login","search",{"text":385,"default":386},"Suggestions",[387,389,393,395,399,403],{"text":57,"config":388},{"href":62,"dataGaName":57,"dataGaLocation":383},{"text":390,"config":391},"Code Suggestions (AI)",{"href":392,"dataGaName":390,"dataGaLocation":383},"/solutions/code-suggestions/",{"text":109,"config":394},{"href":111,"dataGaName":109,"dataGaLocation":383},{"text":396,"config":397},"GitLab on AWS",{"href":398,"dataGaName":396,"dataGaLocation":383},"/partners/technology-partners/aws/",{"text":400,"config":401},"GitLab on Google Cloud",{"href":402,"dataGaName":400,"dataGaLocation":383},"/partners/technology-partners/google-cloud-platform/",{"text":404,"config":405},"Why GitLab?",{"href":70,"dataGaName":404,"dataGaLocation":383},{"freeTrial":407,"mobileIcon":412,"desktopIcon":417,"secondaryButton":420},{"text":408,"config":409},"Start free trial",{"href":410,"dataGaName":33,"dataGaLocation":411},"https://gitlab.com/-/trials/new/","nav",{"altText":413,"config":414},"Gitlab Icon",{"src":415,"dataGaName":416,"dataGaLocation":411},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":413,"config":418},{"src":419,"dataGaName":416,"dataGaLocation":411},"/images/brand/gitlab-logo-type.svg",{"text":421,"config":422},"Get Started",{"href":423,"dataGaName":424,"dataGaLocation":411},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":426,"mobileIcon":430,"desktopIcon":432},{"text":427,"config":428},"Learn more about GitLab Duo",{"href":62,"dataGaName":429,"dataGaLocation":411},"gitlab duo",{"altText":413,"config":431},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":433},{"src":419,"dataGaName":416,"dataGaLocation":411},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":439,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":440,"button":441,"image":445,"config":448,"_id":450,"_type":14,"_source":16,"_file":451,"_stem":452,"_extension":19},"/shared/en-us/banner","is now in public beta!",{"text":68,"config":442},{"href":443,"dataGaName":444,"dataGaLocation":28},"/gitlab-duo/agent-platform/","duo banner",{"config":446},{"src":447},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":449},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":454,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":455,"_id":660,"_type":14,"title":661,"_source":16,"_file":662,"_stem":663,"_extension":19},"/shared/en-us/main-footer",{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":652},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":458,"config":459},"View page source",{"href":460,"dataGaName":461,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":464,"config":465},"Edit this page",{"href":466,"dataGaName":467,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":469,"config":470},"Please contribute",{"href":471,"dataGaName":472,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":474,"facebook":475,"youtube":476,"linkedin":477},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[479,502,559,588,622],{"title":46,"links":480,"subMenu":485},[481],{"text":482,"config":483},"DevSecOps platform",{"href":55,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":186,"links":487},[488,492,497],{"text":489,"config":490},"View plans",{"href":188,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Why Premium?",{"href":495,"dataGaName":496,"dataGaLocation":462},"/pricing/premium/","why premium",{"text":498,"config":499},"Why Ultimate?",{"href":500,"dataGaName":501,"dataGaLocation":462},"/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Solutions",[505,510,513,515,520,525,529,532,536,541,543,546,549,554],{"text":506,"config":507},"Digital transformation",{"href":508,"dataGaName":509,"dataGaLocation":462},"/topics/digital-transformation/","digital transformation",{"text":134,"config":511},{"href":129,"dataGaName":512,"dataGaLocation":462},"security & compliance",{"text":123,"config":514},{"href":105,"dataGaName":106,"dataGaLocation":462},{"text":516,"config":517},"Agile development",{"href":518,"dataGaName":519,"dataGaLocation":462},"/solutions/agile-delivery/","agile delivery",{"text":521,"config":522},"Cloud transformation",{"href":523,"dataGaName":524,"dataGaLocation":462},"/topics/cloud-native/","cloud transformation",{"text":526,"config":527},"SCM",{"href":119,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":109,"config":530},{"href":111,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":533,"config":534},"Value stream management",{"href":161,"dataGaName":535,"dataGaLocation":462},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":462},"/solutions/gitops/","gitops",{"text":171,"config":542},{"href":173,"dataGaName":174,"dataGaLocation":462},{"text":544,"config":545},"Small business",{"href":178,"dataGaName":179,"dataGaLocation":462},{"text":547,"config":548},"Public sector",{"href":183,"dataGaName":184,"dataGaLocation":462},{"text":550,"config":551},"Education",{"href":552,"dataGaName":553,"dataGaLocation":462},"/solutions/education/","education",{"text":555,"config":556},"Financial services",{"href":557,"dataGaName":558,"dataGaLocation":462},"/solutions/finance/","financial services",{"title":191,"links":560},[561,563,565,567,570,572,574,576,578,580,582,584,586],{"text":203,"config":562},{"href":205,"dataGaName":206,"dataGaLocation":462},{"text":208,"config":564},{"href":210,"dataGaName":211,"dataGaLocation":462},{"text":213,"config":566},{"href":215,"dataGaName":216,"dataGaLocation":462},{"text":218,"config":568},{"href":220,"dataGaName":569,"dataGaLocation":462},"docs",{"text":241,"config":571},{"href":243,"dataGaName":244,"dataGaLocation":462},{"text":236,"config":573},{"href":238,"dataGaName":239,"dataGaLocation":462},{"text":246,"config":575},{"href":248,"dataGaName":249,"dataGaLocation":462},{"text":259,"config":577},{"href":261,"dataGaName":262,"dataGaLocation":462},{"text":251,"config":579},{"href":253,"dataGaName":254,"dataGaLocation":462},{"text":264,"config":581},{"href":266,"dataGaName":267,"dataGaLocation":462},{"text":269,"config":583},{"href":271,"dataGaName":272,"dataGaLocation":462},{"text":274,"config":585},{"href":276,"dataGaName":277,"dataGaLocation":462},{"text":279,"config":587},{"href":281,"dataGaName":282,"dataGaLocation":462},{"title":297,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":304,"config":591},{"href":306,"dataGaName":299,"dataGaLocation":462},{"text":309,"config":593},{"href":311,"dataGaName":312,"dataGaLocation":462},{"text":317,"config":595},{"href":319,"dataGaName":320,"dataGaLocation":462},{"text":322,"config":597},{"href":324,"dataGaName":325,"dataGaLocation":462},{"text":327,"config":599},{"href":329,"dataGaName":330,"dataGaLocation":462},{"text":332,"config":601},{"href":334,"dataGaName":335,"dataGaLocation":462},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":462},"/sustainability/",{"text":607,"config":608},"Diversity, inclusion and belonging (DIB)",{"href":609,"dataGaName":610,"dataGaLocation":462},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":337,"config":612},{"href":339,"dataGaName":340,"dataGaLocation":462},{"text":347,"config":614},{"href":349,"dataGaName":350,"dataGaLocation":462},{"text":352,"config":616},{"href":354,"dataGaName":355,"dataGaLocation":462},{"text":618,"config":619},"Modern Slavery Transparency Statement",{"href":620,"dataGaName":621,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":623,"links":624},"Contact Us",[625,628,630,632,637,642,647],{"text":626,"config":627},"Contact an expert",{"href":37,"dataGaName":38,"dataGaLocation":462},{"text":366,"config":629},{"href":368,"dataGaName":369,"dataGaLocation":462},{"text":371,"config":631},{"href":373,"dataGaName":374,"dataGaLocation":462},{"text":633,"config":634},"Status",{"href":635,"dataGaName":636,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":638,"config":639},"Terms of use",{"href":640,"dataGaName":641,"dataGaLocation":462},"/terms/","terms of use",{"text":643,"config":644},"Privacy statement",{"href":645,"dataGaName":646,"dataGaLocation":462},"/privacy/","privacy statement",{"text":648,"config":649},"Cookie preferences",{"dataGaName":650,"dataGaLocation":462,"id":651,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,658],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":462},{"text":643,"config":657},{"href":645,"dataGaName":646,"dataGaLocation":462},{"text":648,"config":659},{"dataGaName":650,"dataGaLocation":462,"id":651,"isOneTrustButton":91},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":665,"featuredPost":2521,"totalPagesCount":2540,"initialPosts":2541},[666,692,715,741,761,782,802,822,842,863,885,906,927,948,968,988,1006,1025,1045,1065,1084,1104,1126,1145,1166,1186,1206,1226,1245,1266,1286,1306,1324,1345,1365,1387,1407,1426,1446,1467,1486,1504,1522,1541,1560,1578,1597,1616,1637,1656,1676,1695,1715,1734,1754,1774,1792,1812,1832,1852,1871,1891,1911,1932,1953,1972,1992,2012,2031,2051,2072,2092,2110,2130,2151,2170,2190,2210,2230,2252,2271,2290,2308,2326,2344,2364,2384,2403,2424,2444,2464,2483,2501],{"_path":667,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":676,"config":685,"_id":688,"_type":14,"title":689,"_source":16,"_file":690,"_stem":691,"_extension":19},"/en-us/blog/all-remote-fundraising",{"title":669,"description":670,"ogTitle":669,"ogDescription":670,"noIndex":6,"ogImage":671,"ogUrl":672,"ogSiteName":673,"ogType":674,"canonicalUrls":672,"schema":675},"How to raise funds as an all-remote startup","GitLab CEO Sid Sijbrandij and podcast host Maren Kate unpack why venture firms struggle to fund all-remote startups.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673152/Blog/Hero%20Images/remotefundraisinghurdle.jpg","https://about.gitlab.com/blog/all-remote-fundraising","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to raise funds as an all-remote startup\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-08-16\",\n      }",{"title":669,"description":670,"authors":677,"heroImage":671,"date":679,"body":680,"category":681,"tags":682},[678],"Valerie Silverthorne","2019-08-16","\nIt’s possible to be an all-remote startup and get venture capital – GitLab is proof of that – but that doesn’t mean it’s easy. GitLab CEO [Sid Sijbrandij](/company/team/#sytses) spoke with [Maren Kate](https://www.linkedin.com/in/marenkate), host of the From 5 to 50 podcast, about why venture capitalists don’t love all-remote companies and how to work around that challenge. The [Remote AF](https://podcasts.apple.com/us/podcast/gitlab-raised-$100m-got-valued-at-over-billion-by-starting/id1467214647?i=1000444691471) podcast is aimed at startups looking to scale their companies from 5 to 50 employees and beyond.\n\nMaren starts by asking Sid how the concept of all-remote was received by the venture capital community. Sid’s response: “They don’t like remote. We missed out on investors because we are remote. We have skepticism from investors because we are remote.”\n\n## Stages of fundraising\n\nFundraising changes as a company grows, and it gets easier with time, Sid explains. “In the beginning they assess your team, then they assess your product, and then they assess your financials.” That’s why it can be hard for a newly-minted, all-remote startup to get fundraising traction in the early stages, he says. “When it comes to the team, they’re super skeptical they will be able to create something with all-remote. Then when it’s about the product they say, ‘Yes, maybe, but what about scaling?’ And then when it’s about the financials you can let the numbers speak for themselves so it’s less of a concern.”\n\nAnd in the early days of GitLab, even Sid was skeptical enough about all-remote to open an office. That office made our [series A financing](/blog/gitlab-announces-4m-series-a-funding-from-khosla-ventures/) easier, he says. But Sid soon realized that people weren’t coming into the office (San Francisco Bay Area traffic being what it is) so committed to an [all-remote philosophy](/company/culture/all-remote/). That decision made [series B fundraising efforts](/blog/gitlab-master-plan/) difficult. Some investors just said no to GitLab, but a few at least asked for an explanation. Even after an explanation, many remained dubious and in the end it took an enthusiastic VC who’d actually stayed up late reading through the handbook and vouched for GitLab to seal the deal.\n\n>Some of the best ideas are the least plausible.\n\nAll-remote companies are getting a toehold today, Sid offers, pointing to [InVision](/blog/pyb-all-remote-mark-frein/), WordPress, and Zapier. But there are still some factors that can inhibit fundraising options. “If we were to be acquired there’s probably a 50% discount, because for the acquiring company it’s so hard to bring people over to their headquarters,” Sid says. “Since an acquisition is the most likely outcome (for most startups), if you raise venture capital that depresses the evaluation you will get.”\n\n## Has co-location hit the wall?\n\nOn the upside, though, Sid thinks the limits of co-location are being made very clear. “Investors in San Francisco are all battling it out. They’re saying ‘Our portfolio companies are getting outbid by Google, by eBay, by Airbnb for engineering talent.’ Retention is an enormous problem at these companies. So they don’t like remote yet, but they’re starting to sour on the co-located model and all the disadvantages.”\n\nAnd while the all-remote path might be tough, Sid continues to stress the benefits to startups. “Remote offers you much easier hiring and scaling. Remote forces you to do the things you should be doing anyway, but you do them sooner.”\n\nAt the end of the day, Maren wonders whether some unconscious bias is at play. “If you see someone in an office, it makes them more successful,” she says, “but it’s not really that, it’s just human instinct.”\n\nSid agrees, and then adds perhaps the strongest argument in favor of all-remote – co-location can have a very dampening effect on innovation. “There's a lot of detrimental things that happen because some of the best ideas are the least plausible, like run an illegal taxi service, have people rent out their own home to strangers, or start competing with GitHub. And if you co-locate people, they're going to have to tell everyone what they do. And when they see people frowning, they're going to switch to something more plausible. And that's what you want to prevent.”\n\nListen to the whole conversation [here](https://podcasts.apple.com/us/podcast/gitlab-raised-$100m-got-valued-at-over-billion-by-starting/id1467214647?i=1000444691471).\n\nCover image by [Pau Casals](https://unsplash.com/@paucasals) on [Unsplash](https://unsplash.com)\n{: .note}\n","insights",[683,9,684],"inside GitLab","startups",{"slug":686,"featured":6,"template":687},"all-remote-fundraising","BlogPost","content:en-us:blog:all-remote-fundraising.yml","All Remote Fundraising","en-us/blog/all-remote-fundraising.yml","en-us/blog/all-remote-fundraising",{"_path":693,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":694,"content":700,"config":709,"_id":711,"_type":14,"title":712,"_source":16,"_file":713,"_stem":714,"_extension":19},"/en-us/blog/all-remote-is-for-everyone",{"title":695,"description":696,"ogTitle":695,"ogDescription":696,"noIndex":6,"ogImage":697,"ogUrl":698,"ogSiteName":673,"ogType":674,"canonicalUrls":698,"schema":699},"Why we believe all-remote is for everyone","Darren Murph, leading GitLab's all-remote initiatives, shares why the future of work can be embraced today.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680729/Blog/Hero%20Images/dm-globe.jpg","https://about.gitlab.com/blog/all-remote-is-for-everyone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we believe all-remote is for everyone\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Murph\"}],\n        \"datePublished\": \"2019-08-15\",\n      }",{"title":695,"description":696,"authors":701,"heroImage":697,"date":703,"body":704,"category":705,"tags":706},[702],"Darren Murph","2019-08-15","\n\nWe're committed to [all-remote](/company/culture/all-remote/) work at GitLab – our whole work philosophy\nis designed around it. I joined GitLab to lead our all-remote\ninitiatives – here's a bit about my background and why I'm excited to join the team.\n\n### A pivotal moment in how society looks at remote work\n\nGitLab is known by many as an [open core company](/blog/monetizing-and-being-open-source/) which develops software for the software\ndevelopment lifecycle. What I want the world to know is that it’s *also* a pioneer in remote work,\nbuilding a transparent, empowered workforce of [over 800 team members across 57+ countries](/company/team/).\nYou read that correctly. Over 800 of us, none of whom are required to work from a central\noffice, are making GitLab one of the world’s largest all remote companies.\n\nI was recently given the honor of joining GitLab to lead its all remote initiatives. The\ncompany’s remarkable growth and impact on the world is well documented, but as I’ve\nengaged with team members – as well as pets and families in the background! – I’m beginning to\nunderstand that we’ve barely scratched the surface of what’s possible.\n\n![Embracing the remote lifestyle in Alabama Hills, California](https://about.gitlab.com/images/blogimages/dm-alabama-hills-california.jpg){: .shadow.medium.center}\nEmbracing the remote lifestyle in Alabama Hills, California\n{: .note.text-center}\n\nI believe we’re nearing a sea change in how we work. It’s easy to point to stratospheric rent prices in major urban centers, soul-crushing gridlock, and shifting mindsets in what society values in a career as reasons for turning to remote work.\n\nBut I think it’s deeper than that. We yearn to explore, and work doesn't have to stand in the way.\n\n### Positive change is possible as all-remote becomes the default for many companies\n\nThe internet has never been faster nor more ubiquitous. Computing power has never been more\naccessible. It’s time for organizations large and small to embrace these realities, to open their\nrecruiting pipelines to the world, to divert real estate budget to R&D and to recognize that\nwe’re all better workers when we’re given the space to feel truly alive.\n\nMore importantly, the communities that matter to each of us have never needed our presence more.\nWorking remotely gives each person the autonomy to serve in a place that matters to them –\na place that has shaped them – contributing significantly to the wellbeing of a population\nthat may be at risk of losing its foundation, should talent continue to flee to the usual job centers.\n\n[Research from the University of New Hampshire](https://carsey.unh.edu/publication/rural-depopulation) has found that \"35% of rural counties in the United States are experiencing protracted and significant population loss.\" Speaking to shrinking towns across Europe, [a 2016 report from the European Parliamentary Research Service](http://www.europarl.europa.eu/thinktank/en/document.html?reference=EPRS_BRI(2016)586632) notes that \"younger members of society prefer to migrate to more economically vibrant regions and cities in search of better job prospects as, in most of these territories, professional opportunities remain limited and confined to specific fields (e.g. agriculture and tourism).\" I believe all-remote has the power to pause, and perhaps even reverse, these trends of depopulation.\n\n![Remote work can have outsized positive impact in cities like Accra](https://about.gitlab.com/images/blogimages/dm-accra-ghana.jpg){: .shadow.medium.center}\nRemote work can have outsized positive impact in cities like Accra\n{: .note.text-center}\n\nWhat would traffic in London, Moscow, Mexico City, and Rome look like if every person who *could* work remotely, did?\nWhat talent might we surface by tapping into burgeoning tech hubs in cities like Accra or Lagos? How\nmany San Franciscans – locals who have been priced out of their own city – could move back if some\nof the world’s greatest technical minds were empowered to work from anywhere? What would\nunderserved communities in rural regions across the globe be capable of if well-paying jobs\ncame their way via the internet?\n\nI don’t ask these questions hypothetically. I ask them because I want to leverage GitLab’s\nplatform to change the narrative on work, and I fully expect that we’ll see those answers in\nmy lifetime. It doesn’t hurt that GitLab (the product) is [tailor-made to enable remote work](/free-trial/),\neven across large teams.\n\n### Creating more remote opportunities for others\n\nI’ve had the great privilege of working remotely my entire career. I’ve shared memories with my\nfamily in over 50 countries and have celebrated milestones with colleagues whilst flying over a\nmillion miles on a single airline (thank you, Delta!).\n\nMy wife and I experienced the beautiful and transformative journey of adoption because I\nworked for an employer that trusted me to excel from a place I needed to be to see it through.\nI’ve met countless GitLabbers who have never been happier, more fulfilled, or more engaged with\ntheir family and community, all because they’re empowered to work remotely.\n\n![Remote work encourages exploration of both locales and cultures](https://about.gitlab.com/images/blogimages/dm-delta-munich-germany.jpg){: .shadow.medium.center}\nRemote work encourages exploration of both locales and cultures\n{: .note.text-center}\n\nI share this because I realize I’m one of the fortunate few, and I long for countless others to have\nthese same opportunities. GitLab is positioned to be of service to everyone – from startups, to\nentrepreneurs, to the world’s largest enterprises – in creating a remote infrastructure that works.\nI couldn’t be more excited to help enable precisely that.\n\nIf you're new to the concept of all-remote, I'd encourage you to dive into\nour [Handbook](/handbook/)\nand [learn how it works at GitLab](/company/culture/all-remote/tips/).\n\nIf you're ready to embrace the freedoms enabled by all-remote, browse\nour [vacancies](/jobs/) and join me on this journey!\n","culture",[707,683,9,708],"features","careers",{"slug":710,"featured":6,"template":687},"all-remote-is-for-everyone","content:en-us:blog:all-remote-is-for-everyone.yml","All Remote Is For Everyone","en-us/blog/all-remote-is-for-everyone.yml","en-us/blog/all-remote-is-for-everyone",{"_path":716,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":723,"config":735,"_id":737,"_type":14,"title":738,"_source":16,"_file":739,"_stem":740,"_extension":19},"/en-us/blog/async-sketching",{"title":718,"description":719,"ogTitle":718,"ogDescription":719,"noIndex":6,"ogImage":720,"ogUrl":721,"ogSiteName":673,"ogType":674,"canonicalUrls":721,"schema":722},"Running an Asynchronous Sketch Workshop for UX","How to generate ideas with team members in multiple time zones","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669734/Blog/Hero%20Images/sketch-cover.jpg","https://about.gitlab.com/blog/async-sketching","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Running an Asynchronous Sketch Workshop for UX\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jacki Bauer\"},{\"@type\":\"Person\",\"name\":\"Inchul Yoo, Sunjung Park\"}],\n        \"datePublished\": \"2020-03-27\",\n      }",{"title":718,"description":719,"authors":724,"heroImage":720,"date":727,"body":728,"category":729,"tags":730},[725,726],"Jacki Bauer","Inchul Yoo, Sunjung Park","2020-03-27","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\nMany companies that normally work together in person have been suddenly thrust into an all-remote world. That can be scary for anyone, but especially for UX designers who rely heavily on face-to-face collaboration with their cross-functional peers.\n\nIf you’re in this situation, you may be thinking: How can I ideate without a whiteboard? How do I lead my team through sketching exercises without paper? WHAT DO I DO WITH ALL OF MY SHARPIES AND STICKY NOTES?!\n\nAt GitLab, our entire company is all remote and globally distributed. We’re used to finding ways to sketch, think and brainstorm asynchronously, so we can accommodate team members who live in time zones all over the world.\n\nYou need just a few ingredients.\n## Clear, simple guidelines and instructions\nGuidelines are really important in any design thinking activity, but when you’re asynchronous, they become extra important, because participants can’t ask clarifying questions or observe what others are doing. So it’s the designer’s role to communicate the activity’s purpose and goal, along with clear instructions and a sense of psychological safety. \n\nAnd just like with in-person activities, you also might want to provide timing advice. For example, consider how you want an individual's ideas to influence others. You might want to give everyone a day to ideate and then ask everyone to drop in their ideas at the same time, so they don’t inadvertently influence each other. Or, you might ask people to intentionally play off the ideas of others. It’s ultimately up your judgement about the goals of the session.\n\n\n## Shared understanding of context\nThe team should already understand some basics about the product or context they work in and the audience they are designing for. If you’re working with a newly formed team, you might try a couple synchronous workshops to get everyone on the same page.\n\n\n## A place for everyone to contribute their ideas\nThis one is easy. There are a lot of tools you can use, including Mural, Google Drive, or even \nSlack. At GitLab, we use Mural, and we also work within our own product to run collaborative design sessions. \n\nAll you need is a place where team members can quickly and easily add text, photos of sketches, images, or even videos, and then freely discuss them. To encourage creativity, you’ll likely want to pick a tool that offers flexibility. \u2028\u2028\u2028\n\n![Illustration of a sketch and chat windows](https://about.gitlab.com/images/blogimages/sketching-session.jpg){: .shadow.medium.center}\n\n## Facilitate team communication\nWhen a team meets in person, they get a lot of non-verbal feedback that can be really useful. People might smile at each other, nod when they hear a good idea, or sigh when someone suggests something that won’t work.\n\nIt’s important to offer a way to surface these reactions when you can’t use immediate nonverbal communication. As the team shares their ideas, provide supportive comments (that will encourage others to do the same). You might also use emojis to enhance communication.\n\n## Step just a little outside your comfort zone\nThis last one is important in any kind of design thinking environment. If you’re a designer working with a product or a client team, it’s likely that many (or most) of the participants in your sessions are not designers. Some participants might hate drawing, and some might be terrified of the idea of uploading something they drew to the internet. \n\nThis is where it helps to work with a team that has already established some rapport. As the designer and session leader, it’s also your job to set a relaxed and casual tone and a low bar for participation. \n\nAt GitLab we say “Everyone can contribute,” and we value action and results over perfection. Let people know it’s OK to not be perfect. As an example, this is how one designer at GitLab set the rules for her team sketching session:\n\n**Rules for the game**\n*  This is a 10-minute activity in total. You don't have to spend more than 5 minutes for each round.\n*  Let's not think about layouts such as the top-header, GitLab logo, and left menu.\n*  There are no right or wrong answers.\n*  It doesn't have to be beautiful. (You will be surprised to see how ugly mine is.)\n*  For round 2, you don't need to fill in all the blanks if it is hard for you. It's not an exam. :-)\n\nTo see this method in action, you can read through this [issue](https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/4944) from February 2020. Believe it or not, this team was doing this exercise for the first time!\n\nCover image by [Mounzer Awad](https://unsplash.com/@mounzaw_) on [Unsplash](https://unsplash.com/s/photos/sketching)\n{: .note}\n\n","unfiltered",[731,732,9,733,734],"collaboration","design","UI","UX",{"slug":736,"featured":6,"template":687},"async-sketching","content:en-us:blog:async-sketching.yml","Async Sketching","en-us/blog/async-sketching.yml","en-us/blog/async-sketching",{"_path":742,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":743,"content":749,"config":755,"_id":757,"_type":14,"title":758,"_source":16,"_file":759,"_stem":760,"_extension":19},"/en-us/blog/avoiding-burnout-as-product-designers",{"title":744,"description":745,"ogTitle":744,"ogDescription":745,"noIndex":6,"ogImage":746,"ogUrl":747,"ogSiteName":673,"ogType":674,"canonicalUrls":747,"schema":748},"Tips to avoid burnout for product designers","Effective prioritization and boundary setting are critical to product designers' growth.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670082/Blog/Hero%20Images/productdesign.jpg","https://about.gitlab.com/blog/avoiding-burnout-as-product-designers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tips to avoid burnout for product designers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2023-03-28\",\n      }",{"title":744,"description":745,"authors":750,"heroImage":746,"date":752,"body":753,"category":681,"tags":754},[751],"Veethika Mishra","2023-03-28","\n\nProduct designers often choose to become a designer because of the hard-to-beat and attractive promise that accompanies it: improving the lives of people by adding value through design. Being a designer, I can vouch for how fulfilling and rewarding it can be to see a bud of an idea grow into a feature that is enjoyed by users. However, the demands of product designers can quickly become overwhelming as roles, products, and teams evolve - if left unchecked, this can result in burnout. In this blog, I will discuss how to avoid burnout by being intentional about time management and communication.\n\n## What is a product designer’s scope?\nAt GitLab, similar to many other software companies, [product designer responsibilities](https://handbook.gitlab.com/job-families/product/product-designer/) span designing thoughtfully crafted experiences, playing a central role in the overall business contributions, and everyday collaboration with key product stakeholders. The spectrum has grown over time, leading to a general misconception among designers that they are required to overreach their potential to prove their pedigree. Instead, taking up the right responsibility at the right time and doing it well often produces better results.\n\n## Define your own frame\nEach product designer envisions growth differently. In the pursuit of growth, to demonstrate specific expertise or leadership qualities, each designer may have a unique goal in mind in terms of the means you want to employ or the results you seek from that goal. Also, this implies that you cannot trust a generic template approach to map your priorities. The lens you use to distinguish important responsibilities and tasks from the rest are unique and your planning and rituals should be as well. \n\n## Establish an availability baseline\nA couple years ago, my manager, [Rayana Verissimo](https://gitlab.com/rayana), gave me a task of writing down an approximate estimation of how much time I plan to dedicate to each of the major responsibilities in my role. The math seemed simple at first: I work 40 hours a week and I had a list of about eight responsibilities. I had an idea in mind on how to divide up those responsibilities. What could go wrong? \n\nAs they say, life happens while we’re busy making other plans. I was preparing to move between countries and, in that same timeframe, our team was onboarding a new product manager. Without realizing it, I began spending a considerable amount of time at work on admin-related tasks and getting my processes in sync with my new product manager. These shifts were unannounced and unavoidable. Such surprise challenges are a part of all of our lives, though the form may vary. But when they happen, it is best to be accepting of them and keep some wiggle room in your time allotment estimation to accommodate them without disturbing the rest of your plan. \n\nThere are different ways to understand and manage your capacity. [Sunjung Park](https://gitlab.com/sunjungp), a product designer at GitLab, relies on the [UX issue weights](/handbook/product/ux/product-designer/#ux-issue-weights) framework to maintain a closer to accurate predictability of her tasks for a release cycle. I personally like to use the same and communicate my capacity for the release cycle to the team using a [planning issue](https://gitlab.com/gitlab-org/gitlab/-/issues/386189).\n\n## Assess the importance of a task to you \nDespite the evident benefits, [McKinsey Design Index](https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design) proved to be the very sign that the tech and other industries had always been looking for to validate the correlation between design and financial performance of an organization. Realizing how it can help them differentiate in the industry and directly impact revenue streams, organizations now expect designers to make some business-critical decisions, thereby expanding their responsibilities to be more cross-functional.\n\nThis evolution has led product designers to jump at every opportunity and request. However, if you do not take a moment to assess the “why” of the opportunity or request, you’re merely setting yourself up for failure. Product designers can ask some questions to help decide whether to take on the project:\n- Does the project require my expertise and skills, or help me develop one that aligns with my personal goals?\n- Does the project contribute to the business' goals?\n- Is this project something that someone else can do better than I can - while I invest my time doing something that I can do more confidently? \n- Am I on the same page with the requestor in terms of expectations and time commitment?\n- Will my delivery plan get impacted if I commit to this project? If so, what trade-offs can or need to be made?\n\n## Build trust and communicate transparently\nThe urge to say “yes” is an instinct of human behavior. However, when you say yes to every request from our peers/colleagues, you feed the [cycle of responsiveness](https://hbr.org/2012/05/are-you-sleeping-with-your-sma) to become more intense, to a point where you no longer can respond to the demand. This overwhelming wave of expectations puts you in a position where you stop exercising your creative muscles out of exhaustion and merely keep working more and more, driving down the quality of results. Making it a false victory, if one at all. Ironically, this, in turn, impacts the very relationship that you said “yes” to in the first place.\n\nI have already talked about how to decide if an opportunity or request is aligned to your goals. If the answer to that is “it isn’t,” the next thing you need to do is communicate that clearly to the requester. \n\nA plain “no” can easily be perceived as rude, but kindly communicating an honest and straightforward reason will have a higher chance of building trust with your peers than saying yes and delivering substandard results. The GitLab sub-value [Directness](https://handbook.gitlab.com/handbook/values/#directness) emphasizes the importance of transparent communication with colleagues. Another method a few members of my team, including me, use for maintaining transparency in everyday priorities is [documenting them publicly](https://gitlab.com/veethikaa/veethika-planner/-/blob/master/Weekly%20Priorities/weekly-priorities.md) in a GitLab project and keeping them visible to the team and our counterparts. \n\n## A checklist to avoid burnout\nIf you're looking to continue to enjoy your work as a product designer while also growing in your job, the following tips can help:\n\n- Take a step back and try to understand your own drives and motivations so you can more effectively plan your path ahead.\n- Be realistic about your capacity and potential trade-offs, and communicate the same to your team transparently.\n- Be discerning while taking up a new opportunity, ensure it aligns with your goals, and be comfortable passing it along to a colleague that is better suited if it doesn't.\n- Keep your communication honest, humble, and non-ambiguous to avoid miscalculated commitments that can harm relationships with your peers.\n\nMindfully and intentionally assessing a new opportunity rather than reacting by impulse can play a major role in setting yourself, and your colleagues, up for success, resulting in a happier, more impactful, and less stressful work environment.\n\n_Cover image by \u003Ca href=\"https://unsplash.com/@freestocks?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">freestocks\u003C/a> on \u003Ca href=\"https://unsplash.com/photos/vcPtHBqHnKk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>_\n",[734,732,9],{"slug":756,"featured":6,"template":687},"avoiding-burnout-as-product-designers","content:en-us:blog:avoiding-burnout-as-product-designers.yml","Avoiding Burnout As Product Designers","en-us/blog/avoiding-burnout-as-product-designers.yml","en-us/blog/avoiding-burnout-as-product-designers",{"_path":762,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":763,"content":769,"config":776,"_id":778,"_type":14,"title":779,"_source":16,"_file":780,"_stem":781,"_extension":19},"/en-us/blog/balancing-career-and-baby",{"title":764,"description":765,"ogTitle":764,"ogDescription":765,"noIndex":6,"ogImage":766,"ogUrl":767,"ogSiteName":673,"ogType":674,"canonicalUrls":767,"schema":768},"Balancing motherhood, career and cultural expectations","One team member shares her experience as a new working mother at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673071/Blog/Hero%20Images/parental-leave-global.jpg","https://about.gitlab.com/blog/balancing-career-and-baby","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How I balance a baby, a career at GitLab, and cultural expectations of motherhood\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jarka Košanová et al\"}],\n        \"datePublished\": \"2019-07-25\",\n      }",{"title":770,"description":765,"authors":771,"heroImage":766,"date":773,"body":774,"category":705,"tags":775},"How I balance a baby, a career at GitLab, and cultural expectations of motherhood",[772],"Jarka Košanová et al","2019-07-25","\n_This is the second in a four-part series looking at a myriad of issues surrounding working at home with children. In [part one we took an in-depth look at parental leave policies worldwide](/blog/how-is-it-being-a-new-mom-working-for-gitlab/) and in parts three and four we’ll discover tried-and-true strategies for working remotely with older children._\n\nIn my last post I talked about the big differences among countries when it comes to paid parental leave. But this is only a start. I think maybe even more important is how society sees the issues around parental leave. In my country, women who want to work during the first three years of their child's life are often called \"career chasers\" and considered selfish. The majority opinion is that as a woman, you should prioritize caring for your children and household until your children are at least three years old. A lot of people in the Czech Republic (and elsewhere) think you should give up your old hobbies, stop traveling, and wait to resume your life until your children are older.\n\nYoung people, especially those with higher education or international experience, are usually more tolerant and don't see parenting as so black and white anymore. But I still wondered: Can I work when I have a small baby and still be accepted in my country?\n\nI was sure I wanted to return to work quite soon after having a baby, meaning before the 2-3 years which is \"normal\" in the Czech Republic. I had lived in Switzerland where childminding groups took care of infants and toddlers and women often went back to work four months after birth (or even sooner). I couldn't imagine how I could stay at home with a child, or multiple children, for three or more years without working. I really like my job, so why should I have to get rid of it for three or more years? Why should I forget everything I have learned? But I had no idea how to balance social expectations and my desire to work at that time.\n\n## Flexibility is key\n\nAnd then at GitLab, balancing parenting and work came so naturally. This is perhaps because I was working remotely and that made it much easier. Twelve weeks of parental leave passed quickly. The first 8-10 weeks were crazy, but then it got easier. Whenever our little one was sleeping or playing I had time to work. I started working part time after 12 weeks and I am really happy I was granted this opportunity.\n\nWorking part time has been great for me so far. I am really grateful that working for GitLab offers such a flexible schedule. When our baby was about six months she started moving, but it was not really a problem. I just changed my schedule and I started working two full days and one half day when I have our parents arranged for babysitting (instead of the five half days I had worked before). I actually have rest from the baby while working and rest from work while taking care of the baby.\n\nIn all honesty, if I had the option for more than 12 weeks of parental leave, I would have taken it. I could have applied more leave maybe a bit later in my child's life, because any parent knows that it is a new challenge when a child starts moving. I also can't imagine starting to work full time after those first 12 weeks.\n\n## Still able to contribute\n\nI came to Cape Town with six-month-old Eliška in August 2018, where we had the [GitLab Summit](/blog/gitlab-summit-cape-town-recap/). I was a bit worried about how my husband and I would handle everything but it was amazing. We were able to join in on all excursions and my husband took over for Eliška most of the time so I could enjoy all the activities, including a session about working with kids productively.\n\nI realized that having a child doesn't have to change your life, even in a country where you're \"supposed\" to raise your child full time and not work. Clearly, giving life to a new human being has been a big change in my life. As her parents, my husband and I must support her development, keep her occupied, happy, and safe. But I realized that becoming a mother doesn't mean I have to give up my old life. I can continue working and progress with my career. I can keep my hobbies, such as sport (I just accomplished a half-marathon in Scotland), and my husband and I learned how easy it is to travel with a baby.\n\nAnd the opinion of the Czech society? I have friends and family around who support my decisions, and many say they admire me for continuing to work while raising my daughter. I am pretty sure there are still a lot of people who don't comprehend my decision, but the fact that I work from home for a [family first](https://handbook.gitlab.com/handbook/values/#family-and-friends-first-work-second) company makes my decisions more socially acceptable. My family is also fortunate to have grandparents that help us a lot. In my experience, the GitLab way is simply better for me and my family than the \"traditional Czech way.\" I am happy with how my work and family life is balanced.\n\nWhat do you think about parental/maternity leave around the world and in the US? How has it been working for you and are you happy with your way?\n\n_Next up in our series we look at the practical challenges of managing your physical space while working at home with children._\n\nPhoto by [insung yoon](https://unsplash.com/@insungyoon?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/baby-mobile?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,708,683],{"slug":777,"featured":6,"template":687},"balancing-career-and-baby","content:en-us:blog:balancing-career-and-baby.yml","Balancing Career And Baby","en-us/blog/balancing-career-and-baby.yml","en-us/blog/balancing-career-and-baby",{"_path":783,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":784,"content":790,"config":796,"_id":798,"_type":14,"title":799,"_source":16,"_file":800,"_stem":801,"_extension":19},"/en-us/blog/best-life-best-work",{"title":785,"description":786,"ogTitle":785,"ogDescription":786,"noIndex":6,"ogImage":787,"ogUrl":788,"ogSiteName":673,"ogType":674,"canonicalUrls":788,"schema":789},"Ski first, work later - How to win the burnout battle","How I truly achieved work/life balance with an all-remote async working style.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682336/Blog/Hero%20Images/taylor-peak.jpg","https://about.gitlab.com/blog/best-life-best-work","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ski first, work later - How to win the burnout battle\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n        \"datePublished\": \"2022-06-07\",\n      }",{"title":785,"description":786,"authors":791,"heroImage":787,"date":793,"body":794,"category":299,"tags":795},[792],"Taylor McCaslin","2022-06-07","\n\nIt's 9:13 am and 20 degrees outside in Big Sky, Montana. I'm bundled up in my warm rainbow pride ski suit. Dangling 30 feet in the crisp air, perched on a ski lift, I'm on my way up to a double black diamond run 9,382 feet above sea level. There are few people out this early on a Wednesday morning. I ski off the top of the lift and enjoy a beautifully untracked run of champagne powder snow, fresh from last night's snowstorm. This is a normal start to the workday for me. And I have a bit of a secret to admit, this is exactly why I joined GitLab.\n\n![Taylor on a chair lift at Big Sky Resort](https://about.gitlab.com/images/blogimages/2022-06-04-best-life-best-work/chair-lift.jpg)\n\n## Something's gotta give\n\nRewind two years to January 2020, before I joined GitLab. Before I had materialized my daily skiing routine. Before I moved to Big Sky. Before the global Covid-19 pandemic. I had decided I needed to make a change in my life. I had spent the past decade of my life climbing the startup tech career ladder. Along the way I had sacrificed my health, happiness, and my mental and emotional well-being. I was burnt out. While I don't think I'd change anything going back, I knew the next decade wouldn't sustain that lack of work and life balance. I needed to get back to being the person my friends and family knew: a slim guy with a smile always on his face and a hopeful outlook for the future.\n\n> You’re invited! Join us on June 23rd for the [GitLab 15 launch event](https://page.gitlab.com/fifteen) with DevOps guru Gene Kim and several GitLab leaders. They’ll show you what they see for the future of DevOps and The One DevOps Platform.\n\n## A remote change\n\nGitLab had been on my radar for a number of years as many of my tech friends had become DevOps engineers, but I had not used it myself. What I did know was at the time they were one of the few [truly remote companies with no offices and a global team embracing an async work style](/company/culture/all-remote/tips/#how-it-works-at-gitlab). \n\nWhile I hadn't ever worked remotely before, I knew I liked the idea of not being stuck in a bland office of noisy and distracting open floor layout workspaces surrounded by silly ping pong tables and unlimited snacks. My previous employers thought these things made for a 'supportive environment and 'great work culture'. I couldn't disagree more. It was a scary thought to have less structure, but my previous decade had shown me those offices weren't conducive to my sanity, happiness, or productivity. So I decided, let's go all in.\n\nI knew I wanted to make a big change, so I tested GitLab when I was interviewing. I gauged reactions from my interview panel as I described my desire to move to a ski mountain and balance working and skiing. I was caught by surprise. Every person I interviewed with loved this idea and encouraged me that GitLab's remote and async working style would be supportive of this plan. Just about everyone had a story of how they themselves had adjusted their schedule to add flexibility to their lives. I was convinced. This was the future. \n\n## A global pandemic \n\nTwo months after joining GitLab in January 2020, the pandemic ruined my plans to relocate to a wintry wonderland. I delayed my move, diving into work like many of us did, mainly because there wasn't anything better to do. Fast-forward to December 2020 – it was clear Covid wasn't going away anytime soon. I had gained the Covid 15 lbs. from sheltering in place in my Austin, Texas, apartment for the past nine months. It was time for a change. I needed to prioritize my sanity and health. An outdoor sport like skiing seemed like a relatively low-risk activity. The move was back on. \n\nBy February 2021, I had relocated to Big Sky, 1,600 miles away from the state I had lived in for my entire life. With zero friends and only two bags to a town of 3,000 people. I had visited Big Sky a number of times on ski trips with friends in the years before, and each time the three-to-four day trip never seemed long enough. Now I would be able to call this place my home. \n\n![Welcome sign to Big Sky, Montana](https://about.gitlab.com/images/blogimages/2022-06-04-best-life-best-work/welcome-to-bigsky.jpg)\n\n## A new chapter\n\n2021 was the year of me. I was turning 30, exploring a new life living in a mountain town. It's hard to believe how fast your life can completely change. I went from being depressed and unhappy living a sedentary life in Texas to being out and about on a beautiful mountain nearly daily with a new sense of self. \n\nI've done things I never thought I would, or could, do. I took up hiking. I learned to enjoy the outdoors by visiting Yellowstone National Park, just 30 minutes from my house. I also explored 13 other national and state parks. I learned downhill mountain biking. I rode over 1,000 miles downhill on my mountain bike. I've explored mountains in five states and two countries, and I've skied and biked in the shadow of the Grand Tetons. I skied 186 days at 20 resorts across the last two ski seasons. I went on a combination ski and biking trip to the mountains of Salt Lake City and Moab, Utah, and to the mountains of Canada. Along the way I lost 25 lbs., getting me back to a healthy weight I felt good about. \n\n![Collage of Taylor's adventures while at Gitlab](https://about.gitlab.com/images/blogimages/2022-06-04-best-life-best-work/collage.jpg)\n\n## Happy people do their best work\n\nAnd you know what else is crazy? I've been doing my best work since all this. [GitLab went public](/blog/gitlab-inc-takes-the-devops-platform-public/) last October. I am now establishing and leading [a new machine learning team](/direction/modelops/) at a public company, all from rural Montana. This also presented me with an opportunity to even further embrace remote async life. \n\nWith my new ModelOps team at GitLab, I have a number of team members in APAC, so I decided this past winter to switch to working evenings, embracing some of my favorite GitLab values: [Measure results not hours](https://handbook.gitlab.com/handbook/values/#measure-results-not-hours) and [shifting working hours for a cause](https://handbook.gitlab.com/handbook/values/#shift-working-hours-for-a-cause). This change allows me to ski and mountain bike during the day and, as a night owl, leverage my most productive hours overlapping with more of my colleagues in APAC. \n\n![Taylor biking in Glacier National Park](https://about.gitlab.com/images/blogimages/2022-06-04-best-life-best-work/glacier.jpg)\n\nNow I can join my evening team meetings in person rather than relying on a recording and notes. I always enjoy when I meet with my team members as they always want to know: \"What mountain are you on today?\" It's a simple small talk question, but it's just another way we connect virtually and get to know each other better as people. And, of course, at GitLab we have a Slack channel for everything. I frequently post and share my adventures in #DevSkiOps and #mountainbiking and enjoy swapping photos, tips, and articles with my fellow GitLab skiers and bikers. But let's have the numbers speak for themselves. Here are my '21/'22 ski season metrics, and I can't wait for this summer's mountain biking adventures.  \n\n![Taylor's 2021/22 Ski metrics](https://about.gitlab.com/images/blogimages/2022-06-04-best-life-best-work/slopesapp.jpg)\n\nMy journey to the mountains and switching up my working schedule all showcase my favorite value at GitLab: [Don't wait](https://handbook.gitlab.com/handbook/values/#dont-wait). I think this value applies to our personal lives as much as it does to our professional ones. Life is short, and the pandemic has made that even more real as we've lost so many friends and family so early. Gone are the days of sacrificing your life for 9-5 dead-end jobs. We're realizing life has so much more to offer and employers are increasingly recognizing that happy employees do their best work. \n\nHad you asked me two years ago if I'd see myself living in a small mountain town skiing and biking nearly daily while working at a public company, living my best personal life, and doing the best work of my career, I would have thought you were crazy. But now it's my life. All thanks to the [remote and async lifestyle](/company/culture/all-remote/guide/#the-remote-manifesto) GitLab empowers. And the best part, [we're hiring](/jobs/).\n\n![GitLab Remote Work Promo with Taylor](https://about.gitlab.com/images/blogimages/2022-06-04-best-life-best-work/ski-promo.png)\n",[683,9],{"slug":797,"featured":6,"template":687},"best-life-best-work","content:en-us:blog:best-life-best-work.yml","Best Life Best Work","en-us/blog/best-life-best-work.yml","en-us/blog/best-life-best-work",{"_path":803,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":804,"content":810,"config":816,"_id":818,"_type":14,"title":819,"_source":16,"_file":820,"_stem":821,"_extension":19},"/en-us/blog/best-practices-remote-engineering",{"title":805,"description":806,"ogTitle":805,"ogDescription":806,"noIndex":6,"ogImage":807,"ogUrl":808,"ogSiteName":673,"ogType":674,"canonicalUrls":808,"schema":809},"5 Ways to level up your remote engineering skills","A round-up of our blog posts unpacking the top tips for working remotely as an engineer.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677856/Blog/Hero%20Images/collaboration.png","https://about.gitlab.com/blog/best-practices-remote-engineering","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Ways to level up your remote engineering skills\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2021-03-12\",\n      }",{"title":805,"description":806,"authors":811,"heroImage":807,"date":813,"body":814,"category":705,"tags":815},[812],"Sara Kassabian","2021-03-12","\n\nThe COVID-19 pandemic means many engineering teams have made the shift from working under one roof to [working remotely](/company/culture/all-remote/guide/). For some companies that [change could be permanent](https://www.businessinsider.com/salesforce-employees-can-work-from-home-permanently-2021-2). At GitLab, this is how we've always worked. This round-up consolidates some of the top insights from leaders in the all-remote space, and also includes a number of best practices engineering teams of all sizes can replicate.\n\n## 1. Embrace a remote-first culture\n\nTwo HubSpot team members joined GitLab Virtual Commit, our user conference, to talk about how discarding a remote-friendly culture in favor of a remote-first culture helped build a more inclusive workplace. Watch the video below to learn more about HubSpot's move to remote.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/zULmuyw3P38\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## 2. Be a thoughtful manager\n\nLet’s be honest, managing an all-remote, globally distributed team is different from managing when you’re all in the office. [Engineering managers at GitLab share their tips for being a thoughtful and effective team leader – from a distance](/blog/tips-for-managing-engineering-teams-remotely/).\n\n## 3. Cut down on Zoom fatigue\n\nEvery engineering manager we talked to suggested cutting down on the number of meetings and make the pivot to asynchronous work. In this session from GitLab Virtual Commit, Luke Thomas with Friday.app explains how to make the transition.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/o1L_ztow1jk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nNeed to cut down on Zoom fatigue but still require weekly discussions? The GitLab Support team got creative and [turned their weekly department meeting into a podcast](/blog/how-we-turned-40-person-meeting-into-a-podcast/ ). Now, team members can catch up on the latest developments on their own time and off-camera.\n\n## 4. Some advice on engineering together while apart\n\n[Collaboration on an all-remote team takes practice](/blog/engineering-teams-collaborating-remotely/). GitLab team members we interviewed suggest embracing asynchronous communication, share suggestions for onboarding new engineers, and more.\n\nWatch this video from GitLab Virtual Commit to dive deeper into best practices for remote onboarding engineers.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/tdWxlpN8dUk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nPair programming is great for problem solving tricky code, but when you work on an all-remote team, you can’t just pull up a chair and get it done. [Our remote pairing enthusiasts share four tips on how to make it happen](/blog/remote-pair-programming-tips/).\n\nWhen it comes to pairs, [nothing goes together better than Agile software development and all-remote work practices](/blog/agile-for-remote-work/). GitLab (the product) is built on Agile principles and facilitates remote collaboration while GitLab (the company) is made up of a globally distributed workforce.\n\n## 5. Always know your results\n\nGitLab is a [results-driven company](https://handbook.gitlab.com/handbook/values/#results), meaning we care about what you achieve than how you achieve it. To measure your engineering productivity, we suggest calculating your merge request (MR) rate. [Read on to learn why this metric matters](/blog/measuring-engineering-productivity-at-gitlab/).\n\n## Bonus: Learn more about remote work\n\nWe have a number of resources to help engineering teams up-level their all-remote work. Here are a few places to start:\n\n- [How to manage a remote team](https://www.coursera.org/learn/remote-team-management): Join nearly 17,000 people in taking the Coursera class we created to help newly remote teams. Learn how to manage a remote team (for free).\n- Get the [GitLab guide to all-remote work](/company/culture/all-remote/guide/): We round-up lots of remote work tips in our all-remote section of the GitLab Handbook.\n- Check out more resources on our [all-remote hub](/company/culture/all-remote/), including our 2021 Remote Playbook, the Remote Manifesto, and more.\n",[9],{"slug":817,"featured":6,"template":687},"best-practices-remote-engineering","content:en-us:blog:best-practices-remote-engineering.yml","Best Practices Remote Engineering","en-us/blog/best-practices-remote-engineering.yml","en-us/blog/best-practices-remote-engineering",{"_path":823,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":824,"content":830,"config":836,"_id":838,"_type":14,"title":839,"_source":16,"_file":840,"_stem":841,"_extension":19},"/en-us/blog/building-a-handbook-first-remote-learning-culture",{"title":825,"description":826,"ogTitle":825,"ogDescription":826,"noIndex":6,"ogImage":827,"ogUrl":828,"ogSiteName":673,"ogType":674,"canonicalUrls":828,"schema":829},"Building a Handbook First Remote Learning Culture","An overview on how to build a handbook first remote learning culture","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","https://about.gitlab.com/blog/building-a-handbook-first-remote-learning-culture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Building a Handbook First Remote Learning Culture\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Josh Zimmerman\"}],\n        \"datePublished\": \"2020-12-22\",\n      }",{"title":825,"description":826,"authors":831,"heroImage":827,"date":833,"body":834,"category":729,"tags":835},[832],"Josh Zimmerman","2020-12-22","\n{::options parse_block_html=\"true\" /}\n\nLearning & Development (L&D) is a vital function of any organization’s People or HR team. When most professionals think of L&D, they may remember sitting in the back of a conference room hearing a corporate trainer deliver slides, or maybe accessing self-paced training once or twice a year, or perhaps taking a survey on how to grow their skills. At GitLab, L&D is a huge priority and we do it differently than most organizations! \n\nSince GitLab is [all-remote](https://about.gitlab.com/company/culture/all-remote/) and our [Handbook](https://about.gitlab.com/handbook/) is our primary source of learning, you may be asking yourself, how does L&D create and reinforce a remote learning culture? \n\n[GitLab’s Handbook](https://about.gitlab.com/handbook/) is over 8,000 pages long, and it grows every day. We consider each page to be a source of learning & development material. Pages are for training new team members on GitLab processes, culture, ways of working, and much more. The Handbook is publicly available worldwide, and anyone can [learn about GitLab's Remote working culture](/company/culture/all-remote/building-culture/) and [DevOps](/topics/devops/). It’s a ton to digest, and from a learning perspective, the text-based format can lean heavily on reading and video. For GitLab to scale L&D, we need to make our Handbook more consumable where it is easy to learn new things!  \n\nI joined GitLab eight months ago from management consulting to help build a learning culture. It’s an exciting opportunity. Our team is growing fast. We deliver more resources to the community, and we are helping team members learn more by introducing new handbook first learning modalities. I wanted to share my thoughts on some of the biggest takeaways on building a handbook first remote learning culture. Consider these ingredients to scaling L&D: \n\n## Build a Learning Infrastructure \n\nGitLab’s Handbook is our primary source of training material. Every piece of content pulls from the handbook. As GitLab continues to grow, we needed to invest in a learning technology infrastructure that can enable personalized/self-service learning. By taking material in the handbook, we can apply a [level of interactivity](https://about.gitlab.com/handbook/people-group/learning-and-development/interactive-learning/) to allow various learning styles to consume bite-sized content. We recently invested in a [Learning Experience Platform (LXP)](https://about.gitlab.com/handbook/people-group/learning-and-development/#gitlab-learn-edcast-learning-experience-platform-lxp) by [EdCast](https://gitlab.edcast.com/log_in?auto_sso=true) that will significantly improve our ability to provide certifications, assessments, and self-service learning. \n\nWe also invested in a content library from LinkedIn Learning for off-the-shelf content. Team members will have access to the library for courses that can supplement GitLab’s customized learning content. There's also our use of Articulate 360, which we use to [build interactive handbook first courses](https://about.gitlab.com/handbook/people-group/learning-and-development/interactive-learning/) in the LXP. \n\nThe L&D team has pursued various certification programs that complement our values, such as [Tracom Corporations Social Styles](https://tracom.com/social-style-training/model) facilitator and [Crucial Conversations certification from VitalSmarts](https://www.vitalsmarts.com/crucial-conversations-training/). Our plan is to equip the L&D team with as many tools to design and deliver scalable training. By continuing to invest in learning technologies, we want our team members to know that growing your skills is a top priority for the future of GitLab. \n\n## Design Social Learning Experiences\n\nRemote work can have [some drawbacks](https://about.gitlab.com/company/culture/all-remote/drawbacks/). One of those challenges may be a lack of connection with your coworkers. GitLab L&D uses our live learning courses as an opportunity to build relationships and a sense of community with team members. There may not be a lot of forums outside of [coffee chats](https://about.gitlab.com/company/culture/all-remote/informal-communication/#coffee-chats), [AMAs](https://about.gitlab.com/handbook/communication/ask-me-anything/), [group conversations](https://about.gitlab.com/handbook/group-conversations/), or [1-1 meetings](https://about.gitlab.com/handbook/leadership/1-1/) where team members can **Learn From Others**. We have started to adapt our [live learnings](https://about.gitlab.com/handbook/people-group/learning-and-development/#live-learning) to serve as networking activities where team members work on scenarios in small groups, get to know one another, and share lessons learned. We’ve noticed increased engagement across learners and an atmosphere of encouraging collaboration. Social Learning is the cornerstone of how we will design learning experiences. We can’t expect participants to pay attention to slides for 25 to 50-minute sessions, so we decided to throw out most of them! Team members want to network and build connections during sessions. Why not use learning as a forum to do just that? \n\n## Prioritize Leadership Buy-In and Sponsorship. \n\nGitLab’s CEO, Sid, is very passionate about L&D. He wants to be part of our learning initiatives and share knowledge from his experience growing the organization. Sid has partnered with L&D on recording interviews and [advocating for up-leveling our handbook first learning content](https://about.gitlab.com/handbook/people-group/learning-and-development/#handbook-first-training-content). In order to scale, we receive executive support from Sid and the rest of the e-group on essential initiatives. Our leadership is behind us. Without their support for learning, it would be difficult for L&D to grow and show our people we are invested in them.\n\n## Change Management for Learning & Development\n\nAsking team members to [take time out to learn new skills](https://handbook.gitlab.com/handbook/organizational-change-management/) takes time and energy. Everyone at GitLab is incredibly busy, and carving out time to reskill, and upskill requires a proactive approach. We use GitLab communication vehicles such as Slack channels and Issues to spread various [learning initiatives](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/). With the introduction of new tools, technology, initiatives, and courses, L&D has to conduct [continuous change management](https://handbook.gitlab.com/handbook/organizational-change-management/#introduction) with a heavy focus on communications and enablement. Some of those methods include a [monthly continuous learning call](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#monthly-continuous-learning-call-overview) and quarterly newsletter, where we highlight what’s happening in the L&D space. \n\n## Focus on Developing your Leaders\n\nOne of my first initiatives at GitLab was developing a [manager enablement program](https://about.gitlab.com/handbook/people-group/learning-and-development/manager-challenge/). The program’s focus is to reinforce behaviors through a set period of time, 3 weeks, to train our leaders on remote management practices. We applied neuroscience techniques so that participants can learn at their own pace through positive engagement and social learning. We also recognized that learners might have various attention span ranges, so why not create a program that allows participants to complete activities through [daily challenges](https://about.gitlab.com/handbook/people-group/learning-and-development/manager-challenge/#week-1) that take 20 minutes to complete. The program is bite-sized, blended for different learning styles, flexible, and engaging with the focus on equipping managers with critical skills.\n\nBy focusing on managers as a key priority for L&D, we were able to pilot a program and iterate on future deliveries rapidly. We now have a group of managers who are learning ambassadors that can advocate for learning initiatives in the future.\n\n## Reinforce GitLab Values \n\n[C.R.E.D.I.T.](https://handbook.gitlab.com/handbook/values/#credit) is the acronym GitLab uses for our six values. One way for us to reinforce our values is by threading them throughout our curriculum design and development. The values serve as the cornerstone to how GitLab operates as a Remote organization. I’m lucky to work for an organization that takes them so seriously, and it makes my job as an L&D professional easier. By rooting learning in our values, we can reinforce behaviors. \n\n## Prove L&D is a high-value organization\n\nL&D is a relatively new organization within GitLab. Our team considers ourselves strategic enablers. We are striving to develop a mindset that feels responsible for driving strategy and leading change. Think bigger and broader by being proactive in understanding GitLab’s goals, methods, and operations. We have a goal to align every aspect of L&D with the rest of the company. By piloting and [iterating new initiatives](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/), we let the organization know that we are here to enable behavioral change that directly increases results!\n\nWe have a colossal charter set out for us in L&D. But with the strong encouragement from our leadership, we know that building a handbook first remote learning culture is top of mind. Hopefully, some of the points outlined in this blog will equip you with a few tips on building a learning culture within your organization. \n\nTo learn more, check out our handbook page, [GitLab Learning and Development](https://about.gitlab.com/handbook/people-group/learning-and-development/), or contact learning@gitlab.com to speak with a member of our team.\n",[731,683,9,267],{"slug":837,"featured":6,"template":687},"building-a-handbook-first-remote-learning-culture","content:en-us:blog:building-a-handbook-first-remote-learning-culture.yml","Building A Handbook First Remote Learning Culture","en-us/blog/building-a-handbook-first-remote-learning-culture.yml","en-us/blog/building-a-handbook-first-remote-learning-culture",{"_path":843,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":844,"content":850,"config":857,"_id":859,"_type":14,"title":860,"_source":16,"_file":861,"_stem":862,"_extension":19},"/en-us/blog/building-an-award-winning-culture-at-gitlab",{"title":845,"description":846,"ogTitle":845,"ogDescription":846,"noIndex":6,"ogImage":847,"ogUrl":848,"ogSiteName":673,"ogType":674,"canonicalUrls":848,"schema":849},"How we're building an award-winning culture at GitLab","We're proud to see GitLab recognized as one of Inc. Magazine's Best Workplaces in 2019!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670139/Blog/Hero%20Images/gitlab-contribute-team-photo.png","https://about.gitlab.com/blog/building-an-award-winning-culture-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we're building an award-winning culture at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Betsy Church\"}],\n        \"datePublished\": \"2019-05-16\",\n      }",{"title":845,"description":846,"authors":851,"heroImage":847,"date":853,"body":854,"category":299,"tags":855},[852],"Betsy Church","2019-05-16","\n\nWe’re delighted to share that GitLab has been named one of [Inc. Magazine’s Best Workplaces in 2019](https://www.inc.com/best-workplaces)!\n\nIn its fourth annual ranking for the private company sector, Inc.’s Best Workplaces list recognizes companies that have created exceptional workplaces through vibrant cultures, employee engagement, and stellar benefits.\n\nAlong with nearly 2,000 other participating companies, GitLab submitted an initial application followed by an anonymous employee survey, which gathered information about our team members’ confidence in the future, management effectiveness, trust, perks, and more.\n\nThere are many reasons we’re proud of the culture we’ve built and continue to sustain at GitLab, but we think it’s best to hear about it straight from our people.\nHere’s what a few of our [team members](/company/team/) from across the globe value most about life at GitLab:\n\n\n> “GitLab has a world-class team and industry-changing product velocity. I'm constantly learning from the people around me, and I've yet to hear anyone reject an idea because ‘It's just too hard.’ As a UX practitioner, we're often used to seeing our efforts get pushed down a backlog, but at GitLab, we see product refinements continually (and quickly) delivered into production. It's exciting and motivating.” [_– Christie Lenneville, UX Director_](/company/team/#clenneville)\n\n\n> “Working for GitLab is about something bigger than myself – it's bigger than my team, it's bigger than the employees – it's about partnering with the entire community to create better software.\nSimultaneously I get to help blaze a new trail – scaling an amazing culture with remote teams from around the globe.”\n[_– Joel Krooswyk, Manager, Customer Success_](/company/team/#JoelKroos)\n\n\n> “There are so many things that make GitLab special.\nTo start, of course, it's the people. I think this is due to the unique way in which we work – totally remotely from all around the globe.\nThere is a better chance of obtaining the best talent for the role when there aren't restrictions placed on location.\nThe flexibility also allows me to have time back for my family and life.\nThe stress is lower, I am happier working, and the overall work-life balance is just better here.”\n[_– Candace Byrdsong Williams, Diversity, Inclusion and Belonging Partner_](/company/team/#cwilliams3)\n\n\n> “Working at GitLab gives me confidence because we work with the highest level of transparency.\nBeing able to work remotely not only saves me on average two hours of daily commute time, but also makes it so efficient to respond to customers on time at any time.” [_– Xiaogang Wen, Solutions Architect_](/company/team/#xiaogang_gitlab)\n\n\n> “I love working at GitLab for a variety of reasons, but the flexibility in creating work-life harmony in my life tops my list.\nI work closely with our executive team here, and they have been so supportive and encouraging when family-related conflicts arise.\nThey are constantly reminding me that “family first” is our mantra, and give me ease of mind to take time away when needed.\nOutside of that, Sid, our co-founder and CEO, told me if it’s a beautiful day out and I just want to go enjoy it, I should do that.\nMoments like these make me so proud to be a part of the GitLab team.” [_– Cheri Holmes, Manager, Executive Assistant_](/company/team/#cheriholmes)\n\n\nWe celebrate this news as many of our team members are returning home from [GitLab Contribute](/events/gitlab-contribute/), the next iteration of our company [summits](/company/culture/contribute/previous/).\nHere's a glimpse of the fun we had together in New Orleans:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xdtPNXtkBhE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nThank you to all of our team members around the globe who contribute to making GitLab a great place to work.\n\nInterested in joining our fast-growing, [all-remote](/company/culture/all-remote/) team? [Check out our vacancies](/jobs/).\n",[9,731,856,683],"news",{"slug":858,"featured":6,"template":687},"building-an-award-winning-culture-at-gitlab","content:en-us:blog:building-an-award-winning-culture-at-gitlab.yml","Building An Award Winning Culture At Gitlab","en-us/blog/building-an-award-winning-culture-at-gitlab.yml","en-us/blog/building-an-award-winning-culture-at-gitlab",{"_path":864,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":865,"content":871,"config":879,"_id":881,"_type":14,"title":882,"_source":16,"_file":883,"_stem":884,"_extension":19},"/en-us/blog/cern-connect-global-researchers",{"title":866,"description":867,"ogTitle":866,"ogDescription":867,"noIndex":6,"ogImage":868,"ogUrl":869,"ogSiteName":673,"ogType":674,"canonicalUrls":869,"schema":870},"CERN uses GitLab to remove the obstacles around global researchers","Learn how GitLab helps particle physics laboratory CERN manage over 7,000 projects globally","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670719/Blog/Hero%20Images/cern.jpg","https://about.gitlab.com/blog/cern-connect-global-researchers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CERN uses GitLab to remove the obstacles around global researchers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kim Lock\"}],\n        \"datePublished\": \"2018-10-12\",\n      }",{"title":866,"description":867,"authors":872,"heroImage":868,"date":874,"body":875,"category":681,"tags":876},[873],"Kim Lock","2018-10-12","\n\nCERN is the European Organization for Nuclear Research. Using highly sophisticated\ninstruments, the organization’s physicists and engineers study the fundamental particles\nthat are the building blocks of the universe. This organization was looking for a way to\novercome the challenges associated with managing thousands of projects with numerous contributors\nlocated all around the world.\n\nTo assist with these challenges, the [CERN IT department searched for a streamlined solution](https://about.gitlab.com/customers/cern/) for\ncode review. In addition to having the capacity to get a large number of projects and users up and\nrunning quickly, they were also looking for their selection to be easy for those users who are less\nexperienced with Git. GitLab met their requirements and they began utilizing these features.\n\nCERN chose to make the move to GitLab for their code hosting needs approximately three years ago. CERN\nhas long been a strong advocate for open source software, and solutions enabling data sovereignty. GitLab’s\nopen core, self-managed model was attractive to the organization because of these desires.\n\n### Today CERN has more than 12,000 users using GitLab and runs 120,000 CI jobs per month\n\n“It’s clearly a powerful tool to do our operations, code collaboration and record discussions on our\ndevelopment and deployment process. We can do more because we can handle more complex projects. As an\nindividual, I’m able to be involved with several large projects because I can rely on GitLab, and the\nother development tools that we have deployed around GitLab, to keep track of things. This is my perception\nas a GitLab user for three years: it’s not that I can do new things, but I can do more because of the\nefficiency of the tool,” said Alex Lossent, Version Control Systems Service Manager, CERN IT department\n\nThe team at CERN's IT department recently sat down with us to share the details of how GitLab is helping\nthem bridge the gaps of working and communicating in a global workspace. “We have this main analysis code on\nGitLab with millions of lines of code. Each team of physicists also has their own repositories with their\nspecific data analysis. And the on-premise nature of GitLab is really useful because we can access other CERN\nservices, data storage and other information that we wouldn’t have on GitHub,” Lukas Heinrich, a partner\nphysicist currently studying at New York University, explained.\n\nYou can learn more about CERN's story and how they are using GitLab in this case stuy [Particle physics laboratory uses GitLab to connect researchers from across the globe](https://about.gitlab.com/customers/cern/)\n",[877,878,731,9],"user stories","code review",{"slug":880,"featured":6,"template":687},"cern-connect-global-researchers","content:en-us:blog:cern-connect-global-researchers.yml","Cern Connect Global Researchers","en-us/blog/cern-connect-global-researchers.yml","en-us/blog/cern-connect-global-researchers",{"_path":886,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":887,"content":892,"config":900,"_id":902,"_type":14,"title":903,"_source":16,"_file":904,"_stem":905,"_extension":19},"/en-us/blog/collaborating-on-a-cross-stage-feature",{"title":888,"description":889,"ogTitle":888,"ogDescription":889,"noIndex":6,"ogImage":807,"ogUrl":890,"ogSiteName":673,"ogType":674,"canonicalUrls":890,"schema":891},"How we tested a feature that affected (almost) all parts of GitLab","Crowd-sourcing testing across teams","https://about.gitlab.com/blog/collaborating-on-a-cross-stage-feature","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we tested a feature that affected (almost) all parts of GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aakriti Gupta\"}],\n        \"datePublished\": \"2021-03-17\",\n      }",{"title":888,"description":889,"authors":893,"heroImage":807,"date":895,"body":896,"category":729,"tags":897},[894],"Aakriti Gupta","2021-03-17","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIn 13.9 Team Geo [released Maintenance Mode](https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/#maintenance-mode), which was a large, cross stage and cross team project, a few milestones in the making.\n\nThis feature allows system administrators to put GitLab in a read-only mode. All parts of the system are affected and testing such a wide scope was challenging.\n\n## Why was testing this feature hard?\n\nAs we started testing with the QA team, it was clear that no one individual or team could know enough about the entire product to design a comprehensive QA plan. The more we tested, the more features we found to test - it was soon becoming an impossibly long list of tests to write for our small team.\n\nWe needed to prioritize manually testing the most important features, and save working on automated tests for another iteration.\n\nBut, what were the most important things to test?\n\nThis is where we decided to crowd-source testing. [We rolled-out discussion issues](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=closed&author_username=aakriti.gupta&search=crowd-sourced+maintenance+mode+testing) to each of the 13 stages and asked them to contribute the three most important features that they own, that we should prioritise testing.\n\nWe used these issues to share knowledge of maintenance mode, and responsibility of its development, testing and documentation.\n\nThe response was overwhelming!\n\nProduct managers and engineers from across the development department contributed to our list of tests and collaboratively reviewed and improved documentation. They proactively asked how their features would behave and in some cases, even started MRs to fix the documentation.\n\nThe conversations helped us hone our plan for future iterations of this feature.\n\n## What we learned\n1\\. **Test iteratively and collaboratively**\n\nGet QA and developer teams working together early, instead of after development is almost done, or worse - after release. GitLab's [Quad planning](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning/) process was introduced last year to foster better collaboration between Quality, Development, UX, and Product teams. As [Jennie from QA](https://gitlab.com/jennielouie) chalked out a plan for QA together with developers, she found a few edge cases that would have otherwise been discovered too late.\n\n2\\. **Don’t hesitate to ask other teams to contribute**\n\nWhen we rolled out a dozen plus issues to all development teams, we were not sure if we’d get even a few responses, but we were overwhelmed with the interest, response and active participation that came from all the teams.\n\n3\\. **Communicate well**\n\nGive people enough and succinct information. When requesting help from other teams, help them prioritize the request by explaining the why.\n\n4\\. **Documentation as a form of developer communication**\n\nAs we worked through large documentation MRs, I realized the documentation was not only important for system administrators, but for developers of GitLab as well. Developers wanted to know how maintenance mode affected their features.\n\n5\\. **Iterate**\n\nKeep the discussions short-lived and focused on the most important aspects. Do not draw out the conversations too long, and move pending conversations over to follow-up issues.\nAs we learned of new test cases, [Nick from QA](https://gitlab.com/nwestbury) and I created follow-up test issues to resolve together with DRIs.\n\n6\\. **The more, the merrier**\n\nWhile the discussions started only with Engineering Managers and Product Managers, they often invited engineers in their conversations and this brought more eyes to the project and helped us answer a lot of unknowns.\n",[731,683,9,898,899],"testing","workflow",{"slug":901,"featured":6,"template":687},"collaborating-on-a-cross-stage-feature","content:en-us:blog:collaborating-on-a-cross-stage-feature.yml","Collaborating On A Cross Stage Feature","en-us/blog/collaborating-on-a-cross-stage-feature.yml","en-us/blog/collaborating-on-a-cross-stage-feature",{"_path":907,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":908,"content":914,"config":921,"_id":923,"_type":14,"title":924,"_source":16,"_file":925,"_stem":926,"_extension":19},"/en-us/blog/collaboration-techniques-for-distributed-teams",{"title":909,"description":910,"ogTitle":909,"ogDescription":910,"noIndex":6,"ogImage":911,"ogUrl":912,"ogSiteName":673,"ogType":674,"canonicalUrls":912,"schema":913},"Synchronous collaboration for async distributed teams","The strategic exercise supported meaningful reflection as well as alignment in setting goals.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682962/Blog/Hero%20Images/collaboration-techniques-blog-post.jpg","https://about.gitlab.com/blog/collaboration-techniques-for-distributed-teams","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How a Lightning Decision Jam helped our asynch, distributed team collaborate synchronously\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amelia Bauerly\"}],\n        \"datePublished\": \"2022-01-19\",\n      }",{"title":915,"description":910,"authors":916,"heroImage":911,"date":918,"body":919,"category":681,"tags":920},"How a Lightning Decision Jam helped our asynch, distributed team collaborate synchronously",[917],"Amelia Bauerly","2022-01-19","\nIn a remote, asynchronous company, is there ever a time when teams need to collaborate synchronously? \n\nWe recently asked ourselves that question on the Monitor team. It had been three years since we started thinking about how to build out Incident Management as a team, and a lot had happened in that time. We’d built out a range of new features and created the broad outlines for a complete incident management workflow with GitLab. We’d achieved a lot.\n\nWe had also been through a number of changes as a team, and we had several possible paths ahead of us. It felt like an appropriate moment to step back and take stock of where we’ve been, what we’ve done, and where we still need to go. However, given our team's geographical distribution, we realized we needed to think creatively about how best to create space for reflection as a team.\n\n## Opting for a Lightning Decision Jam\n\nOutside of regularly scheduled team meetings, our team adheres to the standard GitLab practice of prioritizing [asynchronous communication](/handbook/communication/asynchronous-communication). Because our team is distributed around the world, this model usually works great for us. But, given the amount of time that had passed since we had all gathered together, this time around, we decided it might actually be nice to gather synchronously.\n\nOwing to the time zone differences we'd face, we wouldn’t have a lot of time together. We needed to find a structure that would allow us to do some reflection as a team in a limited amount of time. \n\nEnter: [Lightning Decision Jam](https://uxplanet.org/lightning-decision-jam-a-workshop-to-solve-any-problem-65bb42af41dc). \n\nA Lightning Decision Jam (LDJ) is a quick way for teams to come together to collaboratively identify problems and challenges, and then work together to ideate on solutions for those challenges – all in one hour. This format would give us space to check in with each other as a team about the work that we’ve been doing, while keeping those discussions constrained in a way that would (hopefully) respect the fact we’d all be gathering at different times in our days. \n\n## How the LDJ worked?\n\nWe hosted the session on [Zoom](https://zoom.us), and a majority of our team members were able to join the call synchronously. We met with the team members unable to join prior to the main LDJ session so they could participate as well. We also recorded the session so they could review the larger discussion afterward. We used [Mural](https://www.mural.co/) to collaborate during the session. \n\nThe session itself involved a series of time-boxed, individual brainstorming exercises, where each team member generated sticky notes in response to a prompt. Some of the brainstorming exercises included questions like:\n\n- What is moving us forward?\n- What’s gone well?\n- What are the challenges that are holding us back?\n- How might we address those challenges?\n\nAfter each person generated their sticky notes, the ideas were shared with the group. After all the ideas were shared, we used [dot voting](https://www.nngroup.com/articles/dot-voting/) to surface the ideas that had the most traction within the group. \n\n## What the LDJ taught us\n\nThere were a few things we observed as we conducted this exercise as a team. \n\nAt GitLab, we work in a monthly cadence. We have a large backlog of features to implement, and an ever-growing list of things to improve. All of these factors, taken together, can make it easy to focus on the things that aren’t yet where we'd like them to be, or that still need to be done.\n\nThat being the case, simply taking some time to reflect on what we’ve done well was a worthwhile exercise. Holistically thinking about what we’ve built over the past few years and taking a moment to pause and celebrate the things that we’d achieved as a team was a beneficial thing for us to do together. \n\nSpending time thinking about the main challenges we face as we move forward was also a useful exercise. Importantly, though, we didn't just focus on the challenges; we also spent time ideating on solutions and voting together, as a team, on which solutions seemed the most meaningful to action. These additional steps helped us to re-align and re-focus on the path ahead.\n\nOf course, we could have done some reflection on these topics outside of an in-person, synchronous session. The benefit of doing this as part of the LDJ was that we all got to spend some time together as a team, brainstorming and collaborating in real-time. Especially now, due to the global circumstances and the pandemic more generally, being able to see, hear, and spend time with each other has a certain intrinsic value, especially in terms of team cohesion. Furthermore, the strict structures of the LDJ meant that we could spend some time discussing these topics in a focused way. While we didn’t get to discuss everything as thoroughly as we would have liked, it at least gave us space and the opportunity to start the conversation.\n\n## What’s next? \n\nThe result of the LDJ was a set of GitLab issues that outline the opportunities we identified. These issues already have ideas attached to them that have been vetted by the team, so they are immediately actionable. The hope is that we can start experimenting with the ideas we've generated in upcoming milestones, and that these ideas will help us address our larger goal of increasing the number of people using our features.\n\nWe also conducted an asynchronous [plus-delta exercise](https://www.lucidmeetings.com/glossary/plus-delta) to identify opportunities for improving similar sessions in the future. In particular, there was interest in conducting the entire LDJ asynchronously, so everyone can participate at their leisure, perhaps having team members spend 5-10 minutes on five consecutive days to complete all of the exercises independently. This may also give people the room to reflect on the questions more deeply than we can do in a live, in-person session.\n\nMy hope, though, is that this is just the first of these kinds of collaborative workshops that we can do as a team. Experimenting with different ways of thinking about problems, and different ways of interacting, should help keep us feeling aligned and engaged with the path ahead. It also gives everyone a chance to have a voice in what we do, which, for me, may well be the most important thing.\n\nCover image by [MaxBender](https://unsplash.com/photos/iF5odYWB_nQ) on [Unsplash](https://unsplash.com)\n",[732,731,9],{"slug":922,"featured":6,"template":687},"collaboration-techniques-for-distributed-teams","content:en-us:blog:collaboration-techniques-for-distributed-teams.yml","Collaboration Techniques For Distributed Teams","en-us/blog/collaboration-techniques-for-distributed-teams.yml","en-us/blog/collaboration-techniques-for-distributed-teams",{"_path":928,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":929,"content":935,"config":942,"_id":944,"_type":14,"title":945,"_source":16,"_file":946,"_stem":947,"_extension":19},"/en-us/blog/conducting-remote-ux-research",{"title":930,"description":931,"ogTitle":930,"ogDescription":931,"noIndex":6,"ogImage":932,"ogUrl":933,"ogSiteName":673,"ogType":674,"canonicalUrls":933,"schema":934},"Conducting remote UX research at GitLab","Learn about the different kinds of UX research we conduct at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666775/Blog/Hero%20Images/cover.jpg","https://about.gitlab.com/blog/conducting-remote-ux-research","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Conducting remote UX research at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah O’Donnell\"}],\n        \"datePublished\": \"2017-12-20\",\n      }",{"title":930,"description":931,"authors":936,"heroImage":932,"date":938,"body":939,"category":940,"tags":941},[937],"Sarah O’Donnell","2017-12-20","GitLab is a [remote-only](http://www.remoteonly.org/) organization and just like our [team](/company/team/), our users are spread across the globe. Conducting remote UX research allows us to quickly connect with GitLab users anywhere in the world. It provides us with the opportunity to gather insight into users’ behaviors, motivations and goals when using GitLab. This helps us to determine what features should be built and how they should behave. But how do we do all this remotely?\n\n\u003C!-- more -->\n\nThese are some of the remote UX research methods we use at GitLab.\n\n## Card sorting\n\nCard sorting is a research method for discovering how people understand and categorize information. Each card represents an item or a topic and we ask users to group the cards in a way that makes sense to them. We may also ask them to help us label these groups.\n\nCard sorting can be used to:\n\n- Help design the information architecture of your application\n- Establish what information should be on a page and in what order that information should appear\n- Provide a ranking for items or topics based on a set criteria\n\nWhen analyzing a card sort, we look for common patterns such as which cards appear together the most and which cards are labeled in a similar way.\n\nAt GitLab, we’re currently using card sorting to restructure the sidebar navigation at a project and group level. We want to understand how you, our users, would expect our features to be grouped and classified. Our aim is to improve the ease and the speed at which you navigate around GitLab. We conduct remote card sorting via [Optimal Workshop](https://www.optimalworkshop.com/).\n\n## First-click testing\n\nFirst-click testing explores what users click on first when completing a task within an interface. It tells us whether users are able to find what they’re looking for quickly and easily. This research method is based on the principle that users are two to three times more likely to find what they are looking for if their initial click is correct, rather than a click in the wrong direction.\n\nWe’ve used first-click testing at GitLab to quickly evaluate multiple design ideas against one another. We share our designs with users via [UsabilityHub](https://usabilityhub.com/). We measure whether users take the correct path and how long it takes them to decide where to click. A slower click time would suggest a user has hesitated about where to click.\n\nFirst-click testing is great for providing an indication of whether a design is intuitive to users and helps us to quickly narrow down multiple design concepts.\n\n## Surveys\n\nSurveys are used to investigate the opinions or experiences of users by asking them questions through an online form. A survey invites people to share open and honest feedback. Some people find them less intimidating than other forms of research as there is the option to remain anonymous when providing answers. They also allow us to track how the attitudes and behaviors of our users change over time.\n\nWe’ve used surveys to understand our users and form [personas](https://design.gitlab.com/), to generate new ideas for future GitLab improvements and to help measure users’ satisfaction with our existing features.\n\n## User interviews\n\nIf you take part in a user interview at GitLab, you’ll usually be speaking one on one with a UX researcher. In order to do this, you’ll need a desktop or laptop computer and a headset with a microphone.\n\nWe find that most of our users like to talk with us on their lunch break at their work station, whether situated at home or in an office. We love this, as it provides some insight into the environment in which you use GitLab.\n\nOften our interviews are focused on you! We’ll ask you to chat about things such as your background, occupation and experience with GitLab. Sometimes we might have a particular topic we’d like to discuss, such as how you’ve incorporated GitLab into your workflow. We’ll always tell you our intentions ahead of the call so you have time to think about what you’d like to contribute to the discussion. We also welcome you to share your screen with us during the call. We understand that it is sometimes easier to show and demonstrate something than it is to just talk about it!\n\nWe’ve used feedback from user interviews to:\n\n- Inform our [personas](https://docs.gitlab.com/ee/development/ux_guide/users.html)\n- Follow up on survey answers\n- Understand and develop objectives and goals for features\n\n## Usability testing\n\nUsability testing is a technique used to evaluate a product by testing it with representative users. Usability testing can be divided into two categories: moderated and unmoderated research.\n\n**Moderated**\n\nIf you participate in moderated usability testing at GitLab, you’ll complete a series of tasks whilst being observed by one of our UX researchers. In order to see what you're doing, we'll ask you to share your screen with us. We use [Zoom](https://zoom.us/) to run our moderated usability testing sessions.\n\nAs you use GitLab, we’ll ask you to try and think out loud: tell us what you’re looking at, what you’re trying to do and what you’re thinking. We’re interested in hearing your honest feedback. Sound scary? It really isn’t! It’s important to remember that we’re testing GitLab, not you. You can’t say or do anything wrong during a study.\n\nModerated research allows for conversation between a user and the UX researcher, because both are online simultaneously. It gives the researcher the opportunity to ask a user follow-up questions regarding something they’ve said or done. Subsequently, moderated research provides us with a lot of in-depth qualitative research about our users’ needs. It can help us to uncover usability problems that we weren’t aware of and to generate solutions to solve these problems.\n\n**Unmoderated**\n\nUnlike moderated research, unmoderated research doesn't involve any conversation between a user and a UX researcher. Instead, unmoderated usability testing sessions are completed alone by a user. As users can complete sessions at their own convenience and studies can be run simultaneously, they're good for collecting data quickly.\n\nWe use [Validately](https://validately.com/) to serve the tasks to you and to record your actions. We then analyze the data collected asynchronously. It is, however, still very helpful to us if you try and think out loud while you’re completing tasks.\n\nUnmoderated research can provide some qualitative data. However, as there’s no opportunity to ask users follow-up questions related to their actions, the study should focus on a few specific elements or relatively minor changes. Unmoderated research is usually better at addressing specific quantitative questions, such as:\n\n- What percentage of users successfully completed the task?\n- How long did it take users to complete the task?\n\nAs a researcher cannot view an unmoderated usability testing session until it's completed, there's a risk of a study being unusable if the user didn't complete the tasks as specified or if they ran into technical difficulties.\n\nWe conduct both moderated and unmoderated usability testing sessions at GitLab to test new features and changes to existing features.\n\n## How can I get involved?\n\nWe’re always looking for people to participate in our research, whether you're a GitLab user or not. You can get involved by signing up for [GitLab First Look](/community/gitlab-first-look/), a comprehensive research program that will help us ship the features and fixes you need to do your best work.  Besides being instrumental in shaping the future of GitLab, you’ll have the opportunity to earn gift cards and win awesome tech prizes by sharing your feedback with us.\n","engineering",[9,683,734],{"slug":943,"featured":6,"template":687},"conducting-remote-ux-research","content:en-us:blog:conducting-remote-ux-research.yml","Conducting Remote Ux Research","en-us/blog/conducting-remote-ux-research.yml","en-us/blog/conducting-remote-ux-research",{"_path":949,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":950,"content":956,"config":962,"_id":964,"_type":14,"title":965,"_source":16,"_file":966,"_stem":967,"_extension":19},"/en-us/blog/considerations-for-going-hybrid-remote",{"title":951,"description":952,"ogTitle":951,"ogDescription":952,"noIndex":6,"ogImage":953,"ogUrl":954,"ogSiteName":673,"ogType":674,"canonicalUrls":954,"schema":955},"What to consider when going hybrid","Hybrid-remote is an alluring alternative to all-remote, but requires careful consideration. Here's what you need to know when making the shift.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681897/Blog/Hero%20Images/san_francisco_skyline_dm.jpg","https://about.gitlab.com/blog/considerations-for-going-hybrid-remote","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What to consider when going hybrid\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Murph\"}],\n        \"datePublished\": \"2021-02-17\",\n      }",{"title":951,"description":952,"authors":957,"heroImage":953,"date":958,"body":959,"category":705,"tags":960},[702],"2021-02-17","\n\nAs the working world embraces the reality that we aren't going back to old ways of working, a growing chorus of leaders are forecasting a [hybrid-remote](/company/culture/all-remote/hybrid-remote/) future. While the allure of this concept is understandable — it seems to present the best of two worlds on paper — a great deal of nuance lurks.\n\n\u003Cblockquote class=\"twitter-tweet tw-align-center\">\u003Cp lang=\"en\" dir=\"ltr\">Sorry to break it to all of the remote-only people, but I think offices will make a comeback.\u003C/p>— Allison Barr Allen (@abarrallen) \u003Ca href=\"https://twitter.com/abarrallen/status/1349539596242075648?ref_src=twsrc%5Etfw\">January 14, 2021\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\nIn fact, without great deliberation, care, and intentionality, hybrid can deliver the *worst* of both worlds. If you're charging down this road, you'll want to consider and plan for the points below to minimize dysfunction and the toxic friction of a [two-tier work environment](/company/culture/all-remote/what-not-to-do/).\n\n## Only some days in the office\n\nCompanies that mandate or encourage one or more days per week in-office should be mindful of three important factors:\n\n1. This inhibits team members from considering drastically different living locales, because they still need to be within a commutable distance to an office.\n1. This prevents a company's sourcing and recruiting teams from operating differently compared to all-colocated. New hires will still need to relocate to the general office area, limiting your talent pool.\n1. This will make the process of shifting to remote-first workflows more difficult, as the office will serve as a crutch to collaboration.\n\n## Informal meetings\n\nInformal (or unscheduled and unplanned) meetings in an office can be highly disruptive to hybrid-remote teams. While it may feel efficienct to ask someone you see in a hallway for a few minutes of their time, this typically creates disruption in the day of the person you're hailing and leads to undocumented progress. Any progress made in an informal conversation is invisible to those outside of the office *as well as* others in the office who are not invited to the meeting. Unplanned meetings with undocumented results works against the remote-first practice of documenting all work so that others in the organization can contribute.\n\nLeaders should reinforce a particular rigor on documenting takeaways after informal meetings so that context is agreed-upon, visible to others regardless of their location, and to minimize miscommunication and gossip.\n\n## Redesigned spaces for individual meeting rooms\n\nHybrid calls are also [suboptimal for remote attendees](/company/culture/all-remote/meetings/#avoid-hybrid-calls). We recommend leaders transitioning to hybrid-remote consider redesigning existing office space to optimize for individual workspaces and individual meeting rooms. This reinforces that the office is simply [another venue to work remotely from](/company/culture/all-remote/how-to-work-remote-first/#offices-are-simply-venues-to-work-remotely-from).\n\nBy eliminating conference rooms, a company ensures collaboration is accessible to all and removes the temptation to have in-office team members gather around a single camera for a video call with remote attendees.\n\nLeaders may consider keeping one or two large spaces that can be reserved for team onsites, where entire teams or sub-teams will intentionally travel on specific dates to meet in person (e.g., fiscal year planning, team bonding, etc.). It's important to still document outcomes from these gatherings and ensure that 100% of the team is included.\n\n\u003Cblockquote class=\"twitter-tweet tw-align-center\">\u003Cp lang=\"en\" dir=\"ltr\">I have worked from home for most of my 20+ year career and never ever had so many calls and meetings. I've kept it to myself for a full year but I cannot anymore: y'all are doing this wrong\u003C/p>— Amy Westervelt (@amywestervelt) \u003Ca href=\"https://twitter.com/amywestervelt/status/1353902805048647686?ref_src=twsrc%5Etfw\">January 26, 2021\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n## Agendas upfront\n\nThe most functional hybrid organizations operate [remote-first](/company/culture/all-remote/how-to-work-remote-first/). This ensures that business continues even if 100% of the workforce opts to work remotely, outside of the office, on any given day. A key part of reinforcing this mindset is the mandate that all work meetings have an upfront agenda.\n\nPractically speaking, this means that all in-office meeting invites have a shared agenda document attached, so that others can read, learn, and contribute regardless of their location (or even if they're awake and available during the meeting time). This process ensures that a [live doc meeting](/company/culture/all-remote/live-doc-meetings/) procedure happens even for onsite meetings.\n\nThis is critical for process continuity regardless of where a team member is located. In a hybrid organization, you will have team members who conduct onsite meetings some days, and remote meetings on other days. It's vital that the *process* of those meetings are the same – it's merely the physical position of a team member that changes.\n\n## Coffee chats should be indiscriminate of location\n\n[Coffee chats](/company/culture/all-remote/informal-communication/#coffee-chats) are an excellent way to broaden one's perspective and meet new people from across the organization. Hybrid organizations should take care to not enable selective coffee chat pairing based on who is onsite and who is remote, as it signals a two-tier work environment.\n\n## Record important conversations\n\nThe proximity of people in an office makes hallway, watercooler, and ad hoc conversations appealing. Leaders in hybrid-remote settings should reinforce the importance of using a smartphone as a recording device to capture important, non-confidential work-related conversations, with the consent of both parties. Recording conversations ensure that takeaways can be shared transparently with those outside of the office and minimizes potential misinterpretations.\n\n\u003Cblockquote class=\"twitter-tweet tw-align-center\">\u003Cp lang=\"en\" dir=\"ltr\">Want to make hybrid work? Start at the top.\u003Cbr> \u003Cbr>People want flexibility, a remote-office blend. But allowing flexibility without addressing how execs work risks “faux flex.”\u003Cbr>\u003Cbr>Changing where & how senior execs show up will make or break hybrid.\u003Ca href=\"https://twitter.com/hashtag/futureofwork?src=hash&ref_src=twsrc%5Etfw\">#futureofwork\u003C/a>\u003Ca href=\"https://t.co/H7obOrKlHl\">https://t.co/H7obOrKlHl\u003C/a>\u003C/p>— Brian Elliott (@brianpelliott) \u003Ca href=\"https://twitter.com/brianpelliott/status/1353744550724943872?ref_src=twsrc%5Etfw\">January 25, 2021\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n## Leadership's place in the office\n\nThe best place for leaders and executives to be in a hybrid-remote environment is *[outside](/company/culture/all-remote/transition/#make-the-executive-team-remote)* of the office.\n\n1. This prevents remote team members from a perceived lack of \"face time\" with executives.\n1. This prevents senior leadership from conducting their work in ways that are counter to remote-first principles.\n1. This prevents cognitive dissonance from leadership on what tools, technologies, and training need to be prioritized to support remote-first workflows.\n1. This prevents team members from coming to the office to rub shoulders with executives.\n1. This reinforces that the office is no longer the [epicenter](/company/culture/all-remote/stages/#7-remote-first) of power or decision making.\n\n## Spontaneous social events\n\nIt's understandable for team members to want to gather socially in and around office settings. Structuring [informal communication](/company/culture/all-remote/informal-communication/) is vital in a remote setting, and some companies may choose to repurpose some of their office space to accommodate groups and gatherings. Libraries, fitness centers, game rooms, and music studios (among others) could be created to facilitate social gatherings for those who are onsite on any given day.\n\nLeaders who enable this should be mindful of the following:\n\n1. It's important to budget for travel to include remote team members in onsite social events.\n1. Work should not happen in social rooms, because it hinders [transparency](https://handbook.gitlab.com/handbook/values/#transparency) and creates [dysfunction](https://handbook.gitlab.com/handbook/values/#five-dysfunctions) by forming communication silos.\n\n\u003Cblockquote class=\"twitter-tweet tw-align-center\">\u003Cp lang=\"en\" dir=\"ltr\">"Relative to expectations, how has work from home turned out?"\u003Cbr>\u003Cbr>Expansive research on work-from-home from \u003Ca href=\"https://twitter.com/Stanford?ref_src=twsrc%5Etfw\">@Stanford\u003C/a>, \u003Ca href=\"https://twitter.com/ChicagoBooth?ref_src=twsrc%5Etfw\">@ChicagoBooth\u003C/a>, \u003Ca href=\"https://twitter.com/ITAM_mx?ref_src=twsrc%5Etfw\">@ITAM_mx\u003C/a>, and \u003Ca href=\"https://twitter.com/Jose_MariaRD?ref_src=twsrc%5Etfw\">@jose_mariard\u003C/a> 🌎\u003Cbr>\u003Cbr>(Some well-considered comments in the \u003Ca href=\"https://twitter.com/newsycombinator?ref_src=twsrc%5Etfw\">@newsycombinator\u003C/a> thread as well)\u003Ca href=\"https://t.co/gvanMImy5Y\">https://t.co/gvanMImy5Y\u003C/a> \u003Ca href=\"https://t.co/Ig1X2PDBQH\">pic.twitter.com/Ig1X2PDBQH\u003C/a>\u003C/p>— Darren Murph (@darrenmurph) \u003Ca href=\"https://twitter.com/darrenmurph/status/1353879546358095873?ref_src=twsrc%5Etfw\">January 26, 2021\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n## Equitable benefits and perks\n\nLeaders should carefully evaluate spoken and unspoken perks of the office, and seek to extend equal benefits to those outside of the office. For example, access to an onsite daycare and fitness center would demand a childcare and fitness credit for those who are remote by default. This situation becomes particularly tricky for team members who are onsite some days of the week, and offsite others, unless the credits are extended to all.\n\n## Expect rapid iteration\n\nHybrid-remote organizations may see high office use in the early days of a workplace transition, as people flock to the familiar. However, as remote-first workflows are implemented and people relocate or change their workplace setting for personal reasons, it's possible that more space will go unused.\n\nWhile this may seem jarring, it's a positive indicator that work and culture are progressing without the need of an office. This will create opportunities to capture greater real estate savings and/or repurpose office space for philanthropic efforts, such as opening up an internship center for the local community.\n\nTo assist with the transition, enroll in our \"[How to Manage a Remote Team](https://www.coursera.org/learn/remote-team-management)\" course on Coursera, and download [GitLab's Remote Playbook](https://learn.gitlab.com/suddenlyremote).\n",[9,708,961],"demo",{"slug":963,"featured":6,"template":687},"considerations-for-going-hybrid-remote","content:en-us:blog:considerations-for-going-hybrid-remote.yml","Considerations For Going Hybrid Remote","en-us/blog/considerations-for-going-hybrid-remote.yml","en-us/blog/considerations-for-going-hybrid-remote",{"_path":969,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":970,"content":976,"config":982,"_id":984,"_type":14,"title":985,"_source":16,"_file":986,"_stem":987,"_extension":19},"/en-us/blog/contribute-through-the-eyes-of-a-new-gitlabber",{"title":971,"description":972,"ogTitle":971,"ogDescription":972,"noIndex":6,"ogImage":973,"ogUrl":974,"ogSiteName":673,"ogType":674,"canonicalUrls":974,"schema":975},"Contribute through the eyes of a new GitLabber","I joined GitLab just in time to make it to Contribute New Orleans. Here's a few things you might want to know before going to Contribute Prague...","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683192/Blog/Hero%20Images/contribute-through-the-eyes-of-a-new-gitlabber-unsplash.jpg","https://about.gitlab.com/blog/contribute-through-the-eyes-of-a-new-gitlabber","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Contribute through the eyes of a new GitLabber\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vlad Stoianovici\"}],\n        \"datePublished\": \"2020-02-25\",\n      }",{"title":971,"description":972,"authors":977,"heroImage":973,"date":979,"body":980,"category":705,"tags":981},[978],"Vlad Stoianovici","2020-02-25","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nThe moment when I decided I wanted to work for GitLab was when I saw this interview with Sid:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/e56PbkJdmZ8\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\nI remember I had researched **\"all remote\"** companies and Sid’s interview popped into the queue. He said that since they’re all-remote they pick an interesting place and every 9 months everyone gets together to hang out. And because it’s really \"all remote\" any given location will be far from most but close to some ([GitLab employs people in at least 66 countries](https://about.gitlab.com/company/team/)) so it can literally be anywhere in the world that has a large conference room and internet. \n\nHuh? That sounds really cool, \n\n...but how does that really work? \n\nWho's doing support? :) \n\nDo they all just stop working for a week? \n\nSo I spent the next few minutes watching Sid put into a very appealing context concepts like: boring solutions, everyone can contribute, unified continuous integration, a single source of truth that is written down for the whole world to see, transparency, async communication …etc. Now, at this point I had been working remotely in more-or-less traditional companies for the best part of 5 years and was painfully aware this can lead to quite a few drawbacks, but here was this company that had working remotely embedded in its DNA, where everyone was equally remote, where every workflow was built to accommodate remote collaboration (transparent, distributed, scalable, asynchronous) …and they also have this huge party / get together every 9 months?!\n\nFast forward 2 months, 4 interviews and quite a bit of email chatter and I was boarding this first of 3 planes that would take me to  **N’awlins** for *Contribute 2019* (this was my 3rd day with the company). \n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/xdtPNXtkBhE\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\n**Fun fact #1:** I told my wife all about GitLab’s culture, values and mission which created a huge community and how it was a \"force for good\".\n\nHer response was: That’s all very nice, but I really like the orange foxy logo, it’s really cute, I’ve got a good feeling about them (she’s more of a visual person). \n\n\n![GitLab Tanuki](https://about.gitlab.com/images/blogimages/contribute-through-the-eyes-of-a-new-gitlabber/contribute-through-the-eyes-of-a-new-gitlabber-tanuki.png \"GitLab Tanuki\"){: .shadow.medium.center}\n\n[Tanuki](https://www.linkedin.com/pulse/how-gitlab-logo-relates-software-development-joel-krooswyk/) is Japanese for raccoon dog, which is a smart animal that works in a group to achieve a common goal.\n\n\n\n**Fun fact #2:** It seems that for each Contribute GitLab doubles its size. There were about **600 GitLabbers** when I joined (Contribute New Orleans) and for the Prague 2020 Contribute there’s going to be **at least 1200 of us**. That’s hyper-growth for y’a! Just take a moment to imagine and appreciate the massive effort done by some of our GitLabbers to make this possible. Big ups to all of those involved!\n\n## What to expect\n\nWe tend to think that we need to have trust with someone before allowing ourselves to be vulnerable (to show emotion and to generally act like a human) . And this may ring even more true in the workplace. But it looks like we got that completely backwards (studies show): in order to create trust you need to show and perceive your peers as actual human beings (what psychologists call *\"vulnerability\"*). That makes people feel more relatable and approachable and physical proximity is very important in establishing this report. That is why, even though it is a gargantuan undertaking both logistically and financially, Contribute is still happening and it’s such a huge part of our culture. This is where we get together to bind those relationships that make remote working at such a scale possible. \n\n**Contribute** is where you will be meeting your teammates, where you’ll be socialising with like-minded peers, where you will be making so many connections and where you will be hearing so many interesting stories. Last year I talked to (to mention but a few) snowboarders, skiers, sailors, painters, hacktivists, minimalists, adventure travellers, people who, while working at GitLab, continuously travel the world hopping from one continent to another. People who’ve had the opportunity, while at GitLab, to change their family’s lives for the better by moving to countries where they can be safe, can benefit from healthcare and children can get better education. Generally, people who don’t settle, who have a full life and stride to achieve their full potential from the most diverse backgrounds possible. And they all consider you their peer and share your goals and values. If you’re an introvert and this sounds like your worst nightmare, don’t worry we’ve got you covered: check out this workshop: [Introverts unite! How to survive & thrive at events while introverting](https://gitlab.com/gitlab-com/marketing/contribute/contribute-2020/issues/102).\n\nI remember that last year, at NOLA Airport, a bunch of us had grouped together for the shuttle to the hotel. We were kind of a mixed bunch: people from the US and Canada (who had shorter flights and thus had a much higher energy level), a few Europeans (most of which had been traveling for around 16 to 20 hours) as well as a few GitLabbers from Singapore and Taiwan who had left home over 30 hours ago. Nevertheless, excitement and cheerfulness were the norm and the bus was buzzing with conversations. Most of the people on the bus didn’t know each other and some had known each other but had never met in person. Regardless, it **felt like going** on a road-trip **to summer camp** :).\n\nI distinctly remember that, just before Sid’s Keynote speech (which marked the beginning of Contribute), people were gathering in the foyer of the hotel and as I was walking down the stairs, and into the crowd,  I felt like I was immersing myself in an effervescence pool of exuberance and anticipation.\n\nAnd speaking of Sid, you’ll also get plenty of chances to chat with him but even if you don't you’ll still witness his special brand of humor during his keynote speech. Here’s the one from New Orleans:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/kDfHy7cv96M?t=736\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\nI’d also like to mention [Matt Mullenweg](/company/team/#matt-m)’s (creator of Wordpress and founder / CEO of Automattic) speech where he shared his vision on how companies like GitLab and Automattic are disrupting the paradigm of start-ups and, more broadly, tech companies by being **\"all remote\"** by design and how that offers a huge competitive advance. He was then joined by Sid in an open discussion where both of them made it clear that the big tech companies are trying to tap into this \"all remote\" vision and they are looking to adapt to remote working in ways that would fit their monolithic organisations.\n\nWe also had **workshops**, structured and unstructured discussions about an abundance of topics (from **Kubernetes, Continuous Integration / Continuous Development, GitLab Performance, AutoDevOps  to  Work/life balance, Traveling Hacks, Yoga, etc**).\n\nThe last few days were mostly for team time and outdoorsy activities like **Swamp Pontoon Boat trips**, or excursions through the various **scenic areas of New Orleans**. \n\nFor those of you itching for that GitLab T-shirt or that GitLab coffee mug, you need not worry, there will be a **Pop-up Swag store**, but do hurry, the good stuff sells really fast!\n\nAt the end there will be **a huge party** with drinks and food to end what will be a crazy few days! In New Orleans we got to wear masks which you could have built yourself at one of the workshops.\n\nAs you can imagine it can get pretty hectic since there’s a lot to experience. Add to that a pinch of jet-lag, mix it with the queue of emails you have to keep up with, top it off every night with an open bar and it’s no wonder how this whole thing might seem like a giant laundromat that will leave you spinning. **Just remember to breathe!**\n\n**Pro tip 1:** learn how to use the event’s app and check-out the [#Contribute2020](https://gitlab.slack.com/archives/CLERRHMC2) slack channel to be up to date on where things are happening, what’s up next and where you need to go.\nCheckout [the Contribute FAQ](/events/gitlab-contribute/) for a lot of useful information, but also keep an eye out for emails about Contribute as they contain important updates and links to resources. \n\n**Pro tip 2:** flight duration / country / position within the company are very easy-to-use icebreakers. Maybe put something/original on your name badge. \n\n## Conclusions\n\nWhat I’d recommend (*and my extensive experience of attending a total of one other Contribute speaks for itself*) is this: go out there with an open mind and immerse yourself into it. It’s one hell of a ride. Meet as many people as possible, make connections, create lasting bonds, eat something that you’ve not tried before, try to seat next to different people through breakfast/lunch/dinner or on tour busses, go to sessions with topics that you have no clue about and generally go with the flow and soak it all in. You will go home feeling energised and filled with a sense of belonging and gratitude for being part of this culture.\n\nCover Photo by [Marvin Meyer](https://unsplash.com/@marvelous) on [Unsplash](https://unsplash.com/photos/SYTO3xs06fU)\n{: .note}\n",[277,9],{"slug":983,"featured":6,"template":687},"contribute-through-the-eyes-of-a-new-gitlabber","content:en-us:blog:contribute-through-the-eyes-of-a-new-gitlabber.yml","Contribute Through The Eyes Of A New Gitlabber","en-us/blog/contribute-through-the-eyes-of-a-new-gitlabber.yml","en-us/blog/contribute-through-the-eyes-of-a-new-gitlabber",{"_path":989,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":990,"content":995,"config":1000,"_id":1002,"_type":14,"title":1003,"_source":16,"_file":1004,"_stem":1005,"_extension":19},"/en-us/blog/contribute-wrap-up",{"title":991,"description":992,"ogTitle":991,"ogDescription":992,"noIndex":6,"ogImage":847,"ogUrl":993,"ogSiteName":673,"ogType":674,"canonicalUrls":993,"schema":994},"What we learned at Contribute 2019","Community is everything, all remote makes contribution possible, CMO Todd Barr plays a mean trumpet, and more takeaways from Contribute 2019.","https://about.gitlab.com/blog/contribute-wrap-up","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What we learned at Contribute 2019\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"},{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-06-04\",\n      }",{"title":991,"description":992,"authors":996,"heroImage":847,"date":997,"body":998,"category":705,"tags":999},[678,812],"2019-06-04","\n\n“Community is the best part of GitLab.”\n\nThat message, from the [keynote presentation](https://youtu.be/kDfHy7cv96M) during [Contribute 2019 in New Orleans](/events/gitlab-contribute/), sums up the spirit of GitLab’s seventh all-company gathering. Sure CMO (and MC) [Todd Barr](/company/team/#tbarr) added his trumpet to a NOLA classic, \"When the Saints Go Marching In,\" while others shared potentially embarrassing photos and anecdotes from the past. Contribute newbies, who represented more than half of the over 500 attendees, got advice on how to make the most of the unique event, and CEO [Sid Sijbrandij](/company/team/#sytses) made a clear and compelling case for remote work.\n\nBut what stood out most were the ways “community” plays such a vital role at GitLab. “This is our first Contribute,” Sid said. “We changed the name to remind everyone of our mission, that [everyone can contribute](/company/mission/#mission).” In fact, in the product release before Contribute, contributions from the community to GitLab reached an all-time high of 195, Sid said. Because the company is all remote, “everyone can contribute to GitLab on equal footing.”\n\nIn the spirit of community contributions, we asked GitLabbers to share their top takeaways, advice, and feel-good moments from Contribute.\n\n## Your best self\n\n“I’m so pumped for where GitLab is heading,” said strategic account leader [Adam Olson](/company/team/#adamsolson). “Contribute has inspired me to be better GitLabber. (I want to) win more customers while learning more from others.”\n\n## Network like it matters\n\n[Heather Simpson](/company/team/#Heatherswall), senior external communications analyst, got more out of Contribute than expected. “I think because the main focus of Contribute was to spend time getting to know our team members and having fun, the quantity and **quality** of connections I made far exceeded any I'd made at networking or \"team building\" conferences I'd attended with companies in the past.”\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Our \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> CEO put forth a challenge to make our product better while we’re down in \u003Ca href=\"https://twitter.com/hashtag/NOLA?src=hash&ref_src=twsrc%5Etfw\">#NOLA\u003C/a> at \u003Ca href=\"https://twitter.com/hashtag/GitLabContribute?src=hash&ref_src=twsrc%5Etfw\">#GitLabContribute\u003C/a> and teams got to work and made several iterative improvements, so \u003Ca href=\"https://twitter.com/sytses?ref_src=twsrc%5Etfw\">@sytses\u003C/a> made good on his word and donned this amazing costume (his wife too!) So good. \u003Ca href=\"https://t.co/8nfQCt0NV0\">pic.twitter.com/8nfQCt0NV0\u003C/a>\u003C/p>— Heather Simpson 🌈🍃 (@heatherswall) \u003Ca href=\"https://twitter.com/heatherswall/status/1128129734934704129?ref_src=twsrc%5Etfw\">May 14, 2019\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## Spread the wealth\n\n“This was most definitely the best Contribute ever,” said GitLab's unofficial bacon ambassador [Richard “Reb” Baum](/company/team/#therebbie) (who is also a solutions architect). “Focusing on building relationships allowed us to spread the culture and feel of the company to the large number of new people who have joined since the previous event. As an all-remote company, this is critical to our ongoing success.”\n\n## Continued inspiration\n\n“As an early employee here at GitLab and my sixth [Summit](/company/culture/contribute/previous/), I have never felt more inspired after this week in New Orleans,” said [Philip Camillo](/company/team/#pmanjr311), enterprise account executive. “Working remotely, it’s hard to contextualize hiring 10-12 people a week, and it only hit home when I first walked into the opening keynote. Seeing over 500 people in the main room simply left me speechless.\n\n“Leaving Contribute, I’m inspired by all the team members who received awards and all the people who have helped build the product over the years, as well as new team members making an impact immediately by just jumping in.\n\n“Imagine what we will create if we all work towards generating as much value as possible and making everyone around us inspired. Meeting everyone this last week also made me realize that people see you, and the hard work doesn’t go unnoticed. Working remotely, it can be a bit more difficult to see the direct impact you’re making, and the personal brand you’re building with your colleagues.”\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">A full house of GitLabbers celebrating and gathering around the notion that Everyone Can Contribute \u003Ca href=\"https://twitter.com/hashtag/GitLabContribute?src=hash&ref_src=twsrc%5Etfw\">#GitLabContribute\u003C/a> \u003Ca href=\"https://t.co/dWHiSPZGtV\">pic.twitter.com/dWHiSPZGtV\u003C/a>\u003C/p>— John Northrup (@northrup) \u003Ca href=\"https://twitter.com/northrup/status/1126498724518268929?ref_src=twsrc%5Etfw\">May 9, 2019\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## Decisions at the speed of light\n\n“I took a lot of notes about the keynote but the thing that really stuck out to me was how Sid emphasized speed of decision making,” said [Emilie Schario](https://gitlab.com/emilie), data engineer, analytics. “That was really a lightbulb moment for me.”\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">My awesome teammate \u003Ca href=\"https://twitter.com/rspaik?ref_src=twsrc%5Etfw\">@rspaik\u003C/a> kicking off day two. Amazing stat he shared: 13.5% of merged MRs to \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> come from our community. \u003Ca href=\"https://twitter.com/hashtag/GitLabContribute?src=hash&ref_src=twsrc%5Etfw\">#GitLabContribute\u003C/a> \u003Ca href=\"https://t.co/1CUcyFF70y\">pic.twitter.com/1CUcyFF70y\u003C/a>\u003C/p>— John Coghlan (@john_cogs) \u003Ca href=\"https://twitter.com/john_cogs/status/1126853746754039809?ref_src=twsrc%5Etfw\">May 10, 2019\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nYou can check out the rest of the highlights from Contribute below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xdtPNXtkBhE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVideo directed and produced by [Aricka Flowers](/company/team/#arickaflowers)\n{: .note}\n",[267,707,683,9],{"slug":1001,"featured":6,"template":687},"contribute-wrap-up","content:en-us:blog:contribute-wrap-up.yml","Contribute Wrap Up","en-us/blog/contribute-wrap-up.yml","en-us/blog/contribute-wrap-up",{"_path":1007,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1008,"content":1013,"config":1019,"_id":1021,"_type":14,"title":1022,"_source":16,"_file":1023,"_stem":1024,"_extension":19},"/en-us/blog/crucial-conversations",{"title":1009,"description":1010,"ogTitle":1009,"ogDescription":1010,"noIndex":6,"ogImage":827,"ogUrl":1011,"ogSiteName":673,"ogType":674,"canonicalUrls":1011,"schema":1012},"Having crucial conversations on an all-remote team","Exploring crucial conversations and the way they fit into our values here at GitLab.","https://about.gitlab.com/blog/crucial-conversations","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Having crucial conversations on an all-remote team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Samantha Lee\"}],\n        \"datePublished\": \"2021-02-18\",\n      }",{"title":1009,"description":1010,"authors":1014,"heroImage":827,"date":1016,"body":1017,"category":729,"tags":1018},[1015],"Samantha Lee","2021-02-18","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nLast week, I attended the [Crucial Conversations training](https://www.vitalsmarts.com/crucial-conversations-training/). Since joining the GitLab Learning and Development team back in October of 2020, requests for support in having difficult conversations with team members have been a recurring theme from people leaders. I completed this training as the first step in a two-part training that will enable myself and other members of the Learning and Development team to be certified to train the GitLab team in having crucial conversations.\n\nIn this post, I'll outline a few key takeaways from the course, share how crucial conversations look in an all-remote work environment, and explain how crucial conversations connect to our [CREDIT values](https://handbook.gitlab.com/handbook/values/).\n\n### What are crucial conversations?\n\nWhen a conversation turns crucial, emotions and stressors are running high. Crucial conversations can occur any day, at any time, with any person. They can be planned or they can come out of a casual conversation.  \n\nCrucial conversations usually address one of three topics, but it's not abnormal for a crucial conversation to touch multiple topics!\n\n1. **Content**: This could be a crucial conversation about a one-time issue, like a missed deadline, forgotten appointment, or an aggrivating comment. Content conversations address what happened and how to move forward from it.\n\n2. **Pattern**: When topics of content conversations happen time after time, they become a pattern conversation. Crucial conversations to address patterns could be centered around multiple missed responsibilities or repetitive comments that impact a team's ability to work together efficiently. At home, maybe your requests to your partner to take their phone calls in another room to keep a quiet workspace have been repeatedly ignored. Or at work, your direct report has missed the end of month reporting deadline for 3 months in a row. It's important to address pattern conversation early to get to the root cause, which is likely a content issue.\n\n**A quick note about pattern conversations:** At the time of writing this blog post, our world has just hit the one-year mark of life during the Covid-19 pandemic. While addressing patterns is important, it's equally as important to treat each other with kindess and understand that pandemic-induced stress might show itself in problematic patterns. All the more reason to have a conversation about it!\n\n3. **Relationship**: Here's when things get sticky. Content and pattern conversations are about the action happening (or not happening). But relationship conversations are about the _people having the conversation_. These crucial conversations could be about a lack of trust or mutual respect in a relationship, differing communication styles, or lack of agreement on a project or plan of action. It's also important to remember that conversations intended to be content or pattern-focused can turn into relationship conversations quickly, especially when the person feels an emotional tie to the work or action being discussed.\n\nUnderstanding what crucial conversations **are** is as important as understanding what crucial conversations **are not**. Crucial conversations are **not** synonymous with conflict. This was one of the first things we addressed in the training and I think it's one of the most important factors. When we enter crucial conversations prepared for conflict, we're already approaching fight or flight. We're ready to defend ourselves, to act in protection mode. The goal of crucial conversations is not to fight or protect ourselves, but rather to collaborate on desired results.\n\nTake a second to think about the last time you were part of a crucial conversation - a conversation where you perhaps felt stressed, overwhelmed, or nervous about the topic being discussed. How did your body react? Did your heart rate increase? Did you fall silent? Maybe instead your voice was raised. We each respond to crucial conversations in different ways that detract from the main goal of arriving at a solution that works for all parties.\n\nWe've likely all been part of a crucial conversation in the past, whether it be at work or home. Once we know how to identify these conversations, we can move on to strategies for having them effectively. \n\nAt GitLab, this means having effective, results-driven crucial conversations on Zoom with people from all over the world, which brings its own set of unique challenges.\n\n### Having crucial conversations is hard, and an all-remote team brings its own challenges.\n\nIn an office setting, you might pass by a manager or colleague who asks to discuss a challenge or frustration they're having with your work. Or at home, you might spend time after dinner discussing household responsibilities with your children or roommates. During these crucial conversations, we feed off of body language, tone, and energy in the room to recognize if someone feels [psychologically unsafe](/handbook/leadership/emotional-intelligence/psychological-safety/).\n\nBut on Zoom, when your teammate might be in their home office across town or across the globe, we need to use different cues to [build safety and trust](/handbook/leadership/building-trust/).\n\nSome ways we do that at GitLab include:\n\n1. We meet regularly with our people leaders in [1:1 meetings](/handbook/leadership/1-1/). These regular sessions give space for team members to raise crucial conversations often and address challenges and blockers early.\n1. We keep [1:1 agendas](/handbook/leadership/1-1/#the-1-1-agenda) to get a heads up on what will be discussed and to document action items and takeaways from synchronous conversations.\n1. We watch for the [body language cues](/handbook/leadership/crucial-conversations/#having-crucial-conversations-on-an-all-remote-team) that we can see on a video call or in a person's tone of voice. This includes checking if someone turns their camera off mid-call, becomes silent or unresponsive to the conversation, or sounds choked up or angry.\n1. We create intentional [space for pause](/handbook/leadership/crucial-conversations/#having-crucial-conversations-on-an-all-remote-team). There can be a sense of pressure to fill every minute during any conversation. During video or phone conversations, silence might feel more uncomfortable. We ask for and respect requests for a minute to think before responding right away.\n\nThese strategies aren't exclusive to an all-remote team - I'm sure they can have a positive impact on in-person crucial conversations, too! But when working on a remote team, it's important to recognize what's missing from in-person connection and be mindful to make the space as safe as possible.\n\nI've explained what crucial conversations are and how they show up in an all-remote work environment, but most importantly, I need to explain the **why**.\n\n### Why do crucial conversations matter?\n\nCrucial conversations enable our team to live our [CREDIT values](/handbook/leadership/crucial-conversations/#how-crucial-conversations-align-with-gitlab-values). In our [values hierarchy](https://handbook.gitlab.com/handbook/values/#hierarchy), we prioritize results. What I love most about crucial conversations is that they also prioritize results.\n\nHere's an example:\n\nImagine you're an individual contributor at GitLab. You're feeling overwhelmed with the number of projects on your plate this quarter.\n\nIf you wanted, you could commit to each project, knowing the deadlines were probably unrealistic. You could show up to work each day feeling stressed and overwhelmed. You might snap one day, saying something out of frustration to your team, and regret the comment later on.\n\nOr, you could decide to address the issue with your manager in your 1:1. You can:\n1. Collect your facts. In this case, it's your list of projects all due in the quarter.\n1. Share your story. Express how the workload feels unattainable and you know you can't complete your best work in the given time frame)\n1. Come to a conclusion together. Perhaps you decide to prioritize projects, breaking each project down into specific tasks and moving long-term priorities to the next quarter.\n\nThis second scenario is completely based on results. This crucial conversation has enabled you to set yourself up for success in completing every project with your highest quality of work. The company benefits from your high-quality output. Your team benefits from having a team member who isn't totally stressed out. You benefit from feeling safe and confident in the work you're doing. Every outcome from the conversation can be traced back to a key result for yourself, your team, and the company.\n\nWith such a focus on results, our GitLab team should be having crucial conversations every day!\n\nI see crucial conversations map back to the rest of our values as well. You can read more about the [alignment of GitLab values to crucial conversations in our handbook](/handbook/leadership/crucial-conversations/#how-crucial-conversations-align-with-gitlab-values).\n\n### Getting started having crucial conversations\n\nIf you've read through this post and want to give crucial conversations a try, here are a few ways to get started:\n\n1. Read our [Crucial Conversations handbook page](/handbook/leadership/crucial-conversations/).\n1. Read our [Psychological Safety handbook page](/handbook/leadership/emotional-intelligence/psychological-safety/). Creating safe space to have crucial conversations is essential.\n1. Check out the [Crucial Conversations training](https://www.vitalsmarts.com/crucial-conversations-training/) from VitalSmarts. GitLab team members might consider using our [Growth and Development benefit](https://about.gitlab.com/handbook/total-rewards/benefits/general-and-entity-benefits/#growth-and-development-benefit) to take the training themselves.\n1. Try it out! Practicing crucial conversations is the key to getting better at the skills, so give it a try at work, at home, or even with yourself!\n1. GitLab team members - keep an eye out for internal Crucial Conversations training coming in Q2/Q3 of this year as the Learning and Development team gets certified to deliver the training!\n\n### Looking for more Learning and Development material from GitLab?\n\nIf you want to learn more about what the Learning and Development team at GitLab is up to, check out our [handbook page](/handbook/people-group/learning-and-development/) or read our past newsletters. You can also reach us at `learning@gitlab.com`.\n",[9,731,683],{"slug":1020,"featured":6,"template":687},"crucial-conversations","content:en-us:blog:crucial-conversations.yml","Crucial Conversations","en-us/blog/crucial-conversations.yml","en-us/blog/crucial-conversations",{"_path":1026,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1027,"content":1033,"config":1039,"_id":1041,"_type":14,"title":1042,"_source":16,"_file":1043,"_stem":1044,"_extension":19},"/en-us/blog/day-in-life-of-remote-sdr",{"title":1028,"description":1029,"ogTitle":1028,"ogDescription":1029,"noIndex":6,"ogImage":1030,"ogUrl":1031,"ogSiteName":673,"ogType":674,"canonicalUrls":1031,"schema":1032},"A day in the life of a remote Sales Development Representative","Working as a remote SDR is a fulfilling career that enables flexibility, a positive work/life balance, and encourages strong bonds with team members.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680115/Blog/Hero%20Images/day-in-life-remote-sdr.jpg","https://about.gitlab.com/blog/day-in-life-of-remote-sdr","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A day in the life of a remote Sales Development Representative\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Miranda\"}],\n        \"datePublished\": \"2018-05-11\",\n      }",{"title":1028,"description":1029,"authors":1034,"heroImage":1030,"date":1036,"body":1037,"category":705,"tags":1038},[1035],"Michael Miranda","2018-05-11","\n\nSales Development Representatives (SDRs) are the frontline forces built to march through endless rejection and cold calls to people who may not have heard of a product or who may already be committed to a solution. SDRs help an organization generate revenue by playing a crucial role in actively searching for customers who could benefit from our products and working to set up meetings between decision makers, solutions architects, and account executives. Across all industries, this is a difficult but rewarding path, since we have to use a variety of techniques to quickly establish a meaningful rapport and open a line of communication. Essentially, an SDR is a bridge between new customers and the product.\n\nIf you're familiar with the SDR role, then you have a basic understanding of what a typical day looks like. But, I don’t work at a typical organization. I work at GitLab, and I want to introduce you to life as a [remote SDR](https://handbook.gitlab.com/job-families/marketing/sales-development-representative/). Yes, there are some challenges, and yes, it does look different, but I wouldn’t have it any other way.\n\n## Getting started\n\nNormally, I wake up and check my email, Slack, and my calendar to know what I have for the day. Then, I take my daily three-step commute to the office; that’s right, three whole steps (studio apartment, don’t judge). Or, I’ll take a seven-minute walk to the coworking space that GitLab pays for. As a remote SDR, I can work from anywhere!\n\nThe activity kicks off with a daily standup meeting with my team, where we plan to discuss serious goals for the day but end up laughing about stories shared from the previous one. Our camaraderie helps to let off some steam and serves as a daily reminder that we’re all in this together. After our standup, we sync up with the rest of the company for the [Team Call](/handbook/communication/#team-call), which gives us a glimpse into the lives of other ’Labbers across the world. I may have a couple of meetings after the call, but here at GitLab, we’re not bogged down by countless internal meetings. We’re given the time to focus on what’s really important: crushing quota!\n\n## Working collaboratively\n\nAfter doing my research, I’ll make my calls and send out emails throughout the day. If I’m stuck on something, I’ll reach out to my team, hop on a video call with someone, and collaborate to come up with a strategy or solution. One of the most refreshing aspects about working at GitLab is that everyone is willing to help each other. We’re encouraged to build bonds with each other, so I schedule regular [coffee chats](/company/culture/all-remote/tips/#coffee-chats) to make a new friend or catch up with an old one. Everyone from our CEO to our newest ’Labber is happy to join a coffee call. In my first week, I messaged our [Chief People Officer](https://handbook.gitlab.com/job-families/people-group/chief-people-officer/), and we chatted the next day. I’ve never worked at an organization that encouraged its executive team to make themselves so available to others.\n\nIn addition to collaboration, GitLab values flexibility. If I have a doctor’s appointment, errands to run, or just decide that I want to take a longer lunch and embrace food coma, I have the freedom to do so. As a results-driven organization, GitLab is concerned about your productivity – not your hours.\n\n## Physical proximity isn’t necessary\n\nThroughout the day, my [account executive](https://handbook.gitlab.com/job-families/sales/account-executive) (AE) and I have a 1:1 call, depending on activity. At GitLab, each SDR is paired with a knowledgeable, experienced AE. My AE and I have a strong relationship, and we’re constantly communicating throughout the day. We send articles to each other, share random ideas, and drop in the occasional (ok, maybe frequent is the better word here) hilarious GIF or video. I feel like we’ve known each other forever, and we’ve never even met in person. He’s in Kansas, and I’m in Los Angeles! When I first started working at GitLab, I wasn’t sure how easy it would be to communicate with others across time zones, but with all the tools and processes that GitLab has developed, collaborating with him feels natural and easy. We may not work in the same building, but we have developed a great relationship.\n\n>I wasn’t sure how easy it would be to communicate with others across time zones, but with all the tools and processes that GitLab has developed, collaborating feels natural and easy\n\nThe freedom to work wherever I want allows me to minimize distractions and control noise levels, something that many SDRs are unable to do in a traditional office setting. I am able to completely focus on making calls, connecting with customers, and conducting research without getting distracted by the buzzing conversations of other SDRs around me. If I worked in an office, I would also be subjected to the challenges of context switching if a fellow SDR unexpectedly stopped by my cubicle to discuss a call or ask for help. While it may take more effort to build camaraderie with team members when working remotely, I believe that a remote work environment is more conducive to an SDR role, since noise and distraction can make potential customers feel unimportant.\n\nI wrap up each day by looking over my tasks and setting myself up for the next day. Sometimes I cut my day shorter (yay for Friday!) or start later (~~yay for~~ Monday!). The beautiful thing is that we focus on results, not the amount of hours teammates put in. I’m not forced to clock in at a certain time or wait to clock out even though my work is done. Remote and SDR may be two words you’d never thought would be a good fit, but I’m here to tell you that it fits well. I’ve been grateful to learn and experience that physical proximity isn’t required to develop strong bonds, deliver results, and feel immersed in a company culture. GitLab empowers their frontline with tools to facilitate camaraderie, helping the SDR team march forward to success.\n\nDoes working as a remote SDR appeal to you? We're hiring across multiple time zones – check out [our job listings](/jobs/).\n\nPhoto by [rawpixel.com](https://unsplash.com/) on [Unsplash](https://unsplash.com/search/photos/business?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,683],{"slug":1040,"featured":6,"template":687},"day-in-life-of-remote-sdr","content:en-us:blog:day-in-life-of-remote-sdr.yml","Day In Life Of Remote Sdr","en-us/blog/day-in-life-of-remote-sdr.yml","en-us/blog/day-in-life-of-remote-sdr",{"_path":1046,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1047,"content":1053,"config":1059,"_id":1061,"_type":14,"title":1062,"_source":16,"_file":1063,"_stem":1064,"_extension":19},"/en-us/blog/day-in-the-life-remote-worker",{"title":1048,"description":1049,"ogTitle":1048,"ogDescription":1049,"noIndex":6,"ogImage":1050,"ogUrl":1051,"ogSiteName":673,"ogType":674,"canonicalUrls":1051,"schema":1052},"A day in the life of the \"average\" remote worker","Go on, you know you're curious! Explore a day in the life of GitLab team members from around the world.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670134/Blog/Hero%20Images/remote-life-cover.png","https://about.gitlab.com/blog/day-in-the-life-remote-worker","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A day in the life of the \"average\" remote worker\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"},{\"@type\":\"Person\",\"name\":\"Charlie Ablett\"}],\n        \"datePublished\": \"2019-06-18\",\n      }",{"title":1048,"description":1049,"authors":1054,"heroImage":1050,"date":1056,"body":1057,"category":705,"tags":1058},[812,1055],"Charlie Ablett","2019-06-18","\nGitLab is an [all-remote company](/company/culture/all-remote/), meaning we are not based in one location or even one time zone. Instead, our team is distributed in home offices and work spaces [across the globe](/company/team/#countries), everywhere from San Francisco to London to Taipei.\n\nBecause GitLab is not limited to one time zone, we work asynchronously. Our asynchronous workflow gives us a [competitive advantage](/blog/remote-enables-innovation/), because we are contributing 24 hours a day, as opposed to the standard 9am-5pm if we had a brick-and-mortar office headquartered in one location. As an organization, the focus is not on when or how a team member works, but rather on our [results](https://handbook.gitlab.com/handbook/values/#results).\n\nBecause of this emphasis on results rather than regimen, there is a lot of variability in how we structure our workdays. At [Contribute 2019](/events/gitlab-contribute/), a group of us came together to discuss how we use the flexibility GitLab affords us to structure our ideal workdays. Our discussion featured team members working in different capacities, as engineers, writers, and managers, from many different locations.\n\n## Morning\n\nThere are a few morning activities that were universal: A warm cup of coffee or tea to kick off the day; and morning cuddles with a cat or dog if you have the good fortune of having a pet.\n\n\"When my alarm goes off, Milly, my dog, who hates getting out of bed, snuggles closer to me. I get up, make coffee, and log on to begin working. Meanwhile, Milly is usually still in bed until 10:30am, sometimes even 11:30am,\" says [Sara Kassabian](/company/team/#sarakassabian), content editor, from Oakland, California.\n\nFor some of us, sunshine (or other humans) function as the morning wake-up call.\n\n\"I stopped setting an alarm because mornings are quiet in my time zone, and (inevitably) I get woken by my upstairs neighbors getting ready for work anyway! I make a big cup of coffee and try to get all my deep focus work done before my coworkers in the US start to wake up,\" says [Rebecca Dodd](/company/team/#rebecca), managing editor, from London.\n\n\"I also do not set an alarm because I often work until late. Usually my kids wake me up at some point, and then I will have a big cup of tea,\" says [Charlie Ablett](/company/team/#cablett), a senior backend engineer, [Plan](/handbook/engineering/development/dev/plan/), from New Zealand.\n\nMornings can be a particularly hectic time for working parents. Oftentimes, parents who don't work remotely will have to juggle getting their children ready for school, getting ready for work, and making school drop-off in time to get to the office between 8am-9am. Parents working at GitLab have the opportunity to be in the home and available to their children because we're [all remote](/blog/building-an-award-winning-culture-at-gitlab/). Flexible scheduling makes it a little bit easier to balance family with work obligations.\n\n## Midday\n\nWe all structure our afternoons differently. Some of us have children to pick up from school, while others are just starting their workday, or taking a break from the computer to run errands or exercise.\n\n\"I usually take a break to go running or to walk my dog. Then I’ll pick up my kids from school. I usually have one or two more screening calls and some team meetings,\" says [Stephanie Garza](/company/team/#stephaniegarza), diversity sourcing specialist, from Michigan.\n\n\"I start my workday in the afternoon by checking Slack and emails. I may go for a walk. I might work out then start focused work at 3pm or so,\" says [Laura Montemayor](/company/team/#lauraMon), frontend engineer, [Monitor](/handbook/engineering/frontend/monitor/), from New York City.\n\nWeather is also a big determinant about whether work or play is on the agenda for the afternoon.\n\n\"It depends on whether or not the weather is nice or if I have plans in the evening. If it’s sunny in New York City, you have to go outside. If it’s nice I want to go enjoy the weather! Or if I’m going out in the evening I’ll get my work done first,\" says Avielle Wolfe, backend engineer, [Secure](/handbook/engineering/development/sec/secure/), from New York City.\n\n\"If it’s sunny in Oakland, I will take Milly for a longer walk, which gives me some Vitamin D and the boost of energy I’ll need to finish up any remaining tasks for the day,\" added [Sara](/company/team/#sarakassabian).\n\nNot every team member lives in a location as urban as Oakland or New York City. Some live in suburban neighborhoods or more rural locations, all of which can have an impact on how we structure our day. For instance, [Charlie](/company/team/#cablett), who lives in a more rural setting, once had to set aside an hour around 4pm each day to milk her cows.\n\n## Evening\n\nFor those of us with children, the evenings are the ideal time to set work aside and focus on family time.\n\n\"My evening typically begins with practice. My daughter does soccer and my son does karate. My husband works a weird schedule so this is my alone time with the kids. I will make dinner and then get some more work done sometime between 8-10pm,\" says [Stephanie](/company/team/#stephaniegarza).\n\nIf our workday started in the afternoon as opposed to the morning, there are often more tasks to be completed throughout the evening.\n\n\"I am still working by evening,\" says [Laura](/company/team/#lauraMon). \"I’ll have a meal around 8pm. If I have plans, I go out, otherwise I play video games. If I get a second wind I’ll work more after 10pm.\"\n\n\"I try to finish my work by 6pm, but if I work overtime then the next day I will have an excuse to relax a little bit! In the evenings, I’ll cook dinner by putting some chicken and veggies into a steamer pot, and then continue working while that cooks, or I will go out for dinner. Sometimes I’ll attend local meetups, or just relax and watch TV. My bedtime is around midnight,\" says [Mark Chao](/company/team/#lulalala_it), backend engineer, [Create](/handbook/engineering/development/dev/create/), from Taipei.\n\n## Focused versus collaborative work\n\nGitLab gives us the flexibility to build a custom schedule, so early birds and night owls can work when they feel they are most effective. When we choose to work in tandem with teammates and when we do our focus work depends primarily upon two factors: When the overlap happens across teams and time zones, and also when we are most focused and/or creative.\n\n\"Europe and the Americas are chatty overnight so I have lots to catch up on in the morning, including the minutes of meetings that happened at 3am (e.g., daily company call),\" says [Charlie](/company/team/#cablett). \"America is still awake so I collaborate with them if I need to, and I do all my deep focus work later on when not many folks are around.\"\n\nThough GitLab has a globally distributed team across 54 countries and regions, the majority of us are based in the United States and Europe.\n\n\"After lunch, I get maybe one more hour of focused work in until 3pm when America wakes up. Then meetings start, Slack gets busy, and then I'm trying to disentangle myself and switch off for the evening,\" says [Rebecca](/company/team/#rebecca). \"If something doesn’t happen before 3pm, it generally doesn’t happen that day.\"\n\n\"In the afternoon for me, people will start to wake up and log on so I will have more interactions and working on issues,\" says [Mark](/company/team/#lulalala_it).\n\nSometimes team members with children will log on to complete a few more hours of work while the children are sleeping, generally between 8pm-10pm, and sometimes after 10pm.\n\n## Family first at GitLab\n\n\"I love working at GitLab for a variety of reasons, but the flexibility in creating work-life harmony in my life tops my list. I work closely with our executive team here, and they have been so supportive and encouraging when family-related conflicts arise. They are constantly reminding me that \"[family first](https://handbook.gitlab.com/handbook/values/#family-and-friends-first-work-second)\" is our mantra, and give me ease of mind to take time away when needed,\" says [Cheri Holmes](/company/team/#cheriholmes), manager, executive assistant, from Dublin, California, in a previous [blog post](/blog/building-an-award-winning-culture-at-gitlab/).\n\nInc. Magazine recently ranked GitLab as one of the [best places to work](/blog/building-an-award-winning-culture-at-gitlab/), due in large part to a company culture that gives team members the agency to balance our personal and professional obligations. While the \"average\" team member may not share a schedule, we do share a commitment to our [values](https://handbook.gitlab.com/handbook/values/#credit): Collaboration, results, efficiency, diversity, iteration, and transparency. In order to work asynchronously effectively, everyone must embrace and embody the values of our organization.\n",[707,9,731,683],{"slug":1060,"featured":6,"template":687},"day-in-the-life-remote-worker","content:en-us:blog:day-in-the-life-remote-worker.yml","Day In The Life Remote Worker","en-us/blog/day-in-the-life-remote-worker.yml","en-us/blog/day-in-the-life-remote-worker",{"_path":1066,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1067,"content":1073,"config":1078,"_id":1080,"_type":14,"title":1081,"_source":16,"_file":1082,"_stem":1083,"_extension":19},"/en-us/blog/designing-in-an-all-remote-company",{"title":1068,"description":1069,"ogTitle":1068,"ogDescription":1069,"noIndex":6,"ogImage":1070,"ogUrl":1071,"ogSiteName":673,"ogType":674,"canonicalUrls":1071,"schema":1072},"How we work 100% remote in Product Design","UX is such a collaborative activity. How do you work effectively when everyone is remote?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679473/Blog/Hero%20Images/designing-in-an-all-remote-company.jpg","https://about.gitlab.com/blog/designing-in-an-all-remote-company","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we work 100% remote in Product Design\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2020-03-27\",\n      }",{"title":1068,"description":1069,"authors":1074,"heroImage":1070,"date":727,"body":1076,"category":705,"tags":1077},[1075],"Christie Lenneville","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-04-02.\n{: .alert .alert-info .note}\n\nIn 2019, GitLab’s all-remote UX team grew from fewer than 15 team members to almost 60.\n\nHiring at that velocity meant we interviewed a lot of great product designers, UX researchers, and technical writers. One of the most common questions I personally heard in interviews was, “UX is such a collaborative activity. How do you work effectively when everyone is remote?”\n\nIt’s a fair question. As UX practitioners, we’re often used to getting in a room with our product team to brainstorm ideas and work through problems. So, how do you keep everyone engaged and informed without that face-to-face time?\n\nHonestly, there is no perfect answer, and we’re still figuring it out every day. We tend to try new ideas as pilot programs and then adopt them more broadly when they prove to be successful. And just like we [iterate on our product](https://handbook.gitlab.com/handbook/values/#iteration), we also iterate on our processes, making them better over time.\n\nIn that spirit, here are a few things we’ve tried that have helped to encourage collaboration and connection both within our UX department and with our cross-functional peers.\n\n## Pair designers\n\nWhen I joined as GitLab’s UX director, I spent my first few weeks just talking with the team to understand what was working well and where they needed more support.\n\nA recurring theme was that product designers felt they lacked design peers to partner with. They were getting good feedback from their product managers and engineering partners, but it was different than the support they knew they’d get from another designer.\n\nBecause we’re all remote, the product designers were hesitant to just randomly reach out to another designer, because they didn’t know if they’d interrupt that person’s workflow. They couldn’t just look across the aisle to see if someone was busy. And without a consistent partner, they’d need to give a lot of additional context about the problem they were solving.\n\nWe addressed this by piloting a Pair Designer program where every product designer is assigned a design peer in their same time zone who works on a different part of the product. For six months, this is their go-to person for ideation sessions and quick, on-the-spot design feedback. After six months, we swap pairs to give people more exposure to different ideas, working styles, and product areas.\n\nPair designers are encouraged to work together however they’re comfortable. Some agree to meet for a weekly sync over video, others meet every two weeks, some contact each other ad hoc, and some meet primarily asynchronously.\n\nWe received very positive feedback on the pilot, so we’ve continued this program, and we’re now on our third rotation. It’s been a great way for designers from all over the world to learn from each other. Here’s a quote from one of our designers:\n\n> “I have loved working with each of my 'pairs'’ in UX! Usually we meet once a week for 30 minutes to an hour and spend about half the time each talking about something that is top of mind for us. Sometimes it is just discussing some process or higher level stuff; most of the time we are sharing our screens in Zoom and walking through Sketch, Figma, Axure, someone's branch, etc. to talk through design challenges we are having. The most exciting part of this to me is getting to really dive into a space that I don't get as much exposure to -- also getting to know another designer and having that dedicated time just for us.” [Alexis Ginsberg](/company/team/#uhlexsis), senior product designer at GitLab\n\n## Synchronous kick-off sessions\n\nAt GitLab, we try to work as asynchronously as possible. This is important for a few reasons.\n\nMost importantly, we’re all remote and [globally distributed in 67 countries](/company/team/), so face-to-face meetings aren’t always feasible across varied time zones. Also, we find that asynchronous communication is often faster than meetings. Lastly, by defaulting to asynchronous communication, we always have documentation of the decisions we’ve made and why we made them. Those are some great reasons to default to written communication.\n\nThat said, when a design project first begins, we’ve found that it can be helpful to get everyone together to ask questions, discuss the problem, ideate on possible solutions, and discuss constraints. Depending on the project’s complexity, this can happen very quickly (30 minutes), though bigger problems may take longer.\n\nWhen we have synchronous kick off sessions, we record them and post them to [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A), so that anyone who can’t attend still has access to the information. We also document the outcome in a [GitLab issue](https://docs.gitlab.com/ee/user/project/issues/index.html#issues), so that information doesn’t get lost. Lastly, we quickly move from synchronous to asynchronous activities for the reasons noted above.\n\n## Video walkthroughs\n\nAt GitLab, we believe that design is collaborative. That's why we try to involve our team members as early as possible and throughout the entire process. One way to keep our team up to date without having to set up a meeting is to record short videos where we walk them through our designs, preferably in the form of a prototype.\n\n> “If a picture is worth 1000 words, a prototype is worth 1000 meetings.” [Tom & David Kelley](https://blog.prototypr.io/a-prototype-is-worth-1000-meetings-b9ec8107befc)\n\nIn these videos, we lay out the rationale behind our designs and also offer information about other options we thought about and decided against. In certain situations, it also makes sense to add additional background about our long-term vision.\n\nOne of the many positive outcomes from this approach is that even team members who have only been minimally involved are now empowered to provide feedback, add their own ideas, or provide us with additional information about the amount of work our ideas will require.\n\n## UX Showcase\n\nWhen a company is widely distributed, it can be hard to keep up with all of the amazing work that’s happening. Staying updated on changes is especially important in a company like GitLab, where we all work on the same product. We need to understand what other designers are doing and how they are doing it, so we can create seamless workflows that maintain consistency throughout the UI.\n\nIn our biweekly UX Showcase, four product designers each take 15 minutes to share recent work. We have no restrictions on what they share or how they share it. It can be work in progress or something that recently moved to production. Similarly, the \"presentation\" can be as simple as walking through a [GitLab issue](https://docs.gitlab.com/ee/user/project/issues/index.html#issues) or a more elaborate Google Slides deck. The point isn’t to be fancy – it’s just to share information in an easy-to-understand and compelling way.\n\nPersonally, I learn so much from seeing designers talk through the problem they were trying to solve, why it was important, how they solved it, the challenges they encountered along the way, and why the final solution ended up the way it did.\n\nI’m so proud of the work that I see our team doing. It’s as motivating as it is educational.\n\nBut the value of the UX Showcase isn’t just to the UX team. We record the showcases and post them in a [YouTube playlist on GitLab Unfiltered](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz), so that anyone in the company (or the world) can watch, if they’re interested. We also make sure to post links to the videos in a variety of Slack channels, so that our cross-functional peers can watch at their convenience.\n\n## Asynchronous sketching exercises\n\nMost people think about sketching sessions as synchronous and co-located. But at GitLab, we have team members who live in time zones across the world, and we’ve had success at inviting team members to sketch, think, and brainstorm asynchronously.\n\nThis does require a team to already have a good level of trust and a shared understanding of the problem space, but it can be a really efficient way to bring out the team’s creativity, regardless of where in the world they work.\n\nIf you’re interested and would like to see an example, you can learn more in this detailed [blog post](/blog/async-sketching/).\n\n## Slack channel for UX coworking\n\nSometimes designers just want a quick, ad hoc collaboration session, and their Pair Designer may not be immediately available. For times like these, we have a Slack channel dedicated to UX coworking.\n\nIn this channel, designers can ask whether anyone is available for a quick ideation or feedback session. They can also post work in progress to get quick feedback. This has been a great way to promote on-the-spot collaboration within the team.\n\n## Design documentation\n\nThe most important thing to remember when designing remotely is: document, document, document!\n\nAt GitLab, we document our design decisions and rationale in GitLab issues. We even launched a new feature category recently called [Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html) that lets designers upload images and invite comments in the same platform that product managers and developers use to do their daily work. We’re adding new features in this category that will make this more and more effective over time.\n\nWhen it comes to UX process, we document everything in our handbook. That means when someone wants to understand how we research, design, and write about our product, the information is always available and up to date. Everyone at GitLab has a shared responsibility to keep this content clear, current, and easy to use.\n\n## All-remote design works!\n\nFor teams that are used to collaborating in person, it can seem like a big leap to go all remote. As someone who has practiced UX in a variety of models – 100% in person, a hybrid of remote and in person, and all remote – what I can say is: It works!\n\nIn my experience, the least effective model is hybrid. Nothing is worse than being one of the few people on video while the rest of the team works in a room together. Your voice just doesn’t get heard.\n\nWe know that we can’t design a great product without close collaboration from our cross-functional peers. When you’re all remote, you have to make a conscious effort to involve peers in your design process early and often. While that takes an extra level of thoughtfulness in an all-remote team, the improved outcomes are worth it.\n\nCover image by [Christina @ wocintechchat.com](https://unsplash.com/@wocintechchat) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[734,733,9],{"slug":1079,"featured":6,"template":687},"designing-in-an-all-remote-company","content:en-us:blog:designing-in-an-all-remote-company.yml","Designing In An All Remote Company","en-us/blog/designing-in-an-all-remote-company.yml","en-us/blog/designing-in-an-all-remote-company",{"_path":1085,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1086,"content":1092,"config":1098,"_id":1100,"_type":14,"title":1101,"_source":16,"_file":1102,"_stem":1103,"_extension":19},"/en-us/blog/eliminating-distractions-and-getting-things-done",{"title":1087,"description":1088,"ogTitle":1087,"ogDescription":1088,"noIndex":6,"ogImage":1089,"ogUrl":1090,"ogSiteName":673,"ogType":674,"canonicalUrls":1090,"schema":1091},"9 Tips for eliminating remote work distractions and being more productive","Working remotely comes with great power and great responsibility. Here are a few tips on being efficient and productive.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682933/Blog/Hero%20Images/getting-things-done.jpg","https://about.gitlab.com/blog/eliminating-distractions-and-getting-things-done","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"9 Tips for eliminating remote work distractions and being more productive\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matej Latin\"}],\n        \"datePublished\": \"2018-05-17\",\n      }",{"title":1087,"description":1088,"authors":1093,"heroImage":1089,"date":1095,"body":1096,"category":705,"tags":1097},[1094],"Matej Latin","2018-05-17","\nI lived in London for the past three years and worked for two companies in this time: a late-stage startup and an enterprise. Both are trying to emulate the early-stage startup working environment by designing an open-plan office. It sounds great, but if it’s not done right, it isn’t.\n\n![Open Plan Office](https://about.gitlab.com/images/blogimages/gtd-open-plan-office.jpg)\n\nAt one place, the office was huge. Around 100 people sitting in rows of desks, a kitchen in the centre and a pool table just a few feet from where I was sitting. I remember how I got so used to getting distracted that it turned into an addiction. When nobody distracted me, I found a way to distract myself. I found it hard to start working most of the time and I ended up reacting to everyone else’s priorities but never had time to be proactive and work on things that *I deemed important*.\n\n## Going back to working remotely\n\nI had worked remotely before and going back gives me better control of my working environment. There aren’t a lot of other people in the same room and there are no loud noises, flashing email or chat notifications on top of everything if I don’t want them.\n\nAt GitLab especially, where [asynchronous work is encouraged](/handbook/communication/), it’s much easier to control your schedule and decide when you’ll have a few hours dedicated to focus on meaningful work. When working remotely, your colleagues mostly reach out over email, chat or GitLab itself - all easy to turn off for a while. And that’s all you really need! [Cal Newport](http://calnewport.com/) researched this topic and wrote a really cool book about it called “Deep Work.” In it, he argues that we only need a few hours of deep and undisturbed focus every day to get meaningful work done.\n\n>We only need a few hours of deep and undisturbed focus every day to get meaningful work done\n\nThink about it. When was the last time you were completely undisturbed and deeply focused for more than a couple of hours in a day? Instead, we crave distractions like chat sound notifications and red circles on top of the app icons. The only way to regain focus is to consciously and systematically cut our dependence on these distractions.\n\n## Tips for regaining control and getting things done\n\nHere are a few tips that I picked up from others or learned from my own mistakes and applied to my life. I think they’re especially useful for people working remotely.\n\n### 1. Establish a routine\n\nWhen it comes to productivity, nothing beats a well-established routine: \n\n- Get up early and exercise to get your body going\n- Plan for your day ahead\n- Have a few hours of “focus time”\n- Plan for the next day\n- Wrap up work and disconnect\n- Go to sleep early\n- Repeat\n\nIt sounds kinda boring, I know. But establishing a routine like that will free up time for the fun things you want to do. Not every day needs to have the same routine either. Just make sure you plan your days out instead of leaving all your time up to others for grabs.\n\nAfter a while, your routine will turn into a habit, so you won’t need to spend willpower and energy on deciding when to start working, have lunch etc., you’ll simply start at the designated time. And you’ll be able to spend that extra attention and energy on work instead of deciding.\n\n![MITs](https://about.gitlab.com/images/blogimages/gtd-MIT-notepad.jpg)\n\n### 2. Write down your MITs\n\nMIT stands for “Most Important Thing.” The idea is simple: write down a few important things that you want to do that day. I write these down in a small notepad the first thing in the morning. The key here is to have a visual cue in front of us that reminds us of the things we want to do and keeps us focused.\n\n### 3. Book out your “focus time”\n\nEach day, try to find a slot of 3-4 hours and reserve them for your “focus time.” Try to spend those hours completely undisturbed and focused, with short breaks of course.\n\n### 4. Turn notifications off\n\nAt least for those few hours that you reserved for focused work turn off your email, phone and chat notifications. I have Slack notifications turned off all the time, and I check it outside of my “focus time.” The same goes for email.\n\nResearch suggests that [it takes a person 25 minutes](https://www.nytimes.com/2013/05/05/opinion/sunday/a-focus-on-distraction.html) and lots of mental energy to refocus on their work after a distraction. Stay strong and ignore the [dancing panda](https://www.youtube.com/watch?v=tf9ZhU7zF8s), at least for a while.\n\n### 5. Wrap up work and disconnect\n\nIf you work remotely it doesn’t mean that you need to work all the time. Treat your work just like you would in an office. Set your working hours and stick to them. Disconnect from everything work related after that. Spend time with your family, read a book, play a video game, write a journal…\n\nI go even further and set my “Do not disturb” mode on my phone from 8 p.m. to 9 a.m. and simply don’t check in on it during that time – it’s hard at the beginning when your brain is hardwired for that dopamine rush every time you check it, but it’s doable.\n\n### 6. Set a deadline for yourself\n\nWe have such a negative association with deadlines, but a self-imposed deadline is different. First of all, it needs to be realistic. If you can’t hit that deadline it will only lead to depression, burning out and chronic apathy. You know what’s cool about self-imposed, realistic deadlines? The feeling you get when you cross the tasks out and mark them as complete. People think that motivation is a thing that comes out of thin air but it doesn’t. The best way to get motivated is getting things done – even if it’s little things.\n\n### 7. Focus on one thing at a time\n\n[Multitasking really is a myth](https://www.inc.com/scott-mautz/psychology-and-neuroscience-blow-up-the-myth-of-effective-multitasking.html). Even if you think you’re an exception, the reality is that you’re wasting energy and attention when you’re switching from one thing to the other.\n\n## Bonus Stuff:\n\nIf you’re feeling edgy and want to go even further.\n\n### 8. Dedicate a room to work\n\nIf possible, dedicate a room to work, you know, like a study. Don’t work in a room where you do other stuff or where you sleep. If you do, your brain will start associating one with the other and soon it won’t know whether you’re going into the room to work or to sleep. This results in less focus when you work and lower quality of sleep. If that’s not possible, try going to a co-working space or even a coffee shop.\n\n### 9. Getting things done spreadsheet\n\n[![Getting things done spreadsheet](https://about.gitlab.com/images/blogimages/gtd-spreadsheet.jpg)](https://docs.google.com/spreadsheets/d/1j3N1mSbs_48r4kBo7SOCI2Weh4BdTL4dCn3ozP5HwzQ/edit?usp=sharing)\n\nThis is my systematic approach to getting things done. I didn’t come up with this idea, I picked it up from somewhere and modified it so it works for me. It’s quite simple: I keep all the things that I want to do in a spreadsheet, where I can set to which project each item belongs to, the status of the item and the deadline. I set my filters so it only shows me items with “To Do” and “Doing” status labels and sort by the Due Date. [You can see it in action and make a copy here.](https://docs.google.com/spreadsheets/d/1j3N1mSbs_48r4kBo7SOCI2Weh4BdTL4dCn3ozP5HwzQ/edit?usp=sharing) It feels so good to mark things as done and watch them disappear from the list 😊\n\n**Recommended reading:**\n- [Preventing Burnout](/blog/preventing-burnout/)\n- [Deep work: Rules for Focused Success in a Distracted World](https://www.goodreads.com/book/show/28383248-deep-work) by Cal Newport\n- [Getting things done: The Art of Stress-Free Productivity](https://www.goodreads.com/book/show/1633.Getting_Things_Done?ac=1&from_search=true) by David Allen\n- [The Power of Habit: Why We Do What We Do in Life and Business](https://www.goodreads.com/book/show/12609433-the-power-of-habit?ac=1&from_search=true) by Charles Duhigg\n",[9],{"slug":1099,"featured":6,"template":687},"eliminating-distractions-and-getting-things-done","content:en-us:blog:eliminating-distractions-and-getting-things-done.yml","Eliminating Distractions And Getting Things Done","en-us/blog/eliminating-distractions-and-getting-things-done.yml","en-us/blog/eliminating-distractions-and-getting-things-done",{"_path":1105,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1106,"content":1112,"config":1120,"_id":1122,"_type":14,"title":1123,"_source":16,"_file":1124,"_stem":1125,"_extension":19},"/en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces",{"title":1107,"description":1108,"ogTitle":1107,"ogDescription":1108,"noIndex":6,"ogImage":1109,"ogUrl":1110,"ogSiteName":673,"ogType":674,"canonicalUrls":1110,"schema":1111},"Enable secure sudo access for GitLab Remote Development workspaces","Learn how to allow support for sudo commands using Sysbox, Kata Containers, and user namespaces in this easy-to-follow tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675033/Blog/Hero%20Images/blog-image-template-1800x945.png","https://about.gitlab.com/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Enable secure sudo access for GitLab Remote Development workspaces\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vishal Tak\"}],\n        \"datePublished\": \"2024-11-20\",\n      }",{"title":1107,"description":1108,"authors":1113,"heroImage":1109,"date":1115,"body":1116,"category":1117,"tags":1118},[1114],"Vishal Tak","2024-11-20","A development environment often requires sudo permissions to install, configure, and use dependencies during runtime. GitLab now allows secure sudo access for [GitLab Remote Development workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/). This tutorial shows you how to enable GitLab workspace users to securely use sudo commands to perform common tasks.\n\n## The challenge\n\nFor the sake of this article, say your project is as simple as the below code.\n\n```\npackage main\n\nimport (\n\t\"encoding/json\"\n\t\"log/slog\"\n\t\"net/http\"\n\t\"os\"\n)\n\nfunc main() {\n\t// Set up JSON logger\n\tlogFile, err := os.OpenFile(\"server.log\", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tdefer logFile.Close()\n\n\tjsonHandler := slog.NewJSONHandler(logFile, nil)\n\tlogger := slog.New(jsonHandler)\n\tslog.SetDefault(logger)\n\n\t// Define handlers\n\thttp.HandleFunc(\"/path1\", handleRequest)\n\thttp.HandleFunc(\"/path2\", handleRequest)\n\n\t// Start server\n\tslog.Info(\"Starting server on :3000\")\n\terr = http.ListenAndServe(\":3000\", nil)\n\tif err != nil {\n\t\tslog.Error(\"Server failed to start\", \"error\", err)\n\t}\n}\n\nfunc handleRequest(w http.ResponseWriter, r *http.Request) {\n\tdata := make(map[string]interface{})\n\tfor k, v := range r.Header {\n\t\tdata[k] = v\n\t}\n\n\tdata[\"method\"] = r.Method\n\tdata[\"url\"] = r.URL.String()\n\tdata[\"remote_addr\"] = r.RemoteAddr\n\n\tresponse, err := json.MarshalIndent(data, \"\", \"  \")\n\tif err != nil {\n\t\tslog.Error(\"Failed to marshal metadata\", \"error\", err)\n\t\thttp.Error(w, \"Internal Server Error\", http.StatusInternalServerError)\n\t\treturn\n\t}\n\n\t// Log the metadata\n\tslog.Info(\"Request received\",\n\t\t\"path\", r.URL.Path,\n\t\t\"response\", string(response),\n\t)\n\n\t// Write response\n\tw.Header().Set(\"Content-Type\", \"application/json\")\n\tw.Write(response)\n}\n```\n\nThis code starts an HTTP server on port 3000, exposes two paths: `path1` and `path2`. Each HTTP request received is logged to a file `server.log`.\n\nLet's run this code with `go run main.go` and generate some requests.\n\n```\ni=1\nwhile [ \"$i\" -le 100 ]; do\n  echo \"Iteration $i\"\n\n  if [ $((random_number % 2)) -eq 0 ]; then\n    curl \"localhost:3000/path1\"\n  else\n    curl \"localhost:3000/path2\"\n  fi\n\n  i=$((i + 1))\ndone\n```\n\nAs you work on this application, you realize the need to analyze the logs to debug an issue. You look at the log file and it is long to parse with a simple glance. You remember there is a handy tool, [jq](https://jqlang.github.io/jq/), which parses JSON data. But your workspace does not have it installed.\n\nYou want to install `jq` through the package manager for this workspace only.\n\n```\nsudo apt update\nsudo apt install jq\n```\n\nThe output is:\n\n```\nsudo: The \"no new privileges\" flag is set, which prevents sudo from running as root.\nsudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.\n```\n\nThis happens because GitLab workspaces explicitly disallows `sudo` access to prevent privilege escalation on the Kubernetes host.\n\nNow, there is a more secure way to run `sudo` commands in a workspace.\n\n## How sudo access works\n\nThat is exactly what we have [unlocked](https://docs.gitlab.com/ee/user/workspace/configuration.html#configure-sudo-access-for-a-workspace) in the 17.4 release of GitLab.\n\nYou can configure secure sudo access for workspaces using any of the following options:\n\n- Sysbox  \n- Kata Containers  \n- User namespaces\n\nWe will set up three GitLab agents for workspaces to demonstrate each option.\n\n### Sysbox\n\n[Sysbox](https://github.com/nestybox/sysbox) is a container runtime that improves container isolation and enables containers to run the same workloads as virtual machines.\n\nTo configure sudo access for a workspace with Sysbox:\n\n1. In the Kubernetes cluster, [install Sysbox](https://github.com/nestybox/sysbox#installation).\n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n  enabled: true\n  dns_zone: \"sysbox-update.me.com\"\n  default_runtime_class: \"sysbox-runc\"\n  allow_privilege_escalation: true\n  annotations:\n    \"io.kubernetes.cri-o.userns-mode\": \"auto:size=65536\"\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings.  \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information.  \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\n### Kata Containers\n\n[Kata Containers](https://github.com/kata-containers/kata-containers) is a standard implementation of lightweight virtual machines that perform like containers but provide the workload isolation and security of virtual machines.\n\nTo configure sudo access for a workspace with Kata Containers:\n\n1. In the Kubernetes cluster, [install Kata Containers](https://github.com/kata-containers/kata-containers/tree/main/docs/install).  \n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n  enabled: true\n  dns_zone: \"kata-update.me.com\"\n  default_runtime_class: \"kata-qemu\"\n  allow_privilege_escalation: true\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings.  \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information.  \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\n### User namespaces\n\n[User namespaces](https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/) isolate the user running inside the container from the user on the host.\n\nTo configure sudo access for a workspace with user namespaces:\n\n1. In the Kubernetes cluster, [configure user namespaces](https://kubernetes.io/blog/userns-beta/).  \n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n  enabled: true\n  dns_zone: \"userns-update.me.com\"\n  use_kubernetes_user_namespaces: true\n  allow_privilege_escalation: true\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings.  \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information.  \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\nSetting up a Kubernetes cluster with user namespaces configured is challenging since it is behind a beta feature gate in Kubernetes Version 1.31.0. This means it is not yet possible to configure such a cluster on the major cloud providers because they don't provide a mechanism to enable feature gates in their managed Kubernetes offering. Here is an example of [configuring a simple Kuberenetes cluster using `kubeadm`](https://gitlab.com/gitlab-org/gitlab/-/issues/468290#note_1959300036).\n\n### Create a workspace\n\nIf you now create a workspace with these agents and try installing `jq` through a package manager, it should succeed!\n\nYou can analyze the logs using `jq`. Say you wanted to inspect the log entries where the path is `/path1`, you can run:\n\n```\njq 'select(.path == \"/path1\")' server.log\n```\n\nThe output is:\n\n```\n{\n  \"time\": \"2024-10-31T12:04:38.474806+05:30\",\n  \"level\": \"INFO\",\n  \"msg\": \"Request received\",\n  \"path\": \"/path1\",\n  \"response\": \"{\\n  \\\"Accept\\\": [\\n    \\\"*/*\\\"\\n  ],\\n  \\\"User-Agent\\\": [\\n    \\\"curl/8.7.1\\\"\\n  ],\\n  \\\"method\\\": \\\"GET\\\",\\n  \\\"remote_addr\\\": \\\"[::1]:61246\\\",\\n  \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n{\n  \"time\": \"2024-10-31T12:06:22.397453+05:30\",\n  \"level\": \"INFO\",\n  \"msg\": \"Request received\",\n  \"path\": \"/path1\",\n  \"response\": \"{\\n  \\\"Accept\\\": [\\n    \\\"*/*\\\"\\n  ],\\n  \\\"User-Agent\\\": [\\n    \\\"curl/8.7.1\\\"\\n  ],\\n  \\\"method\\\": \\\"GET\\\",\\n  \\\"remote_addr\\\": \\\"[::1]:61311\\\",\\n  \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n{\n  \"time\": \"2024-10-31T12:19:34.974354+05:30\",\n  \"level\": \"INFO\",\n  \"msg\": \"Request received\",\n  \"path\": \"/path1\",\n  \"response\": \"{\\n  \\\"Accept\\\": [\\n    \\\"*/*\\\"\\n  ],\\n  \\\"User-Agent\\\": [\\n    \\\"curl/8.7.1\\\"\\n  ],\\n  \\\"method\\\": \\\"GET\\\",\\n  \\\"remote_addr\\\": \\\"[::1]:61801\\\",\\n  \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n```\n\n## Get started today\n\nLearn even more with our [Configure sudo access for a workspace documentation](https://docs.gitlab.com/ee/user/workspace/configuration.html#configure-sudo-access-for-a-workspace). See [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for details on individual settings.\n\n> New to GitLab Remote Development? Here is a [quickstart guide](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) to get you up to speed.","security",[1117,1119,9,482,731],"tutorial",{"slug":1121,"featured":91,"template":687},"enable-secure-sudo-access-for-gitlab-remote-development-workspaces","content:en-us:blog:enable-secure-sudo-access-for-gitlab-remote-development-workspaces.yml","Enable Secure Sudo Access For Gitlab Remote Development Workspaces","en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces.yml","en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces",{"_path":1127,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1128,"content":1134,"config":1139,"_id":1141,"_type":14,"title":1142,"_source":16,"_file":1143,"_stem":1144,"_extension":19},"/en-us/blog/engineering-teams-collaborating-remotely",{"title":1129,"description":1130,"ogTitle":1129,"ogDescription":1130,"noIndex":6,"ogImage":1131,"ogUrl":1132,"ogSiteName":673,"ogType":674,"canonicalUrls":1132,"schema":1133},"How to carry out remote work team collaboration","Some tips for successful asynchronous collaboration from all-remote engineering teams.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681893/Blog/Hero%20Images/remoteengineering.jpg","https://about.gitlab.com/blog/engineering-teams-collaborating-remotely","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to carry out remote work team collaboration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2021-02-09\",\n      }",{"title":1129,"description":1130,"authors":1135,"heroImage":1131,"date":1136,"body":1137,"category":940,"tags":1138},[812],"2021-02-09","\n\n_This post is the third in our ongoing series about remote work and engineering. Check out the previous posts, [Tips for engineering managers learning to lead remotely](/blog/tips-for-managing-engineering-teams-remotely/), and [Tips for remote pair programming](/blog/remote-pair-programming-tips/)._\n\nAlmost a year into the pandemic, it’s still unclear when it will be safe to head back into the office. While many companies have resolved the initial growing pains of transitioning from a colocated to an all-remote workplace, we want to help your teams go from surviving to thriving by sharing some strategies to [improve remote work collaboration](/company/culture/all-remote/collaboration-and-whiteboarding/).\n\n## Remote working and asynchronous communication\n\nTraditional methods of communication and project management might work in a colocated office setting, but don’t necessarily translate to a remote environment. In a video on GitLab Unfiltered (our company YouTube channel where team members share their work with the public), [Austin Regnery](/company/team/#aregnery), product designer on Manage: Compliance at GitLab, and [Nick Post](/company/team/#npost), senior product designer on Manage: Optimize at GitLab, talk about the growing pains of transitioning from working synchronously to asynchronously.\n\n\"Emails and meetings... [it's all] email, email, email, meeting, PowerPoint, that’s the modus operandi for how companies collaborated,\" says Nick. \"And it’s something that companies and teams have really held on to.\"\n\nAsynchronous communication challenges the traditional modes of workplace communication, but at GitLab, we’ve discovered that this more modern method of collaboration is more efficient and effective in delivering business value to our customers and helping our team members achieve a work-life balance.\n\nWatch the video below to learn how these designers work asynchronously.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/stLBy9TWJBw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Remote work collaboration: be sensitive to timezones\n\nWhen your team is working in the same office, the workday begins and ends at roughly the same time for everyone. At GitLab, we work asynchronously and our team is globally distributed, which means work is completed on a 24-hour clock instead of just eight hours. \n\nOne of the biggest challenges with working asynchronously is ensuring that all team members feel a sense of belonging across timezones. \n\n\"Timezones matter,\" says [Nuritzi Sanchez](/company/team/#nuritzi), senior open source program manager at GitLab. \"Make sure you're not leaving out team members in one locale. Have meetings at different times if needed (e.g., once a week in a NORAM-friendly time, next week in APAC-friendly time, etc).\" \n\nMaking the switch from synchronous to asynchronous work isn’t easy but really pays off. Learn more about [how we work asynchronously at GitLab](/company/culture/all-remote/asynchronous/#async-at-gitlab).\n\n### Remote work collaboration: maximize synchronous time \n\nThere are times when synchronous communication is the best option, such as during weekly team meetings and one-on-ones. Nuritzi explains that there are a few teams at GitLab that have adopted a particular structure to make the most out of every team meeting. \n\n*  Always have an agenda: Every meeting needs an agenda, usually in Google Docs, that allows team members to add discussion items and notes before and during the meeting. \n*  Notes are key: \"In OSS communities, meeting notes or IRC chats are something that are usually posted publicly later so everyone who needs to can catch up,\" says Nuritiz. \n*  Start with check-ins: Team members voluntarily share whether they're at a green/yellow/red level in their work life and personal life. Managers are always advised to participate in these check-ins to set a collaborative tone. \n* FYIs: Not everything on the agenda will merit discussion. Add FYIs for items that should be shared with the team but don't require extensive dialogue. \n*  Discussion topics: Some agenda items will need to be discussed with the team, add these in the discussion items section of the agenda.\n*  Meetings are optional: Not every team member will be able to attend every meeting, and that's OK. Team members that aren't present can still participate by adding discussion items, FYIs, and notes to the agenda that can be shared by their fellow team members. \n*  Try to make it fun: We start and end every [Inbound Marketing weekly recap meeting](https://youtube.com/playlist?list=PL05JrBw4t0KppgWkSa3YgDgc_qUTKsBCs) with music to liven up Thursdays for our globally distributed team. \n\n## How to make remote onboarding feel welcoming\n\nOnboarding is just one example of a workplace process that has been impacted by the pandemic. This makes having empathy for the new hire even more important than usual. Empathetic onboarding means framing the process from the perspective of the new hire, says [Alexandra Sunderland](https://ca.linkedin.com/in/alexandrasunderland), engineering manager at Fellow.\n\nAlexandra iterated on her onboarding process over a number of years and has since developed a six-step framework that she presented at our virtual user conference, GitLab Commit, last year. The six steps are: (1) Focus on relationships, (2) write knowledge down, (3) create an FAQ, (4) set goals and milestones, (5) set up their physical space, (6) ask for feedback.\n\nWatch the video below to learn how Fellow onboards engineers remotely. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/tdWxlpN8dUk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nBeyond making sure new team members are set up with a functional workspace, the secret to successful onboarding is assuming that the team member has the skills and knowledge necessary to do their job, but still needs to learn the context in which to do it, according to Alexandra. \n\nGitLab has a [unique onboarding process](/handbook/people-group/general-onboarding/), in that new hires are given a detailed checklist in an issue and are assigned an onboarding buddy. This onboarding process is a crash course in working as a [manager of one](https://handbook.gitlab.com/handbook/values/#managers-of-one) in an asynchronous workplace. \n\n## How to collaborate on releases remotely\n\nMattermost's [Aaron Rothschild](https://www.linkedin.com/in/arothschild), senior product manager, and [Paul Rothrock](https://www.linkedin.com/in/icelander), customer engineer, describe how their dashboard that provides visibility into the DevOps process can be used with tools such as Jira, Jenkins, and GitLab, to release software remotely. Watch the presentation from our user conference to see an example of how the team collaborates to deliver a release.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/QBG0-YaDXu0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## How to stay social when you’re working alone\n\nCommunication technologies, specifically Slack, can help to cultivate a sense of community and belonging within our teams. We publicly recognize team members that contributed to success in a #team-member-updates channel on Slack, where we announce bonuses and promotions for team members across the company. We also show appreciation for our collaborators in the #thanks channel.\n\n### The (virtual) water cooler\n\nThe pandemic has us all practicing social distancing, but at GitLab, we worked hard to try and replicate the social aspect of the office through a [few different informal communication programs](/company/culture/all-remote/informal-communication/), such as our coffee chats, and Slack channels devoted to different extracurriculars (I’m fond of the #dog and #baking channels, personally). The [Donut bot on Slack is a neat social feature](/company/culture/all-remote/informal-communication/#the-donut-bot). The bot will randomly introduce you to a team member that you may not otherwise have collaborated with in your daily work, and invites the two team members to [set up a coffee chat](/company/culture/all-remote/informal-communication/#coffee-chats). \n\n## Up-level your remote work skills\n\n[GitLab launched a free program on Coursera](https://www.coursera.org/learn/remote-team-management) to help managers with the transition of managing a team remotely. The course is free to join and is packed with valuable information to help companies adapt to working remotely.\n\nCover image by [Chris Montgomery](https://unsplash.com/@cwmonty?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/remote-work?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,731],{"slug":1140,"featured":6,"template":687},"engineering-teams-collaborating-remotely","content:en-us:blog:engineering-teams-collaborating-remotely.yml","Engineering Teams Collaborating Remotely","en-us/blog/engineering-teams-collaborating-remotely.yml","en-us/blog/engineering-teams-collaborating-remotely",{"_path":1146,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1147,"content":1153,"config":1160,"_id":1162,"_type":14,"title":1163,"_source":16,"_file":1164,"_stem":1165,"_extension":19},"/en-us/blog/five-signs-you-should-think-bigger",{"title":1148,"description":1149,"ogTitle":1148,"ogDescription":1149,"noIndex":6,"ogImage":1150,"ogUrl":1151,"ogSiteName":673,"ogType":674,"canonicalUrls":1151,"schema":1152},"Five signs you should think BIGGER!","Are you a designer who is frustrated with only focusing on the next milestone? Do you feel like you have to answer too many questions in every Issue? Do you feel like your product is not making any progress? **Time to Think Bigger!**","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099620/Blog/Hero%20Images/Blog/Hero%20Images/insights_insights.png_1750099620265.png","https://about.gitlab.com/blog/five-signs-you-should-think-bigger","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Five signs you should think BIGGER!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Iain Camacho\"}],\n        \"datePublished\": \"2021-03-30\",\n      }",{"title":1148,"description":1149,"authors":1154,"heroImage":1150,"date":1156,"body":1157,"category":940,"tags":1158},[1155],"Iain Camacho","2021-03-30","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAs a designer, it’s difficult to balance the scale of initiatives: Design too small, and nobody is excited or can understand the direction things are going. Start too big and everyone on the team may be too intimidated to start. ThinkBIG is a way of utilizing designers’ natural skillset to balance the iterative nature of engineering with the visionary nature of design.\n\nHere are 5 signals that you should switch up your style and Think Bigger:\n\n### 1) Every milestone is spent only prepping the next\n\n#### Signal\n\nWe’ve all been there. The next milestone planning issue is starting to get filled out and you, the designer, are realizing how many issues need design in order to be ready. As the priorities shift, you know the last two weeks of this milestone will be spent desperately trying to design mockups for engineers to start working on days later. I like to call this “Feeding the sharks”. It describes a certain level of panic some designers feel every milestone: If I don’t deliver enough, I might get chomped!\n\n#### Solution\n\nThinkBIG focuses on creating a larger-scale vision that can be iterated on as we go. This means that each design you put together leads to many independent issues engineers can work on. For a designer, this increases [results](https://handbook.gitlab.com/handbook/values/#results) by delivering one design worth many issues.\n\n### 2) Engineers are asking _a lot_ of questions\n\n#### Signal\n\nHave you ever started a new milestone and as engineers get started, they have a million questions detailing every possible state, permutation, and example that they should account for? This line of questioning means you, the designer, now need to make a myriad of new designs with only minute changes between them. This is not an [efficient](https://handbook.gitlab.com/handbook/values/#efficiency) use of the designer’s time.\n\n#### Solution\n\nFirst off, all these questions are valid and decisions that need to be made. By Thinking Bigger, engineers are better prepared to handle all the edge cases independently because they walk into their work with a fuller context of the impact on users.  This enables empathy-driven engineering, allowing engineers to lead the conversation around edge-cases with solutions in mind, instead of needing it to be defined ahead of time. By pushing the edge cases further down the product development lifecycle, there is also a unique opportunity for product, design, and engineering to [collaborate](https://handbook.gitlab.com/handbook/values/#collaboration) on delivering value to customers while still working iteratively.\n\n### 3) Nobody agrees on what the “MVC” actually is\n\n#### Signal\n\nPicture it: You’ve worked hard for weeks refining and distilling a big feature ask into a nicely designed MVC. It’s small, delivers value, and is beautiful to boot! You’ve convinced your PM to prioritize this beautiful little gem and it’s going onto the planning board. Everything feels amazing until… devastation!\n\nAfter engineering looked at it, they came back and said it was too large and would need to be broken down further. Now you’re at the end of your milestone and you’re swiftly picking away at your beautiful design into a shallow imitation of its former glory.\n\n#### Solution\n\nHowever, there is a simple way to keep this from happening: “[Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is a team sport”. The designer shouldn’t be the only person on the team compromising for the sake of MVC. With ThinkBIG, you have multiple chances to bring engineering into the fold early and with the full vision in mind. This means devs are part of the conversation from the start, able to craft a valuable iteration and your designs become the conversation piece of deciding “What can we do next to deliver an amazing experience to our customers?”\n\n### 4) We’re working so hard but not getting anywhere\n\n#### Signal\n\nWorking iteratively is incredibly powerful and at GitLab, we can see the value of an iterative approach. We’re able to change our priorities at a moment’s notice and the work we actually have to deliver is reasonable and manageable while continuously delivering new value to customers. There is, however, a small drawback: When you’re only focusing on the step immediately in front of you, it’s easy to get lost along the way.\n\n#### Solution\nAs a designer, we have a unique opportunity to be the navigator for our teams. Using the ThinkBIG model, designers are empowered to hold responsibility for the Vision. From here, the Product Manager/Product Designer relationship becomes a balance between the vision and the strategy. Designs based on the large vision are used to keep the team on track for hitting the targets that bring value to customers while allowing for collaboration with the rest of the team on what tiny steps we take to get there.\n\n### 5) Engineers are reworking a lot\n\n#### Signal\n\nMy engineer and I are excited to work on a new effort. I’ve designed the first iteration and successfully passed it to them.  While they’re building, I’m working on the design for the next iteration. A few weeks later the new changes are merged, the next iteration designs are ready, and customers are already seeing value. Your engineer looks at the next iteration and painfully mutters “Well, I’ll have to rewrite what I wrote the last milestone to account for this.”\n\n#### Solution\n\nIn a highly iterative development lifecycle, it’s not uncommon to have to rework things as the product evolves. However, it shouldn’t be happening every time. With ThinkBIG, engineers are informed of the long-term goal as well as the short-term MVC iteration. This extra context allows them to deliver the iteration while architecting their code in an informed way of where it will go.\n\n### Start Thinking BIGGER!\n\nAre some of these signals sounding familiar? Then switching your design style to ThinkBIG may be for you! The simplest way to make this change is to move iteration breakdown to **after** the design phase. It immediately shows engineers where we want to go as a product or feature, opens the implementation breakdown (MVC) conversation to the whole team, and provides incredibly valuable insight to everyone on the team. This model of working helps designers be more efficient, deliver results, and foster a tight collaboration with the broader team. To see this process in action, check out a [Package ThinkBIG around the dependency proxy design and research](https://www.youtube.com/watch?v=LXFu6oDxhsw). For more information, check out the GitLab Handbook on [ThinkBIG](https://about.gitlab.com/handbook/product/ux/thinkbig/) to learn more.\n",[731,732,683,9,1159],"AWS",{"slug":1161,"featured":6,"template":687},"five-signs-you-should-think-bigger","content:en-us:blog:five-signs-you-should-think-bigger.yml","Five Signs You Should Think Bigger","en-us/blog/five-signs-you-should-think-bigger.yml","en-us/blog/five-signs-you-should-think-bigger",{"_path":1167,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1168,"content":1174,"config":1180,"_id":1182,"_type":14,"title":1183,"_source":16,"_file":1184,"_stem":1185,"_extension":19},"/en-us/blog/five-things-you-hear-from-gitlab-ceo",{"title":1169,"description":1170,"ogTitle":1169,"ogDescription":1170,"noIndex":6,"ogImage":1171,"ogUrl":1172,"ogSiteName":673,"ogType":674,"canonicalUrls":1172,"schema":1173},"5 Things you might hear when meeting with GitLab's CEO","After two weeks shadowing our CEO, I can share the hottest topics on his mind right now.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670738/Blog/Hero%20Images/coghlanshadow.jpg","https://about.gitlab.com/blog/five-things-you-hear-from-gitlab-ceo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Things you might hear when meeting with GitLab's CEO\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Coghlan\"}],\n        \"datePublished\": \"2019-06-28\",\n      }",{"title":1169,"description":1170,"authors":1175,"heroImage":1171,"date":1177,"body":1178,"category":705,"tags":1179},[1176],"John Coghlan","2019-06-28","\n\nDuring my two-week rotation in GitLab’s [CEO shadow program](/handbook/ceo/shadow/) I noticed something: Being a CEO involves a lot of repetition. Whether meeting with his executive team, board members, public or private market investors, candidates for [open roles](/jobs/), or journalists, our CEO [Sid Sijbrandij](/company/team/#sytses) had to repeat himself – a lot.\n\nThis shouldn’t be a surprise. I’ve read [articles](https://www.mckinsey.com/business-functions/organization/our-insights/the-ceos-role-in-leading-transformation) about the [importance of repetition](https://getlighthouse.com/blog/power-of-repetition-successful-leaders/) for leaders. My job can be pretty repetitive, too. I'm constantly planning meetups and explaining my role and the programs I manage to people throughout the wider GitLab community. And yet, given Sid’s position in GitLab and his desire to pursue “interestingness” (a Sid-ism I heard often), I was still surprised the 10th time I heard him tell the story of [how GitLab was founded](https://www.youtube.com/watch?v=CZ07wk3t31g&feature=youtu.be&t=135).\n\nI want to highlight a few of the other common themes, topics, and questions that came up repeatedly throughout my time in the CEO shadow program – to both share some insight with our community and inform folks who will be meeting with Sid about what to expect.\n\n## 1. \"We don't have any offices\"\n\nGitLab’s all-remote culture is a popular topic right now. It came up frequently in conversations with potential investors, candidates for executive positions, and journalists. People were curious to learn how we make it work at our scale and how we replicate the serendipitous moments that occur among co-located teams. Sid typically relies on explanations of our [handbook](/handbook/), [breakout calls](/handbook/communication/#breakout-call), [coffee chats](/company/culture/all-remote/tips/#coffee-chats), and [Contribute](https://www.youtube.com/watch?v=xdtPNXtkBhE) to help folks better understand how we are able to be successful as an all-remote company.\n\nIt's exciting to hear the conversation on all-remote work evolve as people learn more about it. One of the main reasons I joined GitLab was the ability to be part of an [all-remote](/company/culture/all-remote/) company. I believe we can change how the world views all-remote teams as we continue to be successful. With more than 2,000 [contributors](/community/contribute/), more than 600 people on our [team](/company/team/), and many more wanting to join, we are off to a good start.\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-cards=\"hidden\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Over the last 3 months we had over 20,000 applications for the vacancies at \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> \u003Ca href=\"https://t.co/JbmWvk3uDB\">https://t.co/JbmWvk3uDB\u003C/a> It encourages us to push for even more transparency \u003Ca href=\"https://t.co/WQcUPXzcWj\">https://t.co/WQcUPXzcWj\u003C/a> since many people cite that as a reason to apply.\u003C/p>— Sid Sijbrandij (@sytses) \u003Ca href=\"https://twitter.com/sytses/status/1134122539670691841?ref_src=twsrc%5Etfw\">May 30, 2019\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nOur success has [already inspired other companies to follow the all-remote blueprint](/handbook/inspired-by-gitlab/). The movement towards all-remote organizations will continue as we grow, generating more awareness and opening up opportunities that were never previously available to people around the world.\n\nHere's a recording of a meeting I attended between our CEO Sid and GitLab board member Sue Bostrom that touched on our all-remote story:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ePZpfeTG63M\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## 2. \"One of our values is...\"\n\nIn nearly every meeting I attended over the two-week rotation, [GitLab’s values](https://handbook.gitlab.com/handbook/values/) were mentioned. Transparency is the most common value highlighted when our CEO meets with members of the wider GitLab community (see above tweet), many of whom are surprised to see Sid using Google to search for our handbook, roadmap, or OKRs – which is possible because they’re published publicly on our website. With his executive team and other leaders in the company, Sid is frequently focused on [results](https://handbook.gitlab.com/handbook/values/#results) – from structuring his meetings with a bias to action (more on this later) to pushing for GitLab to always be more data-driven and analytical in how we execute on everything from [our releases to our vision](/handbook/product/product-processes/#planning-horizons). When something is moving slower than expected, Sid will encourage people to break down the work and make small changes that are easier to ship in alignment with our [iteration value](https://handbook.gitlab.com/handbook/values/#iteration).\n\nOur other values came up in conversations about how we recruit for our fast-growing team and the recruitment of a new chief people officer ([diversity](https://handbook.gitlab.com/handbook/values/#diversity-inclusion)), how well our people are performing as managers of one ([efficiency](https://handbook.gitlab.com/handbook/values/#efficiency)), and the importance of dogfooding our own product ([collaboration](https://handbook.gitlab.com/handbook/values/#collaboration)).\n\n## 3. \"Is this already in the handbook?\"\n\nAs I alluded to earlier, at GitLab we value results and that starts with the CEO. Internal meetings with Sid require an agenda. Those agendas typically follow a [specific format](/handbook/leadership/1-1/suggested-agenda-format/), and they are usually filled with merge requests and other actionable items. Meetings with our CEO are not for status updates. They tend towards discussions that lead to action or for taking action (such as reviewing and merging an MR that is linked to in a meeting agenda). When a discussion takes place without a related MR link in the agenda, Sid inevitably asks, \"Is this already in the handbook?\" or something to that effect. This ensures any follow-up actions are assigned to someone so that actionable, visible changes are not delayed.\n\nEven participation in the shadow program is viewed through the lens of results. As a shadow, one of the [tasks](/handbook/ceo/shadow/#tasks) you’re expected to complete is updating GitLab’s handbook, particularly the shadow page. During my rotation, Sid commented multiple times on the number of MRs that I created to update our handbook. Results have the CEO’s attention.\n\n## 4. \"Google Docs are the new whiteboard\"\n\nGoogle Docs are the default tool for GitLab agendas and meeting notes. While they are a necessity in the remote work environment, once you begin using them, you quickly notice the efficiency they bring to meetings. The delight that Sid draws from the efficiency of using Google Docs for notes is clear whenever he happily explains how they are superior to whiteboards, which happens frequently in meetings with people new to GitLab's way of working.\n\nAt GitLab, we find Google Docs to be so efficient and helpful, that we’ve even included [why to use them in our handbook](/company/culture/all-remote/tips/index.html#docs-beat-whiteboards). This handbook addition was contributed by my fellow CEO shadow, [Cindy Blake](/company/team/#cblake2000). In her words:\n\n> \"Often we are asked, 'But how do you whiteboard without everyone physically together?' We use Google Docs for collaboration. Every meeting has a Google Doc for the agenda and for documenting discussion, decisions, and actions. Everyone in the meeting adds notes at the same time. We literally even finish one another's sentences sometimes. By brainstorming in text, instead of drawings, we are forced to clearly articulate proposals, designs, or ideas, with less variance in interpretations. A picture may be worth a thousand words, but it is open to as many interpretations are there are people viewing it. In Google Docs, we use indentations to drill deeper into a given topic. This method retains context for comments, discussions, and ideas.\"\n\n## 5. \"Can you put your headphones on?\"\n\nThe emphasis on clear communication is a priority for Sid and leaks into many of his conversations. This ranges from his awareness and respect when communicating with folks for whom English is not their first language to how we name and structure the parts of our organization and to whether or not a meeting attendee is using headphones on a Zoom chat (note: you should). All of this – even the preference for headphones – makes sense.\n\nAt a macro level, as an all-remote, open core company with a global community and [team members in 54 countries](/company/team/), GitLab’s community consists of people with varying levels of English fluency. In order to promote a diverse and inclusive culture, it’s important to choose clear language when writing and speaking – from how we name teams and features to the idioms and slang we choose not to use. At a micro level, if you’re meeting with someone who has a poor video or audio connection the issue must be resolved so that everyone can understand each other and get through the agenda.\n\n## Takeaways\n\nWhether you're reading this because you have a meeting with Sid, you're joining the CEO shadow program, or you simply want to add some best practices from a CEO to incorporate in your routine, there are a few key takeaways to distill from these common topics and questions.\n\n* All-remote is gaining momentum\n* Values matter\n* Have a bias towards action\n* Find tools that work for you\n* Clear communication is key\n\nOne other thing you'll hear often when you're with Sid is \"Thank you.\" Despite being a CEO, Sid is generous with his time and praise and never fails to say thank you to folks he spends time with. As a parent of two young children myself, I think that might be the most important takeaway of all.\n",[9,731,683],{"slug":1181,"featured":6,"template":687},"five-things-you-hear-from-gitlab-ceo","content:en-us:blog:five-things-you-hear-from-gitlab-ceo.yml","Five Things You Hear From Gitlab Ceo","en-us/blog/five-things-you-hear-from-gitlab-ceo.yml","en-us/blog/five-things-you-hear-from-gitlab-ceo",{"_path":1187,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1188,"content":1194,"config":1200,"_id":1202,"_type":14,"title":1203,"_source":16,"_file":1204,"_stem":1205,"_extension":19},"/en-us/blog/five-ways-to-scale-remote-work",{"title":1189,"description":1190,"ogTitle":1189,"ogDescription":1190,"noIndex":6,"ogImage":1191,"ogUrl":1192,"ogSiteName":673,"ogType":674,"canonicalUrls":1192,"schema":1193},"5 Ways to scale remote work on your team","Learn how technology businesses are embracing the future of work by going all-remote.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679453/Blog/Hero%20Images/remote-work.png","https://about.gitlab.com/blog/five-ways-to-scale-remote-work","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Ways to scale remote work on your team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Betsy Bula\"}],\n        \"datePublished\": \"2021-08-09\",\n      }",{"title":1189,"description":1190,"authors":1195,"heroImage":1191,"date":1197,"body":1198,"category":705,"tags":1199},[1196],"Betsy Bula","2021-08-09","\n\nAt GitLab, we believe that remote work at scale will define not only the future of work, but the future of living. We created [REMOTE by GitLab](https://remotebygitlab.com/) to bring together the remote work community and answer the questions many companies are asking: \"How do we do this, and what's next?\"\n\nWe heard from some of the top leaders in remote work, from large companies that made the decision to leave the office behind, to teams of experts who have been studying the organizational design for years.\n\nWe share five lessons from the REMOTE by GitLab event that your team can apply to uplevel your [remote practices and culture](/company/culture/all-remote/building-culture/).\n\n## Set guiding principles for your remote transition (and stick to them)\n\nAs you navigate the changes that come with implementing remote-first practices, it's important to have a set of values and guiding principles that your team can refer back to each time you make a decision, process, or change.\n\nDaisy Linden, employee experience and remote-first at Coinbase, and Dominique Baillet, global head of employee experience and diversity and inclusion at Coinbase, shared the story of why their organization decided to be a virtual-first company, and what principles they leaned on throughout the transition to remote work. Watch their session in the video below for more insights and lessons learned.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/qOoiWVgWbYY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Hire a remote work lead\n\nIf your organization is grappling with decisions about the future of work, it's crucial to have guidance and leadership from someone with experience converting remote work from a logistical challenge to a strategic advantage. This is even more important as your team grows and scales. That's why many companies are hiring a \"Head of Remote\" to guide them on this journey.\n\nWe learned how Facebook's team is approaching remote work in a session from Annie Dean, Director of Remote Work, at the social media platform. Watch Annie's session to learn how her team works, and what insights she has for other remote leaders.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/VSQRMv-N1Ls\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Invest in your team's workspaces\n\nCompanies that are going all-remote or embracing a hybrid-remote structure may be saying goodbye to corporate office space, but that doesn't mean employees should be required to set up their own workspaces. A healthy workspace enables productive work and promotes physical and mental wellbeing. Just like in a colocated office, it's up to leaders to support their teams in creating positive work environments from home, or any location they choose to work remotely.\n\nIn this session, workspace expert Ryan Anderson from MillerKnoll shares everything you need to know to create your best workspace.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/l9jmb8TE7sw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nSee how [GitLab team members set up their workspaces](/blog/not-everyone-has-a-home-office/) – from the home office to being on the road, and learn more about the [tools GitLab's all-remote workforce swears by](/blog/whats-in-your-backpack/).\n\n## Build a rest ethic within your organization\n\nJust as leaders and managers are responsible for setting their team up for success at work, they are also responsible for ensuring they take time away from work. This is crucial not just for preventing burnout, but also for increasing employee engagement, enthusiasm, and productivity.\n\nJohn Fitch, the founder of Time Off, says your team's \"rest ethic\" is just as important as their work ethic. Watch his session to find out how you can update your organization's practices to make intentional time off part of your culture, and unlock the full potential of your team.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/bQMoF7oSh2o\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Shift your collective mindset from productivity to purpose\n\nWe must unlearn traditional work habits and shift our mindset to truly embrace the future of work and living. During his talk at REMOTE by GitLab, Alastair Simpson, Dropbox VP of Design, shared the lessons Dropbox  learned as they continue to redesign the way they work.\n\nAs Alastair points out, it's up to leaders and managers to help their teams feel purpose beyond just work, turning traditional ways of working into human-centered ways of working. Watch the video below to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/FfYstjnCre8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Ready to go REMOTE?\n\nExplore more best practices in the remote work world by watching talks from leaders at Twitter, Robinhood, Harvard Business School, Remote, and more. Every session from REMOTE by GitLab is available on-demand on the [GitLab YouTube channel](https://www.youtube.com/c/Gitlab/playlists?view=50&sort=dd&shelf_id=1).\n",[9],{"slug":1201,"featured":6,"template":687},"five-ways-to-scale-remote-work","content:en-us:blog:five-ways-to-scale-remote-work.yml","Five Ways To Scale Remote Work","en-us/blog/five-ways-to-scale-remote-work.yml","en-us/blog/five-ways-to-scale-remote-work",{"_path":1207,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1208,"content":1214,"config":1220,"_id":1222,"_type":14,"title":1223,"_source":16,"_file":1224,"_stem":1225,"_extension":19},"/en-us/blog/from-berlin-to-new-zealand",{"title":1209,"description":1210,"ogTitle":1209,"ogDescription":1210,"noIndex":6,"ogImage":1211,"ogUrl":1212,"ogSiteName":673,"ogType":674,"canonicalUrls":1212,"schema":1213},"Visiting Family During COVID-19 (Germany to New Zealand)","My experience working for Gitlab traveling from Berlin to New Zealand on short notice","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672592/Blog/Hero%20Images/berlin-to-new-zealand-1.jpg","https://about.gitlab.com/blog/from-berlin-to-new-zealand","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Visiting Family During COVID-19 (Germany to New Zealand)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Marc Shaw\"}],\n        \"datePublished\": \"2021-04-27\",\n      }",{"title":1209,"description":1210,"authors":1215,"heroImage":1211,"date":1217,"body":1218,"category":729,"tags":1219},[1216],"Marc Shaw","2021-04-27","The story started in January 2020, around the time chatter of COVID-19 started. I was concerned, but still relatively confident I would be able to travel home and see my grandparents later that year. The initial plan was to fly home to New Zealand in November 2020, and fly back to Berlin in March 2021. Little did I know that countries would nearly all but shut their borders completely over the next few months, restricting travel to only residents and citizens. After the first lockdown, and as summer approached, COVID-19 improved drastically in Berlin with Germany being one of the few countries that were handling the virus with poise and targeted/reasonable restrictions. Back in New Zealand, there was a very strict lockdown that lasted a couple of months, aiming to eradicate the virus from the country.\n\nFast forward to October 2020, Germany was getting hit with the start of their second wave and by November we had gone back into a lockdown. New Zealand on the other hand had introduced a strict quarantine system, one which required you to book months in advance, with openings often hard to come by. Having not seen my grandparents for two and a half years, I was anxious to see them again. This feeling was compounded due to health concerns unrelated to COVID-19, which caused two of them to be admitted to a hospital in late 2020.\n\nA year after the start of the story in January 2021, we had just entered our third consecutive month of being locked down in Berlin, Germany. I mentioned to my manager that I am thinking about trying to get a quarantine slot to make the 30+ hour flight from Berlin to New Zealand, her instant reaction was of support and asked if there was anything she could help with. I mentioned that nothing is set, but I will keep her updated on booking a quarantine slot. Luckily I managed to snap up a slot (after a week of trying) for the 2nd of February. I then booked my flights and messaged my manager. Since the time zones difference between Germany and New Zealand was around 12 hours, she sorted out meetings and suggested I take a few days off after landing to get over my jet lag even though it was in the same release. It was the genuine care shown and ease at making changes on short notice that I wholly appreciated.\n\nThroughout the whole experience, it has reinforced to me that GitLab practices the values that it preaches, and for me, this was shown through [family and friends being put first, work is second.](https://handbook.gitlab.com/handbook/values/#family-and-friends-first-work-second) The few months that I have been in New Zealand have made life for me exponentially better (given the circumstances). Living in a country without COVID-19 has allowed me to visit all my family, friends, and colleagues around the country, I have attended street festivals with over 100,000 people, indoor concerts, surfed, got my tattoo, gone hiking. This would not have been possible on such short notice for a lot of companies, potentially at all. Every day I reflect on where I am currently in terms of job, location, and everyone around me, and just spend a few minutes appreciating just how lucky I am.\n\n| Ngarunui Beach, Raglan | Cubadupa, Wellington | |:-------------------------:|:-------------------------:| | ![Raglan](https://about.gitlab.com/images/blogimages/berlin-to-new-zealand-2.jpg) | ![Cubadupa](https://about.gitlab.com/images/blogimages/berlin-to-new-zealand-3.jpg) |\n| Blue Spring, Putāruru | Kāpiti Coast | |:-------------------------:|:-------------------------:| | ![Blue Springs](https://about.gitlab.com/images/blogimages/berlin-to-new-zealand-4.jpg) | ![Raglan](https://about.gitlab.com/images/blogimages/berlin-to-new-zealand-5.jpg) |",[683,9],{"slug":1221,"featured":6,"template":687},"from-berlin-to-new-zealand","content:en-us:blog:from-berlin-to-new-zealand.yml","From Berlin To New Zealand","en-us/blog/from-berlin-to-new-zealand.yml","en-us/blog/from-berlin-to-new-zealand",{"_path":1227,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1228,"content":1234,"config":1239,"_id":1241,"_type":14,"title":1242,"_source":16,"_file":1243,"_stem":1244,"_extension":19},"/en-us/blog/funny-gitlab-remote-meetings",{"title":1229,"description":1230,"ogTitle":1229,"ogDescription":1230,"noIndex":6,"ogImage":1231,"ogUrl":1232,"ogSiteName":673,"ogType":674,"canonicalUrls":1232,"schema":1233},"Wild and crazy things that only happen to all-remote teams","Working remotely may make for a calmer commute but plenty of adventure awaits.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680938/Blog/Hero%20Images/joshua-tree-leap.jpg","https://about.gitlab.com/blog/funny-gitlab-remote-meetings","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wild and crazy things that only happen to all-remote teams\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Murph\"}],\n        \"datePublished\": \"2019-12-16\",\n      }",{"title":1229,"description":1230,"authors":1235,"heroImage":1231,"date":1236,"body":1237,"category":705,"tags":1238},[702],"2019-12-16","\n\nGitLab has more than [1,000 team members](/company/team/) across 65 (and counting!) countries. Every employee works remotely, from wherever they're most comfortable, and we have no company offices. While that allows us all to avoid the headaches of [commuting](/company/culture/all-remote/#for-the-world), it doesn't mean that our days are boring. Far from it, actually.\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">"It was just this mad scramble to turn off the camera." More people are working remotely, leading to videoconference call faux pas. \u003Ca href=\"https://t.co/NbdEeWxbGv\">https://t.co/NbdEeWxbGv\u003C/a>\u003C/p>— The Wall Street Journal (@WSJ) \u003Ca href=\"https://twitter.com/WSJ/status/1159505825016295424?ref_src=twsrc%5Etfw\">August 8, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n[Tim Zallmann](/company/team/#timzallmann), a director of engineering at GitLab, was recently featured in a [Wall Street Journal report](https://www.wsj.com/articles/why-are-you-shirtless-when-remote-video-calls-go-wrong-11565280525?mod=e2tw) highlighting comedic happenings for those who work remotely. We polled the entire company to see if they had any stories to share, and the answers came rolling in.\n\n### Surprise guests\n\n![Monkeys in meetings](https://about.gitlab.com/images/blogimages/monkey-airbnb.jpg){: .shadow.medium.center}\nMonkey in the meeting.\n{: .note.text-center}\n\n> I was work-traveling last year for 6 weeks with my wife and kid through South Africa. One day, I was in a video call at a new Airbnb. I had my headphones in when a monkey tried to get through the window behind me. In the middle of the call, I was casually informed that there was a monkey behind me... which resulted in me screaming quite loudly, realizing the monkey was already well on its way inside.\n– [Tim Zallmann](/company/team/#timzallmann), director of engineering, Dev\n\n> When food delivery arrives in the middle of a meeting, but you didn't order enough for everyone.\n– [Patrick Harlan](/company/team/#pharlan), technical account manager\n\n> It's great when kids decide to jump into a call. Lots of big eyes and cute little hand waves. They also tend to whisper frantically into their parents' ears. Toddlers are the best.\n– [Christie Lenneville](/company/team/#clenneville), director of UX\n\n> Our dogs talk to each other. If I am on computer audio and my dog hears a GitLabber dog barking, he joins in. Some people – who shall remain nameless – like to tease dogs with pretend barking to see if they can get them to bark. We have also had pets join us for coffee chats and visit with each other.\n– [Kimberly Lock](/company/team/#kimlock), customer reference manager\n\n### Serendipitous run-ins\n\n![GitLab team members meet up for a day at the zoo](https://about.gitlab.com/images/blogimages/gitlab-san-diego-zoo.jpg){: .shadow.medium.center}\nGitLab team members meet up for a day at the zoo.\n{: .note.text-center}\n\n> I love traveling somewhere and instantly finding friends. I recently took a road trip with my family down the coast of California and met a GitLab team member who joined for a walk to the San Diego Zoo. I'd never met him before, but felt like an instant friend with so much to talk about.\n– [Priyanka Sharma](/company/team/#pritianka), director of technical evangelism\n\n> Joining a video call and finding out the person you are meeting with lives in your city.\n– [Lee Matos](/company/team/#leematos), Support engineering manager, Americas East\n\n\n\n### Moments fantastic and funny\n\n![Virtual happy hour](https://about.gitlab.com/images/blogimages/team-group-call-gitlab.jpg){: .shadow.medium.center}\nVirtual happy hour.\n{: .note.text-center}\n\n> We do virtual Friday happy hours with the team. We get on a big group call and everyone brings their beverage of choice (water, tea, whatever) and just chats for a few minutes about what they're doing for the weekend, etc. Fun times where you can bond with you co-workers. Even our [CEO Sid](/company/team/#sytses) shows up to many of them!\n– [Tina Sturgis](/company/team/#t_sturgis), senior manager, partner and channel Marketing\n\n> I have an LED color-changing light that I use at the foot of the basement stairs so my kids know if they can come in or not. Red, yellow, and green lights let them know if I'm on a call or taking a break (or somewhere in between).\n– [Brendan O'Leary](/company/team/#olearycrew), senior solutions manager\n\n> Green screen usage is a must! Cape Town, Star Trek ships, or a beach in Hawaii – the backdrop options on video calls are endless.\n– [Priyanka Sharma](/company/team/#pritianka), director of technical evangelism\n\n> When someone on a video call says \"Alexa\" and everyone's Alexa wakes up.\n– [Brendan O'Leary](/company/team/#olearycrew), senior solutions manager\n\n### GitLab's approach to meetings\n\nWe [approach meetings differently](/company/culture/all-remote/meetings/) at GitLab. While one's appearance, surroundings, and background can be the source of great stress and anxiety when preparing for a video call, GitLab team members are encouraged to bring their whole selves to work. That means we celebrate unique surroundings and welcome appearances from family and pets.\n\nLearn more about our [all-remote culture](/company/culture/all-remote/). If you're interested in being featured in the next round of remote outtakes, browse our [vacancies](/jobs/) and apply!\n\nCover image by Kevin Oliver\n{: .note}\n",[708,683,9],{"slug":1240,"featured":6,"template":687},"funny-gitlab-remote-meetings","content:en-us:blog:funny-gitlab-remote-meetings.yml","Funny Gitlab Remote Meetings","en-us/blog/funny-gitlab-remote-meetings.yml","en-us/blog/funny-gitlab-remote-meetings",{"_path":1246,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1247,"content":1253,"config":1260,"_id":1262,"_type":14,"title":1263,"_source":16,"_file":1264,"_stem":1265,"_extension":19},"/en-us/blog/gitlab-acquisitions",{"title":1248,"description":1249,"ogTitle":1248,"ogDescription":1249,"noIndex":6,"ogImage":1250,"ogUrl":1251,"ogSiteName":673,"ogType":674,"canonicalUrls":1251,"schema":1252},"A guide to GitLab’s soft landing acquisitions","Find the team a new home, release your technology to a wider user base, and continue to build products you love through a soft-landing acquisition.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680671/Blog/Hero%20Images/soft-landing-acquisitions.jpg","https://about.gitlab.com/blog/gitlab-acquisitions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A guide to GitLab’s soft landing acquisitions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eliran Mesika\"}],\n        \"datePublished\": \"2019-07-30\",\n      }",{"title":1248,"description":1249,"authors":1254,"heroImage":1250,"date":1256,"body":1257,"category":299,"tags":1258},[1255],"Eliran Mesika","2019-07-30","\n\nA few months ago we published our [acquisitions handbook](/handbook/acquisitions/). A first of its kind, it provides a clear view on how we approach and carry out acquisitions at GitLab. We believe this handbook is the basis for effective communication and expectation setting.\n\nOur unique approach to acquisition is suited for companies which have built great technologies but were unable to reach the desired distribution and are nearing the end of their runway. For companies in this state we are offering an opportunity for soft landing in GitLab through acquisition, finding the team a new home, releasing the technology you developed to the greater GitLab user base, and continuing to build awesome products you love.\n\n## Is this relevant for your company?\n\nIf you’re a technology company:\n1. Operating in the expanded [DevOps space](/direction/)\n2. With a team of 10 employees or fewer\n3. At the end of your runway and/or thinking about winding down\n4. Open to a soft-landing acquisition and ready to move through the process quickly\n\n... then your company is potentially a great fit for our soft-landing acquisition process.\n\n## What GitLab has to offer\n\n1. Assets will be purchased for up to $1M total, all cash. GitLab stock will not be offered as part of the deal for the assets sold.\n2. We believe talent follows leadership they trust. In addition to the purchase price, GitLab will offer cash bonuses for founders and engineers to help in the transition, conditional on employee interviews and offer acceptance:\n   - Each founder with more than 10% ownership of the company will receive $250,000 paid as follows: $50,000 on closing and $200,000 as a retention bonus\n   - Each engineer will receive $60,000 paid as follows: $12,000 on closing and $48,000 as a retention bonus\n1. Triple our normal stock option grants for founders, normal stock option grants for non-founders\n\nWe invite you to take a closer look at our acquisitions [handbook page](/handbook/acquisitions/) and reach out to myself, the acquisitions lead,  eliran@gitlab.com, to start a discussion.\n\nIt's important to add that we're open to other types of acquisitions, aside from the soft-landing type. We've felt it's beneficiary to all sides of a soft-landing acquisition to have a streamlined, fast process, which is why we've created ours at GitLab. If you'd like to engage us in an acquisition conversation, again, feel free to reach out to me at eliran@gitlab.com.\n\nYou can also read about [one startup's experience of being acquired by GitLab](/blog/gemnasium-our-gitlab-journey/).\n\nCover image by [Pascal Meier](https://unsplash.com/photos/UYiesSO4FiM) on [Unsplash](https://unsplash.com)\n{: .note}\n",[1259,684,9],"DevOps",{"slug":1261,"featured":6,"template":687},"gitlab-acquisitions","content:en-us:blog:gitlab-acquisitions.yml","Gitlab Acquisitions","en-us/blog/gitlab-acquisitions.yml","en-us/blog/gitlab-acquisitions",{"_path":1267,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1268,"content":1274,"config":1280,"_id":1282,"_type":14,"title":1283,"_source":16,"_file":1284,"_stem":1285,"_extension":19},"/en-us/blog/gitlab-employees-on-working-at-gitlab",{"title":1269,"description":1270,"ogTitle":1269,"ogDescription":1270,"noIndex":6,"ogImage":1271,"ogUrl":1272,"ogSiteName":673,"ogType":674,"canonicalUrls":1272,"schema":1273},"What GitLab employees like about working at GitLab","We're often asked about what it's like to work at GitLab. Every GitLab team member answers this question a little differently.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679222/Blog/Hero%20Images/2015_amsterdam_team.jpg","https://about.gitlab.com/blog/gitlab-employees-on-working-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What GitLab employees like about working at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2016-04-26\",\n      }",{"title":1269,"description":1270,"authors":1275,"heroImage":1271,"date":1277,"body":1278,"category":705,"tags":1279},[1276],"GitLab","2016-04-26","\n\nWe're often asked about what it's like to work at GitLab. Every GitLab team\nmember answers this question a little differently. But there were some\nnoticeable themes across each of their answers. We've highlighted some of\nthose key themes that making working at GitLab great.\n\n\u003C!--more-->\n\n## Gathering Feedback from our Team\n\nWe pay close attention to what our employees like and don’t like about\nworking at GitLab. To get insight from the team, we send out an anonymous\nsurvey to all GitLab team-members on a regular basis. The goal of the survey\nis to facilitate an open environment for people to share their thoughts,\nask questions, or raise potential concerns. Feedback, even if it is only\nmentioned by one employee, is acknowledged and addressed. Most often, the\nfeedback captured in the survey is addressed in our [Team Call](/handbook/communication/#team-call).\n\n## Five key themes\n\nFive key themes consistently came out as we got feedback from the team.\n\n**The people.** Our team members have described each other with words like talented,\ncaring, approachable, honest, frank, smart, brilliant, and skilled.\n\n**The product.** One of our team members summed it up nicely when she said,\n“It’s great working on a product that I actually love to use.”\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">I must say, working in the open full time on OSS (in Ruby even!) \u003Ca href=\"https://twitter.com/gitlab\">@gitlab\u003C/a> is a very nice and welcome change. Great team and product.\u003C/p>— Josh Frye (@joshfng) \u003Ca href=\"https://twitter.com/joshfng/status/687994632454672385\">January 15, 2016\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n**Open source values.** Being involved in an open source project is motivating,\nbecause it’s not just a category, it’s a philosophy. Or to put it in the words of\nan anonymous team member, “working on open-source while getting paid for it is a dream job!”\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Things that I love about working at \u003Ca href=\"https://twitter.com/gitlab\">@gitlab\u003C/a>: Getting in touch with the OSS community. Awesome experience so far.\u003C/p>— A. Felipe Cabargas (@juanpintoduran) \u003Ca href=\"https://twitter.com/juanpintoduran/status/713573732829249536\">March 26, 2016\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n**Freedom.** On this theme, it's important to note that GitLab is a remote-only company,\nmeaning our employees are dispersed across the world. A lot of personal independence comes\nwith working fully remote, and the people who are drawn to GitLab tend to appreciate that.\nHere's a glimpse into our remote-only work culture.\n\n\u003Ciframe width=\"854\" height=\"480\" src=\"https://www.youtube.com/embed/NoFLJLJ7abE\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\nAnd last, but certainly not least, the opportunity.\n\n**Opportunity.** There is a great opportunity to learn from the people around you.\nGitLab has a large community of teachers and learners helping each other.\nSome of these people exist within our company and others are people who contribute their\nideas and knowledge to GitLab. Additionally, the fact that the company is growing presents\nan opportunity for team members to expand their skillset into new areas or grow to take\non a leadership role in their existing functional expertise. One GitLab team-member\nsaid, \"you have the ability to take on multiple hats and responsibilities, [and] everyone\nand everything is open to constant improvement.”\n\nHere’s a [more detailed presentation](https://docs.google.com/presentation/d/1h9P8Vf_6fzPbLCCahvwtIF5j_cH54zsv9iRSseVZzl0/edit#slide=id.gd443388ea_2_173) on what our team likes and dislikes, including what\nthe challenges and problems are, and how we’re dealing with them. We’re proud of the fact that\nour employees are pretty happy and we're committed to maintaining that! Perhaps, we'll\neven see more GitLab team-members setting up branded home offices\nlike our Service Engineer, [Drew Blessing](https://twitter.com/drewblessing).\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">.\u003Ca href=\"https://twitter.com/gitlab\">@GitLab\u003C/a> is hiring! Work wherever you're most comfortable...even your own GitLab-branded home office \u003Ca href=\"https://twitter.com/hashtag/remotework?src=hash\">#remotework\u003C/a> \u003Ca href=\"https://t.co/VMEhBui0Yh\">pic.twitter.com/VMEhBui0Yh\u003C/a>\u003C/p>— Drew Blessing (@drewblessing) \u003Ca href=\"https://twitter.com/drewblessing/status/697510602965553156\">February 10, 2016\u003C/a>\u003C/blockquote>\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\nHave a question or a comment? As always, [give us a shout.](https://twitter.com/gitlab)\n",[9,683],{"slug":1281,"featured":6,"template":687},"gitlab-employees-on-working-at-gitlab","content:en-us:blog:gitlab-employees-on-working-at-gitlab.yml","Gitlab Employees On Working At Gitlab","en-us/blog/gitlab-employees-on-working-at-gitlab.yml","en-us/blog/gitlab-employees-on-working-at-gitlab",{"_path":1287,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1288,"content":1294,"config":1300,"_id":1302,"_type":14,"title":1303,"_source":16,"_file":1304,"_stem":1305,"_extension":19},"/en-us/blog/gitlab-for-the-non-technical",{"title":1289,"description":1290,"ogTitle":1289,"ogDescription":1290,"noIndex":6,"ogImage":1291,"ogUrl":1292,"ogSiteName":673,"ogType":674,"canonicalUrls":1292,"schema":1293},"GitLab 101 – a primer for the non-technical","If a set-in-her-ways English major can conquer the GitLab product and culture, you can too. Here’s what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678544/Blog/Hero%20Images/gitlab101.jpg","https://about.gitlab.com/blog/gitlab-for-the-non-technical","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 101 – a primer for the non-technical\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2019-08-02\",\n      }",{"title":1289,"description":1290,"authors":1295,"heroImage":1291,"date":1296,"body":1297,"category":705,"tags":1298},[678],"2019-08-02","\nI am living proof it’s possible to work at GitLab and not be particularly technical, or even particularly quick about learning technical things. Three months ago I joined the company having never used the tool and with no idea what a merge request or an issue was. I’d never touched Git or pushed a commit, and I certainly had never owned a laptop with Docker on it.\n\nIf you’re like me, fear not. Here’s everything you need to know to jump right in.\n\n## It’s an issue\n\nLet’s start with the thing that confused me the most in the first weeks – issues. An [issue](/handbook/communication/#issues) is something you create if you want to start an initiative, or simply keep track of an idea. Derived from the software development space (obviously), it’s like the starting point in any work-related conversation. Have a great idea for a new GitLab feature? Open an issue. Have an idea for a marketing campaign? Start an issue. Anyone can chime in on your issue and it becomes a place to not only have a conversation but also to keep track of the conversation. At GitLab we call all that “chiming in” collaboration. [Collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) is central to the company’s culture and our mission [“everyone can contribute.”](/blog/how-do-you-contribute/) Issues are sort of the file folders we store all that collaboration in. (And, because you might hear this term and wonder about it, as I did...an [“epic”](https://docs.gitlab.com/ee/user/group/epics/) is a collection of related issues, sort of how a filing cabinet holds file folders, to use a very old school analogy.)\n\n## Lanes merge ahead\n\nA [merge request](/handbook/communication/#start-with-a-merge-request) is a formalized way to request something (usually in the [GitLab handbook](/handbook/) or [blog](/blog/)) be created or changed. Creating a merge request triggers GitLab.com to rebuild the entire website (which is both cool and sort of scary the first few times you do it). When you submit a merge request you’ll get a message that says the pipeline is running, meaning the process of rebuilding the entire website has begun. That’s not a small undertaking, so it can take 15 minutes, or more, for your merge request to go through. If it does go through, you’ll get a message that says “passed with warnings!” Ignore the “warnings” – builds always pass with warnings. These warnings are usually not relevant if you're not contributing code. The key thing is it passed. (Speaking from personal experience, refreshing the page or simply staring at the “pipeline running” message doesn’t actually make it go faster.)\n\nNotice the term is merge *request.* That means once it’s passed you’ll need to ask someone who has magical merging powers to actually merge it (usually your manager). You do that by assigning the request to them (top right of the MR form) and leaving them a comment asking them to do so.\n\n## All aboard\n\nYou’ll get a big [onboarding](/handbook/people-group/general-onboarding/) issue on day one. Do not panic. Take your time. And realize that some of what you’re doing will only make sense in a month, or even a few months (like all that time I spent downloading Git).\n\nMost of the onboarding tasks are very straightforward and helpful. But ultimately you’ll have to add yourself to the [team page](/company/team/), creating your first merge request in the process. Anything involving the team page can be very tricky because it is based on `.yml` files (cranky, touchy things that are pronounced a little like the vegetable, “yaml”) so do not be afraid to ask for help. The #mr-buddies, #git-help, or #questions channels in Slack can be great resources. You’ll want to remember to use “command F” to search through the hundreds of files on the team page to find your entry.\n\nDon’t worry – no matter how much of a struggle it is to add yourself to the team page, you’re unlikely to actually “break” anything on [about.gitlab.com](/). (I’ll freely admit it took me *several days* to accomplish this one task… )\n\n## Communication\n\nIn an all-remote company, communication is vital. But *how* to communicate at GitLab doesn’t necessarily come naturally to someone like me who came from an email and phone call culture. Our communication methods are [spelled out in the handbook](/handbook/communication/#introduction), but here’s the quick version: You want to communicate primarily within GitLab. That means within an issue – tag someone with their GitLab “handle” (@vsilverthorne as an example) – in the discussion box. Or the same thing can happen in a merge request. Whoever you tag will get a notification in their To-do list on GitLab, and may also be notified via email. But speaking as someone who’s been pointed in the right direction after using Slack or email instead of GitLab, trust me when I say _within_ GitLab is the first and best way to communicate.\n\nIf it’s urgent, [Slack](/handbook/communication/#slack) can be a good choice. Slack is also a great place to ask questions, chit-chat with colleagues and/or share common interests. GitLab has lots of groups on Slack for everything from crafty people to gardeners. Email is the last choice because much of the company checks it only occasionally.\n\n## Meetup IRL or virtually\n\nThe [video call on Zoom](/handbook/communication/#video-calls) is another key GitLab practice and although I was a little skeptical it could be more effective than a phone call, I’m now a convert. Not only do you get to know people better because you can see them, the ability to screen share is invaluable, particularly when you’re learning something new. I never feel “camera ready” though, so if you feel that way, you’re far from alone. Luckily, there is a function on Zoom called \"Touch up my appearance.\" It's like FaceTune for the workplace instead of Instagram. Just go into Zoom>Preferences>Video and under My Video check \"Touch up my appearance.\" This way your dark circles won't be making an appearance in the latest video on [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A).\n\nIf meetups are possible in real life, I’d suggest those too. At an all-remote company you do have to put time and energy into feeling like you’re part of the team.\n\nAre there other challenges you’ve encountered when you were brand new to GitLab that would have been helped by a clearer or more detailed explanation? Let us know and we’ll update this blog post (and the handbook).\n\nCover image by [Charlotte Karlsen](https://unsplash.com/@charlottemsk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[683,1299,9],"git",{"slug":1301,"featured":6,"template":687},"gitlab-for-the-non-technical","content:en-us:blog:gitlab-for-the-non-technical.yml","Gitlab For The Non Technical","en-us/blog/gitlab-for-the-non-technical.yml","en-us/blog/gitlab-for-the-non-technical",{"_path":1307,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1308,"content":1313,"config":1318,"_id":1320,"_type":14,"title":1321,"_source":16,"_file":1322,"_stem":1323,"_extension":19},"/en-us/blog/gitlab-mental-health-awareness-week-recap",{"title":1309,"description":1310,"ogTitle":1309,"ogDescription":1310,"noIndex":6,"ogImage":827,"ogUrl":1311,"ogSiteName":673,"ogType":674,"canonicalUrls":1311,"schema":1312},"GitLab Mental Health Awareness Week Recap","A recap of the Learning and Development Mental Health Awareness week","https://about.gitlab.com/blog/gitlab-mental-health-awareness-week-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Mental Health Awareness Week Recap\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Samantha Lee\"}],\n        \"datePublished\": \"2020-12-21\",\n      }",{"title":1309,"description":1310,"authors":1314,"heroImage":827,"date":1315,"body":1316,"category":729,"tags":1317},[1015],"2020-12-21","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\nAs an [all-remote](https://about.gitlab.com/company/culture/all-remote/guide/#why-remote) company, the GitLab team is distributed across the globe. Our team is used to working online, scheduling Zoom social hours, and using asynchronous communication strategies.\n\nEven with all these work from home skills in our back pockets, 2020 has been a challenge. Over the year, we've adapted to new work environments, taken on new roles within our families and communities, and found new and creative ways to connect from a distance. It's been chaotic and it has taken a toll on our mental health.\n\nOver the last few months, the [Learning and Development (L&D) team at GitLab](https://about.gitlab.com/handbook/people-group/learning-and-development/\n) heard team members express feelings of burnout. Personally, in [coffee chats](https://about.gitlab.com/company/culture/all-remote/informal-communication/#coffee-chats) and slack conversations, I heard team members speak of feeling exhausted and overwhelmed. The combination of maintaining a regular work schedule, caring for family, and finding time to relax and recharge, all while living through a global pandemic, is taking its toll.\n\nI could relate. I was feeling this overwhelm, too.\n\nIn response to these conversations, the L&D team launched an asynchronous [internal learning campaign](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#internal-learning-campaigns) for the GitLab team with the goal of increasing awareness of, and access to, existing [mental health](https://about.gitlab.com/company/culture/all-remote/mental-health/\n) resources at GitLab. This was a new [learning initiative](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#learning-initiatives-introduction) for the team, leveraging GitLab issues, Slack reminders, polls, and a [learning speaker series](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#learning-speaker-series-overview) to engage and educate team members.\n\nTake a few minutes to read the rest of this post to learn about the intentions behind the initiative, major takeaways, and what we're doing moving forward to continue the conversation.\n\n## Why participate asynchronously?\n\n[Asynchronous communication](https://about.gitlab.com/company/culture/all-remote/asynchronous/) gives team members the opportunity to work [efficiently](https://handbook.gitlab.com/handbook/values/#efficiency), [collaborate](https://handbook.gitlab.com/handbook/values/#collaboration), and put [friends and family first](https://handbook.gitlab.com/handbook/values/#family-and-friends-first-work-second). \n\nWhen it comes to engaging learning content, applying asynchronous strategies can be challenging. Many learners are used to learning in collaborative, co-located groups or calls. The GitLab L&D team is always exploring and experimenting with new ways to make asynchronous learning just as engaging as synchronous learning. With this campaign, we used [GitLab issues](https://gitlab.com/gitlab-com/people-group/learning-development/challenges/-/boards), Slack, the [Polly app](https://www.polly.ai/), and Zoom to deliver information and host discussion.\n\nThis awareness campaign needed to be designed with as many asynchronous elements as possible to\n\n1. Make content accessible and consumable for all team members, regardless of their time zone or location\n1. Avoid creating additional overwhelm for participants related to attending synchronous calls, and instead let team members review content on their own time\n1. Document content for future self-paced learning paths\n\nIn addition to making this awareness campaign asynchronous, all participation was optional. Discussing mental health and [burnout](https://about.gitlab.com/blog/preventing-burnout/) can be challenging and uncomfortable. We wanted to allow space to discuss burnout only when team members felt comfortable and ready.\n\n\n## So, how'd it go!\n\nA few great wins from the week:\n\nFirst, we collaboratively stood up our [mental health tool stack](https://about.gitlab.com/company/culture/all-remote/mental-health/#mental-health-tool-stack) as part of our [day 2 issue](https://gitlab.com/gitlab-com/people-group/learning-development/challenges/-/issues/35). Team members were asked to open an MR and contribute tools they use to manage burnout. Together we collected 12 resources. If you have one to add, please [contribute!](https://about.gitlab.com/community/contribute/)\n\nSecond, we created, tested, and documented a new learning initiative, [internal learning campaigns!](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#internal-learning-campaigns). The L&D team is exploring new ways to deliver bite-sized learning, and this is one we will try again in the future.\n\nAnd finally, we hosted a fantastic [live speaker series with John Fitch](https://www.youtube.com/watch?v=BDvpoouM-us&feature=emb_logo), author of the book [Time Off](https://www.timeoffbook.com/). Team members asked questions about how to take meaningful time off, how to return from PTO, and how managers can encourage team members to take time off. Approximately 100 team members attended synchronously, and many watched the recorded replay.\n\nA little more about John - he's the co-author of the international bestseller [Time Off: A Practical Guide to Building Your Rest Ethic and Finding Success Without the Stress](https://www.timeoffbook.com/), a book that expands our value of time off, and how our rest and leisure are as important as our work. John is a recovering workaholic who wrote this book for a former version of himself. He cares deeply about the future of work and is optimistic that everyone has the opportunity to join the creative class in the near future. John is now building tools for helping people and teams design their rest ethic and manage their time off more effectively. He would love to hear from you if you are passionate about intentional time off.\n\nWatch the replay of our live speaker series below!\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/BDvpoouM-us\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n\n## What didn't go so well?\n\nOne of the goals for the week was to increase the number of team members who answered 'Yes' to the following question: 'I know where and how to access resources to manage my mental health at GitLab'. Based on the Polly polls we shared in our #what's-happening-at-GitLab Slack channel, we saw a 3% increase in the number of team members who answered 'Yes', increasing from 73% to 76%\n\nHere are some screenshots of the poll data:\n\nOur initial poll data, collecting information _before_ the awareness week:\n\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/pre-poll-results.jpg){: .shadow}\n\n\nAnd our final poll data, collecting information _after_ the awareness week:\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/post-poll-results.jpg){: .shadow}\n\n\nWhile this shows a slight increase, it's not enough, and the L&D team recognizes we need to do more as a company to communicate this information more widely and empower team members to use the available resources. A few issues we noticed with this data collection:\n\n1. We aren't sure if the people who took the first poll also took the second poll since the poll is anonymous\n1. We also aren't sure if the people who took either poll particiapted in any or all of the awareness week content. Since participation was completion optional, we didn't track who decided to get involved\n1. Fewer people responded to the final poll than the initial poll\n\n\n## Now what?\n\nThe role of Learning & Development at GitLab has evolved during Covid-19 to include more support for mental health and wellbeing of our team members. Looking  after team members wellness is no longer a passing priority. The increasing pace of monumental change and stress indicates otherwise. The pandemic is a marathon, not a sprint, and our role as learning leaders is equipping our team members with a set of tools to build resilience, manage through change, and take care of their mental health.\n\nThis internal awareness campaign was just the start of a series of learning opportunities the L&D team is creating for team members to explore their mental health and learn strategies for managing burnout. We're working on [new mental health and burnout management inititiaves](https://gitlab.com/groups/gitlab-com/people-group/learning-development/-/epics/24) for 2021 to continue this conversation beyond this awareness campaign.\n\nWe're also working on creating a self-paced learning path through this awareness campaign content, so that team members who missed the content, future team members, and our wider community can review the material. Follow the updates from our new GitLab Learn platform to find out when this learning path will be available.\n\nIn the meantime, we encourage you to check out the content from the week shared via GitLab issues!\n\n\n| Issue Link | Content |\n|",[731,683,9],{"slug":1319,"featured":6,"template":687},"gitlab-mental-health-awareness-week-recap","content:en-us:blog:gitlab-mental-health-awareness-week-recap.yml","Gitlab Mental Health Awareness Week Recap","en-us/blog/gitlab-mental-health-awareness-week-recap.yml","en-us/blog/gitlab-mental-health-awareness-week-recap",{"_path":1325,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1326,"content":1332,"config":1339,"_id":1341,"_type":14,"title":1342,"_source":16,"_file":1343,"_stem":1344,"_extension":19},"/en-us/blog/gitlab-summit-cape-town-recap",{"title":1327,"description":1328,"ogTitle":1327,"ogDescription":1328,"noIndex":6,"ogImage":1329,"ogUrl":1330,"ogSiteName":673,"ogType":674,"canonicalUrls":1330,"schema":1331},"Salani kakuhle (bye!) and thanks for a great summit in Cape Town!","And just like that, it was all over. Check out the highlights and keynote from our recent summit in South Africa.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670482/Blog/Hero%20Images/summit_recap_pic_post.jpg","https://about.gitlab.com/blog/gitlab-summit-cape-town-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Salani kakuhle (bye!) and thanks for a great summit in Cape Town!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daisy Miclat\"},{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2018-09-14\",\n      }",{"title":1327,"description":1328,"authors":1333,"heroImage":1329,"date":1336,"body":1337,"category":299,"tags":1338},[1334,1335],"Daisy Miclat","Rebecca Dodd","2018-09-14","\n\nFrom August 23-29, 350 GitLab team-members, significant others, community members, and customers descended on Cape Town, South Africa to get to know one another IRL at our sixth [summit](/events/gitlab-contribute/). As an all-remote company, it’s not often we’re all in one place, so we get together every nine months to hang out, bond, take in the local sights, and even get a little work done.\n\n## Highlights\n\n### Keynote\n\nAfter getting settled in and, for many, powering through some brutal jetlag, we gathered for the opening keynote with Chief Culture Officer [Barbie Brewer](/company/team/#BarbieJBrewer), Chief Revenue Officer [Michael McBride](/company/team/#mmcb), Head of Product [Mark Pundsack](/company/team/#MarkPundsack), and CEO and co-founder, [Sid Sijbrandij](/company/team/#sytses), which you can watch below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4BIsON95fl8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Challenge\n\nIt’s become [tradition at our summits for Sid to throw down the gauntlet with a few challenges](/blog/gitlab-summit-greece-recap/#summit-challenges), and this year’s was no different:\n\n![Cape Town summit challenges](https://about.gitlab.com/images/blogimages/summit2018/summit-challenge-slide.png){: .shadow.medium.center}\n\nAnd, as with previous summits, we were promised to be rewarded richly for meeting the challenges:\n\n![Cape Town summit challenges reward](https://about.gitlab.com/images/blogimages/summit2018/summit-challenge-win.png){: .shadow.medium.center}\n\nIt's also become tradition that we hit it out of the park 😎 We're happy to report that we were successful in challenges! Greg Brewer was convinced and is #movingtogitlab, and we've [added the ability to request a free instance check](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6995).\n\n### Excursions\n\nThe summits also give us an amazing opportunity to get to know the area that we’re visiting. We were able to choose from some phenomenal excursions throughout Cape Town to learn more about the culture and history of what locals affectionately call the Mother City.\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-5\" class=\"carousel slide medium center\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"1\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"2\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n          \u003Cimg src=\"/images/blogimages/summit2018/cape-of-good-hope.jpeg\" alt=\"Cape of Good Hope\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/summit2018/lanzerac-wine-tour.jpg\" alt=\"Lanzerac wine tour\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/summit2018/robben-island.jpg\" alt=\"Robben Island\">\n    \u003C/div>\n\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\n\n#### Boulders Beach and the Cape of Good Hope\n\nA beautiful tour along the coast and the opportunity to say hello to our furry friends, our first stop on this excursion was Boulders Beach, where we saw cute African Penguins waddling around, taking swims, and hanging out. They weren’t fazed by us humans. If anything they enjoyed the attention! Up next, we drove to the southernmost tip of Africa, through breathtaking, untouched terrain. Along the way, we spotted local wildlife including antelopes, ostriches, and a couple of feisty baboons.\n\n#### Robben Island\n\nA somewhat choppy 20-minute ferry ride from Victoria Wharf, [Robben Island](http://www.robben-island.org.za/) is home to the prison where political activist and South Africa's first democratic president Nelson Mandela was imprisoned for 18 years. Our tour guide was a former prisoner himself, and he shared his experiences and the history of Robben Island. Although it was a somber setting, we were able to learn more about the history of South Africa and how inequality existed not too long ago.\n\n#### Cape winelands\n\nThe Western Cape is home to some spectacular wine estates. Some GitLab team-members visited [Groot Constantia](https://www.grootconstantia.co.za/), the oldest wine-producing estate in the country, while others ventured further to Paarl, Franschhoek and Stellenbosch for a leisurely day of vineyard hopping and tasting. Those of us checking baggage loaded up on the good stuff to take home.\n\n#### City and cultural tour\n\nA tour of the city center included visits to the [District Six Museum](http://www.districtsix.co.za/), [Castle of Good Hope](https://castleofgoodhope.co.za/), and the [Slave Lodge](https://www.iziko.org.za/museums/slave-lodge), stopping off at the V&A Waterfront for lunch. Some persuasive GitLab team-members got the tour guide to agree to a diversion to quirky coffee shop and Capetonian institution, [Truth Café](https://truth.coffee/pages/truth-cafe), to soak up some of the city's coffee culture.\n\n#### Tour of Langa\n\nSome GitLab team-members also visited Langa, the oldest township in Cape Town. After being greeted by the locals at the cultural center, they shared their dance, music, and history. Some of us were even able to participate and beat on the drums or do a little dancing! Our tour guide shared the history of the township: its beginnings during Apartheid, how things are today, and where they are striving to rebuild unity within the community. Our tour ended with a lovely dance performance and goodbyes from the locals.\n\n### UGC sessions\n\nOur summit UGC (user-generated content) sessions are an opportunity for anyone attending to raise a subject for discussion or run a workshop. With topics as diverse as \"Kubernetes 101,\" \"Learn to Yo-Yo for fun and profit,\" \"How to be a great public speaker,\" \"Yoga/body balance,\" and \"Cocktail making class,\" there's always something for everyone, and it's up to individuals to decide how formal or off-the-cuff they want their session to be.\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-4\" class=\"carousel slide medium center\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-4\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-4\" data-slide-to=\"1\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n      \u003Cimg src=\"/images/blogimages/summit2018/yoga-ugc.jpg\" alt=\"Yoga and body balance session\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/summit2018/for-funs-sake-ugc.jpg\" alt=\"Pinpoint pain points in GitLab session\">\n    \u003C/div>\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-4\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-4\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\nAs we grow, the summit grows with us. Now, our formidable resident summit expert [Kirsten](/company/team/#kirstenabma) is focusing on planning our summits FULL TIME. As we closed out our Cape Town gathering, she announced to wild cheers that our next one will be going down in May 2019, in New Orleans, LA, USA! Bring on the beignets!\n\nSee you next time 🇿🇦\n",[707,277,9,683],{"slug":1340,"featured":6,"template":687},"gitlab-summit-cape-town-recap","content:en-us:blog:gitlab-summit-cape-town-recap.yml","Gitlab Summit Cape Town Recap","en-us/blog/gitlab-summit-cape-town-recap.yml","en-us/blog/gitlab-summit-cape-town-recap",{"_path":1346,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1347,"content":1353,"config":1359,"_id":1361,"_type":14,"title":1362,"_source":16,"_file":1363,"_stem":1364,"_extension":19},"/en-us/blog/gitlab-summit-greece-recap",{"title":1348,"description":1349,"ogTitle":1348,"ogDescription":1349,"noIndex":6,"ogImage":1350,"ogUrl":1351,"ogSiteName":673,"ogType":674,"canonicalUrls":1351,"schema":1352},"αντίο (Goodbye) and thanks for a great GitLab summit – Crete edition","That's a wrap! Check out the keynote from our summit in Greece below.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671644/Blog/Hero%20Images/gitlab-summit-crete.jpg","https://about.gitlab.com/blog/gitlab-summit-greece-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"αντίο (Goodbye) and thanks for a great GitLab summit – Crete edition\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2017-10-25\",\n      }",{"title":1348,"description":1349,"authors":1354,"heroImage":1350,"date":1356,"body":1357,"category":299,"tags":1358},[1355],"Erica Lindberg","2017-10-25","\n\nFor the past week, around 250 GitLab team-members and significant others gathered in Crete, Greece\nto achieve one simple goal: **get to know each other!** As a remote-only company, we\ndon't often meet face to face, so our [summits](/events/gitlab-contribute/) are an extraordinary occasion. This year, in the spirit of \"everyone can contribute,\" we tried something new.\nWe decided to live stream from 9am to 9pm in an effort to bring the summit experience\ndirectly to you, wherever you are.\n\n\u003C!-- more -->\n\n## Highlights\n\nOver the course of the week, we accomplished a lot! Team members from over 30\ndifferent countries had the chance to work creatively with people outside of their\ncore team during the Amazing Race, mingle on the beautiful island of Santorini,\nand explore the ancient ruins of the Knossos Palace.\n\n### Summit challenges\n\n[In keeping with tradition from past summits](https://www.youtube.com/watch?time_continue=1&v=39chczWRKws),\nSid also had a couple of work-related challenges for the team. If we completed the challenges\nby the end of the week, he would perform a GitLab song.\n\n![summit challenges slide](https://about.gitlab.com/images/blogimages/summit-challenges-slide.jpg)\n\nWe managed to complete all of our challenges and at the closing Toga Party, Sid and Karen delighted us with a GitLab song to the tune\nof *[I'm Gonna Be (500 Miles)](https://www.youtube.com/watch?v=tbNlMtqrYS0)* \u003Ci class=\"fas fa-microphone\" aria-hidden=\"true\">\u003C/i>\n\nAnd the best part is that we were able to share this in real time with contributors from around the world. It was our vision to make the summit `read-write`, so that even if you weren't with us in Greece, you could\nstill participate and contribute. Thanks to everyone who joined in, sent in questions and comments, and for a while made the planet feel a little smaller.\n\n### Keynote with CEO Sid Sijbrandij\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/AopRnEbvgzE?start=3925\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\n#### Keynote slides\n\n\u003Ciframe src=\"https://docs.google.com/presentation/d/e/2PACX-1vQA5srWjTIMmNHR3vWITDXlHj3iBSwxaTVLc_haoDZoBiH6XnGn_JdbR11A1YVOBd_mdcMZnxG_5yDS/embed?start=false&loop=false&delayms=3000\" frameborder=\"0\" width=\"1280\" height=\"749\" allowfullscreen=\"true\" mozallowfullscreen=\"true\" webkitallowfullscreen=\"true\">\u003C/iframe>\n\nThanks everyone for participating! See you next time 😎\n",[9,683],{"slug":1360,"featured":6,"template":687},"gitlab-summit-greece-recap","content:en-us:blog:gitlab-summit-greece-recap.yml","Gitlab Summit Greece Recap","en-us/blog/gitlab-summit-greece-recap.yml","en-us/blog/gitlab-summit-greece-recap",{"_path":1366,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1367,"content":1373,"config":1381,"_id":1383,"_type":14,"title":1384,"_source":16,"_file":1385,"_stem":1386,"_extension":19},"/en-us/blog/gitlab-taught-in-korean-uni",{"title":1368,"description":1369,"ogTitle":1368,"ogDescription":1369,"noIndex":6,"ogImage":1370,"ogUrl":1371,"ogSiteName":673,"ogType":674,"canonicalUrls":1371,"schema":1372},"Schooled in GitLab: Teaching our handbook at a South Korean university","Students at Hankuk University of Foreign Studies tackled our handbook. The students' favorite topics were compensation and remote work.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673044/Blog/Hero%20Images/books-internship-post.jpg","https://about.gitlab.com/blog/gitlab-taught-in-korean-uni","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Schooled in GitLab: Teaching our handbook at a South Korean university\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Guenjun Yoo\"}],\n        \"datePublished\": \"2020-01-29\",\n      }",{"title":1368,"description":1369,"authors":1374,"heroImage":1370,"date":1376,"body":1377,"category":1378,"tags":1379},[1375],"Guenjun Yoo","2020-01-29","\nBusiness students at [Hankuk University of Foreign Studies](http://mis.hufs.ac.kr/) in Seoul, South Korea are studying the GitLab handbook and business model. The students are enthusiastic about GitLab and its story, says lecturer SanJoon Song in an email interview, but there was one problem: Our 3,000+ page handbook is a lot to swallow in one semester.\n\nSo Song had the class divide the handbook into 15 different categories, which different groups of students researched over the course of the semester. At the end of the term, the groups presented a summary of their category to the class.\n\n“Many engineers in Korea said that the GitLab handbook is good to read before starting up a business,” says Song. “However, there is a lot of reading in the handbook; too many pages for me.”\n\nThe level of transparency in the handbook was a revelation to Song and his students.\n\n“We didn't study [the handbook] only to focus on the content itself, but we tried to understand and share about the context of handbook; what conventions GitLab has and what protocols GitLab is trying to develop with its employees by this handbook,” says Song. “In Korea, this is very unusual to share such details of company goals and protocols with entire employees by handbook and for me, this approach is very new and fresh.”\n\n## Inside information\n\nSong was very surprised by how much “insider” information is available in our handbook and says he’s particularly amazed by the detailed explanations of what to do if things go wrong.\n\nOn the other hand, his students were most impressed by the details on [compensation](/handbook/total-rewards/compensation/compensation-calculator/calculator/) and incentives in the handbook, followed closely by the idea of remote work.\n\n“Personally I liked the concept of [‘accept mistakes’](https://handbook.gitlab.com/handbook/values/#accept-mistakes) in the efficiency section,” says Song. “We also talked a lot about GitLab’s [six values](https://handbook.gitlab.com/handbook/values/).”\n\n![Breaking down the handbook](https://about.gitlab.com/images/blogimages/studyingthehandbook.jpg){: .shadow.medium.center}\nStudents in Song's class breaking down the handbook.\n{: .note.text-center}\n\nRemote work was also a big topic of discussion in Song's classroom.\n\n\"Many Koreans are interested in remote work,\" says Song. \"It is really great that people can work anywhere, anytime without having the stress of commuting. Remote work is not common in Korea yet. Only a few software developers are allowed to work from home but that is also partial and in a limited environment only. Many students also want to do the remote work but this is still kind of a dream.”\n\nSong is currently teaching a second GitLab-focused class, this time diving into project management and DevOps by looking at our product and Pivotal Labs. If there is one benefit Song thinks his students have taken away from studying GitLab it’s the importance of communication.\n\n“Communication between employees is one of the most important matters,\" says Song. \"By studying the GitLab handbook, my students and I learned an efficient way of communication between the employer and employees. The handbook explicitly shows how GitLab is trying to do the best way of communication between stakeholders; what is the company goal, why we established the goal and how we are achieving the goal.”\n\nSong hopes to inspire a future generation of entrepreneurs by studying the GitLab handbook in the classroom.\n\n“My students have studied the GitLab handbook for one semester. I hope this study can be their reference when they start their startup, so they can create their company goals and prototype in the direction of success, like GitLab.\"\n\n_If you’re interested in seeing more of Song’s curriculum, he shared it\n[here](https://docs.google.com/document/d/1u5J6Ypj6zwQJVjmrl1wd0eIv7Q_TYLJysDquhGMJimA/edit). You'll need to scroll down a bit._\n\nCover image by [Patrick Tomasso](https://unsplash.com/@impatrickt) on [Unsplash](https://unsplash.com/)\n{: .note}\n","open-source",[708,267,1259,1380,9,684],"open source",{"slug":1382,"featured":6,"template":687},"gitlab-taught-in-korean-uni","content:en-us:blog:gitlab-taught-in-korean-uni.yml","Gitlab Taught In Korean Uni","en-us/blog/gitlab-taught-in-korean-uni.yml","en-us/blog/gitlab-taught-in-korean-uni",{"_path":1388,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1389,"content":1395,"config":1401,"_id":1403,"_type":14,"title":1404,"_source":16,"_file":1405,"_stem":1406,"_extension":19},"/en-us/blog/gitlabs-global-compensation-calculator-the-next-iteration",{"title":1390,"description":1391,"ogTitle":1390,"ogDescription":1391,"noIndex":6,"ogImage":1392,"ogUrl":1393,"ogSiteName":673,"ogType":674,"canonicalUrls":1393,"schema":1394},"GitLab’s Global Compensation Calculator: The next iteration","We released a new version of our Compensation Calculator in January – here’s what that means for new and existing GitLab team-members.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667966/Blog/Hero%20Images/global-compensation-calculator-iteration.jpg","https://about.gitlab.com/blog/gitlabs-global-compensation-calculator-the-next-iteration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab’s Global Compensation Calculator: The next iteration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brittany Rohde\"}],\n        \"datePublished\": \"2018-03-23\",\n      }",{"title":1390,"description":1391,"authors":1396,"heroImage":1392,"date":1398,"body":1399,"category":299,"tags":1400},[1397],"Brittany Rohde","2018-03-23","\n\nWe know many of you have thoughts about our [Compensation Calculator](/handbook/total-rewards/compensation/compensation-calculator/#the-compensation-calculator)! We see your comments on Hacker News; we are listening and continually working on improving it. In line with our value of [iteration](https://handbook.gitlab.com/handbook/values/#iteration), we have made additional changes to our Compensation Calculator. In January 2018, we released a new version to align the calculator closer to market rates, and adjust all current team members’ pay to be in line with the outputs of the iterated version. Here’s how it works.\n\n \u003C!-- more -->\n\n## What is our new formula?\n\nYour compensation = [SF benchmark](#sf-benchmark) x (0.7 x (max (0.2, [Rent Index](#rent-index) + [Hot Market Adjustment](#hot-market-adjustment)) / 1.26) + 0.30) x [Level Factor](#level-factor) x [Experience Factor](#experience-factor) x [Contract Type Factor](#contract-type-factor) x [Country Factor](#country-factor)\n\n### SF benchmark\n\nThis is the employee salary at the 50th percentile for the role in San Francisco (SF), which we determine using various sources of market data including [Comptryx](http://www.comptryx.com/).\n\n### Rent Index\n\nThis is taken from [Numbeo](https://www.numbeo.com/cost-of-living/), which expresses the ratio of cost of rent in many metro areas. Since we are using San Francisco benchmarks, we divide by 1.26 to normalize the rent index to San Francisco. A minimum Rent Index of 0.2 is applied so no one is paid less than 41 percent of San Francisco's market.\n\nWe multiply the Rent Index by 0.7 and then add 0.3, so the sum would equal 1 (i.e. we pay San Francisco rates in San Francisco).\n\n### Hot Market Adjustment\n\nThis is an adjustment to any US-based metro area where the geographical area Rent Index is less than the Hot Market Adjustment plus the Numbeo Rent Index, to recognize that \"hot markets\" tend to have a Rent Index that is trailing (i.e. lower than) what one would expect based on compensation rates in the area.\n\n### Level Factor\n\nThis is currently defined as junior (0.8), intermediate (1.0), senior (1.2), staff (1.4), or manager (1.4), and will be defined as II (.8), III (1.0), Senior (1.2), Staff (1.4), or manager (1.4).\n\n### Experience Factor\n\nThis falls between 0.8 - 1.2 based on our [Experience Factor Guidelines](/handbook/total-rewards/compensation/compensation-calculator/#level-factor):\n\n- 0.8: New to the position requirements\n- 0.9: Learning the position requirements\n- 1: Comfortable with the requirements\n- 1.1: Thriving with the requirements\n- 1.2: Expert in the requirements\n\n### Country Factor\n\nThis is a ratio of the calculator to market data. We [determine this ratio](/handbook/total-rewards/compensation/compensation-calculator/#location-factor) by looking at how our calculator aligns to market in the region. If the calculator comes in higher than market, a factor lower than 1 is applied. If the calculator is in line with market, the factor stays at 1.\n\n### Contract Type Factor\n\nThis distinguishes between employee (1) or contractor (1.17). A contractor may carry the costs of their own health insurance, social security taxes, etc, leading to a 17 percent higher compensation for the contractor to account for the extra expenses to these GitLab team-members.\n\nThe calculator can be found on each position description. For example, take a look at our [Compensation Calculator for Developers](https://handbook.gitlab.com/job-families/engineering/backend-engineer/?area=San-Francisco_California&country=United-States&experience=0&level=Intermediate&low=96160&high=144240#compensation).\n\n## Using San Francisco Market Data\n\nThe first step in this iteration was to gather market data and incorporate it as the benchmarks for each role. After obtaining a global data set to map to our positions, we needed to decide if New York was still the right city to pivot the benchmarks around. After some analysis, we determined that San Francisco was a better source of data, so we adjusted the formula. We also analyzed and adjusted the parameters around rent index to ensure in San Francisco you make San Francisco's benchmark.\n\n## Instituting a Minimum Rent Index\n\nEarlier in 2017, we instituted a Geographical Areas iteration to the compensation calculator to ensure that there are not large pay differences in regions that have a similar job market. We looked at the rent indexes by [region](/handbook/total-rewards/compensation/compensation-calculator/#location-factor), determined any outliers on the high or low end of the rent index, and set the regional rent index at the highest of the remaining data set. With the January iteration of the compensation calculator, we also set a Minimum Rent Index so no one would be paid less than 41 percent of San Francisco’s market.\n\n## Adjusting our team’s pay\n\nWith this iteration of the compensation calculator, we wanted to align our team’s salaries according to market. We first looked at how experienced the team member is in their role by having the manager conduct an [Experience Factor Review](/handbook/total-rewards/compensation/compensation-calculator/#level-factor). This review verified we are paying our team in line with their experience, and not determining their experience to fit compensation. This review generates an output which is applied in the compensation calculator, but is also a great way to start the conversation around growth within each role. Managers and direct reports were able to review the experience factors and have constructive conversations around experience. Once we had all of the calculator inputs, including the up-to-date Experience Factor, our People Ops team reviewed all salaries to match the new compensation calculator. At the same time as the calculator was released, the increases to pay were also communicated.\n\n## What’s next, and why we think the compensation calculator is a powerful tool\n\nWe’ll continue to add more countries to our Country Factors list, review adding an additional factor for specialization within Development roles, review how the levels overlap when it comes to promotions, and review the Rent Indexes for countries with many data points (like the United States and United Kingdom).\n\nWe want to continue to make the calculator as reflective of market in as many locations as we can, given possible data constraints. This will go some way towards eliminating pay inequality among underrepresented groups, promote salary transparency on what each team member and candidate’s market value is, and save valuable recruiting time.\n\nWe also want to hear from you on where this calculator can continue to improve! Please let us know what you think in the comments.\n\n[Cover image](https://unsplash.com/photos/_zsL306fDck?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) by Antoine Dautry on [Unsplash](https://unsplash.com/search/photos/numbers?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,683,708],{"slug":1402,"featured":6,"template":687},"gitlabs-global-compensation-calculator-the-next-iteration","content:en-us:blog:gitlabs-global-compensation-calculator-the-next-iteration.yml","Gitlabs Global Compensation Calculator The Next Iteration","en-us/blog/gitlabs-global-compensation-calculator-the-next-iteration.yml","en-us/blog/gitlabs-global-compensation-calculator-the-next-iteration",{"_path":1408,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1409,"content":1415,"config":1420,"_id":1422,"_type":14,"title":1423,"_source":16,"_file":1424,"_stem":1425,"_extension":19},"/en-us/blog/going-remote-education-virtual-learning-tips",{"title":1410,"description":1411,"ogTitle":1410,"ogDescription":1411,"noIndex":6,"ogImage":1412,"ogUrl":1413,"ogSiteName":673,"ogType":674,"canonicalUrls":1413,"schema":1414},"Going remote in education? Don't panic.","If you're an educator moving online, we have some tips for virtual learning success.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681183/Blog/Hero%20Images/work_remote_coffee_green.jpg","https://about.gitlab.com/blog/going-remote-education-virtual-learning-tips","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Going remote in education? Don't panic.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Hupy, Ph.D.\"}],\n        \"datePublished\": \"2020-03-27\",\n      }",{"title":1410,"description":1411,"authors":1416,"heroImage":1412,"date":727,"body":1418,"category":705,"tags":1419},[1417],"Christina Hupy, Ph.D.","\n\nCampuses around the world in both K-12 and higher education are moving to virtual models of instruction and operation to help reduce the spread of COVID-19. As a result, many faculty, students, staff and leadership are now in the position of navigating how to work, teach, and learn remotely with little to no preparation time and even fewer resources.\n\nJumping into virtual education – voluntarily or otherwise – is not easy. Properly developing an online curriculum takes months and months of work, a coordinated tech stack, and a well-defined communication plan. Intentionally, online courses have IT staff to assist in the process of converting classes and generally only convert one at a time.\n\nAre you an educator facing a suddenly digital classroom? Are you worried about answering endless emails from panicked students? Dreading spending hours upon hours recording lectures? Wondering how you will be able to effectively communicate with all your students?\n\nAs the world’s largest all-remote company with 1,200+ employees in 65 countries, GitLab has a wealth of resources to help navigate this challenge! The GitLab [remote work emergency plan]( /company/culture/all-remote/remote-work-emergency-plan/) can be adapted to help both students and educators get up and running quickly and function effectively in this new reality.\n\nWe're excited to share a few immediately actionable tips for faculty, staff, and students who’ve been suddenly thrust out of the classroom and into a virtual education model.\n\n\n\n## Tip 1: Adopt a single source of truth\n\nWhile this term is pretty self-explanatory, it can’t be emphasized enough. When an entire company of people have to be on the same page, it is essential that everyone knows exactly what needs to happen, how it happens, and when it should happen. This same concept applies directly to an online class.\n\nImagine you need to make a change in your class agenda for a project due tomorrow – where does that update need to appear? A syllabus schedule, due dates on folders, due dates on assignments, class calendars, and of course via email, etc. Chances are, you’ll miss making the update in one of those locations. Confusion and lots of emails with questions will ensue! (see [Tip 2](#tip-2-leverage-a-transparent-communication-tool)).\n\nThe concept of a [single source of truth](https://handbook.gitlab.com/handbook/values/#single-source-of-truth) (SSoT) that serves as a living record has many benefits in a classroom setting. Students need a SSoT in order to build trust, confidence, and be successful in a course, especially when they are used to the reassurance of seeing teachers several times a week. A SSoT also minimizes the number of questions about logistics and allows you to spend more time discussing the content itself.\n\n### How to adopt a single source of truth\n\n* Identify a tool (see [Tip 2](#tip-2-leverage-a-transparent-communication-tool)) that serves as the SSoT and document all relevant information such as due dates, schedules, directions, policies, etc. in this single location.\n* Avoid the temptation to list dates and policies on multiple documents such as calendars and assignments.\n* Update the SSoT as needed. As students ask questions, add the answers to the SSoT. This approach will save you time in answering questions down the road.\n* You will need to adjust as the cadence of the course develops, especially if this is your first time teaching it online.\n* Make sure students know that they will only need to look in this one location for any changes.\n\n## Tip 2: Leverage a [transparent communication tool](/company/culture/all-remote/remote-work-emergency-plan/#establish-a-handbook)\n\nIf you are put in the situation of having to migrate to remote quickly, you probably don’t have much time to invest in a complicated setup.  Don’t worry, you can implement this tip by starting simple.\n\nFirst things first, the tool should not be email. Email is one of the most inefficient methods of communication for remote work. You and your students are better served when information is shared out in a way that everyone has the same knowledge. Reducing email’s allure will save you and your students time and energy.\n\n### [What do we recommend instead?](/company/culture/all-remote/remote-work-emergency-plan/#establish-a-handbook)\n\n* A cloud-based word processor, such as Google Docs, is a great tool to get started with an SSoT. Ensure that you can easily update the document without downloading, uploading, and changing formats..\n* We recommend using a tool that allows for live editing, so making changes is very simple and easy.\n* Adding timestamps to track updates can also be helpful so students know they are looking at the most recent information.\n\n### What other tools do I need?\n\nBe sure to keep the [tech stack simple](/company/culture/all-remote/remote-work-emergency-plan/#minimize-your-tool-stack) and make sure everyone knows when to use which tool for each kind of communication.\n* For live meetings, we use [Zoom](https://zoom.us/) but whatever video conferencing tool your institution has will work.\n* For informal communication we use Slack, but there are other tools available such as Microsoft Teams.\n* If you need a more visual collaboration tool, consider using a tool such as [Mural](https://mural.co/).\n\nLet’s consider an example of how, when taken together, this approach can improve the experience for everyone in a remote environment whether teaching or learning.\n\n* A student asks a good question on the informal chat tool. You update the SSoT and direct the student to the answer there. Now students who may have the same question can see the response and know where to find the answer.\n* A student asks a question that is already in the SSoT. You direct the student to the correct link, thus minimizing the time it takes to answer the question.\n* A student asks a question that has been asked multiple times before. Private message the student, provide the SSoT link and suggest that he looks at the thread for answers in the future so he/she doesn’t need to wait for individualized responses.\n\n## Tip 3: Establish a [communication plan](/company/culture/all-remote/remote-work-emergency-plan/#establish-a-communications-plan)\n\nFor the first time in years, there’s no school bell ringing hourly or class schedule to keep everything on track! We recommend that you start by thinking about – and enjoying – **[asynchronous communication](/company/culture/all-remote/asynchronous/)** and then identify the [tool(s)](/company/culture/all-remote/remote-work-emergency-plan/#minimize-your-tool-stack) that you will use.\n\nFirst, let’s explore **asynchronous communication**. Working asynchronously removes the temptation to find a time that works for everyone and ensures that people who can’t make it to a specific event aren’t left out of the loop.\n\nIt is possible to strike a balance between providing key information in a self-service model while at the same time allowing for teams to ask questions and have discussions. Adopting a self-service model means that all content and relevant information is provided in a manner that students can easily find, read, and digest on their own ahead of time. With this approach, students can decide how much time to spend digging into the content according to their own needs and schedules.\n\nRecording a set of lectures ahead for an entire class, yet alone several classes' worth, is very daunting. Approaching lectures with an asynchronous communication style can help ease the burden on educators and at the same time provide effective mechanisms for discussion.\n\n### How can lectures be asynchronous?\n\n* [Have an editable agenda](/company/culture/all-remote/meetings/#have-an-agenda)  for the actual lecture discussion where students can post their name and a question in a numbered list.\n* Host a live video discussion where students voice their question(s) in the order on the agenda. If they aren’t present, read the question for them.\n* Answer the questions in the meeting and make sure someone is taking great notes. [Document everything](/company/culture/all-remote/meetings/#document-everything-live-yes-everything).  Try the [‘everyone is a moderator’](/handbook/communication/#everyone-is-a-moderator) concept to help run these meetings effectively.\n* Consider live-streaming the video directly to YouTube. This saves time and does not require you to download the recording, process it, and then upload back to your learning management system. The videos will be available on YouTube afterwards as well.\n* For more information, check out GitLab’s guide on [how to run remote meetings right](/company/culture/all-remote/meetings/#how-do-you-do-all-remote-meetings-right). You can also check a [recent example of a meeting livestream](https://www.youtube.com/watch?v=KMvrb0M3fFA) and an agenda to match (see below).\n\n![Agenda screenshot](https://about.gitlab.com/images/blogimages/group-convo-agenda.jpg){: .shadow.medium.center}\nA GitLab editable agenda after a meeting\n{: .note.text-center}\n\n## Tip 4: [Devote time to fostering relationships](/company/culture/all-remote/informal-communication/#devote-time-to-fostering-relationships)\n\nIn all-remote environments, there should be a greater emphasis placed on carving out time to get to know one another as humans. To connect and bond as empathetic beings with interests, emotions, fears, and hopes – people, not just colleagues or classmates. This tip is especially useful when transitioning from an in-person to an online setting. Your students are probably already a bit stressed, overwhelmed, and missing in-person, in-classroom connections.\n\n### How can you foster a sense of community with your online class?\n\n#### Try creating some fun channels in your online chat tool\n\nGitLab has channels that are all business as well as a set of channels for fun topics such as cooking, fitness, and dogs. People who have similar interests will connect and share experiences, photos, recipes etc. Students who connect over their puppies or a great recipe are more likely to help eachother out with questions or study together.\n\n#### Consider starting your video conference five minutes early with a conversational slide as a starter\n\nStudents arriving early can chit-chat just as they may have done in person. It might take a few meetings and some encouragement to get the ball rolling, but they’ll soon look forward to this opportunity to connect with classmates.\n\n![GitLab marketing team Show & Tell social call](https://about.gitlab.com/images/all-remote/marketing-social-call-show-and-tell.jpg){: .shadow.medium.center}\nA GitLab marketing team Show & Tell social call\n{: .note.text-center}\n\n#### Hold your office hours over a video conference\n\nStudents will be able to ask questions and have discussions, allowing them to build on the relationship with you and others they started in the in-person classroom.\n\n#### Try breakout groups\n\nThese are a great way to give students who may be less likely to speak up in a large group a chance to connect in a smaller setting.\n\n#### Consider hosting an **“Ask Me Anything”** meeting\n\nThese meetings are open times when students can ask a variety of questions. The questions could be anything from career advice, to sharing thoughts on research projects, course advising etc. It doesn’t have to be all business either.\n\n#### Encourage group conversation rather than 1:1 wherever possible\n\nThis helps to foster relations. We have some [guidelines that encourage collaboration through group communication](/handbook/communication/#avoid-direct-messages).\n\n#### There are some cases where you may need to discuss something 1:1 with a student\n\nWe recommend clearly outlining when to use group and private conversations in your SSoT.\n\nAdopting some of these strategies for remote teaching and learning is fairly easy. In our experience at GitLab, we find that team members enjoy and respect the independence this way of working affords them.  Students want to be engaged, and encouraging them to contribute by asking questions and taking collective notes themselves will allow them to contribute directly. Start small and go from there.\n\nWe hope this information helps make the transition a little bit easier and challenges some conventions in the long term! To learn more about the GitLab Education Program read our blog post [How to bring GitLab to a classroom near you](/blog/bring-gitlab-to-classroom-nearyou/).\n\nCover image by [Djurdjica Boskovic](https://unsplash.com/@escape_from_reality) on [Unsplash](https://unsplash.com/photos/G8_A4ZWxE3E)\n{: .note}\n",[707,683,9],{"slug":1421,"featured":6,"template":687},"going-remote-education-virtual-learning-tips","content:en-us:blog:going-remote-education-virtual-learning-tips.yml","Going Remote Education Virtual Learning Tips","en-us/blog/going-remote-education-virtual-learning-tips.yml","en-us/blog/going-remote-education-virtual-learning-tips",{"_path":1427,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1428,"content":1434,"config":1440,"_id":1442,"_type":14,"title":1443,"_source":16,"_file":1444,"_stem":1445,"_extension":19},"/en-us/blog/group-conversation-podcast",{"title":1429,"description":1430,"ogTitle":1429,"ogDescription":1430,"noIndex":6,"ogImage":1431,"ogUrl":1432,"ogSiteName":673,"ogType":674,"canonicalUrls":1432,"schema":1433},"How we turn our group conversations into a podcast with GitLab CI/CD","Want to listen to meetings on the go? Senior SRE John Jarvis explains how he turned his favorite remote meetings at GitLab into podcast format.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678626/Blog/Hero%20Images/group-conversation-podcast.jpg","https://about.gitlab.com/blog/group-conversation-podcast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we turn our group conversations into a podcast with GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Jarvis\"}],\n        \"datePublished\": \"2019-07-03\",\n      }",{"title":1429,"description":1430,"authors":1435,"heroImage":1431,"date":1437,"body":1438,"category":940,"tags":1439},[1436],"John Jarvis","2019-07-03","\n[Group conversations](/handbook/group-conversations/) are my favorite remote meetings at\nGitLab because they are a great way to get an inside peek at what different teams are doing,\nhow they collaborate, and what features you might find in future GitLab releases.\nYou may already know that we have been livestreaming these on\n[GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A) for anyone curious about how GitLab operates.\n\nLately, when I have time to listen to these unfiltered discussions I am either not at a screen or not in a place\nwhere it is easy to watch a video. After seeing how [Support turned their weekly meeting into a podcast](/blog/how-we-turned-40-person-meeting-into-a-podcast/),\nI thought it would be nice to make the GitLab group conversation meetings into a podcast as well!\n\n[Subscribe to the GitLab Group Conversations podcast](https://gitlab-com.gitlab.io/gl-infra/podcasts/#podcasts)\n{: .alert .alert-gitlab-purple .text-center}\n\nNow in addition to the livestreams and videos, there is a podcast feed for GitLab group conversations.\nListen to these conversations on your favorite podcast player by accessing the feed on\n[the Group Conversations podcast page](https://gitlab-com.gitlab.io/gl-infra/podcasts/#podcasts).\n\nIf you like the format, please let us know by tweeting us [@GitLab](https://twitter.com/gitlab)\nand we will consider adding more!\n\n### Here is a bit more detail about how these podcasts are generated\n\n* Teams that livestream group conversations\n  [follow instructions  for broadcasting it live](/handbook/group-conversations/#livestream-the-video)\n  and creating the video. When the meeting is over, the video is made available on GitLab Unfiltered.\n\n* A daily GitLab CI job in the [podcasts project](https://gitlab.com/gitlab-com/gl-infra/podcasts)\n  downloads the group conversation videos and converts them to audio files. It's easy to create [pipeline schedules in GitLab](https://docs.gitlab.com/ee/ci/pipelines/schedules.html).\n\n  ![The podcast schedule](https://about.gitlab.com/images/blogimages/podcast-schedule.png){: .shadow.medium.center}\n\n* An RSS feed is generated and audio files are uploaded to object storage from the CI job\n\n* GitLab pages is used to host a static site to link to the feed\n\n* This is all automated in a CI pipeline that runs every hour!\n\n![Podcast pipelines](https://about.gitlab.com/images/blogimages/podcast-pipeline.png){: .shadow.medium.center}\n\nI hope you have the opportunity to tune into the group conversations at GitLab and\nalso take advantage of GitLab CI features like schedules to help automate your own\nworkflows!\n\nPhoto by [Lee Campbell](https://unsplash.com/@leecampbell?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/headphones?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[683,9,109],{"slug":1441,"featured":6,"template":687},"group-conversation-podcast","content:en-us:blog:group-conversation-podcast.yml","Group Conversation Podcast","en-us/blog/group-conversation-podcast.yml","en-us/blog/group-conversation-podcast",{"_path":1447,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1448,"content":1454,"config":1461,"_id":1463,"_type":14,"title":1464,"_source":16,"_file":1465,"_stem":1466,"_extension":19},"/en-us/blog/gsoc-at-gitlab",{"title":1449,"description":1450,"ogTitle":1449,"ogDescription":1450,"noIndex":6,"ogImage":1451,"ogUrl":1452,"ogSiteName":673,"ogType":674,"canonicalUrls":1452,"schema":1453},"Google Summer of Code at GitLab – some intern highlights","GitLab team members mentored student interns and helped them develop open source projects during Google Summer of Code.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682129/Blog/Hero%20Images/gsoc_cover.jpg","https://about.gitlab.com/blog/gsoc-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Google Summer of Code at GitLab – some intern highlights\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aakriti Gupta\"}],\n        \"datePublished\": \"2021-09-01\",\n      }",{"title":1449,"description":1450,"authors":1455,"heroImage":1451,"date":1456,"body":1457,"category":299,"tags":1458},[894],"2021-09-01","\n\nGitLab participated in [Google Summer of Code](https://summerofcode.withgoogle.com/) for the first time this year. We hosted four student interns to work with us on four different projects under the supervision of two or three mentors each.\n\nFor the past 16 years, Google has hosted the Summer of Code to introduce students to the world of open source. Over the summer, student interns work on a project with an open source organization and are closely mentored by the developers of the open source project. More than [200 organizations](https://summerofcode.withgoogle.com/organizations/) participated this year.\n\nWe started off the summer with a two-week long community bonding period to get our students familiar with how we work at GitLab and helped them set-up their local development environments. During the 10-week program we worked through scoped projects with regular check-ins and [a final demo](https://youtu.be/--Neg5pwwnI) to conclude the program.\n\n## Meet the students\n\n### Alejandro Rusi\n[Alejandro](https://gitlab.com/rusi-ruse), a CS student from Argentina, worked on [enabling Courseware as Code](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gitlab-gsoc-2021/-/issues/4) through his project. Check out his [video presentation here](https://youtu.be/qgQQ4MgnKR4) and read [more about the project here](https://alejandro-rusi.gitlab.io/2021/05/31/toward-courseware). Alejandro said:  \n\n> They quickly made me feel welcome and part of Gitlab. All of the topics to choose from were very interesting, and all mentors seemed great.\n>\n> I would like to highlight a moment during GSoC where I wasn't able to do my normal workload due to a personal problem, and my mentors where incredibly supportive and understanding.\n\n### Anshuman Singh\n\n[Anshuman](https://gitlab.com/singhanshuman), a CS student who joined us from India, collaborated with the Static Analysis team to work on [writing vulnerability detection rules  for SAST](https://gitlab.com/groups/gitlab-org/-/epics/6089). Anshuman said: \n\n> For a beginner, it is normal to feel insecure about achieving specified tasks in your group.\n>\n> I am glad that my mentors Julian and Ross were there at every step of the program to provide support and clear my doubts about anything. It was such an enriching experience for me. I am glad to be the part of GitLab for this Google Summer of Code edition. :)\n\n### Cyrine Gamoudi\n\nA computer engineering student from Tunisia, [Cyrine](https://gitlab.com/CyrineG1) worked with the Static Analysis team on [porting SAST and Secret Detection rails platform code to GitLab CE](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gitlab-gsoc-2021/-/issues/6).\n\n> The project went very smoothly. I was able to achieve almost all of the planned milestones and I'm currently still in contact with my mentors, working on what was left. I enjoyed getting an inside look into how open source projects are maintained as well as how they evolve through time. It was also interesting to see the impact of historical architectural decisions on what could and could not be done later on.\n\n### Shubham Kumar\n\nNow in his final year of schooling, [Shubham](https://gitlab.com/imskr) from India helped the Geo team [improve our backup and restore features](https://shubhamkumar.live/blog/Improving-Backup-and-Restore-For-GitLab-GSoC-2021/).\n\n> Mentorship was amazing. Mentors helped me a lot whenever I had problem. Contributing to GitLab is very welcoming. I absolutely loved it.\n\n## GitLab mentors share their thoughts \n\n### What went well?\n\n- External organization\n  - The folks at Google were well organized, the entire schedule was available right at the beginning and the reminder emails were very informative and well timed.\n  - We used it to create our own calendar and that was very helpful.\n- Asynchronous working style\n\n> Having recorded meetings and an agenda doc was really helpful, especially for cases where one mentor went on holidays it was easy to catch up on things. Writing up a planning epic with our student Anshuman was really helpful to make sure that we were on the same page and to clearly define the project deliverables. - [Julian Thome](/company/team/#julianthome), senior vulnerability research engineer at GitLab. \n>\n> Related to this, GitLab's default mode of working that favors asynchronous communication and the written form feels very well-aligned with GSoC and working across time zones. Even without a large amount of overlap between working for myself and our mentee, it felt very effective and like we had a strong foundation in place to support communication and workflows (just point to our existing handbook and docs). - [Lucas Charles](/company/team/#theoretick), staff backend engineer, Secure, at GitLab.\n\n  - It was really useful to have two mentors on the project. This way it was easier sharing responsibilities and managing other priorities, especially when one mentor was out.\n\n### What could be improved? \n\n- We had considerable engagement on the project proposal issues but not as many applications.\n- GitLab is huge and a complex object model for students to hold onto.\n- Running GitLab locally requires a lot of resources.\n- The fork contribution model wasn't efficient for some projects.\n\n\n- Define the required skills for the project better\n> Since GSoC is 10 short weeks, making sure that the student has acquired all the required skills for the project before it starts would have allowed us to reduce the overall mentoring workload and to use mentoring time more efficiently by focusing on the project objectives. Next year, we can make better use of the \"Community Bonding\" period by giving the students more guidance and some time upfront to learn the required technologies/languages so that they are fully prepared before the coding phase begins. -  Julian\n\n- A clear \"victory task,\" possibly in the frontend, would have made some of the projects more \"visible\" and would have felt more complete.\n\n## Wrapping up\n\n[Tetiana Chupryna](/company/team/#brytannia), senior backend engineer, Secure, at GitLab sums up the experience of the mentors really well: \n\n> This program gave me a feeling of deep fulfilment as I was able to look at GitLab through the eyes of a community contributor and I hope that this project was useful for our student in her career, and she will return to GitLab one day as a contributor (we were lucky to have her on this project). So it was a summer well spent 🍎.\n\nWe hope GitLab can be back at Google Summer of Code next year!\n\n[Cover image](https://unsplash.com/photos/7RQf2X6aXXI) by [Raphaël Biscaldi](https://unsplash.com/@les_photos_de_raph)\n{: .note}\n\n",[267,1459,1460,1380,9],"contributors","google",{"slug":1462,"featured":6,"template":687},"gsoc-at-gitlab","content:en-us:blog:gsoc-at-gitlab.yml","Gsoc At Gitlab","en-us/blog/gsoc-at-gitlab.yml","en-us/blog/gsoc-at-gitlab",{"_path":1468,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1469,"content":1474,"config":1480,"_id":1482,"_type":14,"title":1483,"_source":16,"_file":1484,"_stem":1485,"_extension":19},"/en-us/blog/how-a-remote-internship-at-gitlab-shaped-my-career",{"title":1470,"description":1471,"ogTitle":1470,"ogDescription":1471,"noIndex":6,"ogImage":1370,"ogUrl":1472,"ogSiteName":673,"ogType":674,"canonicalUrls":1472,"schema":1473},"My experience as a recruiting intern at GitLab","Why interning for an asynchronous and all-remote company is the best way to go.","https://about.gitlab.com/blog/how-a-remote-internship-at-gitlab-shaped-my-career","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"My experience as a recruiting intern at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Trevor Knudsen\"}],\n        \"datePublished\": \"2019-12-06\",\n      }",{"title":1470,"description":1471,"authors":1475,"heroImage":1370,"date":1477,"body":1478,"category":705,"tags":1479},[1476],"Trevor Knudsen","2019-12-06","\n\n[Applications for GitLab's engineering internship program are open! Apply now](/handbook/engineering/internships/).\n{: .alert .alert-gitlab-purple .text-center}\n\nWhile a remote internship may seem like a foreign idea with many limitations to some, in reality, the options can be far less limiting than office work. Working remotely comes with many perks, including work-life balance, ability to travel, and the flexibility to work wherever you please, but the benefits go beyond that. Taking an internship away from the office offers learning experiences. You have the opportunity to work with people outside your city – and instead collaborate with people from all around the world. Flexibility, learning opportunities, mentors, and work experience are all so accessible with a remote internship.\n\n## Why I joined GitLab\n\nAs a communications major at California State University, Fullerton, I was required to find an internship. While I was looking for an internship, the [all-remote](/blog/the-remote-manifesto/) setup of GitLab immediatly caught my attention, and there was an opportunity as recruiting intern that I could not pass up. I applied and after going through the interview process I was offered the position. 🎉\n\n### Globally distributed team\n\nI started with GitLab in October 2017, which was my senior year of college. My first day with GitLab was such a rush. I met with my mentor, manager, and the team, and went through onboarding. I was welcomed as if I was a full-time employee by my team, and I quickly realized my entire team was my mentor. I had coworkers in the United Kingdom, South Africa, and all across the United States. While every team member was helpful, one of my greatest mentors was (and continues to be) [Nadia Vatalidis](/company/team/#vatalidis). She worked as a recruiter also and checked in with me on a regular basis to make sure I felt comfortable using the GitLab tool and see what tasks I was working on. We also collaborated on different projects the recruting team was working on.\n\n### Our values\n\nGitLab is guided by its values, and each day I saw these [values](https://handbook.gitlab.com/handbook/values/) used in every aspect of our work. The [diversity](https://handbook.gitlab.com/handbook/values/#diversity-inclusion) of the recruiting team was a strength, bringing creative solutions to the table each day. The entire company [collaborated](https://handbook.gitlab.com/handbook/values/#collaboration) on projects and shared ideas, while always respecting each other's thoughts and opinions. One of the great things about working with GitLab was that if an idea was presented, it could be implemented after a bit of discussion even if not yet refined. This ensured that we operated with [efficency](https://handbook.gitlab.com/handbook/values/#efficiency) and [transparency](https://handbook.gitlab.com/handbook/values/#transparency) values. Our team would push forward initiatives and ideas and [iterate](https://handbook.gitlab.com/handbook/values/#iteration) on them as they were implemented.\n\n### All-remote and asyncronous workflows\n\nThe wonderful thing about GitLab is I was able to work when I wanted. When I had midterms coming up, I was able to take a few days off to study. Vacation was never a hindrance, I simply took the days off. GitLab has a [no ask, must tell](/handbook/paid-time-off/) PTO policy, meaning as long as I shared my plans with manager and team, I could take the time off. Working remotely also allowed me to work from anywhere. When I took a trip to Zion National Park in Utah with friends, I was able to adjust my working hours so I could explore by day and work in the evenings. On a snowy day in Zion, I sat on the back patio next to a warm fire, watching the beauty of the snowfall. It was this experience that helped me recognize the true potential of all-remote. The best part about the flexibility is even when I adjusted my work hours, I was never truly alone. Team members in Europe, the Middle East, and even in Africa were online when the team in the Americas has already logged out. Someone was always online and available for support.\n\n## Not your average internship\n\nMy experience as a GitLab intern was not typical, because it was a true work experience. I got the pleasure of working alongside the team on major projects, such as looking into a new application tracking system. I got to be involved in screening calls, scheduling interviews for candidates, and helped implement a better solution on how to maintain company assets. My internship helped me learn and grow the skills necessary to be part of the recruiting team, and ultimately landed me a full-time position at GitLab just six months into my internship.\n\nI learned so much as a GitLab team member, and met so many people who continue to be a mentor to me today. An all-remote internship was also ideal for me as a student, because I was able to have a solid work-life balance – something I continue to enjoy today.\n\nIf you're a student or career-changer searching for an internship, be sure to not undercut remote work opportunities. Check out GitLab's [current internship opportunites](/handbook/engineering/internships/). You can really learn so much as part of a fully distributed team.\n\n_Read more about [making remote internships successful](/blog/making-remote-internships-successful/)._\n\nCover image by Patrick Tomasso on [Unsplash](https://unsplash.com)\n{: .note}\n",[731,683,9],{"slug":1481,"featured":6,"template":687},"how-a-remote-internship-at-gitlab-shaped-my-career","content:en-us:blog:how-a-remote-internship-at-gitlab-shaped-my-career.yml","How A Remote Internship At Gitlab Shaped My Career","en-us/blog/how-a-remote-internship-at-gitlab-shaped-my-career.yml","en-us/blog/how-a-remote-internship-at-gitlab-shaped-my-career",{"_path":1487,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1488,"content":1494,"config":1498,"_id":1500,"_type":14,"title":1501,"_source":16,"_file":1502,"_stem":1503,"_extension":19},"/en-us/blog/how-all-remote-supports-inclusion-and-bolsters-communities",{"title":1489,"description":1490,"ogTitle":1489,"ogDescription":1490,"noIndex":6,"ogImage":1491,"ogUrl":1492,"ogSiteName":673,"ogType":674,"canonicalUrls":1492,"schema":1493},"How all-remote supports inclusion and bolsters communities","When your hiring pipeline is more inclusive, your team becomes more inclusive.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679679/Blog/Hero%20Images/kuala-lumpur-dm.jpg","https://about.gitlab.com/blog/how-all-remote-supports-inclusion-and-bolsters-communities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How all-remote supports inclusion and bolsters communities\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Murph\"}],\n        \"datePublished\": \"2019-12-06\",\n      }",{"title":1489,"description":1490,"authors":1495,"heroImage":1491,"date":1477,"body":1496,"category":705,"tags":1497},[702],"\n\nA diverse and [inclusive](/company/culture/inclusion/#fully-distributed-and-completely-connected) team is a stronger, [smarter](https://hbr.org/2016/11/why-diverse-teams-are-smarter), and more empathetic team. As industries grapple with mechanisms to encourage and facilitate inclusivity, all-remote teams — where [100% of team members](/company/culture/all-remote/stages/) are empowered to work from anywhere — are more inclusive by default.\n\n## All-remote exudes inclusiveness\n\n![GitLab colleagues gathered in London](https://about.gitlab.com/images/blogimages/gitlab-commit-london-2019-colleagues.jpg){: .shadow.medium.center}\nGitLab colleagues gathered in London.\n{: .note.text-center}\n\nResearch from [Deloitte](https://www2.deloitte.com/us/en/insights/deloitte-review/issue-22/diversity-and-inclusion-at-work-eight-powerful-truths.html) shows that \"teams with inclusive leaders are 17% more likely to report that they are high performing, 20% more likely to say they make high-quality decisions, and 29% more likely to report behaving collaboratively.\"\n\nGitLab recognizes that one [advantage](/company/culture/all-remote/benefits/) to being an all-remote company is that we can [hire talent from a global pool](/handbook/hiring/). We are not restricted to the usual job centers, which gives us access to a tremendous amount of talent that many other companies will not consider for employment. It may take more effort to find talent in more diverse places, but that is an effort we are willing to make.\n\nCurrently, GitLab employs over [1,000 team members across more than 60 countries](/company/team/). This level of richness in cultural and geographic diversity is enabled by all-remote, and naturally shields against biases that form when entire teams live, work, and interact in the same region of the world.\n\nWe're surrounded by a tapestry of unique cultures, celebrations, and traditions. Not only does this give us a broader view of the world internally, it enables us to be more empathetic to the broader open-source community.\n\n## Sourcing talent from around the globe\n\n![All-remote allows people to thrive wherever they call home. Image by [Darren Murph](https://twitter.com/darrenmurph)](https://about.gitlab.com/images/blogimages/night-train-city-sweden.jpg){: .shadow.medium.center}\nAll-remote allows people to thrive wherever they call home. Image by [Darren Murph](https://twitter.com/darrenmurph)\n{: .note.text-center}\n\nGitLab's six [values](https://handbook.gitlab.com/handbook/values/) are Collaboration, Results, Efficiency, Diversity, Inclusion & Belonging , Iteration, and Transparency, and together they spell CREDIT.\n\nTrue to those values, GitLab strives to hire team members who are passionate, empathetic, kind, tenacious, and ambitious, *regardless* of their location. By opening the recruiting funnel to as [broad a swath of the world as we can](/handbook/people-group/employment-solutions/#country-hiring-guidelines), we create a more inclusive hiring environment, lean on tight collaboration to drive progress [across time zones](/company/culture/all-remote/management/#asynchronous), and focus our hiring decisions on results rather than location.\n\nHiring an all-remote team from across the globe allows GitLab to [pay local rates](/blog/why-we-pay-local-rates/). By hiring brilliant minds in locations with lower costs of living, GitLab is able to save money to hire even more people as we [scale our business](/company/culture/all-remote/scaling/).\n\n- All-remote means that you [will not sacrifice career advancement](/handbook/people-group/learning-and-development/) by working outside of the office, as even GitLab executives are fully remote.\n- All-remote creates a workplace where caregivers, individuals with physical disabilities, etc., are not disadvantaged by being unable to regularly commute into an office.\n- GitLab's approach to [spending company money](/handbook/spending-company-money/) enables all team members to create a work environment uniquely tailored for them.\n- All-remote enables those who must relocate frequently for family and personal reasons to take their career with them.\n- All-remote allows movement and relocation to physical settings that contribute to an individual's health (e.g., moving to a location with an improved air quality index).\n\n## Bolstering communities\n\n![When people aren't forced to relocate for work, their communities benefit. Image by [Darren Murph](https://twitter.com/darrenmurph)](https://about.gitlab.com/images/blogimages/community-outdoors-eu.jpg){: .shadow.medium.center}\nWhen people aren't forced to relocate for work, their communities benefit. Image by [Darren Murph](https://twitter.com/darrenmurph)\n{: .note.text-center}\n\nAll-remote encourages team members to work and live in a place where they are most fulfilled. This enables our team to reside in regions or communities that provides far more than shelter, but enriches their life experience by enabling long-lasting relationships with people who shape and support them.\n\nBy not forcing people to relocate for work, companies which embrace all-remote are benefitting local comunities in a significant way. Rural communities receive [outsized economic benefit](https://www.lajuntatribunedemocrat.com/news/20190808/state-remote-work-program-could-help-rural-communities), while major metropolitan areas experience less strain on infrastructure.\n\nStay-at-home [parents](/company/culture/all-remote/people/#parents) who wish to further their career, [caregivers](/company/culture/all-remote/people/#caretakers), [military spouses](/company/culture/all-remote/people/#military-spouses-and-families), and those who struggle with mobility can all contribute meaningfully when a company removes the location requirement from the job description.\n\nAll-remote opens the hiring door to places far beyond the usual job centers of the world. Candidates are not limited by geography and [we champion this approach](/blog/all-remote-is-for-everyone/) – to the extent that it’s possible – for all companies.\n\n{: .note}\n\n",[707,683,9],{"slug":1499,"featured":6,"template":687},"how-all-remote-supports-inclusion-and-bolsters-communities","content:en-us:blog:how-all-remote-supports-inclusion-and-bolsters-communities.yml","How All Remote Supports Inclusion And Bolsters Communities","en-us/blog/how-all-remote-supports-inclusion-and-bolsters-communities.yml","en-us/blog/how-all-remote-supports-inclusion-and-bolsters-communities",{"_path":1505,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1506,"content":1511,"config":1516,"_id":1518,"_type":14,"title":1519,"_source":16,"_file":1520,"_stem":1521,"_extension":19},"/en-us/blog/how-is-it-being-a-new-mom-working-for-gitlab",{"title":1507,"description":1508,"ogTitle":1507,"ogDescription":1508,"noIndex":6,"ogImage":766,"ogUrl":1509,"ogSiteName":673,"ogType":674,"canonicalUrls":1509,"schema":1510},"Parental/maternity leave around the world – how does your country stack up?","A new mother at GitLab takes a look at how different countries approach time off for new parents.","https://about.gitlab.com/blog/how-is-it-being-a-new-mom-working-for-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Parental/maternity leave around the world – how does your country stack up?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jarka Košanová et al\"}],\n        \"datePublished\": \"2019-07-18\",\n      }",{"title":1507,"description":1508,"authors":1512,"heroImage":766,"date":1513,"body":1514,"category":705,"tags":1515},[772],"2019-07-18","\n_This is the first in a four-part series looking at a myriad of issues surrounding working remotely with children. We’ll take a look at parental leave policies worldwide, get an inside view of working at GitLab with a newborn, and discover tried-and-true strategies for working remotely with older children._\n\nAt GitLab we have a generous [parental leave policy](/handbook/total-rewards/benefits/#parental-leave).\n\nWhen I returned from my maternity leave, I started to think about what that leave means for all team members. I come from the Czech Republic, a country where it is considered ideal for a mother to stay home from work until their child is about three years old. This expectation extends to each child in the family. In this blog post, I will look at parental leave around the world, and in a second post I’ll talk about my experience working at GitLab with a newborn. The opinions are my own, of course, and in every country, including my home nation, there can be major differences in leave standards between big cities and the rest of the country, especially in the smaller villages and across different social groups.\n\n## Parental leave in the Czech Republic\n\nIt is a [complex system](https://www.euraxess.cz/czech-republic/information-assistance/childrenfamily-and-personal-life/maternity-leave-and-parental) but what is important is that once a baby is born employers must keep the job of an employee on parental leave open for three years, and that’s for each child. Parents are entitled to a fixed amount of government money and they can decide for how long they want to receive the stipend (the amount is split accordingly for each month). Because employers have to keep a job open for three years, the vast majority of mothers stay at home for three years. It is quite rare for fathers to stay at home, although this number is increasing.\n\n## Standards vary, even in Europe\n\nI will summarize laws from a few countries to show how parental policies differ across Europe and worldwide.\n\nAbout [80% of women in the Czech Republic stay home with their new child for two years or more](https://www.oecd.org/els/family/LMF_1_2_Maternal_Employment.pdf), and even fewer women return to work within the first year after birth.\n\nThe parental leave policy is very similar [in Germany where employers must keep a position open for women for three years](https://www.thelocal.de/20140113/german-parental-leave-our-guide) and [a lot of working mothers use it](https://www.destatis.de/DE/Themen/Gesellschaft-Umwelt/Soziales/Elterngeld/Publikationen/Downloads-Elterngeld/elterngeld-leistungsbezuege-j-5229210187004.pdf?__blob=publicationFile&v=2).\n\n> In the US there is no law that enforces paid parental leave.\n\nI lived in Switzerland for almost four years, and it was the first time I encountered completely different rules and approaches to parental leave. In Switzerland, women are permitted to stay at home for three to four months (it depends on the employer but purely by law, they are entitled to [14 weeks of maternity leave](https://www.ch.ch/en/maternity-leave/)) and about 70% of mothers return to work during [the first two years](https://www.bfs.admin.ch/bfs/de/home/statistiken/kataloge-datenbanken/publikationen.assetdetail.1061095.html) of the child's life.\n\n## From the UK to the US\n\n[In the UK, where women can take up to 52 weeks of maternity leave](https://www.gov.uk/maternity-pay-leave/leave), about [65% of mothers of kids up to two years old work](https://www.ons.gov.uk/employmentandlabourmarket/peopleinwork/employmentandemployeetypes/articles/moremotherswithyoungchildrenworkingfulltime/2017-09-26).\n\n[In the Netherlands, women can take at least 16 weeks](https://www.expatica.com/nl/healthcare/womens-health/having-a-baby-in-the-netherlands-107665/) of maternity leave (including pregnancy) and almost 90% of women return to work before their child is one year, while in France 80% of mothers will return to work.\n\n> In the Czech Republic, about 80% of women stay home with children for two years or more.\n\nMore than half (53%) of Australian women return to work within the first two years.\n\n[In Sweden, both parents can split 480 days of parental leave](https://www.forsakringskassan.se/privatpers/foralder/nar_barnet_ar_fott/foraldrapenning/!ut/p/z0/04_Sj9CPykssy0xPLMnMz0vMAfIjo8ziTTxcnA3dnQ28_U2DXQwczTwDDcOCXY1CDc31g1Pz9AuyHRUBTbm8uw!!/) and most families use this benefit. Scandinavian countries also have the largest volume of fathers taking parental leave.\n\nIn the US, there is no law that enforces paid parental leave. The [Family and Medical Leave Act](https://en.wikipedia.org/wiki/Family_and_Medical_Leave_Act_of_1993) ensures 12 weeks of job protection with unpaid leave, and there are some states that have more generous policies. Companies are taken as very generous if they decide to provide at least a couple of paid weeks of leave. In the US, 60% of women return to work during the baby's first year and [44% go back to work within the first three months after giving birth](https://fairygodboss.com/maternity-leave-resource-center/statistics).\n\nThis is just a snapshot of how parental leave is treated around the world. Check the [Parental Leave Review 2018](https://www.leavenetwork.org/fileadmin/user_upload/k_leavenetwork/annual_reviews/Leave_Review_2018.pdf) if you are interested in more data from other countries. You may also find a [length of maternity, parental and father-specific leave table](https://stats.oecd.org/index.aspx?queryid=54760) interesting. And if you want a short summary across 11 countries, check out [this article from Business Insider](https://www.businessinsider.com/maternity-leave-worldwide-2017-8#germany-mothers-can-take-up-to-three-years-family-leave-11).\n\n_Next up: Jarka shares her experience with GitLab maternity leave as well as some good advice for expectant and early-stage parents._\n\nPhoto by [insung yoon](https://unsplash.com/@insungyoon?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/baby-mobile?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,708,267],{"slug":1517,"featured":6,"template":687},"how-is-it-being-a-new-mom-working-for-gitlab","content:en-us:blog:how-is-it-being-a-new-mom-working-for-gitlab.yml","How Is It Being A New Mom Working For Gitlab","en-us/blog/how-is-it-being-a-new-mom-working-for-gitlab.yml","en-us/blog/how-is-it-being-a-new-mom-working-for-gitlab",{"_path":1523,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1524,"content":1529,"config":1535,"_id":1537,"_type":14,"title":1538,"_source":16,"_file":1539,"_stem":1540,"_extension":19},"/en-us/blog/how-remote-work-at-gitlab-enables-location-independence",{"title":1525,"description":1526,"ogTitle":1525,"ogDescription":1526,"noIndex":6,"ogImage":1050,"ogUrl":1527,"ogSiteName":673,"ogType":674,"canonicalUrls":1527,"schema":1528},"How I work from anywhere (with good internet)","Sarah Daily, digital marketing programs manager and remote work advocate, shares how all-remote work at GitLab has enabled her life on the road.","https://about.gitlab.com/blog/how-remote-work-at-gitlab-enables-location-independence","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How I work from anywhere (with good internet)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah Daily\"},{\"@type\":\"Person\",\"name\":\"Betsy Church\"}],\n        \"datePublished\": \"2019-06-25\",\n      }",{"title":1525,"description":1526,"authors":1530,"heroImage":1050,"date":1532,"body":1533,"category":705,"tags":1534},[1531,852],"Sarah Daily","2019-06-25","\n\nWe're committed to [all-remote](/company/culture/all-remote/) work at GitLab – our whole work\nphilosophy is designed around it. So we're always happy to share when one of our team members\nis taking full advantage of the flexibility that remote work affords. We chatted with [Sarah Daily](/company/team/#sdaily) about\nher life on the road:\n\n### What’s your role at GitLab, and why did you want to join the team?\n\nI’m a [digital marketing programs manager](https://handbook.gitlab.com/job-families/marketing/online-growth-manager/index.html) focusing on conversion rate optimization and analysis for our email programs and website. Previously, I was a digital marketing manager for a non-profit organization in the education industry.\n\nI'm a remote work advocate and knew about some of the companies that are 100% remote (GitLab being prominent among them).\n\nThough I had a remote job at the time I applied to GitLab, I knew eventually my passion for technology and software development would lead me elsewhere. I decided to seek GitLab directly to see if they had any open positions in their marketing department. As fate would have it, they did, so I applied immediately.\n\nThe more I learned about the company and culture, the more I fell in love. GitLab is a model for how companies should implement remote work. The culture and values are so deeply integrated in how everyone works and behaves. Everything we do and how we work is centered around being a global workforce and allows us to move at the speed of innovation.\n\n### Tell us about your traveling home office and when you started life as a digital nomad.\n\nThree years ago, my partner and I were living in an 800-square-foot apartment with daily commute jobs. We no longer wanted to live where we were, but we didn’t want to choose a random place to move to without knowing whether we were actually going to like it there.\n\nWe needed to be able to visit family and friends with little hassle, and if we lived over a 1,000 miles away then that was going to be a considerable effort and cost. Before we could make any decisions, I needed the ability to work remotely and I ended up finding a remote job with a non-profit organization that had a hybrid remote work model.\n\nOne night, my partner came home from work and made the suggestion to live in an RV. It would be cheaper to live, we could travel and live anywhere we wanted* for as long as we wanted, and we would be able to visit family and friends, all while living in the comfort of our own home.\n\n![Sarah's truck and trailer](https://about.gitlab.com/images/blogimages/sdaily-truck-and-trailer.jpg){: .shadow.medium.center}\nSarah's truck and trailer\n{: .note.text-center}\n\nAfter researching blogs, Facebook groups, and other websites, we realized not only was it actually possible, but that thousands of other people, couples, and families were doing this and had been doing it for years.\n\nBut before we could start the process, we had to downsize a lot.\n\nWe sold a car, all our furniture, and gave the rest away to Goodwill or family and friends. In March 2016, we moved the rest of our belongings into a less than 200-square-foot space and hit the road. We’ve been all over the west coast of the US and Canada.\n\nOur rig is a 40-foot travel trailer that we haul with our truck. After living and traveling in it for three years, it actually has more space than we need.\n\nMore than anything, we love the freedom of being able to pick up and leave for a new location, all while being in our home. We’ll likely continue to do this for the foreseeable future.\n\n*Criteria: Has to have good internet and an airport nearby.\n{: .note}\n\n### How has working for GitLab enabled you to chase your passion for travel?\n\nThough we’ve been full-time traveling for over three years, GitLab makes this even easier because of the focus on asynchronous work. While some companies allow their employees to work remotely, it isn’t always flexible.\n\nAt my previous job, I was expected to work at least partially in a specific time zone. This is because there was a central HQ and only some employees worked remotely full time. This created a separation and isolation for remote employees. It made us feel like we weren’t always involved in meetings and conversations that happened at HQ.\n\nWith the asynchronous model, I don't have to worry about when I'm working because all my colleagues live in different time zones. This gives me the freedom to design my day around my peak productive hours and also have time to take care of general life stuff (appointments, house chores, etc.)\n\n![Sarah fishing in Grand Teton National Park, Wyoming](https://about.gitlab.com/images/blogimages/sarah-fishing-grand-teton-national-park-wy.jpg){: .shadow.medium.center}\nSarah fishing in Grand Teton National Park, Wyoming\n{: .note.text-center}\n\n### What makes GitLab unique?\n\nIt is so refreshing to work at GitLab. The culture really enables you to be the best version of yourself both as an employee and a human being outside of work. Everyone here fully embraces our ideals and values and it makes contributing a pleasure.\n\n>Everything we do and how we work is centered around being a global workforce and allows us to move at the speed of innovation\n\nYou really feel like you make a difference each day, [no matter how small or boring](https://handbook.gitlab.com/handbook/values/#boring-solutions).\n\nBut I think the biggest difference between GitLab and other companies I’ve worked for is the [transparency](https://handbook.gitlab.com/handbook/values/#transparency). By being transparent with our employees, customers, and community, we enable everyone to fall in love with the product and vision, and contribute to making it better every day.\n\nIt truly becomes a shared goal and I think that’s something that is missing from most company cultures. If you cannot enable everyone to have a say through transparency, you bottleneck the entire company for everyone.\n\n\n\nLearn more about [all-remote](/company/culture/all-remote/) work and [how it works at GitLab](/company/culture/all-remote/tips/#how-it-works-at-gitlab).\n\nWant to join the team? [Browse our vacancies](/jobs/).\n",[707,683,9],{"slug":1536,"featured":6,"template":687},"how-remote-work-at-gitlab-enables-location-independence","content:en-us:blog:how-remote-work-at-gitlab-enables-location-independence.yml","How Remote Work At Gitlab Enables Location Independence","en-us/blog/how-remote-work-at-gitlab-enables-location-independence.yml","en-us/blog/how-remote-work-at-gitlab-enables-location-independence",{"_path":1542,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1543,"content":1548,"config":1554,"_id":1556,"_type":14,"title":1557,"_source":16,"_file":1558,"_stem":1559,"_extension":19},"/en-us/blog/how-to-improve-communication-remote-designer",{"title":1544,"description":1545,"ogTitle":1544,"ogDescription":1545,"noIndex":6,"ogImage":932,"ogUrl":1546,"ogSiteName":673,"ogType":674,"canonicalUrls":1546,"schema":1547},"How to improve your communication as a remote designer in 6 simple steps","When you're explaining designs or requesting feedback, it's easy to give too much information. Here are some tips on how you can communicate better as a designer, especially if you're working remotely.","https://about.gitlab.com/blog/how-to-improve-communication-remote-designer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to improve your communication as a remote designer in 6 simple steps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pedro Moreira da Silva\"}],\n        \"datePublished\": \"2021-01-06\",\n      }",{"title":1544,"description":1545,"authors":1549,"heroImage":932,"date":1551,"body":1552,"category":729,"tags":1553},[1550],"Pedro Moreira da Silva","2021-01-06","\n{::options parse_block_html=\"true\" /}\n\n## Communication is hard\n\nAt GitLab, [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) is one of our core values. Being efficient in everything we do is important, but it's even more important when communicating and collaborating with others. We need this emphasis on efficiency, [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration), and [communication](https://about.gitlab.com/handbook/communication/) for GitLab to work as an all-remote company, with zero offices and team members distributed across the globe.\n\nIn the context of design, when you're explaining a design decision or requesting feedback, it's easy to fall into the trap of giving too much information. **You want people to understand it right away, so you give as much background and arguments as possible. The problem is that long messages and explanations can put up a collaboration-barrier.** When people have many things competing for their attention, it's hard for them to take the necessary time to read long messages and engage themselves in a constructive discussion. Also, often the most important points get diluted because of how long something is.\n\n**So how can you communicate better and more efficiently as a designer, especially if you're working remotely?** I'm a designer working remotely for over 4 years and I've learned a lot about communication. Let me share 6 practical tips that you can use when sharing information or requesting something from someone:\n\n1. Important things first\n1. Keep it short\n1. Balance context and conciseness\n1. Use multiple formats\n1. Clear calls-to-action\n1. Use simple language\n\nAt the end of this article, there's a [structure and example that puts all of these tips together](#example), so that you can improve your communication today.\n\n## ❗️ Important things first\n\n**Make sure you communicate the important things first.** Journalists do this very well by using the [inverted pyramid](https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)) method: information is prioritized so that the major details come before the minor details. So empathize with your audience and think how much little time they can afford to invest in your message. Prioritize and structure your communication so that the key aspects come first and it's as easy as possible to learn about them.\n\n## 📟 Keep it short\n\n[**Keeping written communication short**](https://handbook.gitlab.com/handbook/values/#keep-broadcasts-short) **and** [**giving short verbal answers**](https://handbook.gitlab.com/handbook/values/#short-verbal-answers) goes hand in hand with communicating the important things first. If you need to give a lot of information, maybe there's a communication or expectations problem.\n\nAlthough we default to [asynchronous communication](https://about.gitlab.com/handbook/communication/#asynchronous-communication) at GitLab, sometimes a short video call is enough to unblock and make sure everyone's aligned without having to invest too much time in writing and reading something. Our rule of thumb is: “if you have gone back and forth 3 times, it's time for a video call.” (also see [video calls guidelines](https://about.gitlab.com/handbook/communication/#video-calls)).\n\nOther times, it can also be that the topic at hand is just too large to discuss in one go. Think about how you can break it down into smaller, more “consumable” pieces. It will make life easier for you, the other participants, and anyone else that is following that topic. To help you break things down, read “[Iterate Like a GitLab Designer](https://about.gitlab.com/blog/iterate-like-a-gitlab-designer/)” or our handbook section on [iteration](https://handbook.gitlab.com/handbook/values/#iteration).\n\n## 🤹 Balance context and conciseness\n\n**Try to provide as much context as possible while balancing the conciseness of your message.** This may seem the opposite of keeping it short, but you do need to strike a balance. You don't want your message to be too short, as it can cause confusion and require clarification, which ultimately delays things. But you also don't want your message to be too long, for all of the reasons I've mentioned so far. Striking this balance sounds incredibly challenging, but fortunately, we have some methods to help us with that, like the inverted pyramid that I described before or multiformat communication.\n\n## 🎨 Use multiple formats\n\n**Communicating through multiple formats means thinking about your audience and applying your message to the formats that are most likely to attract that audience.** An example is requesting feedback on an idea: you can share an image, a brief paragraph explaining the idea, a list of bullet points with the pros and cons, and maybe even a short video where you walk people through it. This way, each person jumps to and consumes the format that resonates the most with them, how they want it.\n\nBut remember that you don't have to use every format, every time. It depends on who you're communicating with, what you're communicating, and when a certain action is needed. Think about these aspects and choose the communication format that best suits them (and also the time you can invest in crafting your message).\n\n## ☝️ Clear calls-to-action\n\n**If you have calls-to-action, make them clear, direct, and specific.**\n\nPerhaps the most important aspect of those three: try to direct your asks to specific people, instead of a group of people or no one at all. The work you put into selecting and targeting who you ask is proportional to the quality of their responses. Asking a group of people is sometimes necessary, but there's a risk of getting nothing but “radio silence,” so be extra careful in crafting your message if you're targeting a group.\n\nRegarding CCs, one of our [communication best practices](https://about.gitlab.com/handbook/communication/#top-tips-and-best-practices) says it best:\n\n> It is OK to bring an issue to someone's attention with a CC (\"cc @user\"), but CCs alone are not enough if specific action is needed from someone. The mentioned user may read the issue and take no further action. If you need something, please explicitly communicate your need along with @ mentioning who you need it from.\n\nBe clear and specific about the who, what, and why. If it's a vague or broad ask, it will be much more difficult for others to respond.\n\nFinally, place any asks you have at the beginning of your message. These asks fall into the “important things first” tip because, well, they are supposed to be important! If possible, consider repeating them at the end of the message as a reminder.\n\n## 👐 Use simple language\n\n**Finally, use** [**simple language**](https://about.gitlab.com/handbook/communication/#simple-language) **and terms that everyone understands** (see [ubiquitous language](https://about.gitlab.com/handbook/communication/#ubiquitous-language)). For example, instead of using the “IxD” acronym, say “interaction design.” Or explain what that means with simple language if you can, like saying “how a user might interact with the user interface and how it behaves.”\n\n## Example\n\nTo bring it all together, I'll first share with you a structure that you can use when requesting feedback or communicating your work, either in a written message, a video, or a presentation:\n\n1. **Summary**: A very short summary ([tl;dr](https://en.wiktionary.org/wiki/tl;dr)) of your message, with simple language and shared terms. If possible, consider bolding the whole summary so it sticks out from the rest.\n1. **Asks**: Be clear about what you want and until when. If possible, mention specific people and make sure to bold/highlight their names (if not automatically highlighted). When requesting feedback, specify the kind of feedback you're looking for, what they should comment on, and also what they should not comment on.\n1. **Walkthrough**: If you have a video or presentation that gives an overview of the topic, link to it. Better yet, embed it in your message to reduce clicks and friction, but always keep a link so it's accessible to everyone.\n1. **Visual**: Try to add a simple image/diagram that describes the core elements of what you're communicating.\n   - If you have more visuals that you'd like to share, link to an external page with them. For example, at GitLab we use Figma to design user interfaces, so we link to Figma files where people can view all of the design work.\n1. **Details**: More information in the form of short paragraphs or lists. It could be links to any additional references, support documentation, or artifacts. Remember to keep them short!\n   - Tip: Some writing tools support the `\u003Cdetails>` HTML tag, that allows you to easily hide information behind a toggle, like an accordion. See the [MDN web docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details) for a simple example and copy-pastable markup.\n1. **Close**: Consider reiterating your asks and thank people for their time.\n\nAnd to see how this can work in practice, here's an example message, where I requested feedback from my team members on a few possible design options:\n\n![Example feedback request message showing an embedded video and collapsible information panels](https://about.gitlab.com/images/blogimages/how-to-improve-communication-remote-designer/example.gif){: .shadow.center}\n\n## Keep improving your communication skills\n\nThe act of improving one's communication skills doesn't stop, because the “why, what, how, and who” are always changing. The quality of communication can make or break an individual, a team, or an organization. As Anthony Robbins puts it:\n\n> The way we communicate with others and ourselves ultimately determines our quality of life.\n\nIn this article I focused on writing, speaking, and showing. But communication is also about how you read, listen, and watch. Maybe I'll write about that other side of communication in the future. In the meantime, I leave you with our [handbook page on communication](https://about.gitlab.com/handbook/communication/), which is a great place to learn more about what makes good communication in a remote company.\n\nCover image by [Stellan Johansson](https://unsplash.com/@stellanj) on [Unsplash](https://unsplash.com/photos/1PP0Fc-KSd4)\n{: .note}\n",[731,732,9,734],{"slug":1555,"featured":6,"template":687},"how-to-improve-communication-remote-designer","content:en-us:blog:how-to-improve-communication-remote-designer.yml","How To Improve Communication Remote Designer","en-us/blog/how-to-improve-communication-remote-designer.yml","en-us/blog/how-to-improve-communication-remote-designer",{"_path":1561,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1562,"content":1567,"config":1572,"_id":1574,"_type":14,"title":1575,"_source":16,"_file":1576,"_stem":1577,"_extension":19},"/en-us/blog/how-to-navigate-the-great-resignation",{"title":1563,"description":1564,"ogTitle":1563,"ogDescription":1564,"noIndex":6,"ogImage":1191,"ogUrl":1565,"ogSiteName":673,"ogType":674,"canonicalUrls":1565,"schema":1566},"How to navigate The Great Resignation","Tips for leaders and job seekers as they embrace the future of work or search for their first remote job.","https://about.gitlab.com/blog/how-to-navigate-the-great-resignation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to navigate The Great Resignation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Betsy Bula\"}],\n        \"datePublished\": \"2021-12-16\",\n      }",{"title":1563,"description":1564,"authors":1568,"heroImage":1191,"date":1569,"body":1570,"category":705,"tags":1571},[1196],"2021-12-16","\n\n[The Great Resignation](https://www.forbes.com/sites/jenamcgregor/2021/12/14/2021-brought-us-the-great-resignation-no-one-can-agree-what-to-call-it/?sh=a58146b509c7) is upon us. Turnover rates in the U.S. continued to reach historic highs in October 2021, with more than 4.2 million people quitting their jobs that month, according to the [Bureau of Labor Statistics](https://www.bls.gov/news.release/jolts.nr0.htm). While this Great Resignation can be attributed to a number of factors, it’s clear that remote and flexible work is high on the list for knowledge workers globally. \n\nIn fact, in GitLab’s [2021 Remote Work Report](https://about.gitlab.com/company/culture/all-remote/remote-work-report/), 52% of remote workers said they would consider leaving their co-located company for a remote role. If remote work was suddenly no longer an option, one in three respondents would quit their job. \n\nWhether you’re a job seeker looking for your first remote role or an employer hoping to embrace remote work to attract and retain the most talented people in this new era of work, here are a few things to keep in mind.\n\n## Job seekers: What to look for when considering a remote job\n\n![Working at GitLab Commit London 2019](https://about.gitlab.com/images/all-remote/gitlab-commit-london-coworking-2019.jpg){: .shadow.medium.center}\nWorking at GitLab Commit London 2019\n{: .note.text-center}\n\nIn a job market that is stacked in your favor, you may find yourself comparing multiple offers to decide on your next move. While many companies now claim to support remote and flexible work, they are likely [not all equal](/company/culture/all-remote/all-remote-vs-hybrid-remote-comparison/) in terms of how their remote culture truly operates.\n\nEach person has individual preferences and needs from their employer, but there are some factors that no job title or compensation package can offset. You’ll want to ask a few [critical questions](/company/culture/all-remote/evaluate/) during the interview process to be sure the remote role you’re considering meets your expectations. \n\n### 1. Where do the leaders work? \n\nThere’s a dramatic difference between remote work being tolerated and it being truly ingrained into every process and norm within the organization. \n\nWhere the company’s leaders (and your manager) spend most of their time is an [excellent indicator](/company/culture/all-remote/hybrid-remote/#leaderships-place-in-the-office) of the level of commitment they have for remote or hybrid work. If you’re considering joining a [hybrid organization](/company/culture/all-remote/hybrid-remote) where most senior leaders and even your manager primarily work in an office, you may want to ask more questions about how they ensure all team members have an equitable employee experience. \n\n### 2. How does the team communicate?\n\nIn any hybrid or all-remote organization, communication practices are a foundational piece to team members feeling like they’re able to thrive. Ask about whether the company [maintains a handbook](/company/culture/all-remote/handbook-first-documentation/), or single source of truth, that all team members can access. If not, how is information disseminated? \n\nIt’s a good sign if there are [asynchronous communication](/company/culture/all-remote/asynchronous/) practices in place, and tools that allow teams to collaborate and share information regardless of the hours they work each day.\n\n### 3. What does \"flexibility\" actually mean?\n\nMany companies will use the word “flexibility” on their career site, but it can be hard to know what that actually means in practice. \n\nIs the team expected to be online during certain hours? Will the company track your online hours? These are potential red flags to dig into more in the interview process. Keep in mind that an organization that truly believes in remote work will track your results, not your hours spent on your laptop. \n\nHaving true [autonomy over your schedule](/company/culture/all-remote/tips/#find-your-routine) means you’ll have the opportunity to work [non-linear workdays](/company/culture/all-remote/non-linear-workday/), be there for family and friends when needed, and get work done during your peak productivity hours. This allows you to shape your work around your life, not the other way around. \n\n### 4. Will you be set up for success?\n\nWhen you’re [starting out in a remote role](/company/culture/all-remote/getting-started/), you need the right tools, training, and equipment to be productive and happy. \n\nFind out whether you’ll be offered equipment, or be able to [expense what you’ll need](/handbook/spending-company-money/) to create a [healthy remote workspace](/company/culture/all-remote/workspace/). Some organizations will offer to cover expenses of joining a coworking space if you prefer not to work at home everyday. \n\nAlso be sure to ask what the onboarding process will look like and how your manager and team will [support you](/company/culture/all-remote/being-a-great-remote-manager/#prioritize-onboarding) through the first weeks and months. It’s important to have the resources you need as you learn the company’s culture and adopt new remote skills, especially if this is your first remote role.\n\n## Employers: Evolve your organization to keep talented people engaged\n\n![GitLab all-remote at scale illustration](https://about.gitlab.com/images/all-remote/gitlab_all_remote_work_environment_scale.jpg){: .medium.center}\n\nThe world of work has undergone a dramatic evolution since the start of the pandemic, putting the onus on business leaders and hiring managers to make sure their processes and cultures evolve too. What worked in the past to retain team members may simply not meet their needs today.\n\nDespite the pressure to keep retention as high as possible, remember that some attrition is natural. You don’t want to prevent team members from pursuing the next step in their career, even if that means leaving the organization. It’s also important to recognize when someone is not aligned with your values, because this can cause your culture to erode over time.\n\n### 1. Ask the right questions (and listen)\n\nYou’re probably already surveying your team regularly about their overall satisfaction with your company as an employer. But what are you doing with that information? If you’re asking team members about their work preferences but not using those results as a catalyst for change, your best employees are likely to start looking elsewhere. \n\nSharing a summary of the results transparently will also go a long way in helping to build trust, create accountability, and give everyone a better understanding of the breadth of needs within the team. \n\nManagers also play a crucial role in the employee experience equation, especially in a remote or hybrid environment. They should be checking in with their team members regularly in [1:1 meetings](/handbook/leadership/1-1/) to understand what’s going on in their lives, help them [combat isolation and burnout](/company/culture/all-remote/mental-health/#working-to-prevent-burnout-isolation-and-anxiety), and to keep tabs on their overall engagement. \n\n### 2. Don't try to replicate the in-office experience remotely\n\nIf you were once a colocated company that has recently adopted remote or hybrid work, this means rethinking your processes, norms, workflows, and even [your culture](/company/culture/all-remote/building-culture/). You may have been able to attract and keep talented people engaged in the past by offering stellar on-site perks, but what does your culture look like when the office is stripped away? \n\nInstead of [trying to force old habits](/company/culture/all-remote/what-not-to-do/) to work in a dramatically different setting, take a look at your organizational design as a whole, and start evolving it. This includes how your team communicates, how you recognize and promote people, how you handle meetings, whether you track output or input, and so much more. \n\nIf possible, consider [hiring a Head of Remote](/company/culture/all-remote/head-of-remote), or someone who is experienced in organizational design and remote practices.\n\n### 3. Build a culture of trust, flexibility, and autonomy\n\nThere’s no “one size fits all” when it comes to when and where a diverse team of people can do their best work. That’s why allowing your team to have full autonomy in shaping their workdays and weeks is the best way to boost productivity and build mutual trust within your organization. \n\nFor this to work, you’ll need to focus on [measuring results](https://handbook.gitlab.com/handbook/values/#measure-results-not-hours), not input. Step away from the tracking devices. Instead, outline each team's and each individual's goals on a quarterly or monthly basis, and measure their success based on those goals, not on whether they were sitting in a chair during certain hours.  \n\n### 4. Create clarity through documentation\n\nTo provide a top-notch employee experience in a remote, hybrid, or even colocated setting, your goal should be to have [no unwritten rules](/company/culture/all-remote/building-culture/#no-unwritten-rules-in-a-remote-work-culture). This means you’ll need a handbook, or a single source of truth, where you document everything a team member needs to know about your company. \n\nThis high level of documentation extends to how you approach [meetings](/company/culture/all-remote/meetings/) as well. Every meeting should have an agenda attached to the invite ahead of time. During meetings, take copious notes so that there’s enough context around the discussion. Not only does this create shared clarity for those in attendance, it’s also more inclusive of those who are unable to attend.\n\nWith the dramatic rise in remote-friendly roles and organizations embracing borderless hiring, job seekers today have more options and opportunities than ever before. Organizations and leaders must begin to evolve and be more intentional about how they support their employees beyond the requisite compensation and benefits. Communicate openly, be willing to iterate, and extend empathy and grace to one another. \n\n**Looking for more resources and remote best practices? Check out [GitLab’s Guide to Remote Work](https://learn.gitlab.com/allremote/).** \n",[708,9],{"slug":1573,"featured":6,"template":687},"how-to-navigate-the-great-resignation","content:en-us:blog:how-to-navigate-the-great-resignation.yml","How To Navigate The Great Resignation","en-us/blog/how-to-navigate-the-great-resignation.yml","en-us/blog/how-to-navigate-the-great-resignation",{"_path":1579,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1580,"content":1586,"config":1591,"_id":1593,"_type":14,"title":1594,"_source":16,"_file":1595,"_stem":1596,"_extension":19},"/en-us/blog/how-to-push-code-from-a-hammock",{"title":1581,"description":1582,"ogTitle":1581,"ogDescription":1582,"noIndex":6,"ogImage":1583,"ogUrl":1584,"ogSiteName":673,"ogType":674,"canonicalUrls":1584,"schema":1585},"How to push code from a hammock","Our remote work dream team balances globetrotting with career advancement at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678958/Blog/Hero%20Images/hammock.jpg","https://about.gitlab.com/blog/how-to-push-code-from-a-hammock","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to push code from a hammock\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-09-23\",\n      }",{"title":1581,"description":1582,"authors":1587,"heroImage":1583,"date":1588,"body":1589,"category":705,"tags":1590},[812],"2019-09-23","\n_At GitLab, our team doesn’t wake up at the same time and commute the same routes to sit in the same office. In fact, some of our team members don’t have an office at all! As a globally distributed company with an all-remote workforce, we have an exceptionally diverse set of team members dispersed on multiple continents. In this series, we explore how GitLab team members use the autonomy our company affords them to create workspaces that suit their lifestyle and cater to their hierarchy of needs: Whether that involves creating a cozy home office space, or diving into the unknown by working while traveling. New here? Go back to [read part one](/blog/not-everyone-has-a-home-office/) of our remote work series._\n\nFor many career-minded individuals, the desire to travel for prolonged periods comes at a cost. Sometimes, the only options are to plan for rushed two-week bursts of vacation, wait for retirement, or leave your career behind.\n\nBack in 2013, I had the opportunity to volunteer at an NGO in Hanoi for a month, but in order to do so, I had to make a choice: Leave my job as a reporter, or pass on the opportunity to work in Vietnam. My reporting job only allotted employees two weeks of annual paid time off (PTO) and didn’t allow for remote work at all. After some (but not much) deliberation, I left my job and went to Hanoi.\n\nEven in some companies where working remotely is an option, if all-remote isn’t part of the company culture, traveling abroad isn’t always feasible. [Erich Wegscheider](/company/team/#ewegscheider), talent operations specialist at GitLab, knows firsthand that [not all remote is created equal](/blog/not-all-remote-is-created-equal/).\n\nErich went to Europe for a few weeks while working remotely at a previous job with big plans to travel and work. But because he was tethered to working Pacific Time hours, the logistics made setting up an effective workday a challenge.\n\n“Sure, I was ‘remote,’ but the reality was that I worked in the equivalent of a satellite office by myself,” says Erich in a previous post. “Another detractor to working remotely was that it wasn’t conducive to my career development. Given that my colleagues worked at the office in California, the opportunity to lead or manage a team wasn’t presented, given my desire for location independence.”\n\nToday, Erich is able to balance career advancement with wanderlust. He’s currently delivering results for GitLab while lounging beachside from Bali before heading out to a new location as part of the adventure of a lifetime with [WiFi Tribe](https://wifitribe.co/).\n\nErich’s experience of working from Bali is hardly an anomaly at an all-remote company like GitLab. In fact, if GitLab somehow had geolocation enabled on our [contribute graphs](/blog/how-do-you-contribute/), you’d find code pushed from vans, hammocks, and likely some ancient ruins too. Where WiFi is enabled, GitLab is there.\n\n## “Where are you calling from now?”\n\nCaroline, people experience associate at GitLab, turned heads during our daily breakout call earlier this month by dispatching from [Chiostro del Bramante](https://www.chiostrodelbramante.it/), a stunning art museum in Rome.\n\n![Breakout call at Chiostro del Bramante](https://about.gitlab.com/images/blogimages/allremote-travel/breakoutcall.jpg){: .shadow.medium.center}\nCaroline joins our breakout call from the Chiostro del Bramante art museum in Rome.\n{: .note.text-center}\n\n“There is a coffee bar on the first floor with an outdoor sitting area overlooking the atrium,” says Caroline. “Hands down the best suggestion I have gotten from [workfrom.co](https://workfrom.co/) which is my number one go-to place to find ‘anything with good WiFi’ to work from when I land in a new city.”\n\nIt’s good to have these resources, because Caroline finds herself working from a new city often. Her visit to Chiostro del Bramante was right in the middle of her two-month long tour of Europe.\n\n“I started from Berlin, Germany, and have traveled to Prague, Czechoslovakia; Vienna, Austria; Budapest, Hungary; Zagreb, Serbia; Venice, Milan, Florence, and Rome in Italy; Barcelona and Madrid, Spain, and now Lisbon, Portugal” says Caroline. “From here I intend to proceed on Paris, Lyon, and Marseilles in France; Brussels, Belgium; Amsterdam, Netherlands; Geneva, Switzerland; Greece and Santorini, and finally Qatar before I return back home.”\n\n“I am a nature-holic and I always try to find the hidden parks and waterfalls, even in big cities,” says Caroline. “But this has been a big city tour because I am a village girl and curiosity won't let me. I plan to do another rural places trip next year in most of these countries.”\n\nCaroline lives in Nairobi, Kenya on a small half urban, half rural community called [Kinoo](https://www.google.com/maps/place/Kinoo,+Kikuyu,+Kenya/@-1.2520949,36.6834461,15z/data=!3m1!4b1!4m5!3m4!1s0x182f1ed5ba8b4527:0x1c9818f290cb069!8m2!3d-1.2526258!4d36.6930253) “with lots of tea leaves and sheep.”\n\n[Mike Miranda](/company/team/#mikemiranda), SMB professional advocate at GitLab, lives roughly 9,600 miles from Kinoo in Los Angeles, CA, but like Caroline, he has a full passport from his time working at GitLab.\n\nMike spent about half of 2019 globetrotting, and traveled quite a bit in 2018 as well, visiting: Amsterdam, Netherlands; Sofia, Bulgaria; Kyiv, Ukraine; Izmail, Ukraine; London, England; Budapest, Hungary; Dublin, Ireland; Lisbon and Porto in Portugal; Krakow, Poland; Barcelona and Madrid, Spain; Tel Aviv, Israel; Jerusalem, Israel; returning to Spain in Pamplona; Belgrade, Serbia; Berlin, Germany; Paris, France; Florence, Italy; circling back to Germany in Cologne; Burgas, Bulgaria, and even more cities across the United States, all while working for GitLab full-time.\n\nUnlike Caroline, Mike tends to gravitate more toward urban environments while traveling, but also loves visiting some rural locations as well: “I prefer the hidden gems though I definitely spent plenty of time in classic tourist cities.”\n\n## GitLab wants you to travel and visit team members\n\nGitLab’s all-remote set-up introduces a world of possibilities to our team members, many of whom saw their travel opportunities restricted in the past by colocated workspaces. So, when the opportunities are endless, which direction do you head?\n\nWhy not take a page out of [Douwe Maan](/company/team/#DouweM) and [Robert Speicher](/company/team/#rspeicher)’s playbook, and visit your colleagues with the help of GitLab. After all, GitLab has more than 888 team members across 57 countries and regions on five continents (these numbers are always growing!). The [GitLab visiting grant](/handbook/incentives/#visiting-grant) will help you pay for your travels, allotting $150 toward your transportation costs for each GitLab team member that you see on your journey. For example, if you have plans to travel to the San Francisco Bay Area to visit family and join a coworking day with six local GitLabbers, up to $900 in travel costs (6 x 150 = 900) will be reimbursed.\n\nThis program was inspired by Douwe and Robert, who spent six months of 2016 [traveling around the world](/blog/around-the-world-in-6-releases/), visiting 49 colleagues in 20 cities on all five continents. Their journey started in Robert’s home in Washington D.C., and ended in Douwe’s home in Amsterdam. This experience opened up a new perspective not just on how our colleagues live but how they worked as well.\n\n“While you hear about things going on in people's lives, about the places they live, and about issues they face, it's hard to truly appreciate and understand these different perspectives at a distance of hundreds, thousands, or tens of thousands of miles,” writes Douwe in a previous post. “Visiting them, getting to know them in their ‘natural habitat,’ and experiencing some bits of their life yourself, brings you closer to that understanding than anything else.”\n\nFor instance, [a day in the life of a GitLab team member](/blog/day-in-the-life-remote-worker/) based in the United States is different from an Asia-Pacific (APAC)-based team member, as time zones create major differences in when Slack is buzzing, when the company call is, etc.\n\n## The biggest challenges facing digital nomads\n\n[GitLab prioritizes written, asynchronous communication](/handbook/communication/#introduction), which is largely why all remote works so effectively for our company. But sometimes, you have to take the inconveniently timed meeting anyway. Caroline says being available for meetings across different time zones has been one of the biggest challenges with global travel.\n\n“The biggest part of what [being] a digital nomad involves is having the flexibility to determine your hours and find a perfect balance between work and discovering your current location,” says Caroline. “Meetings are usually fixed times that sometimes just mess up your entire preplanned flow. I have learned to be flexible. To interrupt an afternoon of site-seeing with a quick dash into a coffee shop for a quick meeting or to plan my day around a meeting.”\n\nErich is in Bali, so he’s currently in the APAC time zone. This means his evenings typically conclude with a few work-related calls and meetings.\n\n![The Mocca in Canggu, Bali](https://about.gitlab.com/images/blogimages/allremote-travel/the-mocca-canggu.jpg){: .shadow.small.center}\nThe Mocca is one of the cafes Erich works at during his time in Canggu, Bali.\n{: .note.text-center}\n\n“Another fun part about being on APAC time, when the Americas is the norm, is that weekends are shifted,” says Erich. “It's a 12-hour time difference to Eastern Time and 15 to Pacific, so Monday is essentially my Sunday. That means I usually work Saturday morning, but that's been fine by me thus far! The schedule allows plenty of time to get out and explore. Best of all, Mondays are generally quiet travel-wise, so it's a great time to move around the island as well.”\n\nMike experienced everything from whitewater rafting in Sofia, Bulgaria to thermal bath parties in Budapest, Hungary during his time abroad, but life as a digital nomad isn’t one giant vacation.\n\n“Timezone was initially a challenge and that required being intentional about a schedule and sticking with it,” says Mike. “Also, it was difficult to get into a comfortable routine and sometimes taxing to constantly be living out of a suitcase.”\n\nFor Mike, establishing a routine became critical to staying centered in ever-changing environments: “I would identify a coworking space or understand if the WiFi would work well for calls, know where and how I would exercise, know my work hours given the timezone.”\n\nBut his most important advice? Enjoy the adventure.\n\n“While it's not a vacation, make sure you take your work hours seriously and outside of that time enjoy the city you're in and the people you're around – I can't overstate how important it is to unplug.”\n\nCover Photo by Trinity Treft on Unsplash.\n{: .note}\n",[9,683],{"slug":1592,"featured":6,"template":687},"how-to-push-code-from-a-hammock","content:en-us:blog:how-to-push-code-from-a-hammock.yml","How To Push Code From A Hammock","en-us/blog/how-to-push-code-from-a-hammock.yml","en-us/blog/how-to-push-code-from-a-hammock",{"_path":1598,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1599,"content":1605,"config":1611,"_id":1613,"_type":14,"title":1600,"_source":16,"_file":1614,"_stem":1615,"_extension":19},"/en-us/blog/how-to-stay-productive-in-your-home-office",{"title":1600,"description":1601,"ogTitle":1600,"ogDescription":1601,"noIndex":6,"ogImage":1602,"ogUrl":1603,"ogSiteName":673,"ogType":674,"canonicalUrls":1603,"schema":1604},"How To Stay Productive In Your Home Office","GitLab Developer Brandon Lyon shares his tips on setting up home offices for remote work.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679685/Blog/Hero%20Images/blog-bl-desk.jpg","https://about.gitlab.com/blog/how-to-stay-productive-in-your-home-office","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How To Stay Productive In Your Home Office\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brandon Lyon\"}],\n        \"datePublished\": \"2019-11-06\",\n      }",{"title":1600,"description":1601,"authors":1606,"heroImage":1602,"date":1608,"body":1609,"category":729,"tags":1610},[1607],"Brandon Lyon","2019-11-06","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nRemote work requires a special blend of detached discipline and solo mental fortitude in order to stay productive. Keep your focus and stay sharp with these tips. Make your dream a reality. Create your own schedule and cut out the commute.\n\n## Improve your environment\n\n> Focused work requires a focused space.\n\nWorking from your dining table or couch with a laptop doesn’t  always work well. You’ll want to choose a room which can be closed off from the rest of the house. Keep it presentable for remote conferencing or surprise video chats. Make sure there’s adequate room for you and your supplies and don’t skimp on equipment.\n\nOne great thing about working from home is that you can choose your own furniture. Don’t be afraid to invest in some quality pieces. You’ll be spending most of your time there, so be sure that it’s comfortable and functional. In addition to the obvious desk and chair, **every office should have a whiteboard, a cork board, sticky notes, and a bookcase.** Display some knick-knacks and cool gadgets just as you would in a corporate office, but keep the clutter to a minimum.\n\n## Obtain reliable tools\n\n> Make sure everything in your dedicated work space is reliable.\n\nBuy a battery backup. Ensure the room has plenty of outlets and chargers (you can never have too many). Get a good webcam with a noise-cancelling microphone for video chats and conference calls. Keep a local and offsite backup of computer files. Keep important documents in a fireproof and flood resistant safe. These are all things you should be doing anyway, but it’s important to take extra care when working from home.\n\nNetwork quality can have a huge impact on remote work. Buy a high-quality router. [Get decent cables](https://www.howtogeek.com/210326/not-all-ethernet-cables-are-equal-you-can-get-faster-lan-speeds-by-upgrading/) to go with that new router (old kinked or frayed cables can impact connection quality). [Optimize your wifi](https://broadbandnow.com/guides/optimize-wifi-network-faster-speeds). Take some time to implement [quality of service](https://www.pcworld.com/article/2689995/quality-of-service-explained-how-routers-with-strong-qos-make-better-home-networks.html) (QoS) rules in your router and prioritize your work computer over the rest of the household. Chances are your ISP’s DNS settings aren’t great either, so I suggest using a service like [1.1.1.1](https://1.1.1.1/dns/). Get at least one reliable and fast internet service provider. You should consider getting a second ISP as a redundant failover or to keep your work internet separate from your home internet.\n\n## Stay focused\n\n> Do whatever you can to protect yourself from distractions.\n\nKeep your cellphone on silent/vibrate, just like you would in a normal office environment. Family and friends are not lounging around at a regular office interrupting people, and you should communicate that you have similar expectations for your home office. Don’t keep any distracting personal media on your work computer since TV, movies, and video games can be tempting. Use the internet from your home office in the same way you would use it from a regular office. Don’t get distracted by memes or Facebook.\n\n## Separate work and home\n\n> Clear boundaries are essential.\n\nIt can be difficult even under normal circumstances to separate work from your home life. When working from a home office it’s even more challenging. There are small changes you can make to help manage that separation.\n\nWhen you’re in work mode you might use a *desktop* computer from a *standing* desk with the *curtains closed* while using *headphones*. When you’re not working, you could use a *tablet* from a *sitting* desk with the *curtains open* while using *speakers*. You can do a similar thing with software, using *different browsers* for work and personal tasks to maintain separation. Little things like this will go a long way in keeping you productive during work hours.\n\n## Stay sane\n\n> Do something outside before “going to“ work or “coming home“.\n\nBeing in the same place too long can contribute to cabin fever. Try doing something extra like exercising or visiting a cafe. Don’t forget to take breaks while working, your eyes and your back will thank you.\n\nIt’s easy to lose track of time when you’re working alone, so *set alarms for the start and end of your workday.* After the day is over make sure to step outside for a while. Take a walk or go out to dinner to decompress and change the scenery. Being at home on weekdays makes it even more important to leave the house on weekends, so make time to head to the park, to the beach, or check out a pub in the neighboring town.\n\n## Just another day at the office\n\nWhile working from home provides some additional freedoms that a traditional office does not, I recommend treating it much like a regular office. It takes a good toolset, professional environment, and discipline to stay productive and produce good work, whether or not you have a supervisor looking over your shoulder.\n",[9],{"slug":1612,"featured":6,"template":687},"how-to-stay-productive-in-your-home-office","content:en-us:blog:how-to-stay-productive-in-your-home-office.yml","en-us/blog/how-to-stay-productive-in-your-home-office.yml","en-us/blog/how-to-stay-productive-in-your-home-office",{"_path":1617,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1618,"content":1624,"config":1631,"_id":1633,"_type":14,"title":1634,"_source":16,"_file":1635,"_stem":1636,"_extension":19},"/en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo",{"title":1619,"description":1620,"ogTitle":1619,"ogDescription":1620,"noIndex":6,"ogImage":1621,"ogUrl":1622,"ogSiteName":673,"ogType":674,"canonicalUrls":1622,"schema":1623},"How we are closing the gap on replicating *everything* in GitLab Geo","Developing an internal framework to enable other teams to add Geo support for their features","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669673/Blog/Hero%20Images/engineering.png","https://about.gitlab.com/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we are closing the gap on replicating *everything* in GitLab Geo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Kozono\"}],\n        \"datePublished\": \"2021-04-29\",\n      }",{"title":1619,"description":1620,"authors":1625,"heroImage":1621,"date":1627,"body":1628,"category":729,"tags":1629},[1626],"Michael Kozono","2021-04-29","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIn early 2020, it took 3.5 months of solid work to implement replication of a new data type in Geo. One year later, support can be added within a month -- including development and all required reviews. How did we do it? First, let me introduce you to Geo.\n\n## What is Geo?\n\n[GitLab Geo](https://about.gitlab.comhttps://docs.gitlab.com/ee/administration/geo/index.html) is the solution for widely distributed development teams and for providing a warm-standby as part of a disaster recovery strategy. Geo replicates your GitLab instance to one or more local, read-only instances.\n\n## What are data types?\n\n[GitLab Geo was released in June 2016 with GitLab 8.9](https://about.gitlab.com/releases/2016/06/22/gitlab-8-9-released/#gitlab-geo-new-product) with the ability to replicate project repositories to a read-only secondary GitLab site. Developers located near secondary sites could fetch project repositories as quickly as if they were near the primary.\n\nBut what about wiki repositories? What about LFS objects or CI job artifacts? In GitLab, each of these things is represented by different Ruby classes, database tables, and storage configurations. In Geo, we call these data types.\n\n## Is it really that hard to copy data?\n\nWhen we say a new data type is supported by Geo, this is what we mean:\n\n* Backfill existing data to Geo secondary sites\n* As fast as possible, replicate new or updated data to Geo secondary sites\n* As fast as possible, replicate deletions to Geo secondary sites\n* Retry replication if it fails, for example due to a transient network failure\n* Eventually recover missing or inconsistent data, for example if Sidekiq jobs are lost, or if infrastructure fails\n* Exclude data according to [selective sync settings](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization) on each Geo secondary site\n* Exclude remote stored data unless [Allow this secondary node to replicate content on Object Storage](https://docs.gitlab.com/ee/administration/geo/replication/object_storage.html#enabling-gitlab-managed-object-storage-replication) is enabled on a Geo secondary site\n* Verify data integrity against the primary data, after replication\n* Re-verify data integrity at regular intervals\n* Report metrics to Prometheus\n* Report metrics in the Admin UI\n* View replication and verification status of any individual record in the Admin UI\n* Replication and verification job concurrency is configurable in Admin UI\n* Retry replication if data mismatch is detected ([coming soon to all data types using the framework](https://gitlab.com/gitlab-org/gitlab/-/issues/301244))\n* Allow manual re-replication and re-verification in the Admin UI ([coming soon to all data types using the framework](https://gitlab.com/gitlab-org/gitlab/-/issues/216100))\n* And more\n\n## How to iterate yourself into a problem\n\n[Iteration is a core value](https://handbook.gitlab.com/handbook/values/#iteration) at GitLab. In the case of Geo, by [GitLab 12.3](https://about.gitlab.com/releases/2019/09/22/gitlab-12-3-released/#geo-natively-supports-docker-registry-replication) we had added replication support for the most important data types, for example:\n\n* Project Git repositories\n* Project wiki Git repositories\n* Issue/MR/Epic attachments\n* LFS objects\n* CI job artifacts\n* Container/Docker registry\n\nAnd we had added a slew of features around these data types. But suddenly it was clear we had a problem. **We were falling behind in the race to replicate and verify all of GitLab's data.**\n\n* A new data type was being added by other teams, every few months. It was painful to prioritize 3 months of development time only to add replication to one data type. And even if we caught up, the latest features would always be unsupported by Geo for 3 months.\n* Automatic verification of Project and Wiki repositories was implemented, but adding it to a single data type was going to take 3 months.\n* Maintenance and other new features were increasing in effort due to the amount of code duplication.\n* Our event architecture needed too much boilerplate and overhead to add new events\n\n## How to iterate yourself out of a problem\n\nJust because it's possible to iterate yourself into a problem doesn't mean iteration failed you. Yes, ideally we would have seen this coming earlier. But consider that fast and small iteration has likely saved many hours of upfront work on features that have been quickly validated, and have since been changed or removed. It's also possible to [DRY up](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) code too soon into bad abstractions, which can be painful to tear apart.\n\nBut we reached a point where everyone agreed that the most efficient way forward required consolidating existing code.\n\n### Do the design work\n\n[Fabian](https://gitlab.com/fzimmer), our esteemed product manager, [proposed an epic](https://gitlab.com/groups/gitlab-org/-/epics/2161):\n\n> to build a new geo replication and verification framework with the explicit goal of enabling teams across GitLab to add new data types in a way that supports geo replication out of the box\n\nMost of the logic listed above in [Is it really that hard to copy data?](#is-it-really-that-hard-to-copy-data) is exactly the same for all data types. An internal framework could be used to significantly reduce duplication, which could deliver huge benefits:\n\n* Bugs in the framework only have to be fixed once, increasing reliability and maintainability.\n* New features could be added to the framework for all data types at once, increasing velocity and consistency.\n* Implementation details would be better hidden. Changes outside the framework become safer and easier.\n\nThe proposal went further than making it easy for *ourselves* to add Geo support to new data types. The goal was to make it easy for *non-Geo engineers* to do so. To achieve this goal, the framework must be easy to use, easy to understand, and well-documented. Besides the usual benefits of reducing duplication, this higher standard would help:\n\n* Minimize the effort to implement Geo support of new features, whether it's done by a Geo engineer or not.\n* Minimize lag time to add Geo support. If it's easy to do, and anyone can do it, then it's easy to prioritize.\n* Increase awareness in other teams that new features may require Geo support.\n* Influence the planning of new features. There are ways to make it more difficult to add Geo support. This is much easier to avoid during initial planning.\n\nAs a first step, Fabian [proposed creating a proof of concept of a framework](https://gitlab.com/gitlab-org/gitlab/-/issues/35540) leveraging lessons learned and incorporating improvements we already wanted to make to the existing architecture. The issue stimulated lots of design discussion in the team, as well as multiple POCs riffing off one another.\n\nThe biggest change was the introduction of a `Replicator` class which could be subclassed for every data type. The subclasses would contain the vast majority of the specifics to each data type.\n\nIn order to further reduce duplication, we also introduced the concept of a `Replicator strategy`. Most data types in GitLab could be categorized as blobs (simple files) or Git repositories. Within these categories, there was relatively little logic that needed to be specific to each data type. So we could encapsulate the logic specific to these categories in strategies.\n\nAnother significant decision was to make the event system more flexible and lightweight. We wanted to be able to quickly implement new kinds of events for a `Replicator`. We decided to do this without rewriting the entire event processing layer, by packaging and transmitting `Replicator` events within a single, generic event leveraging the existing heavyweight event system. We could then leave the old system behind, and after migrating all data types to the framework, we could easily replace it.\n\nOnce a vision is chosen, it can be difficult to see how to get there with small iterations. But there are often many ways to go about it.\n\n### Code\n\n#### High-level approach\n\nAt a high-level, we could have achieved our goal by taking two data types that were already supported, DRYing up their code, and refactoring toward the desired architecture. This is a proven, safe, and effective method.\n\nBut to me it felt more palatable overall to deliver customer value along the way, by adding support for a brand-new data type while developing the reusable framework. We already had practice implementing many data types, so there was little risk that we would, for example, take too long or use suboptimal abstractions. So we decided to do this with [Package registry](https://docs.gitlab.com/ee/user/packages/).\n\n#### Lay the foundation\n\nOur POCs already answered the biggest open questions about the shape of the architecture. The next step was to get enough of a skeleton merged, as quickly as possible, so that we could unlock further parallel work. To ensure correctness, we aimed to get something working end-to-end. We decided to implement \"replication of newly created Package files\". Much was left out, for example:\n\n* Replication of changes. (Most Blob types, including Package files, are immutable anyway)\n* Replication of deletes\n* Backfill of existing files\n* Verification was left out entirely from the scope of the first epic, since we already knew replication alone provides most of the value to users.\n\nSince the work still required many specific design decisions, we decided to [pair program](https://en.wikipedia.org/wiki/Pair_programming). [Gabriel Mazetto](https://gitlab.com/brodock) and I used [Zoom](https://zoom.us/) and [Visual Studio Live Share](https://visualstudio.microsoft.com/services/live-share/), which worked well for us, though there are many options available. [See a recording of our first call](https://www.youtube.com/watch?v=2XedCiU634s).\n\n[The spike](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23447) was merged and we thought ourselves safe under the feature flag. Looking back on this particular merge request, we did make a couple mistakes:\n\n1. An [autoloading bug was discovered](https://gitlab.com/gitlab-org/gitlab/-/issues/202044). The merge request was reverted, fixed, and remerged. Thanks to [CI](https://docs.gitlab.com/ee/ci/) and end-to-end QA tests using actual builds, the impact was limited.\n1. The size of the spike was unnecessarily large and difficult to review for a single merge request. As it grew, we should have used it as a \"reference\" merge request from which we could break out smaller merge requests. Since then, GitLab policies have further emphasized [smaller iterations](https://about.gitlab.com/handbook/product/product-principles/#iteration).\n\n#### Build on the foundation\n\nWith the skeleton of the framework in the main branch, we could implement multiple features without excessive conflicts or coordination. The feature flag was enabled on [GitLab's staging environment](https://about.gitlab.com/handbook/engineering/development/enablement/systems/geo/staging.html), and each additional slice of functionality was tested as it was merged. And new issues for bugs and missing features were opened.\n\nWe built up the [developer documentation](https://docs.gitlab.com/ee/development/geo/framework.html) as we went along. In particular, we documented specific instructions to implement a new data type, aimed at developers with no prior knowledge of Geo. These instructions have since been moved to issue templates. For example, [this is the template for adding support to a new Git repository type](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Geo%20Replicate%20a%20new%20Git%20repository%20type.md). This caught a lot of would-be pain points for users of the framework.\n\nFinally, we released [Geo supports replicating GitLab Package Registries in GitLab 13.2](https://about.gitlab.com/releases/2020/07/22/gitlab-13-2-released/#geo-supports-replicating-gitlab-package-registries)!\n\n## Reaping the benefits\n\nFollowing the release of Geo support for Package Registries, we added support for many new data types in quick succession. Automatic verification was added to the framework. This recently culminated in a non-Geo engineer implementing replication *and verification* for a new data type, within one month!\n\n* In GitLab 13.5, [Geo replicates external merge request diffs and Terraform state files](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#geo-replicates-external-merge-request-diffs-and-terraform-state-files). These were added by Geo engineers who had been less involved in building the framework. Many refinements to the framework, and especially to the documentation, came out of this.\n* In GitLab 13.7, [Geo supports replicating Versioned Snippets](https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#geo-supports-replicating-versioned-snippets). This was also added by a Geo engineer, and it was the first Git repository type in the framework, so it required more work than adding new Blob types.\n* In GitLab 13.10:\n  * [Geo supports replicating Group wikis](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#geo-supports-replicating-group-wikis) was implemented by a non-Geo engineer.\n  * [Geo verifies replicated package files](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#geo-verifies-replicated-package-files). This was a big new feature in the framework, adding automatic verification to any data type that can be checksummed.\n* GitLab 13.11:\n  * [Geo supports Pipeline Artifacts](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#geo-supports-pipeline-artifacts) was implemented by a non-Geo engineer.\n  * [Geo verifies replicated Versioned Snippets](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#geo-verifies-replicated-versioned-snippets).\n* GitLab 13.12:\n  * [An already supported data type, LFS objects, is migrated to the framework under feature flag](https://gitlab.com/gitlab-org/gitlab/-/issues/276696). Following this will be the migration of \"Uploads\" and \"CI Job artifacts\", and then **deleting thousands of lines of code**. This should improve both reliability and velocity, for example, verification will be added to these data types.\n\nIn aggregate:\n\n* In GitLab 12.9, we replicated ~56% of all data types (13 out of 23 in total) and verified ~22%.\n* In GitLab 13.11, we replicate ~86% of all data types (25 out of 29 in total) and verify ~45%.\n* **In the last year, GitLab released six new features that needed Geo support. We replicate 100% of those new features and verify ~57%.**\n\n## What did it cost?\n\nFor comparison, it took around 3.5 months to [implement replication of Design repositories](https://gitlab.com/groups/gitlab-org/-/epics/1633). It took around 6 months to [implement the framework for replication of Package files](https://gitlab.com/groups/gitlab-org/-/epics/2346). So the cost to produce the framework for replication was roughly 2.5 months of work.\n\nWe don't really have a comparable for [implementation of verification](https://gitlab.com/groups/gitlab-org/-/epics/1817), but it looked like it would take about 3 months to implement for a single data type, while it took about 4 months total to implement for Package files and simultaneously add to the framework, for a cost of about 1 month.\n\nGiven that new data types now take about 1 month to implement replication *and verification*, the work to produce the framework **paid for itself with the implementation of a single data type**. All the rest of the benefits and time saved are more icing on the cake.\n\nMy only regret is that we should have done it sooner. I intend to be more cognizant of this kind of opportunity in the future.\n\n## What to expect in the future\n\n* [Already supported data types will be migrated into the framework](https://gitlab.com/groups/gitlab-org/-/epics/3588)\n* New features will be added more quickly, for example, verification will be rolled out for all [Blob](https://gitlab.com/groups/gitlab-org/-/epics/5285) and [Git repository](https://gitlab.com/groups/gitlab-org/-/epics/5286) data types\n* Duplication will be further reduced, for example, by [leveraging Rails generators](https://gitlab.com/gitlab-org/gitlab/-/issues/326842)\n\nHuge thanks to everyone who contributed to closing the gap on replicating *everything* in Geo!\n",[1630,731,732,707,683,9,899],"agile",{"slug":1632,"featured":6,"template":687},"how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo","content:en-us:blog:how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo.yml","How We Are Closing The Gap On Replicating Everything In Gitlab Geo","en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo.yml","en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo",{"_path":1638,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1639,"content":1645,"config":1650,"_id":1652,"_type":14,"title":1653,"_source":16,"_file":1654,"_stem":1655,"_extension":19},"/en-us/blog/how-we-scaled-our-summits",{"title":1640,"description":1641,"ogTitle":1640,"ogDescription":1641,"noIndex":6,"ogImage":1642,"ogUrl":1643,"ogSiteName":673,"ogType":674,"canonicalUrls":1643,"schema":1644},"How we double the GitLab summit every year","Take a deep dive into the evolution of our summit, GitLab Contribute, keeping pace with a company that practically doubles in size annually.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673134/Blog/Hero%20Images/scale-our-summits.jpg","https://about.gitlab.com/blog/how-we-scaled-our-summits","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we double the GitLab summit every year\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-09-02\",\n      }",{"title":1640,"description":1641,"authors":1646,"heroImage":1642,"date":1647,"body":1648,"category":705,"tags":1649},[812],"2019-09-02","\nSince fewer than 10 GitLabbers convened in [Serbia for the first summit in 2013](/company/culture/contribute/previous/#summit-in-novi-sad-serbia), the annual meeting has nearly [doubled in size](/company/culture/contribute/previous/#back-in-the-day) each year, in tandem with the growth of our company. GitLab is projected to grow from a team of more than 830 today to more than 1,200 by 2020. The attendance list is getting (much) larger and the logistics more complex. We dive into the nuts and bolts of how our summit scales along with our community.\n\n## What is GitLab Contribute?\n\nFirst, let’s start with what it’s not: [Contribute](/events/gitlab-contribute/) is not an incentive trip, it’s not a conference, and it’s not a vacation. Contribute isn’t mandatory, but it is a unique opportunity to bring the minds that power GitLab together in one place. In 2019 the annual summit was renamed to “Contribute” to better reflect the intention of the experience: to build community with our colleagues and get some work done!\n\nBut just like Rome (which, unfortunately, is not a feasible host city for 2020), Contribute isn’t built in a day. There are numerous considerations that go into creating a successful program, including the location, logistics, program, and creating opportunities for team members to connect.\n\n## Start with the numbers\n\nThe planning process always starts with the most crucial number: the projected attendee list. We had roughly 575 folks (including some significant others) attend Contribute 2019, which is consistent with the 86% attendance rate we’ve seen with past summits, and is about double the number of attendees for our [Cape Town summit](/blog/gitlab-summit-cape-town-recap/).\n\nOur attendance projections for 2020 are double the 2019 numbers at about 1,186. That number of attendees necessitates moving into a different caliber of hotel that includes enough rooms, meeting spaces, and amenities to host more than 1,200 people at a time in a single place.\n\n## Logistics\n\n“The biggest challenge is keeping everybody together,” says [Kirsten Abma](/company/team/#kirstenabma), our corporate events manager. “For Contribute 2019 it would have been pretty doable to keep everybody together in one place, even if we hadn’t gone to New Orleans, but it’s getting trickier for 2020 and it’s going to get even trickier in 2021.”\n\nWhen evaluating a destination, Kirsten lists a few key considerations that narrow down the options:\n\n*   **Cost of transportation:** How much does it cost to bring our globally distributed team to one location?\n*   **Visas:** Is it simple for most community members to get a visa for this destination?\n*   **Number of hotel rooms:** Does the hotel have enough single and double rooms to meet our baseline requirements?\n*   **Meeting spaces:** Can we fit 1,200 people in this ballroom? Are there enough breakout rooms for the number of concurrent sessions?\n\nWorldwide, there are very few locations with hotels large enough to accommodate such a big group, and (sadly) popular vacation destinations and old-world cities are generally excluded from the list for this reason.\n\n“Paris, for example, is a great place to go – for excursions there are so many options. It’s really accessible too; there are a lot of flights going to Paris, Europeans can even take trains or drive. But then all the hotels cap at 500 rooms, and we’re asking for 1,000 rooms and for Contribute 2021 we need more than 1,600, so it’s not going to work.” In other words, GitLab won't always have Paris, unfortunately.\n\nOther factors that go into selecting a meeting space include:\n\n*   **Catering:** Can 1,000 people all dine within 1-2 hours? Can the hotel accommodate dietary restrictions?\n*   **Amenities**: Does the hotel have a restaurant, a gym, and a bar?\n*   **Lastly, the vibe**: Is the hotel crisp and clean? Does it have air conditioning? How do the beds feel? Does the hotel layout make sense?\n\nIn New Orleans, there were three hotels that were contenders, but the Hyatt, where [Contribute 2019](/blog/contribute-wrap-up/) was hosted, won out.\n\n“We walked into the Hyatt. We went up the escalators and we looked around and we knew ‘Yeah this is it,’” says Kirsten. “We instantly knew this was a great vibe. We knew that if it could fit our budget then it was our number one choice.”\n\n## Implementation\n\nThere are about 25 locations that are potential contenders for Contribute 2020 and 2021 based on our attendee list and other projections.\n\nThe corporate events team works with an agent that brokers contracts with the hotels so GitLab gets the most favorable deal possible. The first step is to send our request for proposals (RFP) to hotels in the locations we are considering. This helps us get the specs on different hotels and can help us whittle down our list to a few locations. Once it's down to between 3-5 locations, the events team begins site visits.\n\nThe next step is to reach out to local partners in those locations. Finding a good [destination management company](https://en.wikipedia.org/wiki/Destination_management) (DMC) is crucial to running a smooth event. The DMC has existing relationships with local vendors and can help broker deals on everything from airport transportation, to finding the best excursions, to even the tiniest details that add texture to the whole experience.\n\n“We always try to stay local and really show off the place we’re visiting, its history, things that are significant to that location,” says Kirsten. “These DMCs know everything about everyone and all the local vendors. So when we said we want glow-in-the-dark cotton candy for our masquerade ball in New Orleans, we got it.”\n\nYou have to be nimble in order to be a good event planner, and our events team often changes things up at the last minute. Some partners have difficulty adapting to how quickly we update our events to suit the particular circumstances (H/T to Meg Baird with [NOLA DMC](https://www.noladmc.com) who really pulled through on these things).\n\n“Our partners have to get used to the speed that we work at, because GitLab moves fast and so does our team. There are some venues that are like, ‘What? You mean tomorrow? No!’ Then we’re like ‘Yeah, let’s do this!’” We are literally changing up everything pretty much every week.”\n\n## Activities\n\nCreating a program to keep more than 1,000 people occupied for 4-5 days is one of the biggest challenges of scaling up the Contribute program.\n\n“I think one of the biggest evolutions is that previously we had everybody in the same session, or had broken it up into three or four sessions but the bigger you get the harder that becomes.”\n\n### Unconference sessions\n\nThe unconference sessions were piloted during the 2018 Cape Town summit, and were formalized into the Contribute program in 2019 because they received such a positive reception from attendees. The unconference sessions offer a break from work-related activities and allow team members to connect through games and shared interests. Many of the sessions bore tangible results, such as building a [blog post](/blog/day-in-the-life-remote-worker/) through a game of broken telephone to organizing more [volunteer opportunities](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4437) for GitLab team members.\n\n### Workshops\n\nFormal workshops were introduced this year as a platform for knowledge transfer and exchange. Through these workshops, folks can learn more from their colleagues about different topics they are highly skilled at or use on a daily basis, such as [GitLab 101](https://docs.google.com/presentation/d/e/2PACX-1vTeGh5vq4yHk6NgzTDsKRGbf-NDwzQwRfjnr7jwqfce282h5k4C_xRGUOE1WWwxsj9rEg8Z5UGNT6aj/pub?start=false&loop=false&delayms=3000). Other workshops centered around implementing GitLab’s values – in a packed workshop about recognizing and mitigating unconscious bias we made improvements to the GitLab handbook.\n\n“There will be a lot more to choose from going forward and I think that’s a great change for the program as well,” says Kirsten. “There will basically be something for anyone at any time of day during Contribute.”\n\nFor Contribute 2020 and onward, we are going to introduce different types of sessions such as AMAs, team building, panels, and additional fireside chats.\n\n## Connection\n\nAt an all-remote company, the opportunity to get to know people in person is huge and often makes remote collaboration a bit easier. Attendees of Contribute 2019 reflect this sentiment in feedback shared with the corporate events team:\n\n>“In a fully remote company, the opportunity to meet people in person reinforces and deepens the relationship between the company in ways that are invaluable.”\n\n>“Face-to-face time is incredibly valuable in building strong working relationships.”\n\nJust a quick glance at a colleague's [contributions graph](/blog/how-do-you-contribute/) illustrates the depth of collaboration at GitLab, but the kinetic energy that propels these contributions is inspiring when we're all under one roof.\n\n### Getting new hires to Contribute\n\n“It’s really hard to imagine the size of GitLab, the speed that we work at, and the way that we work together if you haven’t seen everybody together,” says Kirsten. This is why the company decided it’s so important that we do everything possible to bring even our newest team members to Contribute.\n\nAt Contribute 2019, there was a group of 60-70 people who essentially signed their contracts and hopped on a plane to New Orleans, and even more who started maybe a week before the annual event kicked off.\n\nIn spite of it being a surreal first week, new team members largely felt the experience was more positive than disorienting: “As a completely new hire it was a great way to initially meet all the people I was going to be working with moving forward.”\n\n“That’s why we push for people to literally have their first day during these events because it really builds a stronger working relationship,” says Kirsten. “We don’t want people to miss out on that feeling for nine months or a year.”\n\nThe events team deliberately created more opportunities for team bonding with department happy hours and team dinners in New Orleans, and will continue to create more team-building events based on a number of requests that this practice continue.\n\n## Iterating our way to 2020\n\nThe motto for the corporate events team is live and learn, says Kirsten. Every year we discover new things that can make implementing the event easier from behind-the-scenes (e.g. booking the ballroom for two days to prepare for the keynote) and a better, more engaging experience for participants (e.g. including a break in the middle of the keynote so folks can stretch their legs).\n\nBased on feedback from a post-Contribute 2019 survey, Kirsten also plans on creating more “unplanned planned” events, such as karaoke or game nights in breakout rooms – activities that were always a feature of past summits but were usually self-organized among participants. But feedback from 2019 did show us that in bigger groups people want to know what they’re in for ahead of time.\n\nThere were also requests to gamify socialization or randomize seating at meal times so there are more opportunities for community members to meet and connect.\n\nWhen your baseline doubles each year, you’re going to have some growing pains while scaling such a huge, complicated event. But for Kirsten, seeing happy GitLabbers bounce through the hotel doors on arrivals day and overhearing the inevitable, “I didn’t know you were so tall!” at breakfast makes the effort worthwhile.\n\n“When the keynote kicks off on day 1 of Contribute, you can see everybody in one space for the first time since the last Contribute 9-12 months ago. I was standing near the doors during that moment in the keynote when all the doors closed, and I just looked around. Every time I see that I get goosebumps because it’s like, ‘Oh my goodness, this is so many more people than I had imagined it would look like!’”\n\nIf you're wondering where we'll go next, it's still a surprise but [keep an eye on our save the date](/events/gitlab-contribute/index.html) because the announcement should happen soon!\n",[683,9],{"slug":1651,"featured":6,"template":687},"how-we-scaled-our-summits","content:en-us:blog:how-we-scaled-our-summits.yml","How We Scaled Our Summits","en-us/blog/how-we-scaled-our-summits.yml","en-us/blog/how-we-scaled-our-summits",{"_path":1657,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1658,"content":1664,"config":1670,"_id":1672,"_type":14,"title":1673,"_source":16,"_file":1674,"_stem":1675,"_extension":19},"/en-us/blog/how-we-turned-40-person-meeting-into-a-podcast",{"title":1659,"description":1660,"ogTitle":1659,"ogDescription":1660,"noIndex":6,"ogImage":1661,"ogUrl":1662,"ogSiteName":673,"ogType":674,"canonicalUrls":1662,"schema":1663},"How we turned a dull weekly all-hands into a podcast","We love asynchronous communication so much that we turned a uninspiring department-wide meeting into an engaging podcast – here's why and how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671055/Blog/Hero%20Images/headphones-colorful-background.jpg","https://about.gitlab.com/blog/how-we-turned-40-person-meeting-into-a-podcast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we turned a dull weekly all-hands into a podcast\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lyle Kozloff\"}],\n        \"datePublished\": \"2019-06-03\",\n      }",{"title":1659,"description":1660,"authors":1665,"heroImage":1661,"date":1667,"body":1668,"category":705,"tags":1669},[1666],"Lyle Kozloff","2019-06-03","\nWe’ve all been there: A department all-hands. At GitLab, we’ve got them too. They’re important: There’s information you need to know, and there’s really only one way to handle it. While it’s true that we’re [all-remote](/company/culture/all-remote/), and everyone joins from their location of choice, they’re still:\n\n - Slow\n - Synchronous\n - Soul-sucking\n\nA few months ago, one of our Support Engineering Managers ([Lee](/company/team/#leematos)) proposed that we try and embrace our value of [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) and [transition this agenda-driven meeting into a pure agenda](https://gitlab.com/gitlab-com/support/support-team-meta/issues/1394), and remove the need for face-to-face communication.\n\nMaking a big transition like this did leave us with some concerns:\n\n### Synchronous meetings can be a chance for people to connect\n\nAt GitLab we recognize the value of getting to know one’s teammates. Employees are encouraged to schedule [coffee chats](/company/culture/all-remote/tips/#coffee-chats) throughout their time at GitLab to get to know one another. (In fact, we think it’s so important that it’s one of the key tasks in [new employee onboarding](https://gitlab.com/gitlab-com/people-group/employment-templates/-/blob/main/.gitlab/issue_templates/onboarding.md#all-gitlabbers) ) We even have a consistent small group of people many of us meet up with (on video) four days a week [to connect on a purely personal level](/handbook/communication/#breakout-call) built into the company calendar. These calls aren’t forced, but attendance is organic and inviting, because you will start to build connections. This is especially important in an all-remote organization.\n\nTeam-level meetings can also be an important time to sync up and have time to banter and share personalities. However, we noticed that as the room grew these interactions became less natural. Within the structure of the meeting we tried to correct this with process: Rotating meeting chairs, asking people to post a “Friday Song,” and including a specific meeting section called “Cheerful Banter.” It didn’t work.\n\nUltimately it was a subset of voices who felt comfortable participating in these ways. Meetings beyond a certain size appear to lose their value as a chance for connection. They were less a conversation and more an address. As a result, we felt that we’d have more results concentrating on other avenues for the support team to express themselves and get to know one another.\n\n>We tried rotating meeting chairs, asking people to post a “Friday Song,” and including a specific meeting section called “Cheerful Banter.” It didn’t work.\n\n### Synchronous meetings are a scheduled touchpoint\n\nWhile all of our meetings are recorded and can be watched after the fact, there’s still something about having a cadence to the week. If there’s a meeting every Friday, I know that my brain will be getting new information on Fridays.\n\nTransitioning to a meeting where there is no actual meeting left us with the challenge of making sure people read the document regularly.\n\nTo solve this, we have two touch points during the week: On Wednesdays we have an automated Slack reminder to put things in the document. On Fridays, we have an automated cut-off message that starts a Slack thread for discussion of the week's items. This structure gives a little bit of “rails” that really help package up the meeting.\n\n### Synchronous meetings (at GitLab) can be a chance to absorb while working on something else\n\nThere’s something about having the ability to turn off your camera (or watch the video after the fact). I, personally, enjoy having the space that being an inactive participant in a conversation allows. I’ll often chop vegetables, fold laundry, or go for a run while listening along.\n\nIn fact, this type of passive listening while working on something else is not discouraged at GitLab, in fact it’s [actively encouraged in our handbook](/handbook/communication/#video-calls).\n\nAs we discussed the idea of changing this meeting, we thought it would work best if there was a format that would be efficient and multi-channel. As a big fan of podcasts myself, I thought that the format might work well.\n\n### Putting it together\n\nIf you’re interested in the nitty gritty details, we’ve made a [workflow about how the podcast is actually put together](/handbook/support/workflows/how-to-WIR-podcast.html) in the Handbook.\n\n![Slackbot reminder](https://about.gitlab.com/images/blogimages/slackbot-week-in-review.png){: .shadow.medium.center}\nSlackbot reminds us to add content to the document every Wednesday\n{: .note.text-center}\n\nBriefly, one or more team members will first take a look at each of the links in a the \"Week in Review\" document and the surrounding narrative to build out a script. They'll next pull metrics from our dashboards surrounding our [performance indicators](https://about.gitlab.com/company/kpis/#engineering-kpis) and other numbers we're tracking, like the [number of pairing sessions](https://gitlab.com/gitlab-com/support/support-training/milestones/7). Finally, all together the final recording, mixing and exporting happens – all before 12:00pm PST when a Slackbot announces the release.\n\nAll said, in many ways the ‘new’ format mirrors the old. We still move issues forward, make announcements, thank one another, review our metrics, and tell personal stories. Managers still wax poetic about the things that managers wax poetic about. Team members (probably) still roll their eyes. The biggest difference is that we’ve compressed an hour of “chair time” for 40 people into 10-15 minutes of anything time. And the data is still shareable, and readable too. I call that a win/win/win.\n\nWant to hear what it actually sounds like? Check out our [Support Week in Review from May 31, 2019](https://drive.google.com/open?id=1irQgehSpD2lxxYHQoQh4gBsHnZQLLMj9).\n\nIn what ways can you more efficiently organize and disseminate information in your organization? Do you think a podcast would help? Let us know in the comments or tweet us [@gitlab](https://twitter.com/gitlab).\n\nPhoto by Matthieu A on Unsplash\n{: .note}\n",[731,707,683,9],{"slug":1671,"featured":6,"template":687},"how-we-turned-40-person-meeting-into-a-podcast","content:en-us:blog:how-we-turned-40-person-meeting-into-a-podcast.yml","How We Turned 40 Person Meeting Into A Podcast","en-us/blog/how-we-turned-40-person-meeting-into-a-podcast.yml","en-us/blog/how-we-turned-40-person-meeting-into-a-podcast",{"_path":1677,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1678,"content":1684,"config":1689,"_id":1691,"_type":14,"title":1692,"_source":16,"_file":1693,"_stem":1694,"_extension":19},"/en-us/blog/imposter-syndrome-and-remote-work",{"title":1679,"description":1680,"ogTitle":1679,"ogDescription":1680,"noIndex":6,"ogImage":1681,"ogUrl":1682,"ogSiteName":673,"ogType":674,"canonicalUrls":1682,"schema":1683},"How to tackle impostor syndrome while working remotely","Isolation can cause impostor syndrome to flourish. We explain how adopting a growth mindset can help stop impostor syndrome in its tracks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681541/Blog/Hero%20Images/done_perfect.jpg","https://about.gitlab.com/blog/imposter-syndrome-and-remote-work","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to tackle impostor syndrome while working remotely\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2020-09-02\",\n      }",{"title":1679,"description":1680,"authors":1685,"heroImage":1681,"date":1686,"body":1687,"category":705,"tags":1688},[812],"2020-09-02","\n\nNow that the pandemic has shifted office operations at countless companies across all industries from in-person to online, many workers are witnessing the informal modes of communication and recognition that come with occupying a shared space all fall away. When you're working remotely, there is simply no opportunity for chance encounters, which means giving and receiving feedback from colleagues and management requires extra effort. It can be easy to feel anxious about whether or not the right people are noticing your hard work, and even when they are, that nagging feeling of doubt, or feeling like an impostor, can derail your efforts before you even begin.\n\n## What is impostor syndrome?\n\nImpostor syndrome comes down to feeling inadequate or undeserving of your success despite objective evidence showing you otherwise, explained [Taylor McCaslin](/company/team/#tmccaslin), Senior Product Manager, Secure:Static Analysis at GitLab, in a presentation on the topic at [GitLab Virtual Contribute](https://www.youtube.com/watch?v=mICmSotKwik&list=PL05JrBw4t0KrGipyfKvBifwFhNE8sjRN_&index=5&t=0s). Impostor syndrome creates a negative script that can obstruct your progress on meaningful projects, slow your journey to achieving your goals, and suck the energy out of your days.\n\nSo how do you slay the vampire that is impostor syndrome?\n\n## The growth mindset\n\nImpostor syndrome manifests in different ways for different people, and in this blog post we introduce different strategies for stopping these negative thought patterns. But one universal approach is adopting a [growth mindset](https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/). On her blog [Brain Pickings](https://www.brainpickings.org/), Maria Popova summarizes the differences between a fixed mindset and a growth mindset:\n\n\"A 'fixed mindset' assumes that our character, intelligence, and creative ability are static givens which we can't change in any meaningful way... A 'growth mindset,' on the other hand, thrives on challenge and sees failure not as evidence of unintelligence but as a heartening springboard for growth and for stretching our existing abilities.\"\n\nThere is no turnkey solution for combatting impostor syndrome, but thinking about times of challenge as opportunities for growth is one way to stop being so hard on yourself.\n\n## Types of impostor syndrome\n\nSometimes remote work can leave you feeling isolated, a cognitive space where impostor syndrome thrives. Whether you've worked remotely for years, or just recently started working remotely due to the COVID-19 pandemic, impostor syndrome might be showing up for you a lot more now than before.\n\n### Perfectionism\n\nPerfectionism is the ultimate trap and creates a vicious cycle of over-thinking and procrastination. The fear of getting started is often rooted in insecurities about laying bare the imperfections that are guaranteed in first iterations.\n\nSoftware development seemingly tries to correct for perfectionist tendencies by prioritizing iteration over perfection, speed over polish.\n\n\"One thing that I'll mention about a perfectionist vampire is that this is why agile is structured the way that it is,\" said Taylor. \"We do these iteration cycles and do innovative work to avoid this build trap where you want something to be so perfect that you never actually ship anything. So it's interesting to see software development taking some of the cues from the struggles of perfectionism to try to get something out and learn quickly.\"\n\nWhen you're working remotely, the options for procrastination are about as long as your household chore list. At GitLab, we recognize that [friends and family come first](/company/family-and-friends-day/), and that sometimes it's better to step away from your devices and go for a walk or start a load of laundry when your brain can no longer compute.\n\nWhen it comes time for the perfectionist to buckle down and produce results, the mantra ought to be: \"don't get it perfect – just get it done.\" In software development, it's always better to ship small, unpolished changes rather than pressuring yourself to send a finished product in one working session. Remember, in the impostor syndrome roshambo – [iteration](https://handbook.gitlab.com/handbook/values/#iteration) beats perfection every time.\n\n### The superhero\n\nWhile the perfectionist is often afraid to get started, the superhero is afraid to stop. The superhero will push themselves harder and further than everyone else to try and prove to themselves and their colleagues that they are not an impostor.\n\n\"[Superheroes] feel that they need success in all aspects of their life, at work, as parents, as partners, and they may feel stressed if they don't get to accomplish something,\" Taylor explained. \"This is something where you can deal with what's called Clark syndrome, where you're trying to be a superhero. At night you're trying to be a parent, during the day, you're trying to do all of these different things that split you in lots of different directions.\"\n\nRemote work means there is more time in your day to, well, work. While great in theory, for the superhero, remote work means that you can easily reach burn out faster than the speed of light. The pressures of producing results, managing a growing team, and being the most supportive family member can send a high-achiever into overdrive.\n\nIf you recognize yourself in this description, it may be time to assess your [burnout levels](https://burnoutindex.org/). If you're in the red zone, it's time to talk to your manager to see how you can better balance the demands of your work with your health and wellbeing.\n\nA note to managers: It is important to recognize that the responsibility of supporting superheroes doesn't just lie on the individual. It is incumbent upon managers to recognize when a team is underresourced and overperforming – is it fair to continue demanding more from your superhero just because you're confident they'll rise to the occasion?\n\n### The natural genius\n\nThe struggle is part of learning, but the growth mindset is particularly challenging for the natural genius to wrap their heads around.\n\n\"When the natural genius has to struggle to work at something, they think that they're a failure,\" said Taylor. \"This is someone who, maybe, school came easy for them or a particular subject made sense, or maybe they were just someone who's an awesome programmer that self-taught themselves. They're used to skills coming easy. And when they have to put in the effort, their brain tells them, 'Oh, no, like you have to work for this. You're not good at this. You are an impostor.'\"\n\nThe natural genius effect is particularly acute in the tech industry, where you're collaborating with a lot of sharp minds with deep knowledge of technology and computers. But as Taylor pointed out, there is no one person with a complete and total understanding of everything about computers and technology.\n\nYou may be collaborating on code produced by someone who knows all about a complex technical topic that is unfamiliar to you. It's easy for the natural genius to conflate a lack of understanding of one technical subject with a lack of knowledge in _all_ technical subjects. While working remotely, it's even easier to get stuck in your head, and asynchronous collaboration means you're not communicating in real-time.\n\nSometimes, in a quest to prove their smarts, the natural genius can overcorrect their feelings of impostor syndrome and dip their toes into the [Dunning-Kruger effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect), which describes a cognitive bias where people with low ability overestimate their capabilities. Don't fall into the trap of trying to write complicated and clever code to impress yourself and your techy colleagues.\n\nA tip: Don't be so hard on yourself. Instead, think about how you would approach your niece and nephew who may be having trouble with a particular subject in school. Would you admonish them for struggling? Hopefully not. Instead, check your ego at the door, embrace a growth mindset, and remember that learning something new is hard, but that doesn't mean you're incapable.\n\n### The lone ranger\n\n\"Soloists, as I call them, feel like they have to accomplish tasks on their own, and if they need to ask for help, it makes them feel like a fraud or a failure,\" said Taylor. \"When in reality, this is not true. It takes an army to build a company, to raise a child, to build a successful career. This is one where asking for help is not a sign of weakness. In fact, it's actually a sign of strength.\"\n\nThe lone ranger complex is alive and well in a remote work set-up. Without your colleagues nearby, the impulse can be to fumble through a challenging workflow instead of reaching out to a colleague with your questions.\n\nWe are encouraged at GitLab to be a [manager of one](https://handbook.gitlab.com/handbook/values/#managers-of-one), meaning the individual is accountable for themselves and their own time, which could create an environment where impostor syndrome flourishes. Still, the company worked hard to encourage collaboration and communication through our [handbook](/handbook/) and the GitLab tool itself. [Collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) is one of our core values, and we have many methods for communication with colleagues when you might get stuck with a question that isn't documented in our handbook. Post to our #git-help channel on Slack, ping your manager in an issue, or create an MR for some broken code. Just remember, when you find the solution, write it down.\n\nOur [document everything](https://handbook.gitlab.com/handbook/values/#write-things-down) policy and emphasis on collaboration helps to slay the lone ranger vampire at a company-wide level.\n\n### The experts\n\nThe expert feels as though they need to accumulate every single piece of information before they are qualified enough to dive into a new project or new role.\n\nThere are far too many smart and qualified people who feel as though their competence is measured only by what they've already accomplished, and their incompetence is measured by what you are striving to achieve. This insecurity will lead people to collect certifications and do exhaustive research before taking the plunge by diving into a challenging new project or applying for a new role.\n\nWomen-identifying individuals are particularly vulnerable to \"the expert\" fallacy. Research indicates that women-identifying folks are more likely to talk themselves out of opportunities or not apply for promotions or new roles when they don't meet the total list of qualifications.\n\nGitLab has established two mentorship programs that help our team members lean in to new opportunities: CEO shadow and the Minorities in Tech (MIT) Team Member Resource Group (TMRG) mentorship program. The [CEO shadow](/blog/gitlab-remote-ceo-shadow-takeaways/) program is a (formerly in-person, now remote) rotation designed to give future senior leaders insight into the operations of the company by following GitLab CEO [Sid Sijbranij](/company/team/#sytses) throughout his day. Earlier this year, the MIT TMRG launched a [new mentorship program](/blog/gitlab-empowers-minorities-in-tech-with-erg/) that connects underrepresented minorities that work at GitLab to senior leaders.\n\n## What can you do about impostor syndrome?\n\nImpostor syndrome is fueled by the negative scripts we use to narrate our life, so one of the methods for combatting impostor syndrome is to reframe your thinking.\n\nIt can be tough to identify your negative thoughts in the moment (meditation and yoga can help here), but once you can identify a negative thought, challenge it.\n\n\"Ask, 'What is objectively the answer to this negative thought? Is it true? Is there any grounding evidence that suggests that it's true?',\" Taylor explained. \"And then you want to reframe that. Now that you've looked at your negative thought in an objective light, you probably have some very tangible points to be able to take that energy then and say: 'Actually, I had this negative thought, but instead I'm feeling these things because of X, Y, or Z'.\"\n\nThe growth mindset can be a helpful way to combat feelings of impostor syndrome. The idea that success is rooted in learning from mistakes and catalyzing your potential, as opposed to achievement itself, will help rewrite the script that holds so many of us back.\n\n# More questions about impostor syndrome?\n\nThanks to Taylor for putting together the presentation that this blog post is based on. Watch Taylor's presentation from GitLab Virtual Contribute 2020 in full below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/mICmSotKwik\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Brett Jordan](https://unsplash.com/@brett_jordan?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/perfectionism?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[708,9],{"slug":1690,"featured":6,"template":687},"imposter-syndrome-and-remote-work","content:en-us:blog:imposter-syndrome-and-remote-work.yml","Imposter Syndrome And Remote Work","en-us/blog/imposter-syndrome-and-remote-work.yml","en-us/blog/imposter-syndrome-and-remote-work",{"_path":1696,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1697,"content":1703,"config":1709,"_id":1711,"_type":14,"title":1712,"_source":16,"_file":1713,"_stem":1714,"_extension":19},"/en-us/blog/keys-to-success-for-product-operations",{"title":1698,"description":1699,"ogTitle":1698,"ogDescription":1699,"noIndex":6,"ogImage":1700,"ogUrl":1701,"ogSiteName":673,"ogType":674,"canonicalUrls":1701,"schema":1702},"3 keys to success for product operations","Learn how to set a foundation for product operations at your organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682313/Blog/Hero%20Images/prodops-keys-elena-mozhvilo-Lp9uH9s9fss-unsplash.jpg","https://about.gitlab.com/blog/keys-to-success-for-product-operations","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 keys to success for product operations\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Farnoosh Seifoddini\"}],\n        \"datePublished\": \"2022-05-24\",\n      }",{"title":1698,"description":1699,"authors":1704,"heroImage":1700,"date":1706,"body":1707,"category":705,"tags":1708},[1705],"Farnoosh Seifoddini","2022-05-24","\n\nIt is official. Product operations is a thing. A quick Google search will pull up a long list of articles singing the praises of everything product operations has to offer, from making product managers more efficient to data collection and synthesis. \n\nWhen I first took on [product operations at GitLab](/direction/product-operations/), there wasn’t a lot of definition or guidance on the topic. I understood what product operations meant because I’d been “doing it” as an inseparable part of my product management and product leadership roles for some years. But I’d never had the opportunity to focus solely on product operations.\n\nAs excited as I was, I was also nervous. GitLab was [accelerating toward an IPO](/blog/gitlab-inc-takes-the-devops-platform-public/) and both the product management team and the product were in hyper growth mode. And, to boot, the all-remote, cross-functional teams were in motion, sync and async, day and night, all around the globe. So, I reached out to peers who had already started their product operations journey and leveraged the perspective, progress, and learnings they generously shared. And, in doing so, I realized everyone was doing it a bit differently. \n\nNow, two and a half years later, product operations is a thing at GitLab. And the most common question I get from peers reaching out to me is: How can I set up product operations for success at my organization? \n\nTo answer this question, I will assume we all want to be product-led and customer-centered, and “success” would be product operations helping us get there. I’ll also assume we agree with the sentiment that’s evolved [defining product operations responsibility](https://www.pendo.io/glossary/product-operations/) to fall into these core areas: tools, data, experimentation, strategy, and trusted advisor. \n\nWhile there is no one formula, I will share three keys that opened doors for product operations to make an impact and grow with GitLab.\n\n### 1. Empower product operations as its own function, with an equal seat alongside other value-driving functions\n\nAt GitLab, we run product operations as an independent function under the product umbrella. The direct line of responsibility to the head of all product ensures product operations has awareness, alignment, and accountability to the macro needs of the product and the business. This also allows product operations to maintain a broad and unbiased view, as well as the right level of influence, to develop strategies/tactics serving the product and the business without favor toward any particular group. This [Silicon Valley Product Group article](https://www.svpg.com/product-ops-overview/) by Marty Cagan provides more helpful context on the why of this approach. \n\n### 2. Make product operations a people-first operation\n\nBefore product operations can deliver on efficiencies and tools that are useful for the product and the business, product operations must understand all of its internal customers. The first year product operations took shape at GitLab, much of my energy was focused on building relationships, not only with product team members but across the whole organization. Becoming a trusted advisor runs deeper than just delivering data, it’s about sensing pain and building bridges. A product operations team that leads with empathy will elevate the organization rather than just serve the organization. \n\n### 3. Drive adoption of product operations strategies by providing opportunities for team ownership\n\nAt GitLab, [everyone can contribute](/company/mission/#everyone-can-contribute). Leveraging this mindset for product operations led to [more impactful and better-designed iterations](https://handbook.gitlab.com/handbook/values/#iteration) to the problems we were trying to solve. By collaborating with various team members across the organization to improve and implement the shared frameworks in the product system, we not only ensure better multi-dimensional solutions but also boost alignment and acceptance of the solutions as well. This approach also inspires team ownership of flexible workflows rather than a perception that product operations is the “enforcer” of rigid processes. \n\nThese three keys become more challenging to forge if they aren’t introduced to an organization early on. Even if not immediately feasible, it’s helpful to carve space for the philosophy upfront and start small to demonstrate the value of the approach as you build the foundation for product operations. In future posts, I will share strategies and tactics for each of these keys as well as answer the second most common question I get: What is a “product system”? \n\nIn the meantime, feel free to learn more about [what product operations drives](/direction/product-operations/) at GitLab and the product management resources we maintain in our [Product Handbook](/handbook/product/).\n\n\n\nCover image by [Elena Mozhvilo](https://unsplash.com/@miracleday?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/)\n",[731,683,899,9],{"slug":1710,"featured":6,"template":687},"keys-to-success-for-product-operations","content:en-us:blog:keys-to-success-for-product-operations.yml","Keys To Success For Product Operations","en-us/blog/keys-to-success-for-product-operations.yml","en-us/blog/keys-to-success-for-product-operations",{"_path":1716,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1717,"content":1723,"config":1728,"_id":1730,"_type":14,"title":1731,"_source":16,"_file":1732,"_stem":1733,"_extension":19},"/en-us/blog/khosla-ventures-gitlab-meeting",{"title":1718,"description":1719,"ogTitle":1718,"ogDescription":1719,"noIndex":6,"ogImage":1720,"ogUrl":1721,"ogSiteName":673,"ogType":674,"canonicalUrls":1721,"schema":1722},"Acquisitions, growth curves, and IPO strategies: A day at Khosla Ventures","A CEO Shadow’s take on GitLab’s annual investor meeting with Khosla Ventures.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671620/Blog/Hero%20Images/khosla-ventures-meeting.jpg","https://about.gitlab.com/blog/khosla-ventures-gitlab-meeting","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Acquisitions, growth curves, and IPO strategies: A day at Khosla Ventures\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2019-04-08\",\n      }",{"title":1718,"description":1719,"authors":1724,"heroImage":1720,"date":1725,"body":1726,"category":299,"tags":1727},[1355],"2019-04-08","\n\nWhen I accepted the opportunity to participate in GitLab’s [CEO Shadow program](/handbook/ceo/shadow/), I knew exactly what to expect. In typical GitLab fashion, there was already a handbook page detailing the goal, the format, and the expectations of the program. Our co-founder and CEO, [Sid Sijbrandij](https://twitter.com/sytses), keeps his calendar [public by default](https://handbook.gitlab.com/handbook/values/#public-by-default) to GitLab team-members, so I was able to get a good understanding of the meetings I’d be attending, who’d be present, and what would be discussed. What I couldn’t have predicted is how an annual meeting between Sid and venture capitalist [Vinod Khosla](https://en.wikipedia.org/wiki/Vinod_Khosla) would turn out. \n\n## Skeptical about in-person meetings \n\nGitLab is an [all-remote](/company/culture/all-remote/) company. We don’t have any offices, and we communicate and collaborate via Zoom, Slack, Google docs, and GitLab. To me, this is normal, and, as an introvert, my biggest concern with participating in the CEO program was the energy drain I knew I would experience living in downtown San Francisco for three weeks and meeting with people in person. Luckily, even our CEO conducts most of his business remotely. \n\nHowever, many of our investors and board members are still, what I call, remote shy, and tend to default to in-person meetings. This is how I found myself traveling an hour and a half south to Menlo Park to meet with one of our investor groups, Khosla Ventures, for their annual meeting with Sid. Khosla Ventures (KV) is a venture capitalist firm founded by Vinod Khosla, co-founder of Sun Microsystems. KV and GitLab have a long history: They invested in our seed round, led our Series A, and has been a part of every fundraising round since. You could say Khosla Ventures is a big fan of GitLab, and the feeling is mutual. \n\n“I’m not sure what we’re going to get out of this. Khosla is the only investor that can get me to travel an hour and a half to meet in person, every year, without an agenda,” Sid told me. \n\nWhile I sincerely appreciate Sid’s dedication to all-remote, to [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency), and to keeping things simple, I found his sentiment surprising. To me, this was a big deal. We were going to spend the day with some of the industry’s brightest minds in Silicon Valley. However, I equally appreciated his emphasis on the lack of agenda. At GitLab, [we work asynchronously](/handbook/communication/) and agendas allow people to prepare ahead of time so meetings can be interactive, discussion-oriented, and productive. A meeting without an agenda is unpredictable and can be a waste of time. \n\n## Khosla Ventures \n\nPulling up to Khosla Ventures in Menlo Park was a refreshing change of scenery from downtown San Francisco where I’d been staying. The mid-century modern style building is tucked behind lush greenery, and as soon as you enter you are unexpectedly greeted by quirky grape purple walls. Inside Khosla Ventures feels more like a creative incubator than an investor firm. \n\nWe first met with Bruce Armstrong, operating partner at Khosla Ventures and a GitLab board member. Top of mind for everyone was the board. With our plans to go public, we needed to hire new board members with public company experience. Earlier that week, I had the opportunity to sit in on a few conversations with potential board members and now I was getting the chance to hear how they were evaluating the candidates. Across the candidates, a pattern was emerging: They all had experience firing CEOs. For some CEOs this would be worrisome. For Sid, it appeared to be a point of pride: He wanted to hire the best people that were going to make the best decisions for the company in the long run. Period. \n\n## The brainstorm \n\nNext we met with Vinod, Bruce, and investment partners Brian Byun and Sven Strohband for a company brief and brainstorm session. Sid began with an update on the financials, and detailed our massive growth and expansion both in terms of people and product. There were no slides presented. Instead, Sid used our website as a visual aid. Nearly every question or discussion point was first addressed with a Google search to pull up the appropriate GitLab web page to reference. When discussing the progress of the product, he defaulted to our [homepage](https://about.gitlab.com/), where our product team has meticulously detailed our current and future feature set. During a discussion about competitors and potential partners, our [DevOps tools page](/competition/) was referenced for a single page view of all our competitors in context of exactly how we compete. \n\nI’ve been working at GitLab for two and a half years as a content writer on our marketing team and at times have been extremely frustrated with our marketing website—the content on it, how it’s organized, what we’re presenting, etc. It doesn’t look or operate in a way I’m familiar with so my instinct was to not trust it. But nothing we do at GitLab is “normal,” and witnessing our CEO use the website as a single source of public truth to inform our investors is just one example of what it means to be a [transparent company](https://handbook.gitlab.com/handbook/values/#transparency). We don’t hide behind “marketing speak” on our public facing website or develop behind closed walls. We tell the same story and share the same information with the company, the customers, the community, and yes, even the investors. \n\nWhile our website doesn’t have the same flashy graphics and pithy marketing copy I’m used to, it speaks the truth even when the truth makes people a little nervous about how we’re going to pull this off. We have an incredibly ambitious product roadmap to be built by an all remote team in a short amount of time.\n\n### Acquisition strategy\n\nSomething I’ve found surprising throughout my entire CEO Shadow experience is how external people underestimate GitLab’s ability to deliver on ambitious plans. The conversation often defaults to, “I see what you’re trying to do, but realistically, which categories are you really able to compete in?” And, unfalteringly Sid answers: all of them. There are some awkward laughs, and the question is reframed to “What part of the product are most of your customers using today?” We move on.\n\nThe conversation with Vinod Khosla was similar but different in tone. Vinod and the rest of the team were skeptical of our ambition but perhaps more attuned to Sid’s commitment to the direction and vision and thus more willing to dig into how we get there instead of why we won’t. \nPotential partnerships to help fill some of our missing functionality were discussed, but it was apparent that our plan was quickly encroaching into competitive territory among the leading contenders. \n\nInstead, there’s an acquisition strategy. To achieve our goal to deliver a single application for the entire DevOps lifecycle that is best-of-breed in every category, we are going to need some help and make some acquisitions. We already acquired [Gitter](/blog/gitter-acquisition/) and Gemnasium in order to enter into the ChatOps and security space more quickly than if we tried to build it all from scratch.\n\nNaturally, our acquisition strategy and offer was already [drafted and public in our handbook](/handbook/acquisitions/). This enabled the conversation to focus on thinking through potential companies and specific areas of our product where we may want to augment the productivity of our soon-to-be 500 internal developers with an acquisition. \n\n### The IPO date  \n\nGitLab [plans to go public on November 18, 2020](/company/strategy/#sequence) and prefers to remain an independent company with no plans of being acquired. While Vinod made it clear it’s strange to pick and make public an IPO date, at GitLab, we are driven by results and deadlines and even an IPO is no exception to the rule. The route we chose to go—traditional or direct listing—was another topic. \n\nDirect listings are historically uncommon. It wasn’t until [Spotify went public via a direct listing](https://techcrunch.com/2018/02/28/spotify-has-filed-to-go-public/) in 2018 that there was even a precedent for tech companies. Now, Slack and potentially Airbnb are rumored to be next, officially [making direct listings *a thing*](https://www.bloomberg.com/opinion/articles/2019-01-11/direct-listings-are-a-thing-now). As for GitLab, like everything else, it will come down to what’s right for us. I can report in good faith all options are being examined carefully and closely. The takeaway here is that while some might think it’s crazy of GitLab to set this ambitious goal, and Vinod might think it’s crazy to set a specific date, one thing is for sure: As a company, we’re ready and already thinking about what’s next. \n\n### Growth curves \nYou know you’re at a successful company when the VCs aren’t focused on how you’re going to meet your short-term goals or current [product vision](/direction/#vision) but are excited about the long-term vision. \n\n“Where is GitLab five years from now?” Vinod asked the room, as he stood up and drew a chart with three staggered S curves on it. He pointed to the first one, “This is where you are now.” Pointing to the other two he asked, “what comes next?” \n\nHe explained how Square started as a payment device, then to a point-of-sale system, found success, and instead of stagnating, entered into a new market via their Square Capital and Cash App offerings. You see similar trajectory with Facebook entering into the devices space with their newest Portal system. What was it going to be for GitLab? It seemed like an outrageous question to ask considering we still have this huge vision to complete but, unsurprisingly, Sid had thought about this and some things are already in the making. \n\n#### Growth curve #1: Meltano\n\n[Meltano](/blog/hey-data-teams-we-are-working-on-a-tool-just-for-you/) (model, extract, load, transform, analyze, notebook, orchestrate) is a start-up within GitLab aimed at becoming a complete solution for data teams. Similar in concept to GitLab, the goal is to create a single application for the entire data science lifecycle. The mission is similar as well: Make analytics accessible to everyone. If successful, Meltano will begin to bridge the gap between systems and data and bring the GitLab vision of everyone can contribute to even more people. \n\n#### Growth curve #2: Product assisted digital transformation  \n\nThe next idea was a real show stopper: product assisted digital transformation. Think code review as a service but expanded to culture, infrastructure, management, pipelines, process, and integrated directly into the product instead of being an outside service. Imagine if you could bootstrap and up-level your engineering teams’ skills with a product that comes with engineering best practices and support out-of-the-box. \n\n## Safe for another year\n\nAs it turns out, agenda-less meetings at Khosla Ventures can provide a ton of value. We walked out of Khosla’s office with a healthy dose of validation and criticism, and our brains buzzing with new horizons of potential to explore. I was already convinced GitLab is a great company to work for, but my experience at Khosla opened my eyes to just how unique our opportunity is. And, the on-site, half day, agenda-less meeting is good for another year. \n\nCover image by [Reza Rostampisheh](https://unsplash.com/@rezarp) on [Unsplash](https://unsplash.com/photos/-hcCm0kIaSg)\n{: .note}\n",[683,684,9],{"slug":1729,"featured":6,"template":687},"khosla-ventures-gitlab-meeting","content:en-us:blog:khosla-ventures-gitlab-meeting.yml","Khosla Ventures Gitlab Meeting","en-us/blog/khosla-ventures-gitlab-meeting.yml","en-us/blog/khosla-ventures-gitlab-meeting",{"_path":1735,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1736,"content":1742,"config":1748,"_id":1750,"_type":14,"title":1751,"_source":16,"_file":1752,"_stem":1753,"_extension":19},"/en-us/blog/lessons-on-building-a-distributed-company",{"title":1737,"description":1738,"ogTitle":1737,"ogDescription":1738,"noIndex":6,"ogImage":1739,"ogUrl":1740,"ogSiteName":673,"ogType":674,"canonicalUrls":1740,"schema":1741},"9 Lessons on building a distributed company","GitLab CEO Sid Sijbrandij and Outklip Founder Sunil Kowlgi talk about remote hiring, management, customer support, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678641/Blog/Hero%20Images/lessons-building-distributed-company.jpg","https://about.gitlab.com/blog/lessons-on-building-a-distributed-company","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"9 Lessons on building a distributed company\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sunil Kowlgi\"}],\n        \"datePublished\": \"2019-04-18\",\n      }",{"title":1737,"description":1738,"authors":1743,"heroImage":1739,"date":1745,"body":1746,"category":705,"tags":1747},[1744],"Sunil Kowlgi","2019-04-18","\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or a discussion of other things related to GitLab._\n\nIt is far easier to run an all-remote company than one that’s a hybrid of remote and colocated,\nsays [Sid Sijbrandij](/company/team/#sytses). When a company adopts a colocated\nculture there’s less recording of things and fewer digital artifacts, so it’s going to be hard for\nthe rest of the company to figure out how decisions are made.\n\nI interviewed Sid for lessons on building a distributed company like GitLab. Sid answered\nquestions on topics ranging from hiring to customer support.\n\nMy top takeaways from the interview:\n\n### 1. Remote interviews are more convenient than in-person interviews\n\nDuring an in-person interview, you need to make sure all your interview materials are loaded\nbeforehand on your laptop or iPad. It’s also going to be hard navigating things on your computer\nwhile talking to a person in front of you. You might write down notes that you’ll need to\ndigitize later by scanning, which is redundant work. On the other hand, when interviewing\nsomeone remotely over a video conference, you have all the materials at hand.\nBecause you’re looking at a screen you can look up information online and quickly take notes without interruption.\n\n### 2. Spend more time on the candidate’s questions than on your questions\n\nDuring interviews, you can get a lot of information about the candidate from the questions\nthey come prepared with and their follow-on questions. When Sid interviews, he spends most of the interview on the candidate’s questions.\n\n### 3. It is really important to write things down\n\nPeople are very efficient at reading things. If you write something down you can refer to it,\nso you don’t have to say everything again. In order to have alignment in a distributed company,\nrepetition of goals and strategy is needed. Repetition is easier when you have one writeup and people are able to easily find it.\n\n### 4. Google Docs is superior to a whiteboard\n\nIt is quite common to have meetings where everyone is looking at the same thing.\nBut, because of time zone differences, it’s hard to involve everyone in a meeting.\nWhile whiteboards are commonly used in in-person meetings, they’re not missed that much by remote workers.\nGoogle Docs is superior to a whiteboard because you never run out of space, you can use\nnumbered lists and indentation, and people can view them afterwards.\n\n### 5. Cross-functional teams don’t work well\n\nGitLab doesn’t do cross-functional teams. Teams are composed of people that perform a similar role.\nA team manager is someone who has experience with that role. This way the manager is able\nto assess results, coach, and give career advice, which is very important.\n\n### 6. Focus on the output of employees, not the input\n\nGood remote workers are focused on results. Especially for managers, it’s important that they\ndon’t focus on the input of people – how long they worked or things like that – but rather focus on the output.\nFocus on the input is not healthy in any company, but especially with remote work you have to let it go.\nNo one’s looking over your shoulder to check whether you’re on Facebook or not, and it’s fine if you\nare as long as you deliver the work to a reasonable degree.\n\n### 7. To be a good manager, you have to quickly identify and remedy underperformance\n\nGitLab hires people who are capable of being [managers of one](https://handbook.gitlab.com/handbook/values/#managers-of-one). But in instances where someone\nis underperforming, managers have to identify it, have a conversation, and take remedial action.\nHere’s [GitLab’s process for dealing with underperformance](/handbook/leadership/underperformance/).\n\n### 8. Be quick with recognition\n\nGitLab has various kinds of employee recognition. For quick recognition, there’s a #thanks\nchannel on Slack where people can celebrate their colleagues’ work. There are also $1,000\ndiscretionary bonuses and GitLab tends to be very high velocity with those.\nRecognizing employees and doing it quickly is really important.\n\n### 9. Put customer-reported issues on a level playing field with internally reported issues\n\nThe issue tracking process in GitLab doesn’t distinguish whether the issue reporter is a user,\n a customer, or a team member. If an issue comes from a user or customer, it’s probably\nbecause they care a lot about what you’re building. So, every feature request, everything\nGitLab team-members work on is out there on a level playing field. GitLab tends to have a lot more\ninteraction with customers than other companies.\n\nWatch the full interview below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/pDU8lxh1-6U\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n[Visit this page to read the transcript of the interview](https://outklip.com/blog/gitlab-building-a-distributed-company/).\n\n### About the guest author\n\nSunil Kowlgi is the founder of [Outklip](https://outklip.com), a video platform for remote work.\n\nPhoto by [Brett Zeck](https://unsplash.com/photos/eyfMgGvo9PA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/globe?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[683,1380,9,684],{"slug":1749,"featured":6,"template":687},"lessons-on-building-a-distributed-company","content:en-us:blog:lessons-on-building-a-distributed-company.yml","Lessons On Building A Distributed Company","en-us/blog/lessons-on-building-a-distributed-company.yml","en-us/blog/lessons-on-building-a-distributed-company",{"_path":1755,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1756,"content":1762,"config":1768,"_id":1770,"_type":14,"title":1771,"_source":16,"_file":1772,"_stem":1773,"_extension":19},"/en-us/blog/making-remote-internships-successful",{"title":1757,"description":1758,"ogTitle":1757,"ogDescription":1758,"noIndex":6,"ogImage":1759,"ogUrl":1760,"ogSiteName":673,"ogType":674,"canonicalUrls":1760,"schema":1761},"How to make remote internships successful","Support Engineering Manager Lee Matos talks about pitfalls and successes in making remote internships work.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678875/Blog/Hero%20Images/support-series-cover.png","https://about.gitlab.com/blog/making-remote-internships-successful","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to make remote internships successful\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lee Matos\"}],\n        \"datePublished\": \"2018-08-16\",\n      }",{"title":1757,"description":1758,"authors":1763,"heroImage":1759,"date":1765,"body":1766,"category":299,"tags":1767},[1764],"Lee Matos","2018-08-16","\nBack in December I introduced you to [Support Engineering at GitLab](/blog/support-engineering-at-gitlab/). Now I'm excited to talk about my experiences – good and bad – with remote internships. I think remote internships can be a great thing but not without pitfalls. Let's dive in.\n\nAs I started to lead the GitLab Support team, [Collen](/company/team/#collenkriel), our first Support Engineering intern, was wrapping up his internship. We started to spend some time together when I realized Collen was doing great work, but we didn't have a clear definition of what it took to transition out of “intern” to “Junior.” This was not due to lack of management, it was because Collen was the first. We had never even thought about what it would look like to graduate! Lesson number 1:\n\n## 1. Clearly define success\n\nInternships are challenging when you don't know what you want the internship to be about, or what you want it to accomplish. I think it's vital that everyone involved knows what success is, and how close they are to it. It took a lot of time and effort for me and Collen to figure out what we'd mark as success. That made it even more stressful as we were both scrambling to make clear and actionable markers of success as his internship came to a close. It was a sign of Collen's skill and grace that we managed to define and execute those things with a ticking clock counting down. Once we knew what success was, Collen knocked it out of the park. Now, success is different for every team and person. Keep that in mind as you define it here for yourself, and your intern.\n\n### A second chance\n\nA few months later, we had an opportunity to hire [Chenje](/company/team/#ckatanda) as an intern and my number one goal was to improve that experience. For Chenje, he had a lot of drive and a few technical projects under his belt, but lacked experience with working in technical teams. We settled on three tasks as the definition of success for Chenje's internship:\n\n+ Deploy Omnibus HA and improve Documentation\n+ Pair on 25 ticket sessions\n+ Gain expertise in one or two expert subjects\n\nFor Chenje, success was defined as completing two of the three defined tasks. This gave him some freedom to plan and schedule, and even room to fail in the face of challenging tasks. This was important because it was meaningful work, but it was also important as a manager that I can understand how team members approach problems big and small.\n\n## 2. Set expectations\n\nSome of this advice is good for any internship – not just a remote one. But one of the unique challenges of a remote internship is the lack of facetime and potential delays in communication. Both Collen and Chenje are six hours ahead of me, so the time difference was definitely a factor here. With remote work, a lot of the inefficiencies of communication and workflow that are just accepted as part of office life are exposed. There's nowhere to hide.\n\n>With remote work, a lot of the inefficiencies of communication and workflow that are just accepted as part of office life are exposed\n\nIn addition to other internship challenges, we now add the element of time coordination, and knowing that your reports can't just walk over to your desk with a question. We have to be very explicit about connecting to make meaningful change happen. There's a tendency to want that to happen synchronously, but we have to figure out alternatives.\n\nI think setting the expectation that the intern should be ready and willing to ask questions was important. Instead of waiting for you to come rescue them, they'll also need to take initiative to snag time on your calendar if they're blocked, and on your end you need to make that time to help them out. With remote work you have to be willing to step forward; you can't wait on someone else to give you tasks or to check in if everything is going smoothly. It won't work at GitLab, and probably won't fly at other remote companies either.\n\n## 3. Avoid busywork\n\nI also made it clear to Chenje that I would not be giving him busywork and that he'd be able to make real contributions. One of the advantages of a remote internship is that there's no coffee to fetch, so busywork possibilities are limited. If you're managing an intern properly, you should consider them to be 1.5x an ordinary report. I thought about the things that I wanted to do but couldn't focus on and offered those to Chenje. I wanted to give him challenges that would result in work he could be proud of. If you're considering an intern to deal with the things you don't want to do, then you should reconsider. That's a recipe for a bad internship, and your intern won't want to work with your team afterwards.\n\n>If you're managing an intern properly, you should consider them to be 1.5x an ordinary report\n\nYour intern should be someone who you believe to be capable and competent, just missing experience. The dream of an internship is that you're developing somebody who will end up working for your organization. If you're not doing it for that reason, then what's the point?\n\n## 4. But don't throw them in the deep end either\n\nWe didn't push either Collen or Chenje to jump into interacting with customers straight away, to give them time to build up their comfort level, experience, and confidence. The initial goal was that the internship is skill-building period – a safe space. You don't want to overwhelm your intern by making them do everything. They're an intern for a reason.\n\n>The initial goal was that the internship is skill-building period – a safe space\n\n## 5. Give clear feedback on progress\n\nAs an intern, Chenje had full access to the team and myself as a lead. We have weekly 1:1s and we'd review his progress. Now, Collen, our first intern, had regular 1:1s with me, but because we didn't have a clear structure of the internship, we weren't using this time to its full potential. Being able to use our 1:1 time to understand and help Chenje overcome blockers and organize made his internship incredibly smooth. We knew what success was, we regularly tracked it, and we learned how to communicate it to each other.\n\nI'm extremely proud of the work that Collen and Chenje have done on our team and how they continue to excel in the face of two very different internship experiences. If you are running a remote team, or considering interns, these things helped me turn something that started out stressful into a recipe for success.\n",[708,683,9],{"slug":1769,"featured":6,"template":687},"making-remote-internships-successful","content:en-us:blog:making-remote-internships-successful.yml","Making Remote Internships Successful","en-us/blog/making-remote-internships-successful.yml","en-us/blog/making-remote-internships-successful",{"_path":1775,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1776,"content":1781,"config":1786,"_id":1788,"_type":14,"title":1789,"_source":16,"_file":1790,"_stem":1791,"_extension":19},"/en-us/blog/manager-training",{"title":1777,"description":1778,"ogTitle":1777,"ogDescription":1778,"noIndex":6,"ogImage":827,"ogUrl":1779,"ogSiteName":673,"ogType":674,"canonicalUrls":1779,"schema":1780},"Building an All-Remote Management Enablement Program","How to build an all-remote management training & enablement program for the future of work.","https://about.gitlab.com/blog/manager-training","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Building an All-Remote Management Enablement Program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Josh Zimmerman\"}],\n        \"datePublished\": \"2021-02-19\",\n      }",{"title":1777,"description":1778,"authors":1782,"heroImage":827,"date":1783,"body":1784,"category":729,"tags":1785},[832],"2021-02-19","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nOne of GitLab Learning & Development’s (L&D) biggest charters for FY21 was building out a management training program. It was a huge task! The CEO asked the L&D team to build a program that trained managers on remote leadership, managing teams, and management best practices. GitLab has been around since 2011. With our massive growth over the years, there was a huge need to train and develop managers for the future. Building a program from scratch was going to require a proactive approach to ensure all voices were heard and to build a program that equipped our leaders with the right skills. \n\nSo, how do you build a management training program for an all-remote company? What do you include? How do you design and develop an impactful program? \n\nIn this blog, I’ll cover some tips and tricks to what we did in L&D to build the [Manager Challenge](https://about.gitlab.com/handbook/people-group/learning-and-development/manager-challenge/) program. \n\n### Start With a Learning Needs Analysis\n\nWhen I first started at GitLab, I learned that there had never been a formal management training program. L&D was a relatively new function within the organization. With the massive growth, L&D saw an opportunity to train our managers for the skillset they needed to be successful. Our first task for developing a program was to conduct a learning needs analysis. We took a consulting approach to the analysis by interviewing a wide range of stakeholders at the company with varying experience levels. From C-suite executives to new managers, to established Directors, we had to diversify who we would receive input from. \n\nWe divided between us, at the time a team of two, by collecting feedback on the management needs and skill gaps. We conducted a job task analysis by determining what managers do at GitLab and what knowledge and skills they would need. During the interviews, we identified consistent themes across stakeholder groups. Some of the themes mentioned “foundational management” as a critical area to focus skill building. Many of our people leaders had been recently promoted and never managed a team before. The skills needed to manage people are different when you have direct reports versus being an individual contributor. \n\nFrom the learning needs analysis, we could pull out additional themes and recommendations for the training. Managing an all-remote team requires a different set of skills than a colocated office environment. For one, people leaders need to ensure their people are set up to be “[Managers of One](https://about.gitlab.com/handbook/leadership/#managers-of-one).” You have to empower your people to work autonomously and get the job done to achieve results. We synthesized the themes which led us into the storyboarding and training design phase. \n\n### Design a Training Experience That Fits Your Culture\n\nEveryone is super busy at GitLab. Like any high-growth, pre-IPO organization, the company moves at lightning speed. We knew that managers would have limited time to dedicate to training. L&D didn’t want to make managers take huge chunks out of their day to dedicate to training. And there is nothing worse than being on a three to five-hour-long virtual training event! \n\nThe training was divided into two parts: \n1. Daily asynchronous learning activities \n2. Weekly live learning sessions\n\nWe knew that the training needed to be bite-sized over a period of time to reinforce management behaviors and skill-building. When we started designing the program, we looked at 30-day challenges as a framework to support behavior change. Participants would be required to do a short daily challenge that would take twenty minutes to complete on their own time. GitLab is a global company. Our team members live in over 65+ countries around the globe. Coordinating calendars with managers was going to be difficult for dedicated virtual live training time. Instead, we built the curriculum by dividing up themes and topics into weeks and days. We created bite-sized learning and actions for participants to complete on their own time. \n\nAt GitLab, we don’t just read off of slides during a presentation. We ask that participants review slides ahead of the call and use the time together to ask questions while facilitating a discussion. We designed the live learning sessions with these best practices in mind. The live learning sessions would focus on the themes covered during the daily asynchronous activities. Also, we prompted managers to openly discuss specific management topics (i.e., giving/receiving feedback, performance discussions, wellbeing check-ins, etc.) that are important to GitLab. \n\nThe program design started to take shape. We designed a three-week program with asynchronous learning activities to be completed Monday-Wednesday. Thursday’s were dedicated to live-learning events to network and learn from other managers. Friday’s served as catch up days, weekly course evaluations, and self-reflections.\n\n### Use What You Have Available \n\nThe best way to understand how GitLab works is to use it for as much of your job as possible. We [dogfood](https://about.gitlab.com/handbook/product/product-processes/#dogfood-everything) our product by threading it into everything we do in the organization. Managers need to be well-equipped with using GitLab to manage their all-remote team. We designed the training to incorporate GitLab into the curriculum as much as possible. The daily asynchronous learning activities are posted in a [GitLab Issue](https://docs.gitlab.com/ee/user/project/issues/). Everyone in the program, anyone with a GitLab.com account, has access to the learning content. The asynchronous topic was posted daily. Participants could read through the Issue and complete the action item by posting their responses in the comments section. \n\nThe practice enabled our [transparency value](https://handbook.gitlab.com/handbook/values/#transparency) by allowing all participants (anyone really) to review manager’s responses. The benefit of using GitLab reinforced multiple behaviors. One, everyone was dogfooding our product. Two, participants could learn from others by reading how other managers respond to different situations. Three, participants now have a reference point to go back to as they grow in their careers. \n\nDoes your organization have a tool like GitLab to help facilitate L&D initiatives? If so, consider using it to reinforce behaviors and to allow managers to become comfortable using them. If not, consider having your team members sign up for a free [GitLab account](https://gitlab.com/) and [implement a challenge](https://about.gitlab.com/handbook/people-group/learning-and-development/manager-challenge/#learning-and-development-team) using GitLab.  \n\n### Apply Social Learning \n\nRemote work can have some drawbacks. One of those challenges may be a lack of connection with your coworkers. Managers need to form relationships with their team members over virtual calls. And people leaders may not have a lot of opportunities to learn from others in a social setting. When you work for a globally distributed team, there can be isolation if the rest of your team is in different time zones. \n\nWe designed the live learning session as a forum for social learning. Managers were given prompts and scenarios on certain situations they would face in their role. Breakout activities were implemented to strengthen networks and collaboration. Participants would share tips on how they would handle the scenarios. We focused less on slides and presenting material and more on engaging with one another to learn from others. Managers shared lessons learned, and many participants walked away from the live learning sessions with new skills to apply right away on the job. \n\n### Review and Validate the Program with Executives\n\nWe are lucky that our leadership team is passionate about the growth and development of our team members. GitLab’s CEO, Sid, asked us to spearhead management training, and he partnered with us on reviewing the content to ensure it aligned with his vision. High Output Management is a book written by Andrew Grove, former CEO of Intel. It is one of our CEO’s favorite books!\n\nWhen we met with Sid for the first time to review the curriculum, he wanted us to ensure that important principles covered in the book were included. We threaded multiple topics (i.e., 1-1 meetings, performance management, making decisions, etc.) into the program. \n\nAlso, our executive review meetings validated whether or not the program reinforced our values. [Gitlab Values](https://handbook.gitlab.com/handbook/values/) are central to how the organization operates. I’ve never worked for a company where they are emphasized so much! Executives had a keen eye on ensuring that the program equipped managers with being role models of our values. The review and validation from executives were vital as we launched GitLab’s management training program. \n\n### Don’t be afraid to Iterate\n\nIt’s easy for L&D professionals to get caught up in requirement gathering and rapidly develop learning programs. However, it’s important to remember that your solution’s best feedback will occur once you pilot the program. We’ve launched two iterations of the Manager Challenge program, and the two looked completely different. The first program was longer, four weeks, and didn’t do enough to reinforce GitLab Values. We also held several meetings with leadership to thread more GitLab “ways of working” content into the curriculum. We ended up cutting out one of the weeks of training to make it three weeks and used the book High Output Management as the foundation to the enablement. \n\nFor the first iteration, we created a large project plan. We didn’t start with the [smallest thing possible and get it out as quickly as possible](https://about.gitlab.com/blog/behind-the-scenes-how-we-built-review-apps/). The plan allowed us to develop a comprehensive curriculum, but it was without testing. The upfront work took a great deal of time. Looking back, we should have developed a shorter program, iterated, and moved forward with the next version. To be successful, we had to get something out right away, pilot, receive feedback, and update. \n\nDuring the training, we conducted weekly evaluations of the content. With the feedback, we were able to apply constructive points and incorporate them into the next week. For example, participants wanted to network more. So we adapted the curriculum and added more social learning in the remaining weeks. \n\nIteration was central to how we rolled out a more seamless program that incorporated GitLab Values and ways-of-working. Don’t be afraid to iterate if you are building a management training program. The best feedback will come once you get it out the door. \n\n### The Result\n\n\nAfter months of planning, content development, stakeholder reviews, we developed the Manager Challenge program for GitLab people leaders. The program is a blended learning approach that incorporates self-paced daily challenges and live learning sessions to build foundational management skills. The program includes leadership assessments, interactive learning, networking, and digital learning, all in three weeks. The program builds a set of baseline management skills that complement our values. \n\nHere’s what a few participants had to say about the program: \n1. \"The handbook has so much content, it's easy to forget how much tactical information can be found right at your fingertips.\"\n2. \"Team performance is cyclical. Perceived regressions aren't bad, but rather a reflection of a change in team dynamics. Look for the types of questions people are asking to know how to respond.\"\n3. \"The handbook is a great resource with tons of information on being a manager, having hard conversations, and helping teams grow.\"\n4. \"For me, these are good reminders of what are the best practices to adopt as a Manager. I am always exploring what are ways we can do tasks better and faster. With that said, as a manager, we need to be sure my people and others are part of the process.\"\n5. \"I learned that there are so many amazing managers here at GitLab. Each of the days' comments were treasure troves into how to approach something differently or new techniques that others have found success with.\"\n6. \"It's possible to be a great remote manager!\"\n\nIf you are set out to create a management training program for your organization to develop leaders, use some of the points in this blog as a reference point. Feel free to reach out to GitLab Learning & Development at `learning@gitlab.com`. \n\n### Looking for more Learning and Development material from GitLab?\n\nIf you want to learn more about what the Learning and Development team at GitLab is up to, check out our [handbook page](/handbook/people-group/learning-and-development/) or read our past newsletters.\n",[9,683,731],{"slug":1787,"featured":6,"template":687},"manager-training","content:en-us:blog:manager-training.yml","Manager Training","en-us/blog/manager-training.yml","en-us/blog/manager-training",{"_path":1793,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1794,"content":1800,"config":1806,"_id":1808,"_type":14,"title":1809,"_source":16,"_file":1810,"_stem":1811,"_extension":19},"/en-us/blog/managing-global-projects-requiring-rapid-response-continuously",{"title":1795,"description":1796,"ogTitle":1795,"ogDescription":1796,"noIndex":6,"ogImage":1797,"ogUrl":1798,"ogSiteName":673,"ogType":674,"canonicalUrls":1798,"schema":1799},"How to leverage distributed engineering teams for rapid response","Rapid response issues can be handled in a compressed time frame if distributed engineering teams can work continuously. Here's what we've learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681331/Blog/Hero%20Images/all-remote-world-banner-1920x1080.png","https://about.gitlab.com/blog/managing-global-projects-requiring-rapid-response-continuously","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to leverage distributed engineering teams for rapid response\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Baus\"}],\n        \"datePublished\": \"2021-06-04\",\n      }",{"title":1795,"description":1796,"authors":1801,"heroImage":1797,"date":1803,"body":1804,"category":940,"tags":1805},[1802],"Chris Baus","2021-06-04","\n\nI am an [Engineering Manager](https://gitlab.com/chris_baus) working on a distributed engineering team at GitLab. [Our team](/handbook/engineering/development/fulfillment/purchase/) is distributed globally, and we have engineers working in India, Germany, Australia, New Zealand, and the United States. I am [located](https://www.google.com/maps/place/Stateline,+NV/) in the U.S. in Pacific Standard Time (PST). In coordination with [other](/handbook/engineering/development/ops/verify/#verifycontinuous-integration) globally distributed engineering teams, we recently responded to an [abuse issue](/blog/prevent-crypto-mining-abuse/) which was causing disruptions for legitimate GitLab.com users, and required a [rapid response](/handbook/engineering/workflow/#rapid-engineering-response).\n\n## Global distribution as an advantage\n\nMany managers view global team distribution as a constraint (because synchronous communication becomes more difficult), but it is possible to [embrace the constraint](https://basecamp.com/gettingreal/03.4-embrace-constraints) and turn it into an advantage. When teams are globally distributed it is possible for work to continue around-the-clock, uninterrupted, and decrease the overall delivery time of projects. I refer to this as \"continuous development.\"\n\nWhile we don't typically work this way, when problems are pressing, working continuously can be a strategy to advance the delivery time frame. In this case, two engineers from our team worked on the problem [17](https://www.google.com/maps/place/Bellingham,+WA/) [hours](https://www.google.com/maps/place/Melbourne+VIC,+Australia/) apart. This provided some overlap in the afternoon (PST), but for the most part, the engineers were working on the project at different times which allowed work to progress continuously.\n\nIt requires some extra management compared to the typical workflow, but the effort may be worth the investment if time is critical.\n\n## Define clear handoffs\n\nOne risk of multiple engineers working continuously and [asynchronously](https://baus.net/embrace-asynchronous-work/) is duplicating work from lack of clear separation of work or handoffs. If possible, it is best to separate work, so engineers are working in different areas of code, but separating work might not always be feasible or practical. In either case, when an engineer finishes working for the day, they should provide an update describing the work which was completed, any problems impeding progress, and what is left to be done.\n\nIf engineers are working in the same area of code, it should be clearly defined if they are working in the same branch or separate branches. If they are working in the same branch, it might make sense for one engineer to maintain branch and accept merges from other engineers before it merged into the main development branch.\n\n## Agree on interfaces\n\nWhen distributed engineering teams are working on a project, it is critical to define clear and documented interfaces between systems and components. System interfaces should be documented in a centrally maintained location. If there is a need to change the interface, then everyone affected by the change should be notified.\n\nIn retrospect, we lost nearly a day of testing because of confusion about an interface between the frontend and backend of the system. These types of problems tend to be amplified when not all engineers involved in the project are available at the same time, as it may take an entire 24-hour cycle to handle and communicate changes. When a discrepancy is found, the problem should be documented by the engineers currently working and, if possible, a solution proposed.\n\n## Place synchronous communication on management\n\nWhen working concurrently, to help ensure all teams are on the same path, it can be helpful to discuss the project status synchronously. This can be difficult to arrange with distributed engineering teams. On this project, the technical teams met twice weekly for 15-30 minutes. It can be tempting to require team members to work off hours to attend synchronous meetings. I'd recommend fighting this tendency.\n\nIt's the responsibility of a manager to ensure effective communication across teams. During rapid-response actions, it's helpful to keep flexible working hours to synchronize with team members across different time zones. I accept working outside my typical hours (knowing I can [adjust my hours](/company/culture/all-remote/non-linear-workday/) at other times of the day), to communicate the status of my team synchronously. This also requires the manager to have a more detailed technical understanding of the implementation and status than is normally required, so they can speak on behalf of offline team members.\n\nInstead of requiring synchronous meeting attendance, [take good notes](/company/culture/all-remote/meetings/#document-everything-live-yes-everything) and [record the meeting](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A) so team members in other time zones can review the status and decisions from synchronous meetings.\n\n## Trade-offs\n\nIn many ways, engineering is the art of balancing trade-offs. Operating in a continuous, globally-distributed fashion takes more management and cognitive overhead than typical asynchronous workflows, but when time is a priority, it could decrease the release time on critical projects.\n\nOperating continuously may come at cost of other management tasks as compressing time increases the effort required to oversee the project requiring a [rapid response](/handbook/engineering/workflow/#rapid-engineering-response). At the end of the rapid-response issue, a retrospective should be held to determine if the engineering strategy provided the expected results, relative to the increased overhead. My recommendation is to be realistic about costs when planning continuous development even when it provides short-term results.\n\n_Read more on [leading engineering teams](/blog/cadence-is-everything-10x-engineering-organizations-for-10x-engineers/)._\n",[9,683,1630,731],{"slug":1807,"featured":6,"template":687},"managing-global-projects-requiring-rapid-response-continuously","content:en-us:blog:managing-global-projects-requiring-rapid-response-continuously.yml","Managing Global Projects Requiring Rapid Response Continuously","en-us/blog/managing-global-projects-requiring-rapid-response-continuously.yml","en-us/blog/managing-global-projects-requiring-rapid-response-continuously",{"_path":1813,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1814,"content":1820,"config":1826,"_id":1828,"_type":14,"title":1829,"_source":16,"_file":1830,"_stem":1831,"_extension":19},"/en-us/blog/mastering-the-all-remote-environment",{"title":1815,"description":1816,"ogTitle":1815,"ogDescription":1816,"noIndex":6,"ogImage":1817,"ogUrl":1818,"ogSiteName":673,"ogType":674,"canonicalUrls":1818,"schema":1819},"Mastering the all-remote environment: My top 5 challenges and solutions","Unlocking potential and overcoming challenges in an all-remote environment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673105/Blog/Hero%20Images/joshua-tree-desert-sunset.jpg","https://about.gitlab.com/blog/mastering-the-all-remote-environment","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Mastering the all-remote environment: My top 5 challenges and solutions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Shawn Winters\"}],\n        \"datePublished\": \"2019-12-30\",\n      }",{"title":1815,"description":1816,"authors":1821,"heroImage":1817,"date":1823,"body":1824,"category":705,"tags":1825},[1822],"Shawn Winters","2019-12-30","\nSince joining GitLab in late 2018, I’ve experienced a whirlwind of excitement, travel, and continuous change. While GitLab provides the [flexibility](/company/culture/all-remote/benefits/) I always wanted in a career, functioning within an all-remote organization has its [challenges](/company/culture/all-remote/drawbacks/). I’m highlighting these, along with solutions I’ve discovered and engineered, in hopes of helping others who are new to remote work.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/QTPeyRW766Q\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIn this [GitLab Unfiltered video](https://youtu.be/QTPeyRW766Q) above, I sit down with Darren Murph to talk about working in an all-remote setting, providing a glimpse at what's possible by embracing this style of work.\n{: .note.text-center}\n\n## The lack of physical human interaction\n\nTurns out, I crave human interaction. The buzz of being around others gives me energy. Although small talk and watercooler banter can be distracting at times, social interaction is (overall) a calming and rewarding experience for me.\n\nI overcame this by leveraging technology like Slack and Zoom to [constantly communicate](/company/culture/all-remote/informal-communication/) with my colleagues. I’m surprised by how well these tools simulate the effect of being in the office. In fact, video calls oftentimes add an element of intimacy not found in the office, as I’m frequently able to visit a colleague’s home, coworking space, or favorite workplace. This allows [a more authentic connection](/blog/tips-for-mastering-video-calls/) than what’s typically brought into a colocated office setting.\n\n## Questioning my productivity\n\nI struggled early on without the social validation that comes with working in an office. At GitLab, team members are given autonomy to be a [manager of one](https://handbook.gitlab.com/handbook/values/#managers-of-one), which can take time to fully embrace and appreciate.\n\nTo overcome this, I was intentional about defining what a solid day’s work looked like in my role. I asked myself what things I should aim to accomplish each day, no matter what, to be productive based on [goals and objectives](/company/okrs/) that applied to me. This produced a sense of freedom I had not experienced before, and relieved a mental burden. It also allowed me to spend additional time with family and enjoying hobbies.\n\n## Grappling with a chaotic, overloaded calendar\n\nMeetings are a necessary evil in some instances, but GitLab [views them very differently](/company/culture/all-remote/meetings/) than most organizations. It is important to stay on top of what the company is doing, while also making sure you're up-to-date on your particular business unit. I looked for ways to bridge this gap given that there are no hallway conversations in an all-remote setting.\n\nDespite GitLab’s bias towards [asynchronous communication](/blog/remote-communication/), I still found the quantity of meetings on my calendar to be overwhelming. I felt like I had no time to get my actual job done. As I acclimated to all-remote life, I realized that every meeting was recorded. This allowed me to go back and listen to important meetings during downtime.\n\nI also embraced the reality that many GitLab meetings are optional. Once I understood which meetings were vital to my success, and which were helpful for my knowledge of how the company was operating, I was able to use meetings to my advantage rather than being at the mercy of an overloaded schedule.\n\n## Can you _really_ document everything?\n\nGitLab is a huge proponent of documenting everything in our [company handbook](/handbook/about/#count-handbook-pages). In a typical office setting, there are people around to answer every question. Here, I’m encouraged to search for information first – to see if my question has already been answered and documented – which was a major challenge for me early on. My instinct was to ask someone instead of searching in the handbook, and I realized that part of this stemmed from my desire to take any excuse to socialize with colleagues.\n\nI overcame this by retraining myself and flipping an old habit on its head. If I was unable to find an answer in the handbook, I was not only empowered to seek answers from others, but also to use a [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/#merge-requests) to document the solution and help others.\n\n## Turning my video on\n\nGitLab conducts all meetings – internal and external – using a video conferencing platform. With no offices, we lean on video calls to maintain human contact. As participants in a video conference, we voluntarily enable a face-to-face interaction with a person (or persons) on the other side, which requires some level of courage and humility. Initially, this was a challenge for me. I was very uncomfortable turning my video on, routinely concerned with my appearance, my surroundings, and my background.\n\nI overcame this challenge by embracing GitLab’s reminder that [meetings are about the work, not the background](/company/culture/all-remote/meetings/#meetings-are-about-the-work-not-the-background). By being vulnerable, I learned that bringing my genuine self to a video call enabled me to build stronger relationships with colleagues and prospects. Now, I make it my goal to have my video turned on as much as possible. This has helped me overcome my fear of being self-conscious, while allowing me to engage with more people in a meaningful way.\n\nAs more companies embrace all-remote, it’s important for us to collectively discuss challenges and solutions with one another. We're interested in hearing about challenges faced by others implementing remote work, so we can ideally find and document solutions.\n\nLearn more about [requesting a Pick Your Brain interview on all-remote](/company/culture/all-remote/pick-your-brain/)!\n\n*Cover image by [Darren Murph](https://twitter.com/darrenmurph).*\n",[707,683,9],{"slug":1827,"featured":6,"template":687},"mastering-the-all-remote-environment","content:en-us:blog:mastering-the-all-remote-environment.yml","Mastering The All Remote Environment","en-us/blog/mastering-the-all-remote-environment.yml","en-us/blog/mastering-the-all-remote-environment",{"_path":1833,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1834,"content":1840,"config":1846,"_id":1848,"_type":14,"title":1849,"_source":16,"_file":1850,"_stem":1851,"_extension":19},"/en-us/blog/not-all-remote-is-created-equal",{"title":1835,"description":1836,"ogTitle":1835,"ogDescription":1836,"noIndex":6,"ogImage":1837,"ogUrl":1838,"ogSiteName":673,"ogType":674,"canonicalUrls":1838,"schema":1839},"Not all remote is created equal","How GitLab's all-remote culture is allowing me to travel the world for four months.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679071/Blog/Hero%20Images/padang_padang_beach_bali.jpg","https://about.gitlab.com/blog/not-all-remote-is-created-equal","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Not all remote is created equal\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erich Wegscheider\"}],\n        \"datePublished\": \"2019-09-04\",\n      }",{"title":1835,"description":1836,"authors":1841,"heroImage":1837,"date":1843,"body":1844,"category":705,"tags":1845},[1842],"Erich Wegscheider","2019-09-04","\nIn early 2016, I left the office and started working remotely. I moved to Colorado, set up a home office and… basically worked from there. Given my employment arrangements, the romantic notion of being able to work from anywhere wasn’t a reality. At best, I could enjoy the benefits of a few extra long weekends by working a Monday or Friday from wherever I was.\n\n## When remote work doesn't work\n\nAfter working remotely for a year and a half, I went to Europe for a few weeks with the intention of staying up to date on work. That was a disaster due to being tethered to Pacific Time; team alignment made for odd working hours, my managers weren’t pleased with said working hours, I hardly slept, and came back more in need of a vacation than when I left.\n\nAnother detractor to working remotely was that it wasn’t conducive to my career development. Given that my colleagues worked at the office in California, the opportunity to lead or manage a team wasn’t presented, given my desire for location independence.\n\nSure, I was “remote,” but the reality was that I worked in the equivalent of a satellite office by myself. Simply put, all-remote work wasn’t a part of the company culture at either place I worked.\n\nIt wasn’t all bad, though. On the bright side, I eliminated a commute.\n\n## Decisions, decisions\n\nDespite being prone to wanderlust, I contemplated whether or not remote work was actually something I wanted to continue pursuing. In my experience, it had been more challenging than rewarding, so the topic warranted reconsideration.\n\nWhen the offer to work at GitLab was presented, I dropped everything and said, “Yes!” It was a make-or-break moment for my remote endeavors, and it was an all-around great opportunity. All-remote is baked into GitLab's [manifesto](/company/culture/all-remote/#the-remote-manifesto), shapes our [communication strategy](/handbook/communication/), and is seen as the method for practicing our [values](https://handbook.gitlab.com/handbook/values/#what-is-not-a-value). GitLab's company culture plus our anticipated headcount growth (I work in Talent Operations) made this an unmissable opportunity. All things considered, GitLab sounded almost too good to be true: A chance to grow and develop professionally while also being given the freedom to travel, so long as I’m producing results. So, if that was the reality of working at GitLab, then I planned on experiencing true all-remote work firsthand, and soon!\n\n## Taking action\n\nFast forward four months and I found myself in conversation about global co-working/co-living spaces. I had done research about companies that offered such arrangements, like the [WiFi Tribe](https://wifitribe.co), so when I brought them up as a resource to list on a company page, the resounding response was, “Go!” and “Do it!”\n\nWhen I broached the subject with my manager during a 1:1 and mentioned prospective locations, his face immediately lit up with excitement and he exclaimed, “That’s awesome! I’m so excited for you!” Still getting used to GitLab’s culture, I quickly noted the 12-15 hour time difference between my desired locations and the U.S. (most of my teammates and vendors I work with live stateside) with an air of defeatism, as if to refute the overwhelming encouragement I’d just received. But I was met with more encouragement to go for it, so I started planning.\n\n## Present reality\n\nAs I write this, I’m in the [beach town of Canggu](http://www.bali-indonesia.com/canggu/), nestled on Bali’s southern shore. I’ll be here for five weeks before moving onto other locations across four continents in four months. Such a trip with any of my previous employers would have put me at a career crossroads. I could either quit and just travel – while pausing my professional development – or put my travel ambitions on hold for the foreseeable future.\n\n![What co-working in Bali looks like](https://about.gitlab.com/images/blogimages/baliworkspace.png){: .shadow.left.wrap-text}\n\nInstead, I’m immersed in a community of passionate remote professionals and entrepreneurs with the WiFi Tribe. I've been gone for two weeks as of writing this post, and this experience has brought a whole new dynamic to my life. The days feel more vibrant, connected, and fulfilling. Often, small groups of the tribe go from cafe to cafe (or co-working space to co-working space) balancing the art of results-oriented work with taking the time to appreciate our surroundings. We gather for long lunches, plan weekend adventures, play impromptu beach volleyball at sunset, or just gather around the pool at night to get to know one another.\n\nCompared to life at home, where after-work get-togethers felt harder and harder to facilitate, I’m finding a greater sense of intention and community. Without the foundation of an all-remote culture, this simply wouldn’t be possible – I’d still be standing at a career crossroads.\n\nIn the time that I’ll be traveling, GitLab is expected to increase its headcount by approximately 32%. I work on the Talent Operations team, so there will be plenty of things to keep me busy as we grow. While it’s still early in my time at GitLab and this trip is just beginning, my faith in all-remote work has been restored.\n\nIn a sense, this whole opportunity kind of feels like having your cake and eating it too.\n",[9],{"slug":1847,"featured":6,"template":687},"not-all-remote-is-created-equal","content:en-us:blog:not-all-remote-is-created-equal.yml","Not All Remote Is Created Equal","en-us/blog/not-all-remote-is-created-equal.yml","en-us/blog/not-all-remote-is-created-equal",{"_path":1853,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1854,"content":1860,"config":1865,"_id":1867,"_type":14,"title":1868,"_source":16,"_file":1869,"_stem":1870,"_extension":19},"/en-us/blog/not-everyone-has-a-home-office",{"title":1855,"description":1856,"ogTitle":1855,"ogDescription":1856,"noIndex":6,"ogImage":1857,"ogUrl":1858,"ogSiteName":673,"ogType":674,"canonicalUrls":1858,"schema":1859},"Coworking home offices, working on the go - GitLab on remote work","GitLab team members share how they make their unique workspaces work for them, and see how they could work for you too!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680818/Blog/Hero%20Images/homeofficecover2.jpg","https://about.gitlab.com/blog/not-everyone-has-a-home-office","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Coworking home offices, working on the go - GitLab on remote work\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-09-12\",\n      }",{"title":1855,"description":1856,"authors":1861,"heroImage":1857,"date":1862,"body":1863,"category":705,"tags":1864},[812],"2019-09-12","\n\n_At GitLab, our team doesn’t wake up at the same time and commute the same roads to sit in the same office. In fact, some of our team members don’t have an office at all! As a globally distributed company with an all-remote workforce, we have an exceptionally diverse set of team members spread across six continents. In this series, we explore how GitLab team members use the autonomy our company affords them to create remote workspaces that suit their lifestyle and cater to their hierarchy of needs: whether that involves creating a cozy and personalized home office space, or diving into the unknown by working while traveling._\n\n\nIn my first job out of college as a reporter, I worked in a tiny office, which was actually a converted closet in the far back corner of the suburban office building. It was so cold that I had blankets, sweaters, a hot water kettle, and a space heater that hummed even in the middle of the blistering summer. Fast-forward past working at tiny desks in an elementary school classroom, a shared desk scenario in a big San Francisco office building (my snow parka stayed with me at the office), a dubious apartment-turned-company-office setup to today: where I work from a home office in [Oakland, California](https://en.wikipedia.org/wiki/Oakland,_California) and control my own thermostat. Best of all, I get to work alongside my longtime colleague and frequent video call interrupter, [Milly](/company/team-pets/#154-milly).\n\nLike me, organic search manager [Shane Rice](/company/team/#shanerice) works primarily from a remote home office, but unlike me he likes to keep his office on the cool side, in terms of temperature and decor.\n\n“Living in [Florida](https://en.wikipedia.org/wiki/Pensacola,_Florida), I put a lot of thought into keeping my office comfortable. When we converted the building from a shed, we added insulation in the ceiling and walls to save energy and help keep the temperature cozy as I work,” says Shane. “I use a wall-mounted AC during the summer and a space heater during the winter.”\n\nAnyone who has been on a Zoom call with Shane will remember his eye-catching decor, and the most recent addition to his family and the GitLab pets cohort, [Hendrix](https://grabs.shanerice.com/lcFp8n).\n\n![shanerice](https://about.gitlab.com/images/blogimages/home-office/view_from_desk.jpg){: .shadow.small.center}\n\n“This space is all about the things I love. I’ve got a bulletin board with memories, mostly from my kids. I save their drawings and cards and pin them up there,” says Shane. “The rest of the walls have posters and toys I've collected over the years. I framed my posters to show up on my video calls, and they're a great conversation starter when I'm meeting someone for the first time.”\n\n![stickers](https://about.gitlab.com/images/blogimages/home-office/door.jpg){: .shadow.small.center}\n\"One of my favorite things to get when I travel for work are stickers, but I hate to use them on my laptop because I know I won’t use it forever,\" says Shane. \"Instead of saving my stickers, I decided to put them on my office door. Now I can take them with us if we ever move.\"\n{: .note.text-center}\n\nBut not everyone at GitLab works from a home office. In fact, we have many team members that worked at home for a while, but now use a shared workplace, like [Alessio Caiazza](/company/team/#nolith), senior backend Infrastructure engineer.\n\nAlessio, who is based in [Florence, Italy](https://en.wikipedia.org/wiki/Florence), worked from home during his wife’s pregnancy and for the first six months after his son was born. “I loved that period, staying home in a quiet place, with my standing desk and multi-monitor setup,” Alessio said. “Being able to take care of my wife first, and my son later on. I'll always be grateful to GitLab for this opportunity.”\n\nBut [working from home with children can be challenging](/blog/working-remotely-with-children-at-home/) and isn't the best option for everyone. After a while, Alessio realized he needed some time and space to transition from dad mode to engineer mode, and moved his setup to a coworking space. “I used to say that working is the thing that happens between changing diapers. Also having less time for social interaction forced me to search for other adults during working hours. So now I have the best of the two worlds, I'm a happy dad and a happy engineer.”\n\n![florence](https://about.gitlab.com/images/blogimages/home-office/alessio.JPG){: .shadow.small.center}\nWhile Alessio has a nice setup in his usual coworking space, on this day he was driven outside into the summer heat after the AC failed in his building, making it too hot to handle.\n{: .note.text-center}\n\n## On the road with GitLab\n\nWhile many GitLab team members work from an consistent office setup, we have a subset of team members that have surrendered a cozy home office and sleek coworking remote space to work from the open road.\n\n[Nicole Schwartz](/company/team/#nicoleschwartz), product manager at GitLab, is embarking on a zig-zagging road trip across the United States, visiting GitLab team members and speaking at conferences. You might expect that life on the road means unpredictable working conditions, but Nicole has discovered that in most cases there is a coworking space or cafe near where she’s located for the day.\n\n![hotel](https://about.gitlab.com/images/blogimages/home-office/nicole_hotel.jpg){: .shadow.small.center}\nMost hotel rooms have WiFi, so Nicole typically starts her mornings in the hotel before moving on to a local cafe.\n{: .note.text-center}\n\n“I try to go for a local cafe if Yelp says they have WiFi, but in a pinch I’ll go to Panera, Starbucks, McDonalds,” Nicole says. “Once I had to drive over an hour to find a Starbucks! There have been occasions I have had to tether from my phone (GoogleFi) or call in on my phone; neither option is ideal.”\n\nWhen you’re highly mobile, the scenery changes quickly and the working conditions aren't always glamorous. While writing in about her experience, Nicole was sitting on a pretty uncomfortable chair with a tiny desk at a local coffee shop in Pittsburg, Kansas. She wasn’t able to bring her [laptop stand](https://www.therooststand.com/) with her because there wasn’t room in her backpack, and there was some teenagers chatting and a baby crying in the background: “Eh, it happens,” she writes.\n\n### The key to working on the road: flexibility and resourcefulness\n\n[Kerri Miller](/company/team/#kerrizor), [Create](/stages-devops-lifecycle/create/) backend engineer, spends about 40% of her time away from her homebase in Seattle, Washington, adventuring across North America by motorcycle. Kerri's work schedule varies depending upon the conditions. Generally, Kerri tends to wake early and work for a few hours where she's lodging before heading out on her motorcycle, wrapping up any remaining tasks in the evening. If she's someplace hot, she'll wake early to travel and then work in coffee shops or public libraries in the afternoon.\n\nOne of Kerri's favorite workplace setups was in a small town where the only publicly available WiFi was at the local bakery/coffee shop.\n\n\"Recognizing this fact, they offered a 'WiFi only' option on their menu, where for $5 you’d get unlimited internet access for the day, and access to a small RV to the side where they had set up several desks and tables and comfy chairs for the community,\" Kerri says. \"Large windows overlooked a prairie filled with sheep.\"\n\n![morning sheep](https://about.gitlab.com/images/blogimages/home-office/morning_sheep.jpg){: .shadow.small.center}\n\"You can't get this view from WeWork!\" says Kerri.\n{: .note.text-center}\n\nBoth Kerri and Nicole note that the trick to having a successful cross-country journey is a broad and distributed network of friends and colleagues. Kerri generally shares her travel plans in advance on the relevant GitLab Slack channels and on Twitter to see who she might visit on the [next leg of her journey](http://motozor.com/). Similarly, Nicole has been using the [GitLab Visiting Grant](/handbook/incentives/#visiting-grant) and setting up coworking days with our colleagues across the United States.\n\nCurrently dispatching from the scenic backdrop of [Copper Harbor, Michigan](https://en.wikipedia.org/wiki/Copper_Harbor,_Michigan), serverless engineering manager [Nicholas Klick](/company/team/#nicholasklick) has been working from his backpack for the past seven years.\n\n![nicholasklick](https://about.gitlab.com/images/blogimages/home-office/nicholasklick.JPG){: .shadow.small.center}\nNicholas is always in search of good WiFi, bringing a Verizon MiFi as a backup.\n{: .note.text-center}\n\nThough he did grab a desk at a local coworking space where he spends two to three days a week, his spirit is free to roam while his career continues to grow working all-remote at GitLab.\n\n_In the second part of our series, we'll explore how some GitLab team members are going out of their comfort zone and integrating global travel into their workflows and augmenting their workplaces (and expectations) accordingly._\n\n[Cover photo](https://unsplash.com/photos/GaBDdA63GcQ) by [Roberto Nickson](https://unsplash.com/@rpnickson?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/home-office?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n{: .note}\n\n",[683,9],{"slug":1866,"featured":6,"template":687},"not-everyone-has-a-home-office","content:en-us:blog:not-everyone-has-a-home-office.yml","Not Everyone Has A Home Office","en-us/blog/not-everyone-has-a-home-office.yml","en-us/blog/not-everyone-has-a-home-office",{"_path":1872,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1873,"content":1879,"config":1885,"_id":1887,"_type":14,"title":1888,"_source":16,"_file":1889,"_stem":1890,"_extension":19},"/en-us/blog/on-calliday-unsucking-your-on-call-experience",{"title":1874,"description":1875,"ogTitle":1874,"ogDescription":1875,"noIndex":6,"ogImage":1876,"ogUrl":1877,"ogSiteName":673,"ogType":674,"canonicalUrls":1877,"schema":1878},"On-Calliday: A guide to unsucking your on-call experience","Being on-call can be rough because you're likely losing sleep, which can impact your personal and professional life. Here are some tips on how to make on-call shifts less painful for your team and company.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680447/Blog/Hero%20Images/on-calliday.jpg","https://about.gitlab.com/blog/on-calliday-unsucking-your-on-call-experience","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"On-Calliday: A guide to unsucking your on-call experience\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Folson\"}],\n        \"datePublished\": \"2017-06-14\",\n      }",{"title":1874,"description":1875,"authors":1880,"heroImage":1876,"date":1882,"body":1883,"category":705,"tags":1884},[1881],"Amanda Folson","2017-06-14","\nIn spirit of the rapidly approaching summer-vacation season, here are some tips on how to prevent burnout when scheduling on-call rotations. Although I'm currently a developer advocate, I've been a career developer and worked in DevOps roles, and I'm no stranger to the on-call life.  Here I'll discuss burnout, the pros and cons of different shift lengths, and how to make on-call rotations a little less painful.\n\n\u003C!-- more -->\n\n## Four phases of burnout\n\nFirst, let's talk about burnout, because this is what we’re trying to prevent.\nEspecially in tech, people may respond to the demands of their job by staying late to get stuff done, or forgoing vacation days because even the prospect of catching up upon return is daunting. It's worth remembering that work can actually kill you, and there's a lot of stigma around this kind of stress, so it's important to talk about.\n\nThese four stages are for employees and employers alike to keep tabs on yourself and your team.\n\n### Caution\nYou feel like you’re not providing value so you try to prove yourself by working more. You might feel down on yourself.\n\n### Warning\nYou start to ignore your own needs in favor of working. Sleep, family, and hobbies become secondary priorities to you. You might panic. You work all the time and sleep like crap.\n\n### Danger\nThis is the point where you need to REALLY start seeking help. Your behavior starts to change at this stage. You might become aggressive or withdraw from serious commitments and social functions, or start engaging in risky behavior. You might be so anxious about all of the work you have to do that you end up not doing anything at all.\n\n### Emergency  \nIf you’re in this zone you need to seek help immediately. In this stage you might feel empty and engage in even riskier behaviors. Many people are depressed at this stage, and it’s not uncommon for people to have suicidal thoughts.\n\n## How can we make on-call shifts better?\n\nTeam members can protect themselves from burnout by making sure everything is in order before their shift. For example, make sure to pay important bills, run errands you’ve been putting off, and do anything else you can to simplify your work week. In terms of making your team work better as a whole, here are some additional best practices you can consider enforcing:\n\n### Don't make the pain in vain\nA chance of being woken up in the middle of the night is never going to be amazing. You can do a lot to decrease the likelihood of it. If you have to be woken up, make it worth the pain and make the time count.\n\n### Make the data count\nMany companies rely on their on-call employees being woken up, and the buck stops there. They have basic monitoring set up but don’t do anything with the data. You should be auditing the information collected during on-call shifts: do root cause analyses, talk about issues, and look for patterns. If you notice that something happens at 2am every few days, you can dig in and fix that.\n\n### Find the best tool for the job\nMany tools exist to help you manage complex scheduling and data aggregation. There are plenty of alternatives, so definitely find one that works for you. Every single one of them is designed to tell you when people are getting woken up and what’s waking them up.\n\n### Keep your staff sharp\nRun drills where you knock things over in a controlled environment and practice putting out those fires.\n\n### Learn how to do incident response\nYou can learn a lot from actual firefighters. I learned a lot from 3 guys at Blackrock, who were actual firefighters turned ops guys who go around teaching ops orgs how to handle incidents better. When there’s a fire, there’s an incident commander, who is in charge of directing everyone else. Rank isn't important here; this person does not have to be manager, they should just be responsible for checking in on everyone for status updates. This person also assigns a scribe to take notes if necessary, although it's better to record calls if you can for better learnings later.\n\n### Implement \"you write it, you wear it\"\nIf you do nothing else in this list, do this. The people who are writing the code, deploying the infrastructure, or touching the guts should be involved in the on-call rotation somehow. These are the best people to fix issues - they’re the ones that know it inside and out. If you don’t have these people on-call, I’m going to boldly say you’re doing it wrong.\n\n### Set better schedules\nTry to start and end your on-call rotations in the middle of the day to give staff an opportunity to go over any problems or questions they experienced on shift. Starting and ending your shifts mid-week is also ideal, since it avoids many bank holidays. Try never to start or end a shift on a holiday, and if you have to have someone on-call on a holiday, it's important to share the load across the team if you can so that one person isn’t on-call the whole day.\n\n### Make people take vacation (!!!)\nOn a related note, employers should keep track of how many people are taking vacation and when. Force people to actually take vacation if you need to - this will make the team as a whole healthier and better when on their shift.\n\n## Which shift length is right?\n\nThere’s no one-size-fits-all solution to scheduling, but I typically tell people to not do weekly rotations unless they have mature monitoring in place. It’s better to proactively monitor and adjust schedules as needed. Think of schedules as a living calendar that’s flexible and open to improvement, rather than using the “set it and forget it” approach. People are dynamic and their needs change, so your schedule should reflect that. Here are a few examples of common shift length:\n\n### 8 hours\nThis is great for people who are covering a business day. The shift might start when someone comes in and end when they leave - or up to 3 hours after leaving - before another team takes over. Extend by 3 hours after they leave so that work they did during the day has time to settle. This length is useful for people who are doing deploys during the day as they’re around to fix issues that arise without anyone else getting paged for it.\n\n### 12 hours\nThis shift length is ideal for people who are covering an overnight. Try \"follow-the-sun\" rotations, which means exactly what you'd expect: Everyone is on-call during their local business hours. Someone starts at 9am, someone starts at 9pm - this still allows for a hand-off and isn’t in the middle of the night.\n\n### 24 hours\nA 24-hour shift is really common and relatively low stress if you have several people on a team. This prevents anyone from having a “rough week” - there's equal opportunity for everyone to have a rough night. The shift is over before you know it.\n\n### 1 week\nThis is typical for small and large teams, and is great if you want to have longer periods of rest between shifts. If you have 4 people, this schedule means each team member is \"off-call\" for 3 weeks at a time. However, having a week long shift feels really long, particularly if stuff is on fire multiple nights. This is the schedule most likely to lead to burnout.\n\nAs you look at your team's summer schedule, I hope this guide helps ameliorate any dread you have about being on-call. Have any questions I didn't address here? Comment here or tweet me [@AmbassadorAwsum](https://twitter.com/ambassadorawsum).\n",[899,9,708],{"slug":1886,"featured":6,"template":687},"on-calliday-unsucking-your-on-call-experience","content:en-us:blog:on-calliday-unsucking-your-on-call-experience.yml","On Calliday Unsucking Your On Call Experience","en-us/blog/on-calliday-unsucking-your-on-call-experience.yml","en-us/blog/on-calliday-unsucking-your-on-call-experience",{"_path":1892,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1893,"content":1899,"config":1905,"_id":1907,"_type":14,"title":1908,"_source":16,"_file":1909,"_stem":1910,"_extension":19},"/en-us/blog/parallels-between-all-remote-and-cloud-computing",{"title":1894,"description":1895,"ogTitle":1894,"ogDescription":1895,"noIndex":6,"ogImage":1896,"ogUrl":1897,"ogSiteName":673,"ogType":674,"canonicalUrls":1897,"schema":1898},"The parallels between all-remote and cloud computing","The rise of the remote workplace has many parallels with the rise of cloud computing.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673019/Blog/Hero%20Images/vintage-keyboards.jpg","https://about.gitlab.com/blog/parallels-between-all-remote-and-cloud-computing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The parallels between all-remote and cloud computing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joyce Tompsett\"}],\n        \"datePublished\": \"2019-10-29\",\n      }",{"title":1894,"description":1895,"authors":1900,"heroImage":1896,"date":1902,"body":1903,"category":705,"tags":1904},[1901],"Joyce Tompsett","2019-10-29","\nAs a GitLab team member, I’m frequently asked what it’s like to work in an [all-remote company](/company/culture/all-remote/). Folks are curious – they like the idea of being able to work from home, but the idea of a company that is *fully* remote is a strange and [wondrous thing](/blog/all-remote-is-for-everyone/). Occasionally, I also encounter people for whom remote is an inconceivable concept. They argue it cannot be done, and won’t work, despite the fact that we (and a [growing list of others](/company/culture/all-remote/jobs/)) continue to thrive as a successful all-remote organization.\n\nThe rise of the remote workplace draws many parallels to the rise of [cloud computing](/blog/google-cloud-next-anthos-kubernetes/).\n\n## Bringing cloud computing to the mainstream\n\nWhile many were comfortable with the idea of network computing for a long time, the notion of cloud computing started to appear with more frequency at the turn of the millennium, championed by companies like Google and Amazon.\n\nThe notion behind cloud computing was that users could access their files, programs and even their compute resources over the network, and potentially from somewhere that was entirely removed from their physical location. There was no physical data center specific to that organization. The capability offered was important but the physical location of the resources was less relevant, as long as it met the users’ requirements.\n\nInitially, those requirements were challenging. Performance, reliability, and security were closely critiqued, but the *primary* challenge for humans was this: They would have to trust something they could not physically touch.\n\nAs confidence and familiarity with cloud computing increased, software as a service (SaaS) companies emerged. Salesforce and Workday were designed to run in the cloud from inception – and as they became successful, a bevy of SaaS applications emerged. Many companies, GitLab included, offer options for both on-premises and SaaS versions of their applications, and discussions in data centers are about migrating or modernizing legacy mission-critical applications to a cloud environment – a once unthinkable idea.\n\nCloud, once scoffed at by many, is now an expected part of most firms’ [strategic technology portfolio](/blog/kubernetes-chat-with-kelsey-hightower/).\n\n![Focus on outputs, not inputs such as being seen in an office](https://about.gitlab.com/images/blogimages/working-remotely-el-salvador.jpg){: .shadow.medium.center}\nFocus on outputs, not inputs such as being seen in an office.\n{: .note.text-center}\n\n## The evolution of the remote workplace\n\nA similar progression is occurring with remote work. Working off-premises has occurred for years, but it was typically reserved for certain positions or types of companies, and certainly was not a mainstream option.\n\nMany companies that offer remote work are [hybrid-remote](/company/culture/all-remote/hybrid-remote/), where an employee may work remotely, but the bulk of the company reports to a physical infrastructure, either centralized or distributed. The rise of [all-remote companies](/company/culture/all-remote/) such as GitLab is analogous to the rise of cloud-based companies such as Salesforce or Workday. We are starting to see other all-remote companies form and at GitLab we expect all-remote will become more common as we develop [best practices](/company/culture/all-remote/meetings/) and evolve more [efficient ways](/company/culture/all-remote/management/) of working remotely.\n\nWe believe that [all-remote is the future of work](/blog/all-remote-is-for-everyone/) – that it will be as likely that an organization is remote as not — particularly if physical manufacturing isn’t involved.\n\n## What all-remote and cloud computing have in common\n\nIn addition to the similarities in how they evolved, many of the benefits of cloud computing have analogues to those of remote work. Some of the cloud benefits we also see with remote working include:\n\n1. Increased agility: Remote work increases an organization’s flexibility to add, expand, or deploy employees in line with the company’s needs.\n1. Cost reductions: Many capital expenditures arguably become operational in all-remote workplaces. The lack of physical infrastructure to lease or buy and maintain offers cost savings to companies. This also lowers barriers to entry for new companies entering the market.\n1. Employee (compute) location independence: Distributed workplaces enables companies to attract and hire the best talent regardless of location, just as users can connect to the company from anywhere they have adequate Internet access.\n1. Productivity often increases as [asynchronous communication](/company/culture/all-remote/informal-communication/) allows multiple employees to work on the same data simultaneously, rather than waiting for synchronous meetings that function like bottlenecks.\n\nThis innovative deployment of people is strikingly similar to the innovative deployment of cloud computing. The key challenge the same for cloud and remote: Organizations need to [trust](/company/culture/all-remote/management/) the model and realize the [benefits](/company/culture/all-remote/benefits/) for themselves.\n\nCover image by [Darren Murph](https://twitter.com/darrenmurph)\n{: .note}\n",[707,683,9],{"slug":1906,"featured":6,"template":687},"parallels-between-all-remote-and-cloud-computing","content:en-us:blog:parallels-between-all-remote-and-cloud-computing.yml","Parallels Between All Remote And Cloud Computing","en-us/blog/parallels-between-all-remote-and-cloud-computing.yml","en-us/blog/parallels-between-all-remote-and-cloud-computing",{"_path":1912,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1913,"content":1919,"config":1926,"_id":1928,"_type":14,"title":1929,"_source":16,"_file":1930,"_stem":1931,"_extension":19},"/en-us/blog/pick-your-brain-interview-cedric-savarese",{"title":1914,"description":1915,"ogTitle":1914,"ogDescription":1915,"noIndex":6,"ogImage":1916,"ogUrl":1917,"ogSiteName":673,"ogType":674,"canonicalUrls":1917,"schema":1918},"Pick Your Brain interview: FormAssembly CEO Cedric Savarese","GitLab CEO Sid Sijbrandij and FormAssembly CEO Cedric Savarese met online to talk remote culture, hiring and scaling.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680396/Blog/Hero%20Images/pick-your-brain-with-cedric-savarese.jpg","https://about.gitlab.com/blog/pick-your-brain-interview-cedric-savarese","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pick Your Brain interview: FormAssembly CEO Cedric Savarese\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley McAlpin\"}],\n        \"datePublished\": \"2017-08-11\",\n      }",{"title":1914,"description":1915,"authors":1920,"heroImage":1916,"date":1922,"body":1923,"category":705,"tags":1924},[1921],"Ashley McAlpin","2017-08-11","\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or discussion of other things related to GitLab._\n\nNavigating growth in a high-tech remote organization can be challenging. CEO of [FormAssembly](https://www.formassembly.com/), Cedric Savarese, recently sat down with GitLab CEO Sytse (Sid) Sijbrandij to chat about remote culture, hiring and scaling.\n\n\u003C!-- more -->\n\nRemote culture can be difficult to navigate. At FormAssembly, we approach our [team](https://www.formassembly.com/team/) and the way we work by carefully considering job functions and responsibilities, geographical location and team needs overall. During their chat, Cedric and Sid discussed addressing third-party perceptions as a growing remote team — here are some of the highlights.\n\n## Can remote sales teams really grow successfully?\n\n**Cedric:** I’ve heard it especially for sales teams, where it seems to be that salespeople kind of benefit from being in the sort of boiler room environment where they kind of feed on each other’s energy, to successfully grow remotely. You guys do enterprise sales, so is that something that you’ve found to be true? Or are you considering having some teams maybe more concentrated?\n\n**Sid:** Yep, certainly we were under the same assumptions, so we were completely remote at Y Combinator and everyone’s like “Yeah, it works for developers, they’re used to it, they like it, but it doesn’t work for anything else.” So we’re like, ok, we’re not going to be, one of our values is boring solutions, we’re not going to like try to be innovative here. We got an office, I’m sitting in it now, and we got nine desks or something here, and we’re like “We’ll grow  out of this, but it’s a good start. We’ll hire the salespeople and they’ll be working the phones and they’ll be high-fiving one another. So salespeople came in and after a few days, they kind of stopped coming in. And I was like, ok, well, what I’m gonna tell them? You have to be here man. No, that’s like, sort of, like in our handbook. We value results, I don’t particularly care how you get it done, just get it done. So I wanted to stay true to that and actually now that I’ve talked to more and more people, most people say “Oh, enterprise sales team, they’re kind of remote anyway because as soon as you grow, you split it up by geography, especially enterprise sales, so people are spread across the country anyway.”\n\n**Cedric:** Yeah, that’s true that the larger the organization gets, the more they have to spread out, even if you’re not truly remote, you’re going to be in bigger buildings, you’re going to be in different buildings and then you’re going to be in satellite offices and so on, so in the end, you’re doing the same as a remote team.\n\n## How do you address communication and collaboration as a remote team?\n\n**Sid:** So what we do is we create lots of like artifacts. We extensively use issues in Google docs and we tend to write things down. In an on-premises company, you can get away with doing a lot of things verbally, with us, it’s very often written down so there is an issue to refer to, there is a doc to refer to, and like making your own notes and not putting them in the doc is kind of like a cardinal sin. That’s not ok, we should all be on the same page. And we recognize that takes effort but you’re not going to, that’s what makes us work together efficiently. I think that if you do it right it’s easy to have a high-growth company that’s remote but that, well, maybe not necessarily remote, but that has a really good handbook. We went from nine people to 150 people in two years, that is normally your culture dilutes a lot because everyone kind of verbally – you get the telephone game where it gets worse over time. The message gets more garbled every time it’s transferred. Guess what, we don’t use telephone, we use a handbook, and the message doesn’t get more garbled, the message just gets better because continually we’re updating that so we don't end up with a diluted culture, we end up with an enhanced cultures and customs and practices.\n\n**Cedric:** Do you spend any time in person with your new hires or do you just start fully remote?\n\n**Sid:** No, we don’t spend any time in person, either during the hiring process or after they start.\n\n**Cedric:** Do you think there’s value in spending some time with someone in person before kind of letting them loose on a remote project?\n\n**Sid:** Yeah, I guess there’s value. When people are close to each other, we sometimes recommend, like, hey this person’s close to you, consider, especially your first month, spending a day together every week or something. But not that often, and it’s not necessary, I think. But, there is value in having a buddy, so we assign a buddy. There is value in meeting people in the company, so we require everyone to have 10 virtual coffee breaks, and try to distill, the trick is distill what was the in-person thing good for? Well to have a very low-friction way of asking people a potentially stupid question. Well, assign them a buddy so they can ask those questions. Unpack what the interaction is and organize it.\n\n## Does your leadership team get together outside of the team reunions?\n\n**Sid:** We don’t. We do have executive get-togethers. We call them remote off-site where we spend two mornings, working to our quarterly plan, but that’s remote. I think one of the challenges is that you need, as an executive team, you need some talking time together. So we plan that, but because I’m not able to go, when I have something, I tend to not quickly go to someone, but I tend to write it in our agenda. So when we talk we have a big agenda to get through. And the kind of, the risk of that is not talking about the important things, but only about the small things, so that’s something I’m still trying to improve.\n\nHave questions? Tweet us at [@Formassembly](https://twitter.com/FormAssembly?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) and [@GitLab](https://twitter.com/gitlab).\n",[1925,9],"cloud native",{"slug":1927,"featured":6,"template":687},"pick-your-brain-interview-cedric-savarese","content:en-us:blog:pick-your-brain-interview-cedric-savarese.yml","Pick Your Brain Interview Cedric Savarese","en-us/blog/pick-your-brain-interview-cedric-savarese.yml","en-us/blog/pick-your-brain-interview-cedric-savarese",{"_path":1933,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1934,"content":1940,"config":1947,"_id":1949,"_type":14,"title":1950,"_source":16,"_file":1951,"_stem":1952,"_extension":19},"/en-us/blog/pick-your-brain-interview-kwan-lee",{"title":1935,"description":1936,"ogTitle":1935,"ogDescription":1936,"noIndex":6,"ogImage":1937,"ogUrl":1938,"ogSiteName":673,"ogType":674,"canonicalUrls":1938,"schema":1939},"GitLab CEO interview: Building the best distributed Dev team","FineTune CTO Kwan Lee sits down for a 'pick your brain' meeting with GitLab CEO Sid Sijbrandij.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680355/Blog/Hero%20Images/pyb-kwan-lee.jpg","https://about.gitlab.com/blog/pick-your-brain-interview-kwan-lee","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to become the best distributed software development team? My interview with GitLab's CEO\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kwan Lee\"}],\n        \"datePublished\": \"2017-09-15\",\n      }",{"title":1941,"description":1936,"authors":1942,"heroImage":1937,"date":1944,"body":1945,"category":705,"tags":1946},"How to become the best distributed software development team? My interview with GitLab's CEO",[1943],"Kwan Lee","2017-09-15","\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or discussion of other things related to GitLab._\n\nIt was great to find the time for us to pick Sid’s brain and learn from the history and the organizational challenges that GitLab had overcome so that we may reference them for building a better organization. There were some cultural elements, tactical organizational elements and software development process-related elements that were valuable pointers.\n\n\u003C!-- more -->\n\n## Lessons in remote work\n\nHaving 178 people in 38 countries was quite an impressive distribution of employees across different geographies. Sponsoring travel to work with fellow members of the company was a great program that they have to bridge the distributed nature of the company. We are also a very distributed company and we want to grow a company where a distributed team can scale and collaborate actively while continuously increasing the motivation to build higher quality software at higher velocity for our customers.\n\nOne of the challenges of being remote is that, although we are part of one company, it is tricky for us to interact in a casual manner as we do in a physical co-working environment. GitLab promotes virtual coffee breaks and all-team meetings to promote these. People can arrange coffee breaks with others at their will to catch up. During all-team meetings, they go around introducing personal updates about themselves. The team being remote requires everybody to still feel part of one company. In order to feel part of the company, it requires participation from everybody and their willingness to share their personal lives.\n\n>In order to feel part of the company, it requires participation from everybody and their willingness to share their personal lives.\n\nAt [FineTune](https://www.finetunelearning.com/), we are not used to taking coffee breaks during the day with coworkers, but we try to have regular meetings where we try to catch up personally for the first five minutes. Our weekly company meetings have been a little bit informal and did not give opportunity for each of the members to speak. We plan to keep encouraging people to share more as we want to grow a culture of sharing more as we grow and scale.\n\nSid also described various rooms for social interaction in the company. Some more interesting venues for social interaction that were suggested by Sid were:\n\n* Team call four times a week (20 minutes)\n* Summit: every nine months they fly everybody to one place, for interactions that are less organized with scheduled activities and forbidden to have team meetings ('unconference')\n* Asynchronous discussions via merge requests, while they sometimes get on video call to summarize what has been concluded or decided\n\nWriting things down is important due to the remote nature of the company. We have been pretty bad at keeping consistent standards on documentation and keeping them up to date. It also hinders communication flow, making it difficult to discover and share knowledge when we do not have such consistency. We are working on ways to improve this nowadays.\n\n>Writing things down is important due to the remote nature of the company\n\n## Lessons in organization\n\nWhen it comes to organization and growth, what we got most out of it was that we need to find the gaps in our team and try to fill in those parts we lack when we hire new members. Currently, we have a gap in frontend tech lead, and by thinking through what gaps exist in our development and future of our company we found that we would like to find a tech lead who has extensive experience modularizing frontend software components and has worked with complex microservice APIs that would facilitate the flow of communication between frontend and backend members.\n\nSome other organizational lessons learned from growing from 15 to 50 was that:\n* Sid was the only Sales (non-development) team member\n* Get things done on time and having well defined tasks are very important\n* One boss to give approvals\n* No project managers\n\nWe want to organize ourselves so that we are making decisions quickly and moving fast. I believe that as long as the priority framework for decision-making is clear, everybody should feel free to make the decisions that move the company forward.\n\n## Lessons in the development process\n\nIn terms of development process, we realized we needed to shorten the time to release and try to keep shipping. Importance of fast iteration was emphasized by Sid and shipping fast by cutting scope.  We should not fall into the trap of building the car and not shipping when the bicycle is ready.  We also need more discipline to maintain good, coherent design documentations that allows us to be all on the same page.\n\nIt was interesting to see the scale of work that the distributed team worked on. When a new sprint starts, product and UX team already had designed and product team had schedules for release. Ad hoc dev teams get formed for big features (every release has around five big features and 100s of small issues), making a chat channel, discussing issue descriptions, figuring out when you hand off from backend to the frontend team.\n\n>\"always finish the flow first\"\n\nGitLab's approach of \"always finish the flow first\" (breadth vs depth) to take care of coordination resonated strongly since that involves more people and requires people to be on the same page to further dive in deeper. Also, the \"building better a experience\" and \"releasing a more integrated experience\" brings a lot of emergent benefits.\n\nSome mistakes seen were people having hard time iterating and sometimes over engineering implementation which risks release deadline. Everyone can contribute, but at the end person doing the work makes the decision.\n\n## Lessons in leadership\n\nAs a final question, we asked what prevents a software company from growing.  The answer we got was the lack of ambition. We as the founders or development team may not be as ambitious as we should be. Our company has been in the ed tech industry for 10 years and had not seen much growth. What we realized was that our goals and bars were set too low. We have a lot of strong design and engineering capability that we have built up over the last six months and now it is our time to think and act with more ambitious goals. There is a lot of value in helping people to write better and measure the quality of written content since most communication nowadays is done via writing.\n\nWe want to become an important company that helps with not only K-12, higher-ed education in EdTech industry, but also with professional development and employability across any industry that requires written communication to succeed. We have a long way to go, but the invaluable discussion we had with Sid informed us some of the good practices to follow and a trajectory to aim for around our next growth path.\n\n[Cover image](https://unsplash.com/@blakeconnally?photo=B3l0g6HLxr8) by [Blake Connally](https://unsplash.com/@blakeconnally) on Unsplash\n{: .note}\n",[1925,9,731],{"slug":1948,"featured":6,"template":687},"pick-your-brain-interview-kwan-lee","content:en-us:blog:pick-your-brain-interview-kwan-lee.yml","Pick Your Brain Interview Kwan Lee","en-us/blog/pick-your-brain-interview-kwan-lee.yml","en-us/blog/pick-your-brain-interview-kwan-lee",{"_path":1954,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1955,"content":1961,"config":1966,"_id":1968,"_type":14,"title":1969,"_source":16,"_file":1970,"_stem":1971,"_extension":19},"/en-us/blog/preventing-burnout-a-managers-toolkit",{"title":1956,"description":1957,"ogTitle":1956,"ogDescription":1957,"noIndex":6,"ogImage":1958,"ogUrl":1959,"ogSiteName":673,"ogType":674,"canonicalUrls":1959,"schema":1960},"Preventing burnout: A manager's toolkit","GitLab CEO Sid Sijbrandij shares 12 steps that managers can take to help employees avoid burnout.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664472/Blog/Hero%20Images/gitlabflatlogomap.png","https://about.gitlab.com/blog/preventing-burnout-a-managers-toolkit","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Preventing burnout: A manager's toolkit\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-05-03\",\n      }",{"title":1956,"description":1957,"authors":1962,"heroImage":1958,"date":1963,"body":1964,"category":705,"tags":1965},[1276],"2022-05-03","Working at a startup is demanding. GitLab team members are often under a lot of pressure. From mental health awareness to our posts on [identifying burnout](/blog/preventing-burnout/), GitLab wants to ensure our team members are working efficiently without feeling overwhelmed. Recently, GitLab co-founder and CEO Sid Sijbrandij and Michelle Hodges, vice president of Global Channels, discussed how managers can support their team members and help prevent burnout.\n\nSid and Michelle emphasized that the earlier a manager can identify burnout the better. Identifying burnout in a remote environment is more difficult than in a co-located workplace, but looking for early hallmarks such as exhaustion and reduced enthusiasm can help managers get ahead of the problem. \n\nSid shared the following 12 strategies managers can utilize to support their team and prevent burnout:  \n\n1. **Encourage time off.** Even taking a half day can help. Managers can take an active role in encouraging team members to take time off by telling their team members about their own upcoming vacations. Managers can ask team members when their next vacation is and, if they don’t have one, encourage them to plan one.\n\n1. **Lower the pressure.** When a manager senses that someone on their team may be getting close to burnout, they can lower the pressure of goals and [objectives and key results (OKRs)](/company/okrs/) and also ask about goals less frequently.\n\n1. **Be more positive.** Frankly, managers can be a significant source of stress, so try to be more positive about the team member and their reports. \n\n1. **Increase headcount.** Most of the time, there’s too much work for too few people, so managers can explore options to increase headcount. This can be temporary, such as borrowing time from someone on another team or hiring a consultant. \n\n1. **Offer team members coaching.** External coaching can help team members open up about their struggles, including working with their manager. \n\n1. **Remind employees of mental health care resources.** Point employees toward the company's mental health benefits and services. GitLab provides support to all team members through [ModernHealth](/handbook/total-rewards/benefits/modern-health/).\n\n1. **Express gratitude.** Send team members gifts to their home to show gratitude and an investment in your personal relationship. \n\n1. **Celebrate progress.** Burnout is often caused by a feeling of stagnation. Seeing the progress you’re making day-to-day is hard. Managers should create space to celebrate small wins and reflect on the mountains you’ve climbed. \n\n1. **Sympathize.** The work is tough. Have conversations about it. \n\n1. **Lead by example.** Managers should set and maintain working hours. For instance, Sid says he waits until the next working day to respond to Slack messages that happen after 6 p.m. \n\n    Help team members to be more effective by: \n    - Reviewing recurring meetings and [identifying what can be done async](/company/culture/all-remote/meetings/#2-cancel-unnecessary-meetings)\n    - Talking about what they're working on and helping them identify what work isn’t as important\n    - Identifying work that can be delegated to other team members, and empowering them to do so\n\n    Managers can also encourage team members to name things they won’t do. \n\n1. **Reduce the number of hours worked by agreeing to reduce effort.** Managers can ask team members to identify things that are likely to fail. Taking time to reflect on results can be very insightful and can allow team members to reduce their effort without compromising quality.\n\n1. **Share burnout concerns with others.** Using judgement or with permission, managers can give context and ask others to take it easy on specific team members when necessary.\n\nWatch the full conversation below.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/9VO0H28QEz8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n",[683,9,708],{"slug":1967,"featured":6,"template":687},"preventing-burnout-a-managers-toolkit","content:en-us:blog:preventing-burnout-a-managers-toolkit.yml","Preventing Burnout A Managers Toolkit","en-us/blog/preventing-burnout-a-managers-toolkit.yml","en-us/blog/preventing-burnout-a-managers-toolkit",{"_path":1973,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1974,"content":1980,"config":1986,"_id":1988,"_type":14,"title":1989,"_source":16,"_file":1990,"_stem":1991,"_extension":19},"/en-us/blog/preventing-burnout",{"title":1975,"description":1976,"ogTitle":1975,"ogDescription":1976,"noIndex":6,"ogImage":1977,"ogUrl":1978,"ogSiteName":673,"ogType":674,"canonicalUrls":1978,"schema":1979},"GitLab team members share how to recognize burnout (and how to prevent it)","Burning out is a common feeling at startups – here's what we're doing to address it at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680178/Blog/Hero%20Images/gitlabbers-share-how-to-recognize-burnout.jpg","https://about.gitlab.com/blog/preventing-burnout","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab team members share how to recognize burnout (and how to prevent it)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Clement Ho\"}],\n        \"datePublished\": \"2018-03-08\",\n      }",{"title":1975,"description":1976,"authors":1981,"heroImage":1977,"date":1983,"body":1984,"category":705,"tags":1985},[1982],"Clement Ho","2018-03-08","\n\nThe feeling of [burning out][mayo-clinic] is common for people working at startups. Oftentimes, if you are feeling burned out, you aren't the only one feeling that way. I chatted to some GitLab team members about how they knew they were burned out, and how they get back on track.\n\n\u003C!-- more -->\n\nIt's easy to burn out when you work remotely. It's easy to work straight through lunch, and feel like you must put in extra hours to help finish a big project. With monthly releases, many features feel extra important and necessary to put in extra time. This isn't ideal because pacing yourself actually works out cheaper in the long run, as burning out takes extra time for recovery.\n\nDuring the last [summit](/events/gitlab-contribute/), [Marin][marin] led a session about preventing burnout, thanks Marin! A lot of GitLab team members attended that session and many had similar feelings of either being burned out or feeling like they are on their way towards it. Some even mentioned that they were starting to experience those physical signs of feeling burned out (e.g. frequent headaches). After the summit, we as a team added more resources to the handbook and created some tools on how we as a team can recognize and prevent burnout.\n\n## How to recognize if you're burned out, according to GitLab team members\n\n### You're constantly tired\n\n>For me, the greatest signal of burnout is struggling to get out of bed in the morning. I tend to stick to pretty standard working hours so when I work late in the evening, multiple nights in a row, I start to struggle to get up in the morning or even lose track of what day it is. I recognize this as burnout because usually it isn't hard for me to get up and get my day started. In fact, I'm usually up long before I start work so I can make breakfast, walk my dog, do some creative writing. But when I'm burned out, I will wait until 8 or 8:30 to get up and go straight to the computer like a zombie. - Erica Lindberg, former manager, Global Content\n\n>I didn't realize I was burned out until I finally took a vacation. I experienced many symptoms but was not aware of it and since I was experiencing them for so long, I thought it was normal. I was extremely tired all the time and whenever I decided to take a break during the day, I would often fall asleep with my laptop on my lap. - Anonymous GitLab team member\n\n### You no longer enjoy things\n\n> I started losing my general feelings of enjoyment in life. Even the fun activities I had planned, weren't activities I looked forward to. - Anonymous GitLab team member\n\n### Your job performance suffers\n\n>I would put in extra hours to make up for my productivity but it still didn't seem to measure up with my past performance. - [Jacob Schatz, Frontend Lead](/company/team/#jakecodes)\n\n### Your relationships are strained\n\n>I would also have a hard time remembering information, so much so that my friends began noticing the difference in me. I found myself being agitated and angry towards the people around me but couldn't figure out the reason. - Anonymous GitLab team member\n\n## How to prevent burnout, according to GitLab team members\n\n### Set clear boundaries between work and home\n\n>I'm trying to limit how many days I allow myself to work over eight hours by either scheduling other activities in the evening with friends or my partner (it works better when you've committed to someone so they can help hold you accountable. These things can be anything from rock climbing to dinner or watching a movie) or simply blocking out my calendar and setting reminders for when it's time to shut off. And when it is time to shut off I'm come up with a \"ritual\" of shutting down my computer, turning off my keyboard, monitor, and light in my office – this makes it harder to come back to \"just finish up one last thing\" - [Erica Lindberg, Content Marketing Manager](/company/team/#EricaLindberg_)\n\n>In order for me to prevent myself from burning out, I follow several rules. I make sure I only work seven hours a day and spend two additional hours learning. I dedicate at least seven hours of sleep every day, and I make sure I go to the gym and eat healthy regularly as part of my daily routine. - Anonymous GitLab team-member\n\n### Take vacation\n\n>After my vacation, where I did absolutely nothing except enjoying nature, I came home feeling much more energized. I am now a happier person. I am less sleepy and agitated and have found myself much more productive than ever before. That week of vacation gave me years of my life back that I would have never gotten if I didn't truly disconnect from work. - [Jacob Schatz, Frontend Lead](/company/team/#jakecodes)\n\n### Know when to take a break\n\n>Last week, I was feeling really tired and emotional (upset and stressed) about certain things. When I noticed that, I cancelled my last meeting of the day last minute, even though it was with [Sid](/company/team/#sytses). I wouldn’t have been productive and able to deal with the stress. So I took off the rest of the day. I was 10x better equipped to handle things the next day. - Job van der Voort, former VP of Product\n\n### Switch off when you're away from work\n\n>I try to stop thinking about work over the weekends or in the evenings. I practice meditation, mindfulness, and deep breathing. - [Suri Patel, Content Marketing Associate](/company/team/#suripatel)\n\n### Don't suffer in silence\n\n>I experienced burnout at my previous company. If it were to happen again, I would speak to my manager and openly discuss my situation, telling him or her that the pace is not sustainable and that something needs to change. It might be a scary topic to discuss, but burnout doesn't just affect my professional life – it has an impact on my personal life, most importantly on my health, so having these transparent conversations is a necessity. I would speak to my manager as soon as I started feeling overwhelmed over a prolonged period of time. There will always be phases when we have to work more than usual, but if long hours become a norm, then it's something that needs to be addressed right away. - Anonymous GitLab team member\n\n### Other good habits to prevent burnout:\n\n- Don't go straight to work after you wake up. Try not to start working within 30 minutes of waking up\n- Remove Slack from your smartphone or at the very least, turn off notifications for it\n- Keep each other accountable. When you notice someone in a different time zone should be asleep, tell them\n- Use your Slack status to share a message with the team that you are unavailable\n- Schedule [random coffee breaks][random-coffee-breaks]\n\n## Changes we added to the handbook\n- [Encourage team members to communicate with their manager when they recognize burnout][handbook-burnout]\n- [Encourage team members to notice signs of burnout in their peers and direct reports][handbook-burnout]\n- [Added tips to avoid burnout][handbook-burnout]\n\nWhat are some strategies you have to prevent yourself from burning out? Please comment below. We'd love to continue being proactive against burning out.\n\n[Photo](https://unsplash.com/photos/MAGAXAYq_NE) by [Victoria Heath](https://unsplash.com/@vheath) on Unsplash\n{: .note}\n\n[mayo-clinic]: http://www.mayoclinic.org/healthy-lifestyle/adult-health/in-depth/burnout/art-20046642\n[random-coffee-breaks]: /handbook/communication/#random-room\n[handbook-burnout]: /handbook/paid-time-off/#recognizing-burnout\n[marin]: https://gitlab.com/marin\n[unsplash-photo]: https://unsplash.com/photos/_k31aFqnmTM\n[unsplash-credit]: https://unsplash.com/photos/_k31aFqnmTM?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\n[unsplash]: https://unsplash.com/@rikkichan89?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\n",[9,708,683],{"slug":1987,"featured":6,"template":687},"preventing-burnout","content:en-us:blog:preventing-burnout.yml","Preventing Burnout","en-us/blog/preventing-burnout.yml","en-us/blog/preventing-burnout",{"_path":1993,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1994,"content":2000,"config":2006,"_id":2008,"_type":14,"title":2009,"_source":16,"_file":2010,"_stem":2011,"_extension":19},"/en-us/blog/project-management-using-gitlab-platform",{"title":1995,"description":1996,"ogTitle":1995,"ogDescription":1996,"noIndex":6,"ogImage":1997,"ogUrl":1998,"ogSiteName":673,"ogType":674,"canonicalUrls":1998,"schema":1999},"Can DevOps and project management co-exist? Yes, on the daily at GitLab","Stay agile by using GitLab for DevOps project management","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669575/Blog/Hero%20Images/agilemultipleteams.jpg","https://about.gitlab.com/blog/project-management-using-gitlab-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Can DevOps and project management co-exist? Yes, on the daily at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vick Kelkar\"}],\n        \"datePublished\": \"2021-05-11\",\n      }",{"title":1995,"description":1996,"authors":2001,"heroImage":1997,"date":2003,"body":2004,"category":940,"tags":2005},[2002],"Vick Kelkar","2021-05-11","\n\nGitLab is best known as an all-in-one DevOps platform, but it is also an effective tool for project management. Non-technical teams at GitLab, such as [the Marketing team](/blog/gitlab-for-project-management-one/), use the GitLab DevOps platform for project management, and recently the Alliances team learned that DevOps and project management work well for our purposes.\n\n## About the IBM partnership\n\n[GitLab recently launched a partnership with IBM](/press/releases/2021-01-14-gitlab-IBM-to-support-acceleration-of-devops-automation.html) to help the organization automate their DevOps platform. Since I work on the Alliances team, I needed an efficient, compatible, and high-performance project management application to manage the many moving parts of the GitLab and IBM partnership as well as other projects related to our partnerships.\n\nMy very first instinct was to test a few of the project management web applications on the market, but this would involve a tedious process of convincing my colleagues to join me on this journey to explore a sprawling new set of tools. Then I thought why not explore our own Gitlab DevOps platform as a project management tool? The beauty of GitLab is that it is a [DevOps platform](https://www.youtube.com/watch?v=wChaqniv3HI) delivered as a single easy-to-use application.\n\nSome of my early questions were:\n\n- Can the GitLab DevOps platform work as a project management tool for the strategic Alliance team?\n- Can GitLab manage and track business activities over a period of time?\n- Can team members collaborate and manage various projects using a single application?\n\nIn the end, the journey to adopting GitLab as a DevOps platform and project management tool was similar to the journey many of our customers experience. In this blog post, I will dive deeper into how the Alliance team uses GitLab for project management, explain how we used GitLab to onboard a new strategic partner, and launched support of [GitLab Ultimate for IBM Cloud Paks](https://www.ibm.com/products/gitlab-ultimate). All the pre- and post-onboarding activities in particular required collaboration and contributions from various teams across the organization.\n\n## Applying DevOps features to project management\n\n### About epics and roadmaps\n\nWhy organize work into a hierarchy? I began the strategic partnership effort by organizing the work into multi-level epics. The [idea behind epics is to aggregate similar work](https://docs.gitlab.com/ee/user/group/epics/#epics) (or issues) into epics and manage delivery of work. In the example below, you'll see the top-level epic was called \"IBM cloud paks\" which contained three child epics.\n\n![An example of a multi-level epics from the IBM cloud paks project](https://about.gitlab.com/images/blogimages/proj-mgmt-epic.png){: .shadow.medium.center}\nWork is divided into three time-bound levels for the IBM cloud paks project: Pre-launch, 0-90 days, and 90-180 days.\n{: .note.text-center}\n\nAnother way to represent the epics is through a [roadmap view](https://docs.gitlab.com/ee/user/group/roadmap/#roadmap). The main advantage of this feature is that it allows the collaborators on epics and issues to monitor project progress using a calendar timeline view.\n\n![An example of a project management timeline for the IBM cloud paks project using the epics roadmap view](https://about.gitlab.com/images/blogimages/proj-mgmt-timeline.png){: .shadow.medium.center}\nThe same IBM cloud paks project epic is depicted using the Roadmap view, which adopts a timeline view.\n{: .note.text-center}\n\n### How issues are used to capture work\n\nClick into any of the epics to find a set of issues that make up the epic. I use [issues as the basic unit of work](https://docs.gitlab.com/ee/user/project/issues/). Contained within the \"IBM cloud paks: Pre-launch\" epic are 33 issues.\n\n![The list view shows inside the \"IBM cloud paks: Pre-launch\" epic are 33 issues](https://about.gitlab.com/images/blogimages/proj-mgmt-issue.png){: .shadow.medium.center}\nInside the \"IBM cloud paks: Pre-launch\" epic are 33 issues\n{: .note.text-center}\n\nOne thing to note is that an issue can have a single assignee or owner, or it can have multiple assignees.\n\n### How to use issue boards\n\nAn [agile board](/blog/gitlab-for-agile-portfolio-planning-project-management/) can help a user visualize work and manage all the open threads in a given epic and/or project. The board can help you move issues efficiently through various phases of work. On the Alliances team, we are always iterating on how to better track the status of issues. [Here is more information about the current status flows for the Alliances team](/handbook/alliances/#status-alliance---status--status).\n\nThe screenshot below shows how an [issue board can be applied as a Kanban board by filtering for the \"IBM\" label](https://docs.gitlab.com/ee/user/project/issue_board.html#issue-boards). To see transitions between work stages, use [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels), which are mutually exclusive and represent transitions between various workflow statuses, such as \"status::1\" and \"status::2\"\n\n![Kanban board showing how labels can be used to organize issues into work stages](https://about.gitlab.com/images/blogimages/proj-mgmt-board.png){: .shadow.medium.center}\nHow we use boards for the IBM cloud paks project.\n{: .note.text-center}\n\n### Milestones help time-box events\n\nWhile an epic is a collection of related issues, [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), and sub-epics and is generally used to scope a long-running initiative or program (e.g., a marketing campaign or a new product category) epics can also contain smaller, more discrete and timeboxed events, such as monthly releases or calendar quarters. These [timeboxes are represented as Milestones](https://docs.gitlab.com/ee/user/project/milestones/), which roll up issues and merge requests in the same way as higher-level epics. Apply the \"Milestone view\" to track progress on the smaller deliverables within an epic.\n\n![Milestone view showing Alliances team projects](https://about.gitlab.com/images/blogimages/proj-mgmt-milestone.png){: .shadow.medium.center}\nHow milestones can be used to track work progress within a specific time frame.\n{: .note.text-center}\n\n### How Milestone burnup and burndown charts chart progress\n\n[Burnup and burndown charts are used by project managers to measure progress](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html). Burndown charts analyze how much work is left in a project before it can be finished successfully. Burnup charts measure the work that has been done against the total work for the project. Both types of charts are available in the GitLab DevOps platform. I relied mostly on epics and milestones to track work progress for the IBM partnership.\n\n![burndown](https://about.gitlab.com/images/blogimages/proj-mgmt-burndown.png){: .shadow.medium.center}\nThe burdown and burnup charts for the IBM cloud paks partnership project.\n{: .note.text-center}\n\n### Inside analytics and insights project management tools\n\nMost project management tools are great at capturing project details, and can help answer questions such as \"where does the project stand on actual vs. planned activities?\" or can help track progress using milestones and due dates. [Project analytics and insights dashboards](https://docs.gitlab.com/ee/user/analytics/#project-level-analytics) are built into the GitLab DevOps platform. There are many built-in analytics dashboards, such as CI/CD, code review, merge requests, and issues. For the IBM partnership project, I used the [issues dashboard analytics](https://docs.gitlab.com/ee/user/group/issues_analytics/index.html) to see how many issues were opened compared to how many issues were closed. This tool helped me manage the team capacity and identify any bottlenecks in the project.\n\n![The insights dashboard shows how many issues were opened and closed](https://about.gitlab.com/images/blogimages/proj-mgmt-insights.png){: .shadow.medium.center}\nThe insights dashboard shows many issues were opened vs. how many issues were closed each month.\n{: .note.text-center}\n\n[Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) is a particularly unique feature of GitLab's analytics suite. Since GitLab is a complete DevOps platform with a single data store, GitLab can automatically generate reports to not only identify high-level metrics and blockers, but also drill down into those blockers and improve value flow with just a few clicks.\n\n![Showing recent project activity: 32 new issues and 19 commits](https://about.gitlab.com/images/blogimages/proj-mgmt-analysis.png){: .shadow.medium.center}\nAnalytics showing recent project activity.\n{: .note.text-center}\n\nThe Value Stream Analytics provides a high-level view into common stages of the SDLC out-of-the-box, making it easier to monitor the overall workflow from discussion to code changes, through review and collaboration, and out to production – with no additional work required. And since the code changes and collaboration are happening within GitLab, just one click on an item will take you to the blocked issue or merge request, so you can comment, reassign, or contribute to move things along.\n\nSince all the necessary data is already in GitLab's system, customizing Value Stream Analytics can be completed in just a few clicks: Hiding and reordering stages and even creating your own with simple drop-down menus.\n\n![The customized value stream shows the average amount of time spent in the selected stage for each item](https://about.gitlab.com/images/blogimages/proj-mgmt-valuestream.png){: .shadow.medium.center}\nThe custom value stream above shows the number of days to completion.\n{: .note.text-center}\n\n## DevOps platform and project management in one\n\nThere are many project management tools in the marketplace and solutions for managing the SDLC of a project. The GitLab DevOps platform and project management tool satisfied my need to track partnership-related activities while also managing the technical demos and workshops developed for the IBM partnership. I look forward to continuing to explore the constantly-evolving GitLab platform to grow and manage our strategic partnerships on the Alliances team.\n\nCover image by [Martin Sanchez](https://unsplash.com/@martinsanchez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/MD6E2Sv__iA)\n{: .note.text-center}\n",[1630,731,707,9,899],{"slug":2007,"featured":6,"template":687},"project-management-using-gitlab-platform","content:en-us:blog:project-management-using-gitlab-platform.yml","Project Management Using Gitlab Platform","en-us/blog/project-management-using-gitlab-platform.yml","en-us/blog/project-management-using-gitlab-platform",{"_path":2013,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2014,"content":2020,"config":2025,"_id":2027,"_type":14,"title":2028,"_source":16,"_file":2029,"_stem":2030,"_extension":19},"/en-us/blog/pyb-all-remote-mark-frein",{"title":2015,"description":2016,"ogTitle":2015,"ogDescription":2016,"noIndex":6,"ogImage":2017,"ogUrl":2018,"ogSiteName":673,"ogType":674,"canonicalUrls":2018,"schema":2019},"How being all-remote helps us practice our values at GitLab","GitLab CEO Sid Sijbrandij and Mark Frein of InVision talk about why all-remote is the future, and moving beyond 'But how do you know they're working?'","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680686/Blog/Hero%20Images/webcast-cover.png","https://about.gitlab.com/blog/pyb-all-remote-mark-frein","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How being all-remote helps us practice our values at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-07-31\",\n      }",{"title":2015,"description":2016,"authors":2021,"heroImage":2017,"date":2022,"body":2023,"category":705,"tags":2024},[812],"2019-07-31","\n\nAll-remote workplaces like GitLab and InVision are disrupting the status quo by abandoning the office and creating a new model for the ideal workplace, and employees and employers are starting to catch on. GitLab CEO [Sid Sijbrandij](/company/team/#sytses) and [Mark Frein](https://www.linkedin.com/in/mark-frein-886148/), chief people officer at product design platform [InVision](https://www.invisionapp.com/), recently met to chat about the future of remote work, leadership in a distributed company, and the values that drive their work (and why [all-remote](/company/culture/all-remote/) isn’t one of them).\n\n## Build interpersonal relationships, digitally\n\nOn your first day at GitLab or InVision, you don’t walk up to the office, put on a smile, and find your desk. Instead, you sit on your desk chair, deck, or couch, open your laptop and connect using a suite of different technologies that provide a portal into your home.\n\n“I often say, ‘How often do you invite people into your home on day one when you're starting a new job?’” says Mark. “We are already inside your most personal space. We can see your bookcase, we can see things that are important to you, we can see your cat jumping on your lap, because animals always want to make sure they’re with you on important calls.”\n\nWhen a company empowers a distributed team to embrace the inevitable interruptions of doorbells ringing, phones buzzing, and demands from pets, children, and partners, you get to know your remote teammates better than if you shared an office. People are free to share more of themselves than if they were commuting from their homes to a common area.\n\nBy sharing your home, albeit digitally, with your colleagues, it is critical that your teammates show the same degree of humility and empathy for colleagues as they do for customers.\n\nAll-remote companies that are making hiring decisions ought to search for workers that are highly skilled in their areas of expertise, as well as in interpersonal communication. It is the active listeners, clear communicators, and willing collaborators that drive progress in all-remote companies, because these interpersonal skills allow teams to breach the digital divide and make lasting contributions to the company and product.\n\nLeadership in all-remote organizations must be similarly intentional. Managers do not have the benefit of serendipity at all-remote companies; instead, they must work harder to emotionally engage with the people they lead.\n\n## Technology is driving the all-remote movement\n\nThere are three primary communication channels that connect GitLab team members and InVision team members. “I think of our right and left hands as Zoom and Slack,” says Mark. At GitLab, we primarily use our own product, as well as Zoom and Slack to connect our distributed team.\n\nThe advent of these powerful communication tools is what helps all-remote companies like GitLab and InVision exist, and is a driving factor behind the movement for workplaces to go all-remote.\n\n“I think we're just at the beginning of this movement, and a lot of what's worked has been hacked together so far,” says Mark. “I think remote is going to last as long as the history of work, and it’s just in its infancy.”\n\nThinking back to 10 or 15 years ago, communication technologies first started being used in new and unique ways to mediate relationships. Mark points to the early days of online multiplayer game, World of Warcraft, as an example of serious all-remote gaming that helped condition us to using communication technology in collaborative ways. Just like WoW unlocked online massive multiplayer gaming, tools like Zoom unlock the potential of the all-remote workplace.\n\n## But wait, how do you know if they’re working?\n\nThere are many people from outside the all-remote world that remain incredulous about the idea of a distributed team. Both Sid and Mark are often asked the same questions about all-remote: \"How do you know that people are working?\"\n\n“I view these as old workplace, old economy questions,” says Mark. “Those are usually the least interesting questions.”\n\nThe framework that “work” is a lot of people in the building at the same time minimizes the focus on each individual contributor’s work product.\n\n“In many co-located companies, you can just show up and people will presume you’re working, but at GitLab we actually check your output and results,” says Sid.\n\nThere are also many people at co-located companies who will claim they value hiring the best people for the job, or that people are the heart of their organization, a statement largely incongruous with their practices, notes Sid.\n\n“You're saying people are the most important, but you limit your hiring to 1% of the world population? Then the people who are most important, you make them commute two hours of every day?” says Sid.\n\n## The drawbacks of part-remote\n\nIn response to the demand for greater flexibility in scheduling and workplaces, there are more co-located companies that are trying out remote teams or allowing a few remote work days a week or month. While this is generally a move in the right direction for greater employee autonomy, Mark and Sid have some skepticism about the effectiveness of this approach, because in each case there remains a single center of power.\n\n“I am still very much a skeptic around an organization that culturally is anchored in physicality bolting on remote capability,” says Mark. “I have not seen that work, which doesn't mean that it hasn't and I obviously haven't seen every organization out there, but in those cases there sare still real stretches of culture and behaviors when it comes to the haves and have-nots and the people who are in the center.”\n\nThere is intentionally no headquarters for GitLab or InVision, because by creating a physical room where it happens, there are certain advantages for the team members in the room, and disadvantages for those that are not.\n\nHistorically, GitLab’s company robot named Beamy, lived in the San Francisco boardroom, which is in Sid’s home in the city. Beamy was created as an exercise in [transparency](https://handbook.gitlab.com/handbook/values/#transparency), so every GitLab team member can see for themselves that there is no secret headquarters where decisions are made. “I’m just working from home like everyone else,” says Sid.\n\n## All-remote isn’t a value\n\nThe fixtures of GitLab’s company culture are our [values](https://handbook.gitlab.com/handbook/values/): collaboration, results, efficiency, Diversity, Inclusion & Belonging , and transparency. Everything in the company flows from those values, and while being all-remote is a distinguishing feature to our company, like InVision, we don’t really consider it to be a core value.\n\nDuring this part of the discussion, Sid, who is one of the rare people who can stay fully engaged in a conversation while also multitasking, added a section to our handbook, “[What is not a value](https://handbook.gitlab.com/handbook/values/#what-is-not-a-value),” which reads:\n\n“All remote isn't a value. It is something we do because it helps us practice our values of transparency, efficiency, Diversity, Inclusion & Belonging , and results.”\n\nWatch the full conversation between Sid and Mark on GitLab Unfiltered.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/IFBj9KQSQXA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[1925,683,9],{"slug":2026,"featured":6,"template":687},"pyb-all-remote-mark-frein","content:en-us:blog:pyb-all-remote-mark-frein.yml","Pyb All Remote Mark Frein","en-us/blog/pyb-all-remote-mark-frein.yml","en-us/blog/pyb-all-remote-mark-frein",{"_path":2032,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2033,"content":2039,"config":2045,"_id":2047,"_type":14,"title":2048,"_source":16,"_file":2049,"_stem":2050,"_extension":19},"/en-us/blog/remote-enables-innovation",{"title":2034,"description":2035,"ogTitle":2034,"ogDescription":2035,"noIndex":6,"ogImage":2036,"ogUrl":2037,"ogSiteName":673,"ogType":674,"canonicalUrls":2037,"schema":2038},"How remote work enables rapid innovation at GitLab","At GitLab, remote isn’t a business operations risk, it’s a competitive advantage.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678666/Blog/Hero%20Images/paper-lanterns.jpg","https://about.gitlab.com/blog/remote-enables-innovation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How remote work enables rapid innovation at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"}],\n        \"datePublished\": \"2019-02-27\",\n      }",{"title":2034,"description":2035,"authors":2040,"heroImage":2036,"date":2042,"body":2043,"category":705,"tags":2044},[2041],"Victor Wu","2019-02-27","\nI’m a Product Manager here at GitLab, primarily contributing to the [Plan stage](/direction/plan/)\nof the [DevOps lifecycle](/stages-devops-lifecycle/). I joined in November 2016 and I’ve witnessed incredible\ngrowth in GitLab the product as well as GitLab the team. Many\nnew hires have asked me during [coffee chats](/company/culture/all-remote/#coffee-chats)\nabout GitLab culture and remote work in particular, since we're an [all-remote](/company/culture/all-remote/)\ncompany. My view has evolved over this time and I wanted to share specifically why I think\nremote is _not_ a challenge to overcome, but actually a _competitive advantage_, at least for GitLab.\n\n## A remote journey\n\nWhen I joined GitLab, I thought remote was a challenge to overcome or at least\nto manage. It was a risk to be mitigated. For example, I really wanted daily standup\nmeetings with the engineering team I was working with. Silicon Valley-style tech\ncompanies and product management books tell us that frequent, synchronous, face-to-face\ncommunication is necessary for building successful products efficiently and to win\nin the marketplace. To my dismay at the time, we never had in-sync standups (and\nmy team today still doesn’t have them). But curiously, we nonetheless had immense\ncollaboration and continued to ship product at a high velocity. Something really\nweird and unexpected was going on.\n\nLater on, as I started getting comfortable [doing product the GitLab way](/handbook/product/),\nI started to think that remote wasn’t really a risk, but that there were just a\nfew negatives, and that the overall effect was net positive. See the [advantages and disadvantages of remote](/company/culture/all-remote/#advantages-for-employees).\n\nToday, I realize that even a positive-negative accounting of remote is insufficient\nto articulate what remote means at GitLab. I think that remote\n(along with a few other key crucial GitLab ingredients) gives us a differentiated\nand competitive advantage, in particular allowing us to innovate at a rapid pace\nthat is truly unique. Here's why:\n\n## Interdependent ingredients\n\nThere are a several crucial and interdependent GitLab ingredients that make remote\ntruly work in our favor:\n\n### Async communication\n\nRemote implies geographic diversity (since we hire all over the world),\nand because most folks work during the day, that further implies time zone diversity.\nConsequently, we prefer **[Async communication (primarily with text)](/handbook/communication/)** as we scale our organization in\nspace-time. Async demands everything be written down and that it be clear and concise.\nYou can’t afford a prolonged back-and-forth conversation because every round-trip\ntransaction is possibly 24 hours in the worst case. In particular, we prefer text\nbecause the internet and modern apps (for example [GitLab issues](https://docs.gitlab.com/ee/user/project/issues/)) has allowed text\nto be easily organizable, searchable, and even hyperlinked. Text is easy to parse\nand thus consume. It is a highly efficient form of communication, especially for\ntransactional collaboration.\n\n### Transparency\n\nThe async communication we reference is also digital, making it infinitely\nscalable. Unlike the printed page in a physical office, anybody should\nbe able to access a digital message. So, rather than re-erecting the walls and silos\nthat plague traditional organizations and inevitably block collaboration, we\nmake communications and work **[transparent](https://handbook.gitlab.com/handbook/values/#transparency)** by default.\nAdding a layer of permissions is necessary sometimes, and in those cases it becomes an overhead cost to manage\nand use (for example fixing a security bug.) The transmitter of communications\nneeds to figure out who should receive, and set the appropriate permissions. The\nreceiver themself needs additional work to access the content. It’s more pain. It\nadds up. So we try to avoid it when we can.\n\n>Because you know everything you write down will potentially be viewed by anyone – inside or even outside the company – simply telling the truth is the optimal and most efficient strategy\n\nTransparency also makes it really easy to tell the truth, and disincentivizes dishonesty.\nTelling the truth is simply the right thing to do, but it’s also a great strategy\nto grow a long-term sustainable business. In particular, because you know everything\nyou write down will potentially be viewed by anyone in the company or even outside\nthe company, simply telling the truth is the optimal and most efficient strategy\nand you will thus adopt it with little friction. You don’t have to make up slightly\ndifferent versions for different stakeholders. You don’t have to keep track of all\nthese versions. And you only need a single artifact to document that one source\nof truth, which will never be out of sync, because there’s only one! For\nus, that single source of truth is typically the description in an issue.\n\n### Everyone can contribute\n\nWith a single source of truth that is consumable by anybody, it allows **[everyone to contribute](/company/mission/#mission)**.\nEveryone has information parity. And so anyone is welcome to contribute. In fact,\nremember I mentioned above that the transmitter of information typically has an intended receiver\nin mind? In this case, oftentimes somebody who they didn’t expect can even participate\nand add value. This isn’t possible if there’s no transparency because artificial\nbarriers pre-close the opportunities of potential collaboration. Also, everyone\ncan contribute means future folks can participate too. You may start a conversation\non an idea that turns out to be suboptimal in the current circumstances. But it\nmight end up being just a timing issue. And so posterity might be able to recover\nthe old idea and ship a feature later on, taking advantage of all the discussions\nthat were had and made available publicly.\n\nEveryone can contribute also means that the diversity of ideas skyrockets. And so\nat GitLab, people often cross departments and offer some of the best ideas to solve\nbig challenging problems. But we still have [directly responsible individuals](/handbook/people-group/directly-responsible-individuals/)\nto make decisions in order to avoid analysis paralysis.\n\n### Iteration\n\nFinally, how can all this communication and collaboration truly function if the\nmechanisms are so transactional, distributed, and unstructured? It works because\nit forces us to be **[iterative](https://handbook.gitlab.com/handbook/values/#iteration)**. Most people think they understand iteration (myself\nincluded) before joining GitLab. But I’ve discovered over and over again that new\nfolks are surprised that this concept is taken to an extreme. Product\nand code are shipped in the absolute smallest piece possible in an effort to get\nfeedback and momentum. Implementing programs and processes at GitLab means breaking\noff the smallest chunk and then putting it into action right away. We still make\nbig, bold plans and big bets on the future. But we don’t obsess over extended analysis.\nInstead we find the smallest thing that we can do now and we do it. We believe that\nwaiting until tomorrow is an opportunity cost. Doing something small today is low\nrisk and results in immediate feedback. We have a [bias for action](https://handbook.gitlab.com/handbook/values/#bias-for-action).\n\n>We believe that waiting until tomorrow is an opportunity cost. Doing something small today is low\nrisk and results in immediate feedback.\n\nAnd so if all our communication and collaboration is focused on small iterations,\nthe scope of a typical  problem is small and manageable. And it turns out (unsurprisingly)\nmore people are willing to participate in a small problem if it literally takes\nthem a few moments to voluntarily glance at an issue description, instead of being\nforced to attend a two-hour slide presentation explaining a big problem.\nAnd since the problem is made transparent by default, the pool of contributors is\nvery high, as mentioned earlier. Personally, I am actively involved\nin at least 20 to 30 parallel problem conversations on a daily basis. It is impossible\nfor anyone to achieve that level of productivity if all to those conversations required\ndedicated, ongoing, synchronous meetings. This results in an incredible rate of collaboration\nfor myself. Multiply that by all team members at GitLab, and then also all GitLab\ncommunity members further still, and you can see now why GitLab’s pace of innovation\nis ridiculously high.\n\nRemote is not a challenge for GitLab to overcome. It’s a clear business advantage.\n\n## Ending caveat\n\nThe picture I’ve painted here is one of constant messaging and wild ideas. And\nthat’s intentional because it’s true. New folks joining GitLab often are inundated\nby the number of discussions they find themselves involved in after several weeks\nin. This is indeed an ongoing risk for GitLab especially as we scale and the level\nof ideation grows exponentially in relation to headcount (since communication links\ngrow exponentially as nodes in a people network grow). I’ve observed that GitLab\nteam members usually figure out a way to cope soon enough, and typically become\nmore selective in their communications over time. I think this is a good general\nstrategy overall, because good ideas tend to get more attention, and we essentially\nrely on the wisdom of the crowds to surface them. Of course we still have well-defined\nroles and responsibilities that serve as guardrails too, that allow subject matter\nexperts and directly responsible individuals to strategically guide our innovation\nin the right general direction.\n\nHow are you making remote work work? Let us know in the comments or tweet us [@gitlab](https://twitter.com/gitlab).\n\n[Cover image](https://unsplash.com/photos/TaXPogWdzR0) by [amseaman](https://unsplash.com/@amseaman) on Unsplash\n{: .note}\n",[731,683,9,684,899],{"slug":2046,"featured":6,"template":687},"remote-enables-innovation","content:en-us:blog:remote-enables-innovation.yml","Remote Enables Innovation","en-us/blog/remote-enables-innovation.yml","en-us/blog/remote-enables-innovation",{"_path":2052,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2053,"content":2059,"config":2066,"_id":2068,"_type":14,"title":2069,"_source":16,"_file":2070,"_stem":2071,"_extension":19},"/en-us/blog/remote-future-how-remote-companies-stay-connected",{"title":2054,"description":2055,"ogTitle":2054,"ogDescription":2055,"noIndex":6,"ogImage":2056,"ogUrl":2057,"ogSiteName":673,"ogType":674,"canonicalUrls":2057,"schema":2058},"Remote teams: How tech companies build future collaboration","Resistance to remote work often stems from fears of reduced collaboration, isolation, and complexity – here's why those fears are unfounded.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678684/Blog/Hero%20Images/remote-future.jpg","https://about.gitlab.com/blog/remote-future-how-remote-companies-stay-connected","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The remote future: How tech companies are helping their remote teams connect\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ariel Camus\"}],\n        \"datePublished\": \"2018-04-27\",\n      }",{"title":2060,"description":2055,"authors":2061,"heroImage":2056,"date":2063,"body":2064,"category":705,"tags":2065},"The remote future: How tech companies are helping their remote teams connect",[2062],"Ariel Camus","2018-04-27","\nA few weeks ago, I was surprised when I saw the following [tweet](https://twitter.com/ManuKumar/status/972548351123062784) from [Manu Kumar](https://twitter.com/ManuKumar), investor of Lyft and Twilio, among many other successful startups:\n\n![Manu Kamar tweet](https://about.gitlab.com/images/blogimages/remote-future-tweet.png){: .shadow.center.medium}\n\nManu Kumar was known for his clear determination to invest only in startups whose team were at a bike distance from his house in Silicon Valley. And maybe he still wants the founders to be close to him, but he is also clearly seeing and accepting the huge problem companies are facing when trying to find talent.\n\nHowever, **in order to make that remote future possible, we need to look at why** companies have resisted the idea of creating and managing remote teams. Managers and founders are afraid that remote collaboration will prevent their employees from having impromptu conversations, which will then kill innovation within the organization. There are also issues connected to trust between managers and the people that report to them, interpersonal problems due to isolation, increased complexity in communication, and so on.\n\nHowever, **companies are being forced to start considering hiring remote employees if they want access to the best talent** they can afford. An outdated education system and strict immigration laws are making this a real issue. Isn’t that ironic considering the Internet has made access to knowledge and distributed collaboration easier than ever?\n\n## How to make remote work work\n\nThe best way to understand what innovation in the remote workspace is like is to look at what companies with distributed teams are already doing. And if there is something they have in common, it is that **they all create plenty of opportunities for their team members to have face-to-face conversations**.\n\n### Encourage virtual face-to-face time\n\nGitLab, for example, has created an internal system to coordinate weekly “[digital coffee breaks](/company/culture/all-remote/tips/#coffee-chats)” between its employees, who are encouraged to dedicate a few hours a week to having social calls with any teammate. They can also join a Slack channel where, every Monday, a bot will pair them with a random team member. This way, GitLab is creating intentional spaces for spontaneous and personal connection to happen between its employees.\n\nHowever, no video conference or digital solution can replace actual face-to-face communication.\n\nAnecdotally, a friend of mine recently quit the agency where she used to work as a remote software developer. She moved to another agency where she now does the exact same job. Why? Because even though she works as part of a remote team for clients who are based all around the world, the new agency puts a lot of effort into creating a local community of colleagues where my friend can find a network of support. And this is just one example of how “remote work” doesn’t necessarily have to mean “alone work.”\n\n### Make time for real face-to-face time\n\nA clear example of how remote companies are creating opportunities for real face-to-face conversations to happen is team retreats. [GitLab](/events/gitlab-contribute/), Buffer, Zapier, and HelpScout are some of the companies who organize at least a **yearly team retreat where all of their employees travel to the same place and spend a few days, or even weeks, together**.\n\n[Zapier’s co-founder, Wade Foster, said](https://zapier.com/blog/how-to-run-company-retreat/) that…\n\n>Some things are just better done in person. For instance, it’s hard to have an impromptu, deep conversation with a teammate over Google Hangout **about their kids, some random idea you’ve had improving a secondary process in the company, or company values**. All those things tend to naturally happen in person, while they don’t happen in a remote team unless you force it.\n\nBut also, as companies evolve and their teams grow, their retreats change to serve the right purpose.\n\nBuffer’s CEO, Joel Gascoigne, said in an interview with Inc. that…\n\n>When we were a team of less than 30 people, the retreats felt like they could be a productive day-to-day work time for us, a shift towards working together, but continuing with the projects we happened to be working on. **Today our retreats serve less of a purpose of immediate productivity and are more geared towards long-term productivity and meaningful connectedness of the team**.\n\n### Learn from what others are doing right\n\nOther initiatives, like the [Running Remote conference](https://runningremote.com/) taking place in **Bali on June 23–24**, are also trying to create spaces to help distributed companies learn strategies to manage and grow their remote teams. In the case of the Running Remote conference, the fact that they have chosen Bali as their hosting place is no coincidence. Due to its weather, culture, food, and waves, Bali has lately become the place chosen by a lot of companies with distributed teams to organize their team retreats.\n\nAt my company, [Microverse](https://www.microverse.org/), we are trying to tackle this issue at an earlier stage. We’re constantly looking for talent all around the world and training it to become remote software developers. **Our students learn in small distributed teams doing remote pair programming, all while working on freelance and open source projects**. And even though learning is happening in an online and distributed fashion, my vision for the future of education and Microverse, is one where our students will also have access to local co-learning spaces where they can find a community that will support them, because everyone benefits from face-to-face time, and that doesn't have to be with co-workers.\n\nWhat’s really great about the future of remote work is that it doesn’t only help companies access the best talent in the world, but it also helps talent flourish regardless of where people are born. As they say, talent is evenly distributed, but opportunities are not, and we now have the chance to change that.\n\nHopefully, we will all continue learning how to better manage remote organizations and how to make people in those organizations connect at a much deeper human level And in the process, we will make the world a much fairer place.\n\n### About the guest author\n\n[Ariel Camus](https://twitter.com/arielcamus) is the founder of [Microverse](https://www.microverse.org/),\na company finding the world's untapped talent and training it to become remote software developers. Ariel was previously the co-founder and CEO\nof TouristEye, a travel startup that he grew to a million users and sold to Lonely Planet in 2013.\n\n[Photo](https://unsplash.com/photos/tysecUm5HJA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) by Papaioannou Kostas on Unsplash\n{: .note}\n",[9],{"slug":2067,"featured":6,"template":687},"remote-future-how-remote-companies-stay-connected","content:en-us:blog:remote-future-how-remote-companies-stay-connected.yml","Remote Future How Remote Companies Stay Connected","en-us/blog/remote-future-how-remote-companies-stay-connected.yml","en-us/blog/remote-future-how-remote-companies-stay-connected",{"_path":2073,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2074,"content":2080,"config":2086,"_id":2088,"_type":14,"title":2089,"_source":16,"_file":2090,"_stem":2091,"_extension":19},"/en-us/blog/remote-kids-part-four",{"title":2075,"description":2076,"ogTitle":2075,"ogDescription":2076,"noIndex":6,"ogImage":2077,"ogUrl":2078,"ogSiteName":673,"ogType":674,"canonicalUrls":2078,"schema":2079},"5 Things to keep in mind while working remotely with kids","A flex schedule, realistic expectations, and a positive attitude will make it easier to work with kids around.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680690/Blog/Hero%20Images/working-at-home-with-kids.jpg","https://about.gitlab.com/blog/remote-kids-part-four","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Things to keep in mind while working remotely with kids\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sean McGivern\"}],\n        \"datePublished\": \"2019-08-08\",\n      }",{"title":2075,"description":2076,"authors":2081,"heroImage":2077,"date":2083,"body":2084,"category":705,"tags":2085},[2082],"Sean McGivern","2019-08-08","\n\n_This is the fourth and final blog post in our series on working remotely with children of all ages. In part one we looked at [maternity/paternity leave policies around the world](/blog/how-is-it-being-a-new-mom-working-for-gitlab/); in part two Jarka Košanová shared her experience [working at GitLab with a newborn](/blog/balancing-career-and-baby/); and in part three GitLab team members had good advice to [make the most of workspace shared with children](/blog/working-remotely-with-children-at-home/)._\n\nDuring [GitLab Contribute 2019](/blog/contribute-wrap-up/) in\nNew Orleans, facilitators [Lyle Kozloff][lyle] and myself, [Sean McGivern][smcgivern], hosted\nfour unconference sessions about\nworking remotely with children at home. GitLab team members had helpful and practical\nadvice on everything from flexibility to time with a partner.\n\n## 1. Embrace a flexible schedule\n\n> My son started playschool (recently) and it's only two hours. I don't go home\nbecause it's a waste of time so I work from there – no coding, no\ndeep work, just going through mentions and stuff. – [_Heinrich Lee Yu, backend engineer_][engwan]\n\n> My daughter has always been a great sleeper, so my husband\nand I wake up around 5:00 each morning (he also works remotely)\nto get a head start on work. We are usually able to get a couple\nhours of work in before she even wakes up, freeing up our afternoon\nto spend time with her. – [_Annabel Dunstone Gray, product designer_][annabeldunstone]\n\nBy [working asynchronously](/handbook/communication/#introduction) we can arrange our time to match our own schedules. (This doesn't only apply to parents, of course; anyone can do this.) Different roles have different expectations, of course. If you work in Support you’ll need to provide timezone coverage, but even within that, there\nis a lot of scope to arrange your work schedule to match your childcare,\nrather than the other way around.\n\n## 2. Be more disciplined with that schedule\n\n> I had to get a lot more disciplined with my time. When I was young and\nsingle I could just get behind and pull an all-nighter, but I can't do\n that any more. I'm more efficient. There's a switching cost, but\n you'll be better in the long run. – [_Eric Johnson, VP of Engineering_][edjdev]\n\n> Having kids will make you develop this efficiency, I have to pick my\n son up from kindergarten at four and sometimes no one else can do that, so I need\n to schedule my work around that. - [_Grzegorz Bizon, staff backend engineer_][grzesiek]\n\nBeing flexible doesn't mean being undisciplined. With children at home,\nthere are a lot of competing demands on your time. For many people, this\nmeans that they become more efficient out of necessity. It’s hard to partly work and partly do something and then make up for it with extra hours at the keyboard, because there are no more spare hours.\n\n## 3. The role of relationships\n\n> My wife and I made an agreement that we're not going to let kids stop\nus doing sports. We play on the same teams, and we just bring our\nkids. There's normally enough people around to help keep an eye on\nthem while we're playing. It's hard when my wife's working one night,\nthough. – [_Chris Maurer – manager, Customer Success, Public Sector_][cdmaurer13]\n\n> When we had the first kid, we were doing everything as a couple:\nwhatever it was, we were together. Then, with the arrival of our\nsecond kid, we felt like we had to care for one kid each. With time,\nthe fear of ending up alone with both kids had taken root. We had to\nchange something: we simply had to let go. One person can care for both\nkids for the night, and the other one is free to go out and do\nwhatever they want. Turns out this actually totally removed the fear\nof being alone. We both let each other go out to do something social to\nreinvigorate a bit. We even started bouldering, but we never go on\nthe same night. – [_Micaël Bergeron, backend engineer_][mbergeron]\n\nIt's important to keep doing things you enjoy when you have children. It\nsets a good model for your children, and will make you happier which\nwill help you be a better parent.\n\n## 4. Set expectations\n\n> It took us an entire child to realise that while co-suffering feels\nlike the right thing to do, it's less efficient – you both end up tired\nand exhausted. – [_Lyle Kozloff, Support engineering manager_][lyle]\n\n> Don't keep count of the things that you and your partner are doing,\njust do everything you can. I did the majority of the raising the\nbabies, but my husband would take night things. – [_Karlia Kue,\nBusiness Systems Analyst_][kxkue]\n\nThis relates to every other point here. The worst thing that can happen\nis that people get resentful or stressed, and that is more likely to\nhappen when it's not clear whose responsibility it is.\n\nOn a personal note, and although it sounds a little goofy: The concept\nof [directly responsible individuals](/handbook/people-group/directly-responsible-individuals/) we use at GitLab also helped my partner and I manage the way we think about who's responsible for our\nson at any point.\n\n## 5. Enjoy it\n\n> My daughter is my best friend, and I am so blessed to be able to see her\ngrow into her own little person while still accomplishing my professional goals.\nSeeing her interact (\"Hi!\" for everyone) with all of my GitLab teammates at\nContribute was also very special. – [_Brittany Rohde, Compensation & Benefits Manager_][brittanyr]\n\nI really appreciate the amount of time I can spend with my son. I see\nhim for several hours every single day. Coming to New Orleans for\nContribute was hard!\n\nHaving a child has been the best part of my life so far. A big part of\nthat was having a job that meant I could spend a good amount of time\nwith him every day without feeling like I was doing something wrong or\nnot being productive.\n\n## Remote work makes it easier\n\nWorking remotely doesn't change the fact that being a parent is\nchallenging, but it does help provide time and space to navigate those\nchallenges.\n\nWhat tips have you stumbled across while working remotely with kids at\nhome? Let us know in the comments or tweet us [@gitlab](https://twitter.com/gitlab).\n\nPhoto by [Baby Natur](https://unsplash.com/@babynatur?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/kids-toys?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n\n[annabeldunstone]: /company/team/#annabeldunstone\n[brittanyr]: /company/team/#brittanyr\n[cdmaurer13]: /company/team/#mauichief\n[edjdev]: /company/team/#edjdev\n[engwan]: /company/team/#engwan\n[grzesiek]: /company/team/#GrzegorzBizon\n[kxkue]: /company/team/#karliakue\n[lyle]: /company/team/#lkozloff\n[mbergeron]: /company/team/#micaelbergeron\n[smcgivern]: /company/team/#mcgivernsa\n",[9,708,683],{"slug":2087,"featured":6,"template":687},"remote-kids-part-four","content:en-us:blog:remote-kids-part-four.yml","Remote Kids Part Four","en-us/blog/remote-kids-part-four.yml","en-us/blog/remote-kids-part-four",{"_path":2093,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2094,"content":2099,"config":2104,"_id":2106,"_type":14,"title":2107,"_source":16,"_file":2108,"_stem":2109,"_extension":19},"/en-us/blog/remote-pair-programming-tips",{"title":2095,"description":2096,"ogTitle":2095,"ogDescription":2096,"noIndex":6,"ogImage":807,"ogUrl":2097,"ogSiteName":673,"ogType":674,"canonicalUrls":2097,"schema":2098},"4 tips for agile remote pair programming","Pair programming is great for remote collaboration. Our remote pairing enthusiasts share how to make the most of it.","https://about.gitlab.com/blog/remote-pair-programming-tips","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 tips for agile remote pair programming\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2021-02-04\",\n      }",{"title":2095,"description":2096,"authors":2100,"heroImage":807,"date":2101,"body":2102,"category":705,"tags":2103},[1335],"2021-02-04","\n\n_This is the second post in our ongoing series about remote work and engineering. Check out our first post, \n[Tips for engineering managers learning to lead remotely](/blog/tips-for-managing-engineering-teams-remotely/)._\n\nAs more companies shift to remote-first or all-remote work, engineers may be feeling the loss \nof their teammates' company. The good news is that unlike other forms of in-person collaboration,\npair programming translates really well to remote work, and in some cases is even more effective. \n\nOur [support engineers](https://handbook.gitlab.com/job-families/engineering/support-engineer/overview/) do regular \npair programming on tickets, and many speak of it as a highlight of their work weeks due to the \nsocial element of the calls, as well as it proving more efficient for some troublesome tickets. \n(We'll dive into why, but feel free to jump to our [tips for effective remote pair programming](#how-to-get-the-most-out-of-remote-pairing)\nif you prefer!)\n\n## What is pair programming?\n\nPair programming (sometimes referred to as paired programming)  is an agile, collaborative software development method done between a team of two developers that each take on an individual role. These roles are called the driver and the navigator. The driver works directly at the computer while the navigator concentrates on the overall programming direction.\n\nThe purpose of pair programming is to design, code, and test user stories all on one computer. Although the driver is the primary teammate at the keyboard, this system requires that each developer role have equal time and responsibility to complete their part of the development. The driver writes the code and the navigator reviews it, and these roles can be switched between the two teammates as needed.\n\n## It's more than just work\n\n[Ronald van Zon](/company/team/#rvzon), senior support engineer, explained that pair programming provides an opportunity for team members to chat about their lives outside of work, instead of focusing solely on outstanding tickets. \n\n\"You see someone face to face, so you might ask them, 'Hey, how was Christmas? How are you doing?' \nIf they have something going on in their private life, the next time I see them I will ask about it, so there's a social aspect to it.\"\n\n\"It's a lot of fun. In cases where you're really focused on work and you have a very difficult ticket, it's actually very nice to have someone there just to throw your ideas at.\" \n\n## You see the problem more clearly\n\nInstead of relying solely on your judgment, programming in pairs means your teammate might ask you questions about something, introducing ideas you hadn't necessarily thought of, and identifying gaps you would otherwise miss.\n\n\"For example, we had one very long-running ticket, where we'd tried a hundred thousand things already, \nand weren't sure what to do next,\" Ronald says. \"Just by talking with a group and explaining what the situation \nwas helped me realize what the next steps should be. I could have looked at that ticket the entire \nday and wouldn't have come up with it on my own.\"\n\nSenior support \nengineer [Arihant Godha](/company/team/#arihantar) explains another scenario where pair programming paid off in a big way. \"In one of our pairings we worked \non a complex customer issue related to merge trains, where we did a multi-cross-team pairing \nand identified the crucial issue which was a blocker for one of our biggest customers. \nWe didn't just identify the problem, we also found the workaround for it until our developers \nwere able to deliver a fix.\"\n\n## You can pool your knowledge\n\nAs the saying goes, two heads are better than one. Pair programming allows engineers who may be experts on different things to come together to tackle a single problem. \n\n\"Pairing on tickets is a great way to collaborate on problem solving,\" says [Cynthia Ng](/company/team/#cynthia), \nsenior support engineer. \"It’s especially useful at GitLab, where we have a single product that \ncovers a wide variety of areas, because each person has expertise on different parts. \nSeeing how others approach and solve problems can also greatly inform your own work as well.\"\n\nSupport engineer [Anton Smith](/company/team/#anton) agrees: \"I find that I learn and absorb so much knowledge just from conversing with another support engineer in a pairing call.\"\n\n## You get to the best solution\n\n\"A problem can have multiple solutions and multiple approaches to solve,\" says Arihant. \n\"Sometimes ticket pairing gives you the best approach to solve a ticket. It also helps you in learning \nand sharing knowledge. For example: If you can ask for all the required information in one\n ticket response rather than having lots of back and forth, then it’s a great user experience.\" \n \nCynthia shares a specific example from her past experience with pair programming. \"[Davin Walker](/company/team/#davinwalker) and I paired a couple of times on getting trials \nand their expiry dates showing on the admin side of GitLab’s Customers Portal. \nThe [merge request](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2096) \nis meant to help improve our team’s efficiency in handling SaaS trial-related requests. \nPairing really helped to work out the scope of the issue and what we could ship as the first iteration.\"\n\n## Benefits of pair programming\n\nThe benefit of pair programming is that there are two sets of eyes to help review the code being produced to ensure that it is as good as it possibly can be. This is commonly known as the four-eyes principle. \n\nThis leads to other benefits, like…\n\n* Reducing the number of coding mistakes\n* Becoming a better coder overall\n* Learning from another experienced developer as well as learning from the mistakes made during a project\n* Building better collaboration skills\n\nThis system also breaks up the development project into smaller, specifically defined tasks under the agile project structure. \n\n## Why _remote_ pair programming works\n\nIn speaking to our remote pairing fans, it's clear that pair programming is a form of collaboration that \ndoesn't lose anything by being conducted remotely.\n\n\"It's no different from sitting next to the person. In fact it gives you a better view to look at and \nfind better approaches simultaneously without wasting any time,\" says Arihant.\n\n\"I’ve done pair programming in person and I actually find it easier remote because of screen sharing,\" explains Cynthia. \"You have more control over what you’re looking at and how, whereas in person, often the main thing you’re working on together is on one person’s screen.\"\n\n## How to get the most out of remote pairing\n\n### 1. Know when to pair \n\nWe've focused on tickets so far because our support engineers at GitLab are our biggest remote pairing advocates. \nSupport engineering often involves debugging a customer problem, so it tracks that pairing would be \nuseful (compared to developers who are usually focused on building something). But really, any developer can \nbenefit from pairing when stuck on a problem. \n\nRonald worked as a developer for more than 15 years before joining the Support team at GitLab, \nincluding a year spent as the only developer for an entire company. \"One thing I learned really \nquickly was that if I was stuck on a problem, essentially, I had no one to talk to, which made things difficult.\"\n\nWorking in isolation, without the distractions of the office, is great when you're in the zone. \"It works until you run into a difficult problem to solve,\" says Ronald. \"Spending three days on a problem, before getting to the single line of code that solves it, sucks.\" If you find yourself not making any progress on a challenge, it's probably time to pair.\n\n### 2. Go in with a clear agenda\n\nOut of [respect for everyone's time](https://handbook.gitlab.com/handbook/values/#be-respectful-of-others-time), we recommend that every meeting start with an agenda, and scheduling a pair programming session is no exception.\n\n\"I think it’s important to set expectations or goals for the session. It can be fairly general like, 'explore what options we have,' but the key is to make sure you’re on the same page about what you want to do during the session,\" says Cynthia.\n\nArihant agrees: \"The agenda should be set beforehand so you have enough time to understand the problem statement.\" \nOtherwise you might spend 20 minutes reading through tickets or bug reports before landing on something to work on together. \n\n### 3. Tackle bugs one at a time\n\n\"Take one problem at a time and try to reproduce if you are trying to solve a bug,\" Arihant recommends. It might be tempting to try to solve more than one problem if you think they're connected, but you really won't know that until you fix the first thing. \n\n### 4. Speak up! \n\nThis goes for remote or in-person pairing: speaking freely helps to get to the root of the problem more quickly.\n\"Don’t be afraid to voice your opinion,\" advises Anton. \"Even if something is wrong, it helps eliminate the cause of a problem and it might spark alternative ideas.\" \n\n## How we do remote pairing \n\nAt GitLab, we have a mix of ad hoc and scheduled pairing sessions. \"Pairings are required as \npart of the Support team onboarding, and we also have a support [Donut app](https://www.donut.com/) \nchannel that people can join to decide who to pair with,\" explains Cynthia.\n\nHaving recurring pairing sessions can help engineers stay connected with their teammates, says Anton, but spontaneity can be helpful if you're swamped or get stuck on a problem: \"If I am working in the queue to stop tickets from breaching, sometimes I will publicly post my Zoom room link in Slack and allow anyone to join.\"\n\nArihant says, \"If I want to pair with someone I simply ask them in team chat or simply send them a calendar invite. If it is for a specific topic or group, then I check the [area of focus](https://gitlab-com.gitlab.io/support/team/areas-of-focus.html) or [skills by person](https://gitlab-com.gitlab.io/support/team/skills-by-person.html) pages to find the best person to partner with.\"\n\nWe also have a [dedicated issue tracker for support pairings](https://gitlab.com/gitlab-com/support/support-pairing/-/issues)\nso team members can track who they've paired with and on what.\n\n_Keep an eye out for the next post in our series, where we'll be sharing more remote collaboration practices for engineers._\n",[731,9],{"slug":2105,"featured":6,"template":687},"remote-pair-programming-tips","content:en-us:blog:remote-pair-programming-tips.yml","Remote Pair Programming Tips","en-us/blog/remote-pair-programming-tips.yml","en-us/blog/remote-pair-programming-tips",{"_path":2111,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2112,"content":2118,"config":2124,"_id":2126,"_type":14,"title":2127,"_source":16,"_file":2128,"_stem":2129,"_extension":19},"/en-us/blog/remote-work-done-right",{"title":2113,"description":2114,"ogTitle":2113,"ogDescription":2114,"noIndex":6,"ogImage":2115,"ogUrl":2116,"ogSiteName":673,"ogType":674,"canonicalUrls":2116,"schema":2117},"Remote work, done right","Guest author Nolan Myers hated conference calls. Here's how we changed his mind.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679812/Blog/Hero%20Images/remote-work-done-right.jpg","https://about.gitlab.com/blog/remote-work-done-right","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Remote work, done right\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nolan Myers\"}],\n        \"datePublished\": \"2018-03-16\",\n      }",{"title":2113,"description":2114,"authors":2119,"heroImage":2115,"date":2121,"body":2122,"category":705,"tags":2123},[2120],"Nolan Myers","2018-03-16","\n\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or discussion of other things related to GitLab._\n\nI’ve been on many terrible conference calls. The gentle voice telling me to enter my nine-digit pin, followed by the pound sign, feels like disappointment before the call even begins. That’s why I was so surprised to hear that GitLab – a company of over 200 people – runs without an office. How could anything get done when every meeting was remote?\n\n\u003C!-- more -->\n\nSeeing is believing, so I jumped at the opportunity to watch firsthand. What I learned convinced me that remote meetings can be just as good as in person, and maybe even better. Here’s what impressed me:\n\n### Video conference for all\n\nEveryone joined a Zoom call, each from their own computer. Most everyone had their cameras on, which gave enough visual cues to see their mood; sometimes even an understanding of who they are, like seeing a pool table or disassembled motorcycle behind them. The video format helped enforce some good meeting practices. Only one speaker at a time; a singular focus of attention, either a person or a shared screen. Meetings started on time, never having to wait for a previous group to clear a conference room. Having everyone join independently also worked much better than having a few people in a room and a few remotes, which inevitably creates a power-center in the room.\n\n>The video format helped enforce some good meeting practices: only one speaker at a time; a singular focus of attention\n\n### Create a live agenda in a shared document\n\nEach meeting started with an agenda in a shared Google Doc. They coupled this with a “write before you speak” etiquette. Anyone was welcome to speak, and added a brief summary of their question or comment into the shared doc before chiming in. This encouraged the speaker to be deliberate about their point, think about where in the flow it made most sense, and to know they’d get the floor when appropriate. It was kind of a marvel to see bullets and sub-bullets evolve during the meeting. A task owner typed “TODO: follow up” right as they said “I got it.” Even better, they were left with detailed meeting notes for posterity.\n\n>It was kind of a marvel to see bullets and sub-bullets evolve during the meeting. A task owner typed “TODO: follow up” right as they said “I got it.”\n\n### Embrace multitasking\n\nHow often have you heard that you should give a meeting your undivided attention? And how often have you actually believed it? GitLab embraces multitasking. Having everyone together ensures the right people are there for important conversations. But inevitably a packed meeting agenda will have sections more and less relevant to a variety of participants. Unlike in a room, a video call where someone tunes out for a bit doesn’t hamper the effectiveness of those focused on a conversation. The shared agenda let everyone know when they were needed, and each topic had the right people ready to contribute.\n\n### Caveats and considerations\n\nThis process felt like a miniature miracle to watch, but does need the right tools. GitLab relied on Zoom and it worked well. One external call used WebEx, and its longer latency led people accidentally to talk over one another. Google Docs was a must for the shared agenda. Everyone had set up a reasonable workspace with fast internet and a camera.\n\nI’d also add that I saw this work well for both update- and decision-oriented meetings. Would this approach support technical brainstorming meetings too? Sometimes drawing on a whiteboard works much better than typing, especially if you have a diagram. Zoom does have a whiteboard feature; perhaps with a Stylus you could do this as well as in person. I’m curious to see it in practice.\n\nWhen I first heard of GitLab’s remote-only hiring, I immediately saw the benefits of hiring in lower-rent locations and not paying for office space. I assumed that it cost some productivity through effective collaboration. Now I see video calls done right can beat all but the best traditional conference room meetings.\n\n## About the guest author\n\nNolan Myers advises startups on organizational development and customer success, leveraging his executive experience in building high-performing products and teams. He also has passions for classical music, fine cuisine, and urban design. Learn more on his [LinkedIn](https://linkedin.com/in/nolanmyers).\n\nPhoto by [Christin Hume](https://unsplash.com/photos/slbqShqAhEo) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[9,683,899,731,1380],{"slug":2125,"featured":6,"template":687},"remote-work-done-right","content:en-us:blog:remote-work-done-right.yml","Remote Work Done Right","en-us/blog/remote-work-done-right.yml","en-us/blog/remote-work-done-right",{"_path":2131,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2132,"content":2138,"config":2145,"_id":2147,"_type":14,"title":2148,"_source":16,"_file":2149,"_stem":2150,"_extension":19},"/en-us/blog/remote-work-facilitates-devops",{"title":2133,"description":2134,"ogTitle":2133,"ogDescription":2134,"noIndex":6,"ogImage":2135,"ogUrl":2136,"ogSiteName":673,"ogType":674,"canonicalUrls":2136,"schema":2137},"People agree that remote work in DevOps creates a stronger DevOps culture","What makes remote work more conducive to DevOps adoption? Here's a look at one of the findings of our 2018 Global Developer Report.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680149/Blog/Hero%20Images/devopsremotework.jpg","https://about.gitlab.com/blog/remote-work-facilitates-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"People agree that remote work in DevOps creates a stronger DevOps culture\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-04-17\",\n      }",{"title":2133,"description":2134,"authors":2139,"heroImage":2135,"date":2141,"body":2142,"category":681,"tags":2143},[2140],"Suri Patel","2018-04-17","\n_Our [2022 Global DevSecOps Survey](/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\nAccording to our [2018 Global Developer Report](/developer-survey/previous/2018/), remote teams tend to trend higher in visibility and DevOps satisfaction compared to in-office teams, suggesting that a remote workplace culture is more conducive to DevOps adoption.\n\n![The differences between remote and in-office teams](https://about.gitlab.com/images/blogimages/devopsremotestats.png){: .shadow.medium.center}\n\nAs a [remote-only](/company/culture/all-remote/) company, this finding naturally piqued our interest. We started thinking about the traits of a remote team and how these characteristics set up operations and development teams for success.\n\n## The challenges of DevOps adoption\n\nOne of the greatest difficulties an organization faces when adopting a DevOps model is a [resistance to culture change](https://www.cio.com/article/3235726/application-development/5-hurdles-to-adopting-devops.html). Because DevOps requires teams to collaborate and communicate in new ways (and at an increasing frequency), historically siloed teams may have trouble adjusting. This type of radical shift in culture can be too difficult for a team to handle and may result in an increase in friction and frustration.\n\nHow can teams that have traditionally worked alongside each other – [but not together](https://www.wired.com/insights/2015/03/culture-war-struggle-adopt-devops/) – suddenly adopt a model that encourages them to contribute to a single conversation across every stage?\n\n## Remote work paves the way to a smoother transition\n\nIn our survey we learned that [20 percent of respondents](/developer-survey/previous/2018/) say most or all of their development team works remotely. Every remote worker knows the importance of [communicating effectively](/blog/remote-communication/) and frequently to ensure that others are aware of decisions and progress. Without the convenience of physical proximity, working remotely requires a commitment to open discussion and an understanding that team members must be able to easily view projects and receive updates. Furthermore, remote teams use tools to work concurrently, decreasing the challenges of siloed workflows.\n\nAn effective remote culture embraces:\n\n- efficiency\n- collaboration\n- visibility\n\nWhen operations and development teams already have a culture founded on trust and transparency, they can more easily adopt a model that fosters cross-functional communication and workflows.\n\nRemote teams are already accustomed to transparency, collaboration, and visibility, making a DevOps adoption a seamless transition. Because teams must document discussion conclusions, an inherent benefit of working remotely is complete real-time visibility of all projects and activities, an advantage of the DevOps model.\n\n## How can in-office teams ease DevOps adoption?\n\nWhile a remote workplace culture appears to create a solid foundation upon which a DevOps model can thrive, we concede that remote teams can still encounter challenges to adoption. Poor communication, internal conflict, and a lack of defined processes can hinder any team. However, there are insights that in-office teams can gain from these findings. Because culture is the underpinning of successful DevOps adoption, in-office teams can ease challenges by encouraging teams to work concurrently and by transparently documenting conversations and decisions. Furthermore, a shift towards empathy can help teams gain respect for the work that others accomplish, a change that can increase collaboration and decrease friction.\n\nBy creating a collaborative culture, an organization can facilitate a smoother [transition to a DevOps model](/blog/a-snapshot-of-modern-devops-practices-today/).\n\nDoes your development team work remotely? Let’s chat about DevOps and remote working! Tweet us [@gitlab](https://twitter.com/gitlab).\n\n[Cover image](https://www.pexels.com/photo/high-angle-view-of-workplace-306533/) licensed\nunder [CC X](https://www.pexels.com/photo-license/)\n{: .note}\n",[9,1259,2144],"developer survey",{"slug":2146,"featured":6,"template":687},"remote-work-facilitates-devops","content:en-us:blog:remote-work-facilitates-devops.yml","Remote Work Facilitates Devops","en-us/blog/remote-work-facilitates-devops.yml","en-us/blog/remote-work-facilitates-devops",{"_path":2152,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2153,"content":2159,"config":2164,"_id":2166,"_type":14,"title":2167,"_source":16,"_file":2168,"_stem":2169,"_extension":19},"/en-us/blog/resources-for-companies-embracing-remote-work",{"title":2154,"description":2155,"ogTitle":2154,"ogDescription":2155,"noIndex":6,"ogImage":2156,"ogUrl":2157,"ogSiteName":673,"ogType":674,"canonicalUrls":2157,"schema":2158},"Resources for companies embracing remote work","We're sharing our comprehensive guide to remote work with companies who are now embracing a remote environment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679651/Blog/Hero%20Images/gitlab-all-remote-cover-2560x1440.jpg","https://about.gitlab.com/blog/resources-for-companies-embracing-remote-work","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Resources for companies embracing remote work\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Murph\"}],\n        \"datePublished\": \"2020-03-06\",\n      }",{"title":2154,"description":2155,"authors":2160,"heroImage":2156,"date":2161,"body":2162,"category":856,"tags":2163},[702],"2020-03-06","\n\nDue to global issues concerning [COVID-19 (Coronavirus)](https://www.cdc.gov/coronavirus/2019-ncov/index.html), there has been a notable shift in appetite for working remotely. Companies previously against remote work are suddenly considering remote or implementing remote, with varying degrees of intentionality.\n\nIn the coming weeks and months, your company may have short- or medium-term needs to establish a work-from-home protocol, even if you’re [unsure about long-term commitment to remote](/company/culture/all-remote/hybrid-remote/), and how it will impact your business.\n\n## Resources for going remote\n\n![GitLab global team map graphic](https://about.gitlab.com/images/blogimages/gitlab-all-remote-laptop-global-map.jpg){: .shadow.medium.center}\n\nGiven these realities, companies are being tasked with advising their workforce on how to work from home. With no warning, this is a tall task. \n\nThankfully, these companies do not have to start from scratch. As the world's largest all-remote company, GitLab has learned a lot in scaling from a few people scattered across Europe to a 1,200+ person team in over 65 countries and regions. \n\nWe've built a [**remote work emergency toolkit**](/company/culture/all-remote/remote-work-emergency-plan/) for leaders and managers, and a [**remote work starter guide**](/company/culture/all-remote/remote-work-starter-guide/) for employees. This is a fast boot guide with five things you can focus on right now to maximize stability.\n\nAdditionally, we’ve architected [dozens of comprehensive guides](/company/culture/all-remote/guide/) to implementing remote, covering topics such as:\n\n* [Pitfalls to watch out for when embracing remote](/company/culture/all-remote/what-not-to-do/)\n* [Embracing asynchronous communication](/company/culture/all-remote/asynchronous/)\n* [Transitioning a company to remote](/company/culture/all-remote/transition/)\n* [How to use forcing functions to work remote-first](/company/culture/all-remote/how-to-work-remote-first/)\n* [Combating burnout, isolation, and anxiety](/company/culture/all-remote/mental-health/)\n* [Understanding the phases of remote adaptation](/company/culture/all-remote/phases-of-remote-adaptation/)\n* [Remote onboarding](/company/culture/all-remote/onboarding/)\n* [Meetings](/company/culture/all-remote/meetings/)\n* [Management](/company/culture/all-remote/management/)\n* [Asynchronous workflows](/company/culture/all-remote/asynchronous/)\n* [Handbook-first documentation](/company/culture/all-remote/handbook-first-documentation/)\n* [Adopting a self-service mindset](/company/culture/all-remote/self-service/)\n* [Learning and development](/company/culture/all-remote/learning-and-development/)\n* [Workspaces](/company/culture/all-remote/workspace/)\n* [Informal communication](/company/culture/all-remote/informal-communication/)\n* [Scaling](/company/culture/all-remote/scaling/)\n* [Getting started in a remote role](/company/culture/all-remote/getting-started/)\n* [Communicating effectively and responsibly through text](/company/culture/all-remote/effective-communication/)\n\nAll of these guides are open, and we encourage other companies to study them, copy them, implement them, and even contribute learnings back to them. It’s an end-to-end toolkit on getting started with remote, iterating as a team, and thriving in an officeless environment. \n\n## Remote work benefits your customers\n\nAs a recent [Economist article](https://www.economist.com/business/2020/03/05/covid-19-is-foisting-changes-on-business-that-could-be-beneficial) points out, COVID-19 is causing companies to rethink their business from a supply chain perspective. Having a remote workforce can lessen the disruption of the supply chain if the product is not a tangible good or service. At GitLab, utilizing a SaaS model and being an all-remote company has provided resiliency to these issues. Our supply chain is not affected by the global impact of COVID-19; however, onsite services may be limited in affected areas. \n\nGitLab, the open source product, and other tools like Zoom and Slack help teams collaborate through asynchronous workflows which not only enable remote work, but may be helpful in times of global crises.\n\n## The importance of in-person interactions\n\nAs an all-remote company, in-person interactions don’t occur by default. In turn, GitLab is [intentional](/company/culture/all-remote/in-person/) about ensuring that team members are given opportunities to meet other team members in a shared physical space. Each year, GitLab offers every team member the opportunity to gather in a new city for a week-long unconference. Whereas most summits are focused on networking and productivity, [GitLab Contribute](/events/gitlab-contribute/) is unique. Our team bonds over video calls year-round, so this week of in-person excursions is one that many mark on their calendar as can’t-miss. When your default is virtual, the chance to explore a new place with colleagues is invaluable. \n\nWith the increased impact of COVID-19 across the world, we have made the difficult decision to cancel the planned March 2020 edition of Contribute. The health and safety of our team members and the community in the city we visit is our highest priority. We are disappointed, but believe this to be the best decision for everyone involved. \n\nBeyond Contribute, we are monitoring the situation carefully and providing team members with [CDC recommendations](https://www.cdc.gov/coronavirus/2019-ncov/about/prevention-treatment.html) to help avoid sharing contagious viruses or illnesses when traveling or meeting with other team members. Our global, [all-remote structure](/company/culture/all-remote/guide/) allows us to continue work as usual with video calls, chat, and other collaboration tools and services to avoid unnecessary travel. \n\n## Everyone can contribute\n\nSharing our learnings with the world is at the heart of our mission: [everyone can contribute](https://handbook.gitlab.com/handbook/values/#mission). GitLab believes that all-remote is the [future of work](/company/culture/all-remote/vision/), and remote companies have a shared responsibility to show the way for other organizations who are embracing it. If you or your company has an experience that would benefit the greater world, consider creating a [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/) and adding a contribution to the all-remote handbook.\n",[683,9,856],{"slug":2165,"featured":6,"template":687},"resources-for-companies-embracing-remote-work","content:en-us:blog:resources-for-companies-embracing-remote-work.yml","Resources For Companies Embracing Remote Work","en-us/blog/resources-for-companies-embracing-remote-work.yml","en-us/blog/resources-for-companies-embracing-remote-work",{"_path":2171,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2172,"content":2178,"config":2184,"_id":2186,"_type":14,"title":2187,"_source":16,"_file":2188,"_stem":2189,"_extension":19},"/en-us/blog/six-key-practices-that-improve-communication",{"title":2173,"description":2174,"ogTitle":2173,"ogDescription":2174,"noIndex":6,"ogImage":2175,"ogUrl":2176,"ogSiteName":673,"ogType":674,"canonicalUrls":2176,"schema":2177},"How to Improve Company Communication","Learn here how we've streamlined and improved company communication in six ways. And now your company can too.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680960/Blog/Hero%20Images/simon-abrams.jpg","https://about.gitlab.com/blog/six-key-practices-that-improve-communication","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to Improve Company Communication\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Brinkman\"}],\n        \"datePublished\": \"2019-12-23\",\n      }",{"title":2173,"description":2174,"authors":2179,"heroImage":2175,"date":2181,"body":2182,"category":705,"tags":2183},[2180],"Eric Brinkman","2019-12-23","\n\nRecently, we caught up with a Fortune 50 company that wanted to understand how to enact change more quickly,\nbolster its product management practice, and execute projects more efficiently. This\nled to a conversation with our CEO and co-founder [Sid Sijbrandij](/company/team/#sytses), who\nwalked through a few key GitLab practices for improving communication in the workplace. Luckily, I was able to \"shadow\" this conversation as I was participating in our [CEO shadow program](/handbook/ceo/shadow/) at the time.\nAfter the discussion, we quickly realized it made sense to share our best practices. While these power our all-remote organization, we think they're good ideas for any company to consider.\n\n## Utilize directly responsible individuals (DRIs)\n\nIn our organization, we have the concept of the [directly responsible individual](/handbook/people-group/directly-responsible-individuals/).\nAnd, as you may have guessed, that person is **directly** responsible for the decision\nthey are tasked with. This could be something routine, such as a prioritization decision\n(in this case the typical DRI is the product manager) or something bigger, such as choosing a vendor to partner with to implement product analytics. The DRI is expected to become\ninformed about options and alternatives via their team, but is ultimately the one responsible\nfor making the call. This helps because you don’t have to wait for consensus-driven decision-making.\nMost organizations are slowed down by governance teams or by a need to ensure every single person\nimpacted signs off. While it’s important to communicate, it can slow you down if you wait for everyone\nto sign off. Consider implementing DRIs to help ensure high velocity decision-making.\n\n\n\n## Make product and engineering responsibilities distinct\n\nAt many organizations, the product manager is responsible for not only setting the priorities,\nbut also must ensure those priorities are shipped on time. This leads to\nan odd situation where product is held accountable for shipping code, something that is typically\noutside of the team's control. At GitLab, we clearly outline that product is responsible for prioritizing\nand defining what is to be done and engineering is responsible for shipping the defined functionality. Setting clear boundaries around what each functional area is responsible\nfor leads to an environment where people can get away from finger pointing and back to the job they should\nhave been doing all along.\n\n## Share via InnerSourcing\n\nAt GitLab, everything is [public by default](/handbook/hiring/principles/#transparency) and there should be a documented\nreason why an issue or line of code needs to be private. Why? The answer is simple:\nby making everything public by default, everyone in the community can contribute. Now, we\nrealize public repositories and issue trackers may not be feasible for every organization,\nbut this typically doesn’t apply _inside_ the organization. InnerSourcing is a mindset shift\nthat helps organizations share code and best practices internally.\nWhen code repositories and issue trackers become open, teams have a much easier time collaborating\non problems and solutions that may be siloed. [DevOps](/topics/devops/) is all about breaking down silos and InnerSourcing\nis a great way to not only reuse code and ideas, but also encourage collaboration.\n\n## Write everything down\n\nCan you recall a time where you went to a meeting, made a decision, and then came back next week to\nfind people forgot that happened? Unfortunately, this is too common at many organizations\nand leads to unnecessary rehashing of the same information, arguments, and talking points. By writing everything down,\nit’s clear when a decision was made or a process was changed. Writing things down is a high leverage activity –\nit allows information to be documented once and then disseminated to many people with little\neffort on the part of the author. It also helps to maintain a record of what happened. At GitLab, we write things down in issues and merge requests. And for bigger things, we have a\n[handbook](/handbook/) of over 3,000 pages where we outline how the company works,\nits various processes, and our product strategy. This single source of truth is also constantly being updated because we encourage everyone to propose changes and additions to it.\n\n## Iterate, iterate, iterate\n\n[Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is one of GitLab’s core values for a number of\nreasons. When you iterate, you reduce the need for coordination amongst many teams and stakeholders. The smallest change or proposal\nyou make, the fewer people you need to ask for permission. If you are going to take six months to build something, you will need to spend a lot of time getting stakeholder and executive buy-in to ensure resources\nare being leveraged appropriately. Conversely, if you are going to take two weeks to build something, less buy-in is\nrequired and it is much easier to know if you’re on the right path. In larger organizations, coordination is the\nthing that slows you down. Iterating allows for quicker feedback.\n\n## Understand the job to be done\n\nThe [jobs to be done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done)\n(J2BD) framework is popular for shifting away from correlation-based models and towards what the customer is trying to\naccomplish. We heavily utilize our user experience (UX) group to work closely with our product management team in order\nto identify and highlight the top jobs to be done. We invest heavily in user research to confirm the jobs\nto be done. The jobs are turned into scorecards which outline areas of potential improvement. These potential improvements\nare provided to product managers to consider when prioritizing features. The jobs-to-be-done framework\nis important to identify cross-service workflows such as code deployment which crosses many DevOps stages\nwithin GitLab. When you fully understand your users, you’re able to prioritize the improvements that\nmatter, leading to a better product.\n\nWhile not an exhaustive list, the six characteristics identified above are key to GitLab’s success as an [all-remote company](/company/culture/all-remote/). And all of these practices can be taken and adapated for any organization looking to strengthen communication in the workplace or considering a move to all remote.\n\nMost everything we do is publicly available, from our code to our roadmaps to our product\nmanagement processes. If you’re interested, you can find out  more in our [product handbook](/handbook/product/),\nwhich outlines other axioms and best practices for software product development. And, as always, if what you’ve just read\nresonates with you, and you’d like to join the team, let [me](https://gitlab.com/ebrinkman) know. We’ve more than tripled\nour team in 2019, and we’ll likely be doubling again in 2020.\n\nCover image by [Simon Abrams](https://unsplash.com/@flysi3000) on [Unsplash](https://unsplash.com)\n{: .note}\n\n",[683,9,734],{"slug":2185,"featured":6,"template":687},"six-key-practices-that-improve-communication","content:en-us:blog:six-key-practices-that-improve-communication.yml","Six Key Practices That Improve Communication","en-us/blog/six-key-practices-that-improve-communication.yml","en-us/blog/six-key-practices-that-improve-communication",{"_path":2191,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2192,"content":2198,"config":2204,"_id":2206,"_type":14,"title":2207,"_source":16,"_file":2208,"_stem":2209,"_extension":19},"/en-us/blog/stem-gems-give-girls-role-models",{"title":2193,"description":2194,"ogTitle":2193,"ogDescription":2194,"noIndex":6,"ogImage":2195,"ogUrl":2196,"ogSiteName":673,"ogType":674,"canonicalUrls":2196,"schema":2197},"GitLab + STEM Gems: Giving girls role models in tech","Meet the GitLab team-members working to inspire the next generation to pursue careers in STEM.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672357/Blog/Hero%20Images/stem-gems.png","https://about.gitlab.com/blog/stem-gems-give-girls-role-models","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab + STEM Gems: Giving girls role models in tech\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stephanie Garza\"}],\n        \"datePublished\": \"2018-10-08\",\n      }",{"title":2193,"description":2194,"authors":2199,"heroImage":2195,"date":2201,"body":2202,"category":705,"tags":2203},[2200],"Stephanie Garza","2018-10-08","\n\nGitLab recently partnered with [STEM Gems](http://stemgemsbook.com/), an organization creating awareness of successful women in STEM, to inspire girls and give them STEM role models. **STEM** (Science, Technology, Engineering, and Mathematics) pervades every aspect of our lives; everything can be tied to technology in some way, shape, or form. Given the constant expansion of technology, career prospects are endless. One would think STEM is the number one pursued career path right?\n\nSurprisingly, according to the US Department of Commerce, in 2017 only 24 percent of women worked in STEM. Another harsh reality is that women who hold STEM degrees are less likely than their male counterparts to pursue a STEM career. In fact, women are more likely to work in education or healthcare.\n\nDriven by the low numbers, STEM Education advocate Stephanie Espy strived to make a change. Espy created STEM Gems, an organization that began as a book filled with inspiring women in STEM. The book was the stepping stone for a greater initiative to create awareness for the successful female powerhouses in STEM, as well as provide girls with role models to look up to.\n\nGirls who have STEM role models are more likely to pursue opportunities outside their traditional realm, and STEM Gems is making it possible for girls to connect with them. Role models, mentors, and career ambassadors inspire and empower girls to achieve their dreams.\n\nAt [our recent summit in South Africa](/blog/gitlab-summit-cape-town-recap/), forty GitLab team-members came together for an epic power hour of delving into each other's professional pathways and identifying challenges. Participants were paired up and asked to interview each other about their individual careers, goals, and accomplishments. This included the significant others of GitLab team-members and men interested in learning more about making GitLab inclusive. Through this event, we were able to strengthen our relationships and identify ways to foster a culture of inclusion. The event also provided greater visibility into the challenges and barriers women in STEM face.\n\nGitLab is building a community where everyone can thrive. We've gathered together the stories and photos of the GitLab team-members that participated in the event. In this post, and in a follow-up post, we will share each of these amazing stories. We want to inspire and encourage girls to set Big Goals and pursue every dream and remember you’ll always have a friend at GitLab!\n\n![Jenny and Molly](https://about.gitlab.com/images/blogimages/stem-gems/jenny.jpg){: .shadow.small.left.wrap-text}\n\n**Name:** [Jenny Nguyen](/company/team/#lankhanh28) (right)\n\n**Role:** Payroll and Payments Lead\n\n**Why is what you do important?**\nI handle payroll and expense reimbursement, making sure all our team members get paid and reimbursed on time.\n\n**What is something you are really proud of?**\n\nI helped save a previous company $2 million by applying technical logic to processes.\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nNo, I started my undergrad with Business major and took programming as an elective class. My teacher encouraged me to change my major to Computer Science and Software Engineering, but I didn't have an opportunity to be in a technical position. However, I have applied my technical knowledge and aptitude from school to reduce manual processes within my functions for the past 10 years.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nAs a non-technical person, I want them to know that they don’t have to have a career in technology to have and utilize their own technical skills. Every function needs input from technical and non-technical perspectives.\n\n----\n\n![Ramya](https://about.gitlab.com/images/blogimages/stem-gems/ramya-authappan.png){: .shadow.small.right.wrap-text}\n\n**Name:** [Ramya Authappan](/company/team/#atramya)\n\n**Title:** Senior Test Automation Engineer\n\n**Why is what you do important?**\n\nAt GitLab, I automate tests as much as possible. I design and develop test frameworks. Test automation is the key to Continuous Integration and Delivery, which in turn is essential in minimizing the 'Time to Market' of any new features, thereby achieving customer satisfaction.\n\n**What is something you are really proud of?**\n\nApart from my work at GitLab, I'm also the Director of [Women Who Code](https://www.womenwhocode.com/), Chennai chapter. As part of Women Who Code, I get to meet a lot of female leaders in the technical space. I was recently invited to be a Panelist in a discussion on digital safety help by Google and SheThePeople.tv. I was also [interviewed by a Indian National News channel](https://www.thenewsminute.com/article/women-tech-freshworks-ramya-authappan-importance-mother-friendly-workplaces-78893). I frequently share my knowledge as a conference/meetup speaker. On the whole, I love doing what I do and being who I am!\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nYes! In my school days I had to choose a specialization at the age of 16 years. I chose Computer Science, and I think I made the right choice. I find that I'm interested in software engineering and always wanted to be a software engineer.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\n1. Choose wisely when it comes to specializations.\n2. Keep learning.\n3. Give back to society.\n4. Change the world! The sky is the limit!\n\n----\n\n![Hannah](https://about.gitlab.com/images/blogimages/stem-gems/hannah-schuler.png){: .shadow.left.small.wrap-text}\n\n**Name:** [Hannah Schuler](/company/team/#hannahschuler8)\n\n**Title:** SDR Team Lead – West and APAC\n\n**Why is what you do important?**\n\nI train other SDR team members to identify and create qualified opportunities. I also assist in recruiting team members and also work closely with online marketing managers for targeted ad campaigns. The SDR role is an evangelist role – we get the opportunity to be the first point of contact for people. It's an exciting and challenging role because most often people have never heard of GitLab. Sharing news about a solution that can help people and bring value is exciting.\n\nMy role is important because I facilitate and add structure to the team. I help remove roadblocks and enable us to work more efficiently. I help team members reach their full potential.\n\n**What is something you are really proud of?**\n\nI received a discretionary bonus a few months ago for going above and beyond in my role! Being promoted from an SDR representative to a team lead in nine months was really awesome, I'm very proud of that. I'm a certified SCRUM master and product owner. I am also certified in SAFE (Agile methodology).\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nIt's evolved over time – when I was little I wanted to be a ballerina. I was super shy, an introvert, and dancing was my way to express myself. When I grew older, everything changed and I become super outgoing. I wanted to make an impact in the world and got a degree in International Business Studies because I wanted to work for the UN. My excitement for technology came a lot later in my career. My friend shared excitement about the industry and that's what initially got my foot in the door. I did not have a traditional background in tech.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nYou will have an impact in this field. Companies are looking for you. You will develop lifelong skills and have an impact in this field. Women are trailblazers in this industry. You can dictate your own earning potential and will have the opportunity to mentor other women as well.\n\n----\n\n![Cristine](https://about.gitlab.com/images/blogimages/stem-gems/cristine-marquardt.png){: .shadow.small.right.wrap-text}\n\n**Name:** [Cristine Marquardt](/company/team/#csotomango)\n\n**Title:** Billing Specialist\n\n**Why is what you do important?**\n\nI process invoices for sales-assisted orders, troubleshoot support tickets (mostly related to money and licensing issues), provide sales support, and I wear a lot of hats. Everyone in the company plays an important role to keep GitLab running. When you work at a startup, you have to be game for all the obstacles that are thrown your way. I never imagined how much I would learn and how much I could contribute in my role.\n\n**What is something you are really proud of?**\n\nI'm currently dabbling in .Net framework and I made my first semi-functional calculator. While this sounds like a rather simple task, this is huge to me since my career has been focused in the finance and accounting world.\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nI knew that I wanted to work in tech ever since I was a kid. I was fortunate enough to go to a school that had computers in each classroom and there was also a computer lab. I wanted to get into computer engineering when I was in middle/high school, but I never pursued it in college. I'm now pushing myself to learn software development.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nBelieve in yourself and don't be afraid. The only one holding you back is yourself.\n\n----\n\n![Gabriela and Diana](https://about.gitlab.com/images/blogimages/stem-gems/gabriela.jpg){: .shadow.small.right.wrap-text}\n\n**Name:** Gabriela Mena Breña (right)\n\n**Title:** Chemical Engineer (Not at GitLab, I am the significant other of a GitLab team-member)\n\n**Why is what you do important?**\n\nPractical transition from fossil fuels to renewable energy solutions. This will save the planet!\n\n**What is something you are really proud of?**\n\nI led the team that created fiscal terms for the first private investments in Mexican oil and gas resources. This protected the Mexican government's financial stability. We secured $3.1 billion worth of contracts to construct gas pipelines for the Mexican state. I am also proud to have received a full scholarship from the Mexican government to study for a Master's degree in Energy Science.\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nYes, I found science and math the most challenging, which made them the most interesting to me.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nDon't let anybody else tell you what you can be. Be true to who you really are and focus on your own goals and desires.\n\n----\n\n![Chloe](https://about.gitlab.com/images/blogimages/stem-gems/chloe-whitestone.jpg){: .shadow.small.left.wrap-text}\n\n**Name:** [Chloe Whitestone](/company/team/#drachanya)\n\n**Title:** Talent Operations Specialist\n\n**Why is what you do important?**\n\nI am part of the recruiting team. I do all of the backend operations for recruiting, such as vendor management, reporting, researching on different tools, and employee branding. In addition, I am also the recruiter for a few roles (customer success, UX designer, data engineer). GitLab cannot be what it is without having great talent and I get to be a part of this exciting journey.\n\n**What is something you are really proud of?**\n\nI've played a critical role in the multiple transitions of GitLab's ATS (application tracking system) which has improved candidate experience, increased efficiency, and given greater visibility for hiring managers to hire the best talent possible. Before I was at GitLab, there weren't any tools for recruiting metrics. Through my efforts, GitLab has recruiting metrics and is now able to analyze how they are doing compared to other industry leaders. This has allowed us to improve the hiring process and enabled applicants to get job offers faster than before.\n\n**Chloe also:**\n\n- Migrated Workable to Lever\n- Migrated Lever to Greenhouse\n- Implemented background checks at GitLab\n- Trained GitLab team-members for Greenhouse\n- Created a vacancy process for GitLab\n- Improved onboarding process and experience\n- Became an assistant manager in six months during her first fulltime job\n- Is proud of every hire she has made\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nGrowing up, I didn't think I would work in Tech. I originally wanted to be president! I was exposed to tech through my high school STEM program. That equipped me to be where I am today.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nStart right away by learning and getting involved in the community. It's harder to start the older you get (IMO). Don't be afraid, no matter how much experience you have or how old you are. You are not alone!\n\n----\n\n![Katherine](https://about.gitlab.com/images/blogimages/stem-gems/katherine-okpara.jpg){: .shadow.small.right.wrap-text}\n\n**Name:** [Katherine Okpara](/company/team/#katokpara)\n\n**Title:** Junior UX Researcher\n\n**Why is what you do important?**\n\nI work with product management and UX designers to understand users' pain points, goals, and needs. My job is to understand where we can improve the product by speaking directly to users. The user experience of a product impacts the customer directly. Positive experiences equal stronger relationships (more feedback) for the product to improve.\n\n**What is something you are really proud of?**\n\nI've received mentorship during my eight months here at GitLab and am now leading studies. I've been able to learn about different features and different aspects of the product at a fast pace. I have helped to build healthy relationships between end users and teams for better product improvements/advancements.\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nNo. I didn't know anything about tech/computers, etc. until college. I took a few programming/data science classes in college and that's when my interest was piqued. I was on more of an academic path at school (psychology). In my last year of college I took a web design class (applying research to products) and felt that I had found my niche. I have been working on those skills ever since through online courses, research, etc.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nThere is a place for you! Whether it's programming or another area, there are still many paths for consideration. If you come from a non-traditional path, there is always a way to link your skills to your desired role. Believe that you can do it, even if you don't currently have the skills (you can build those skills!).\n\n----\n\n![Lucas](https://about.gitlab.com/images/blogimages/stem-gems/lucas.jpg){: .shadow.small.left.wrap-text}\n\n**Name:** Lucas Charles\n\n**Title:** Individual Contributor to Gitlab (significant other to a GitLab team-member)\n\n**Why is what you do important?**\n\nI am an end-user, and GitLab wouldn't be a product without users. It's built on open source technology, which requires everyone to contribute. As a user and contributor, it is powerful to have everything in one place and GitLab is fun to use. It's easier to go to work every day with software you love.\n\nMy significant other works at GitLab, but I would use it every day regardless. I love the product and company. I think GitLab is doing something important and changing the way we build software.\n\n**What is something you are really proud of?**\n\nWhen my significant other was looking for a new job, I realized that GitLab would be a perfect fit for her and encouraged her to apply. I wanted to do everything I could to help her because I care and it's an amazing opportunity to push herself and contribute to a greater tech community full of diverse people, product, and cultures.\n\nI'm incredibly proud of my significant other. She works on GitLab every day, making the world a more interesting place through technology. I'm quite proud to be part of that network. I'm also proud to be one of the first 1,000 contributors to Gitlab. I'm proud that GitLab chose to recognize that by sending me a special sticker!\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nI've always been a tinkerer and like to take things apart and put them together. Tech enables me to do that quickly and easily. It is an amazing industry that creates something out of nothing but an idea, and has limitless possibilities. We move fast and many truly believe they are changing the world.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nFirst, to just do it, because it's an incredible field and we need more diversity. Diversity is important: we need a range of ideas, perspectives, and to create more opportunities to understand each other. We should build products that work for everyone and address all needs. Challenging ourselves and growing ourselves through different perspectives is critical for both personal growth and a healthy culture.\n",[708,267,731,683,9],{"slug":2205,"featured":6,"template":687},"stem-gems-give-girls-role-models","content:en-us:blog:stem-gems-give-girls-role-models.yml","Stem Gems Give Girls Role Models","en-us/blog/stem-gems-give-girls-role-models.yml","en-us/blog/stem-gems-give-girls-role-models",{"_path":2211,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2212,"content":2218,"config":2224,"_id":2226,"_type":14,"title":2227,"_source":16,"_file":2228,"_stem":2229,"_extension":19},"/en-us/blog/support-virtual-pizza-party",{"title":2213,"description":2214,"ogTitle":2213,"ogDescription":2214,"noIndex":6,"ogImage":2215,"ogUrl":2216,"ogSiteName":673,"ogType":674,"canonicalUrls":2216,"schema":2217},"GitLab Support Virtual Pizza Party","Come learn about the GitLab Support Virtual Pizza Party","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670544/Blog/Hero%20Images/alan-hardman-SU1LFoeEUkk-unsplash.jpg","https://about.gitlab.com/blog/support-virtual-pizza-party","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Support Virtual Pizza Party\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Colyer\"}],\n        \"datePublished\": \"2019-10-02\",\n      }",{"title":2213,"description":2214,"authors":2219,"heroImage":2215,"date":2221,"body":2222,"category":729,"tags":2223},[2220],"Jason Colyer","2019-10-02","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nHere at GitLab, we truly appreciate our amazing support team! They work\ntirelessly to provide our users the very best support and achieve the goals we\nset for them. Through tickets, calls, issues, MRs, etc., they work each and\nevery day to not only support GitLab, but also improve it. As a Support Manager,\nI truly appreciate each and every thing they do here. I take a lot of pride in\ntelling people what I do for a living, and it is in large part thanks to the\namazing team I work with.\n\nWith everything they have done, the support managers brought up the topic of\nshowing appreciation. We often thank them, but as of late, we felt we needed to\ndo something more. But the big question was _how_?\n\nWhen I first started working as a manager, it was in an office. Back then,\nshowing appreciation was relatively easy. We saw one another almost every day\nafter all! I could easily address my team, thank them wholeheartedly for their\namazing work, and see they knew they were truly appreciated. If I wanted to\nthink outside the box, I very well could. We were all working together in a \nphysical place, so it wasn't too difficult to get inventive.\n\nOne of my all-time favorite ways of showing appreciation for my team\nwas having a pizza party (yes I know, this isn't _that_ inventive)! We would eat\ngreasy pizza, see different topping choices, and overall, grow as a team. Once I\nstarted working fully remote, I had pretty much convinced myself the days of\npizza parties were a thing of the past. That was, until the Support Managers\nfloated the idea of doing one asynchronously. It was taking the idea of \n[social calls](https://about.gitlab.com/company/culture/all-remote/informal-communication/#social-calls)\nand adding pizza to it!\n\nI instantly fell in love with the idea, so I had no objections when we decided\nto go through with the concept. We encouraged the team to order pizza (any food\nreally) on Friday and post the pictures. What came of this was, in my opinion,\namazing. We got to see pizza and food from all over the globe. It started\ndiscussions of different ways to make pizza, different topping choices, and\ninspired many of us to one day travel outside of our respective regions, all in\nhopes of trying some delicious pizza! I personally had never thought of eating\ngas station pizza, but after seeing the pictures of it, I now long for the day\nI travel to Nebraska to try (what I am told) is the best gas station pizza you\ncan find!\n\n> \"Our global Support team has worked very hard and focused on reaching our\n> lofty targets for our customer service objectives, and this virtual party is\n> in recognition, and appreciation, of their collective efforts!\" - Tom\n> Cooney, Director of Support\n\nThe entire event reminded me of a very important piece of information I had read\nin the [All Remote](https://about.gitlab.com/company/culture/all-remote/)\nsection of the GitLab Handbook: \n\n> \"Remote is not a challenge to overcome.\"\n\nI had seen the concept of showing appreciation to an all-remote team as a\nchallenge I had to overcome. Simply put, it isn't. It wasn't the environment\nthat needed a change, it was merely my way of thinking!\n\nI truly feel honored that I get to work for such an amazing company and a\nfantastic team. I continue to look forward to working more and more with the\namazing GitLab Support team!\n\n![Support Pizza Party 2019-09-27 Collage 1](https://about.gitlab.com/images/blogimages/support_pizza_party/support_pizza_party_2019_09_27_1.jpg){: .shadow.medium.center}\n![Support Pizza Party 2019-09-27 Collage 2](https://about.gitlab.com/images/blogimages/support_pizza_party/support_pizza_party_2019_09_27_2.jpg){: .shadow.medium.center}\n![Support Pizza Party 2019-09-27 Collage 3](https://about.gitlab.com/images/blogimages/support_pizza_party/support_pizza_party_2019_09_27_3.jpg){: .shadow.medium.center}\n![Support Pizza Party 2019-09-27 Collage 4](https://about.gitlab.com/images/blogimages/support_pizza_party/support_pizza_party_2019_09_27_4.jpg){: .shadow.medium.center}\n![Support Pizza Party 2019-09-27 Collage 5](https://about.gitlab.com/images/blogimages/support_pizza_party/support_pizza_party_2019_09_27_5.jpg){: .shadow.medium.center}\n\n[Cover image](https://unsplash.com/photos/SU1LFoeEUkk) by [Alan Hardman](https://unsplash.com/@alanaktion?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[9],{"slug":2225,"featured":6,"template":687},"support-virtual-pizza-party","content:en-us:blog:support-virtual-pizza-party.yml","Support Virtual Pizza Party","en-us/blog/support-virtual-pizza-party.yml","en-us/blog/support-virtual-pizza-party",{"_path":2231,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2232,"content":2238,"config":2246,"_id":2248,"_type":14,"title":2249,"_source":16,"_file":2250,"_stem":2251,"_extension":19},"/en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab",{"title":2233,"description":2234,"ogTitle":2233,"ogDescription":2234,"noIndex":6,"ogImage":2235,"ogUrl":2236,"ogSiteName":673,"ogType":674,"canonicalUrls":2236,"schema":2237},"Synchronous collaboration as a remote designer at GitLab","Find out how GitLab Designers collaborate synchronously within an all-remote company!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669715/Blog/Hero%20Images/synchronous-collaboration-as-a-remote-designer.jpg","https://about.gitlab.com/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Synchronous collaboration as a remote designer at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alexis Ginsberg\"},{\"@type\":\"Person\",\"name\":\"Becka Lippert\"},{\"@type\":\"Person\",\"name\":\"Matej Latin\"},{\"@type\":\"Person\",\"name\":\"Holly Reynolds\"}],\n        \"datePublished\": \"2020-04-01\",\n      }",{"title":2233,"description":2234,"authors":2239,"heroImage":2235,"date":2243,"body":2244,"category":729,"tags":2245},[2240,2241,1094,2242],"Alexis Ginsberg","Becka Lippert","Holly Reynolds","2020-04-01","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nMany designers out there may find themselves new to the remote life within the past couple of months. This post just scratches the surface of how designers collaborate at Gitlab, and some ideas may work a bit differently in a post-COVID world, but hopefully you can find some inspiration for your day-to-day work. \n\nWorking as a designer at GitLab means being a Remote Designer with a capital R. GitLab has no “main” office. We have teammates working from their home office or coworking spaces all around the globe. Some of us don’t even have one home base, preferring to travel the world while working. \n\nAs designers at GitLab, we may not be able to physically get together near the Nespresso machine to chat about our days, or grab a conference room for a quick whiteboard session around the latest design challenge we are solving, but we still find ways to stay in sync. Are you thinking about NSYNC now? Good.\n\nFinding creative ways to collaborate synchronously with all teammates across GitLab is a worthy challenge to be solved, and we are always experimenting and iterating on the best ways to do this! We have found that [synchronous collaboration](/company/culture/all-remote/collaboration-and-whiteboarding/) has to be a bit more intentional, but if time and space is made for it, it can be just as––if not more––fun and productive! Here are some ways the GitLab design team has worked to create that space for synchronous collaboration...\n\n\n## 👯 Pair designers\n\nEvery six months or so, each individual designer is paired with another GitLab designer who is intentionally dedicated to a different[ stage group](https://about.gitlab.com/handbook/product/categories/). We are given the freedom to coordinate how we choose and can collaborate as much or as little as we feel comfortable with. The trend seems to be 30 minutes to an hour either each week or every other week. \n\n**_Alexis:_** I personally look forward to my weekly Zoom meeting with my pair, and we usually aim for an hour but sometimes go over time since we love chatting with each other. We have an agenda of items both of us hope to cover, but also make sure we have time to catch up as people and coworkers, which is especially important to me as a remote designer (sometimes you just want to show off your dog or talk about the latest Netflix show you are binging!).\n\nThe agenda items are usually split evenly between us so that we can dedicate half of the time to a design, research, or process challenge we are working through, and the other half giving feedback. We are encouraged to work in the tools we feel most productive in so sometimes we will be walking through a design in Sketch, Figma, Axure, Mural, or even a quick sketch on paper or iPad.\n\nAs our team grows larger, getting this time to really dive into the design challenges of another stage group is very important. It helps me focus on the holistic journey users have within GitLab, rather than just “my” specific corner of the product. Every designer at GitLab shines in their own way, and this is just another way for us to learn from each other! \n\n\n## ☕ Coffee chats, 1-1s with other designers, and stage specific syncs\n\nWe've already touched on the importance of remembering that although we are remote designers, we have the support of an entire team around the world. In no other place is this more apparent at GitLab than in coffee chats, one-on-one syncs, and syncs with stage specific teams. \n\n**_Alexis:_** We can opt in to random coffee chats with anyone at GitLab, but as a designer magic happens often when just chatting through challenges with other designers. Working remotely means more time to focus, and the formal process of asking to schedule time with others can sometimes feel like you are asking permission to steal focus time away from their day. If all designers agree to set aside time each week that is dedicated to chatting with each other, it helps take that guilty feeling out of the equation and feels more like an informal time to chat and explore designs (that \"turn around in your chair to chat with the coworker next to you\" feeling), rather than another faceless Google Calendar invite.\n\nWe do this in a few ways, either through recurring 1-1s with other designers (including the pair system), recurring small group syncs with other designers in our stage group, and somewhat larger recurring syncs with designers in our [section](https://about.gitlab.com/handbook/product/categories/#hierarchy). They are all useful and full of collaboration to varying degrees.\n\nThe smaller and more specific the syncs get, the more day-to-day-design and feedback-specific the collaboration gets, which is great, because designers in one product area need to be able to support each other frequently on related work. \n\nLarger syncs are perfect for getting a broader understanding of what other designers outside of your stage are up to and for aligning on broader GitLab Design priorities affecting our section.\n\n**_Becka:_** The larger syncs also help discover overlap that you may not know exists, such as similar challenges or new use cases for a component in the [design system](https://design.gitlab.com/).\n\n**_Matej:_** Based on my experience so far, having a recurring 1-1 call with other designers from my stage group can be even better than the option to do it spontaneously in an office environment. And that’s mostly because of how we do it. \n\nThese calls are always at the same time on the same day of the week. We have a Google Doc for the agenda, so we can prepare in advance. Often, when I work on something, I remember that my fellow designer from my group probably knows more about the topic, so I just open that agenda doc and add an item to it so that we talk about it the next time we meet. This way, I don’t interrupt them with Slack messages or ad-hoc calls. \n\nAll this combined, it leads to scheduled, time-boxed calls where participants are prepared in advance and everyone gets so much value out of it. We borrow ideas, prototypes, pieces of UI. We can go into details of why our teams are working on the things that they’re working on. If we relied solely on group status update calls we wouldn’t be able to do that. \n\nIt’s also a great way to socialize and build relationships with other designers, as we often talk about stuff that isn’t work related. We’ve only been doing this for two months in the [Growth](https://about.gitlab.com/handbook/product/categories/#growth-stage) group, but I've already saved hours of wasted time working on things others already did. I also got to know the designers much better, which makes collaboration easier, more likely, and also more enjoyable. \n\nWhen it comes down to it, we are all GitLab Designers and need to not only understand and empathize for each other's work, but also for each other as people who like each other and are working toward the same goals!\n\n\n## 🎬 UX Showcase and UX Weekly\n\nOur largest opportunities for synchronous collaboration are our UX Weekly meeting and the [UX Showcase](https://about.gitlab.com/handbook/product/ux/ux-department-workflow/ux-showcase/). These syncs aim to capture as many designers across time zones as possible, which is a great chance to interact with faces you may not see on your screen often.\n\n**_Alexis:_** Our team has grown substantially over the last year, so having a weekly time to catch up with each other at a department level has also grown more important. The UX Weekly is a time for any and all GitLab designers to discuss any updates they have made to Pajamas (our design system), process changes, OKRs, exciting ideas, or [workshops](https://about.gitlab.com/blog/async-sketching/) designers are tinkering on that they think may benefit others – basically any team updates in general. \n\nGrowth of our department (and GitLab as a whole) has also inspired us to find new ways to stay transparent and visible about the work we are doing. This promotes cross-team collaboration both inside and outside of design. \n\nEvery two weeks product designers are encouraged to dive deeply into problems they are solving at the [UX Showcase](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz), making sure to touch on things like business goals, customer goals, and constraints. Four stage groups present per session for fifteen minutes at a time, giving us an hour to highlight work we are excited about sharing broadly on [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A/videos) for anyone to watch! What we present and the format in which we share is not prescribed, so designers can get creative about how to use that fifteen minutes allotted to their stage group (or at least as creative as sharing a screen on Zoom will allow!).\n\nThe part of the UX Showcase I enjoy the most is understanding the journeys my fellow designers go through and what processes they find most beneficial when creating solutions alongside their teammates in Product and Engineering. I also love the Slacks I get from other GitLabbers after presenting, asking to learn more about the work I am doing because they have feedback or to collaborate on something they are working on that is similar. The most exciting pings I get are from coworkers I am unfamiliar with, because that means we are empowering everyone to learn about and contribute feedback to our user experience!\n\n\n## 🤝 Collaboration with Product Managers \n\nA strong relationship with our partners in Product Management is important for any designer, and this is no different even for those of us who don’t have to walk into an office every day. \n\n**_Alexis:_** One of my favorite weekly meetings is when my team’s product designers and product managers all get together in the middle of the week for a 45-minute sync on Zoom. The first item on our agenda is for each of us to go over our goal of the week. These goals can be very personal or something we are hoping to accomplish professionally that week. I personally really enjoy learning more about what my teammates hopes and dreams are, even if those hopes are just to finish the repairs on their guest bathroom (this seems to be a big priority on our team for some reason!).\n\nWe spend the rest of the time going over our agenda items, such as in-flight research, issues that need collaboration, questions that we need clarification on, and then the good ole’ board walking time (going through our Kanban board of open issues in the current milestone) where we see how prioritized work is going. Usually we don’t get to the last agenda item, because we are busy walking through a design together or collaborating on some research items in Mural. This is fine though, because we have other times set aside to talk about priorities, and this is something that is easy to do asynchronously as well.\n\nA recurring theme I hear from product managers is that working with designers is one of their favorite parts of their jobs, and that they would never want to lose that just because we aren’t co-located. Luckily for all of us, most designers at GitLab are now aligned to one group with one dedicated product manager, so we can really focus on making that working relationship great! \n\nMy product manager and I take an hour out of our busy schedules each week to hop on Zoom and sync up. We use our agenda (are you sensing a theme here?) as our guide to walk through priority design issues that require collaboration or scope clarification. I prefer to drop sketches and mocks into a Mural board that we share, so that I can share my screen and allow him to follow along and make comments as I walk through ideas. Sometimes he will even share sketches with me, which I will then add and build on. This time helps us collaborate and get to know each other outside of regular conversations in Slack and [issues](https://docs.gitlab.com/ee/user/project/issues/). \n\n\n## 💻 Collaboration with Engineering\n\nAnother very important relationship for product designers to nurture is with our friends in Engineering. Designers and engineers at GitLab usually work together asynchronously, often in issues or [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/). Many of the usual touchpoints between these teams - like stand up, retros, brainstorms, and reviews - are effortlessly asynchronous. Instead of distancing us as designers from the engineers we team up with, this just allows us to make the time we do set aside for synchronous work more focused and intentional. Sometimes we may even sneak in a board game or two.\n\n**_Alexis:_** My team has weekly syncs between designers and Engineering Managers to discuss ideas for experience improvements and gather feedback or known constraints around designs. Product managers will also join and help facilitate any pivots or tradeoffs we may need to make while walking through our planned priority work. We also have a larger meeting to discuss big picture updates or retro type items, like processes we think could improve our workflow. \n\nThese (at least) weekly syncs are important in keeping our teams running smoothly, but my favorite engineering syncs are the impromptu one-on-one review and pair sessions I have with teammates. If asynchronous reviews or ideation seem to be going back and forth for a long time, nothing is better for unblocking a teammate than a quick synchronous Zoom call. Usually, what starts with one of us being confused by something the other is working on ends up in us chatting on a call and learning from each other as we share our screens and work through tough challenges together. The best part of these is that if our time zones are very different, we get to say, “Go have some coffee and have a great morning!” and “Get out of the office and have a good night!” at the end of the same meeting.\n\n\n## 🔬 Collaborating with users and the UX Research team\n\nHaving a solid understanding of users and being able to empathize with their frustrations and desires is so important to us. In fact, we even have a team dedicated just to UX Research! As with most organizations, though, GitLab Product Designers also need to have a passion for research and will often wear that “research hat” themselves.\n\n**_Alexis:_** Conducting research as a remote designer has surprisingly not differed as much as I expected from my time as a designer working in an office. Usually we start everything with a synchronous kickoff chat between the person requesting research, the researcher, and anyone else interested in the research project to capture objectives. This is also documented more formally in an issue, so we can iterate together asynchronously and have a single source of truth to refer back to. The planning and scripting can either be done in GitLab itself, or in a Google Document where we collaborate asynchronously.\n\nPrototyping or setting up testing environments is done in GitLab or any tool we feel comfortable will be most effective for the user. We schedule time with participants and conduct the interviews themselves through Zoom, which is something many would be familiar with. Those who join the call take notes and chime in as needed. If anything, this may feel less intimidating to participants, as we are all just friendly faces in a small Zoom box,  rather than people staring at them in person. Many times, users will remark on something going on in our home office, and that acts as an icebreaker and takes pressure off of the situation (I always get comments on my yellow chair and terrible wall art for example).\n\nThe synthesis aspect of research is where things get interesting, although I would imagine organizations that aren’t remote are also catching on to some of the remote techniques I am about to describe. We take the insights captured in Google Docs and GitLab issues and map them out in Mural. These synchronous sessions in Mural help us feel like we are all together at a whiteboard doing some good old fashioned affinity mapping - even more so if we are all doing this on a Zoom call and chatting as we work. Add a few stakeholders to the call, and it is a remote research synthesis party!\n\n## ⚖️ Why synchronous vs asynchronous?\n\nThis post highlights and focuses on some of the ways the GitLab team collaborates synchronously across time zones and teams, but the flipside of this is asynchronous collaboration, which is how we Get Things Done™️ a majority of the time. It is even one of our [values](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication). There are of course pros and cons to each way of collaborating!\n\n**_Holly_**: One of the challenges of being a remote organization is that we all simply can’t be available at the same time. In addition to collaboration, inclusion is also one of our values. Asynchronous communication allows us to ensure that [everyone has a chance](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication) to have a say, regardless of their schedule or timezone. \n\nHowever, we recognize that asynchronous communication is not without its challenges. Because async conversations happen in a page or document rather than a real-time setting, they can slip off the radar of participants. This can result in a stall in productivity. We have to be intentional about managing conversations we want and need to be a part of. This may include using [To-Dos](https://docs.gitlab.com/ee/user/todos.html), tagging others when we need feedback, applying group labels, and assigning items to ourselves, so that we are notified when a change occurs.\n\nAsynchronous communication also gives everyone a chance to pause, reflect and respond to ideas proactively, rather than reactively. This is great, particularly for introverts such as myself, but can at times lead to overthinking in discussions. We strongly believe that everyone can contribute and should feel empowered to do so, but we also recognize the need to move the work forward. Some of the ways we manage this are through asking questions and seeking to understand one another’s views, but also setting timelines (as needed) and goals for what we want to accomplish within a certain time frame.\n\nFinally, asynchronous communication allows the history of our collaboration to be preserved. We’ve grown exponentially this past year in a very short period of time. With so many new faces and great ideas coming in, it’s more important than ever for us to be able to refer to the historical conversations surrounding why certain decisions have been made. This enables us to move forward with insights starting from the original idea all the way through to production.\n\nWith all of these great benefits, though, sometimes problems can be particularly complex and need a quick answer or require real-time visual collaboration. We have a rule that if a conversation goes back and forth asynchronously more than 3 times, we move to a synchronous conversation, usually in Zoom or Slack. We record as many of our meetings and video chats as possible, so that others can still have an opportunity to catch up and provide feedback. And we recognize that as human beings, we are social creatures. Sometimes we simply need to hear someone’s voice, see their body language to fully understand a situation, or to just have a human connection. In these cases, we embrace the benefits of synchronous communication.\n\nFor more details on how we collaborate remotely in general, feel free to add [this blog](https://about.gitlab.com/blog/designing-in-an-all-remote-company/) to your reading list!\n\n\n## 💡 Tips and things to keep in mind when meeting\n\nYou may have a friend of a friend who has a horror story about video calls with coworkers. Mishaps can happen to the best of us (especially those of us with cats), and we understand that at GitLab. Here are a few of the things we keep in mind to make synchronous collaboration as seamless an experience as possible:\n\n**_Becka_**: Keep an agenda! One of the coolest things about GitLab meetings is that there’s always an agenda attached, so you can see what will be covered. Anyone on the call is empowered and encouraged to add items to the agenda, whether it’s to draw attention to an issue, invite feedback, or discuss something process oriented as a group. We can always add “Read-only” items at the top if there are a lot of agenda items, if the discussion can take place asynchronously, or if it’s more of an FYI (“Thank you so much to Alexis for starting this awesome blog post [linked to doc] about remote work!”). \n\nHaving a meeting agenda completed in advance (and often elaborated upon during the meeting), lets attendees come prepared and gives everyone a chance to be heard. If you decide that the other agenda items are higher priority, you can always add yours to the bottom of the list and feel good knowing that if time runs up, it will automatically be moved up as higher priority in the following meeting. \n\nFinally, agenda items are a great place to revisit to-dos from weeks prior, to find links to issues that were discussed, and a great single source of truth for meeting notes that all can contribute to.\n\n**_Becka:_** Mute your mic when you aren’t speaking to avoid frustration and perhaps embarrassment. 👀\n\n**_Holly:_** Remote work can blur the lines between personal and professional, but we are all human and things just happen sometimes! If anything, this can create bonding moments.\n\n**_Alexis:_** Many of our [collaboration values](https://handbook.gitlab.com/handbook/values/#collaboration) are around being kind to each other. This can translate to video calls and collaborative workspaces, too! Build any sessions with easy collaboration in mind. Give each other space to respond, and listen to each other. Pause often to allow other people to chime in with thoughts or ideas without interruption. Read the room as you typically would in person. One thing that really helps with this is turning your camera on during meetings, so that others can see your face and read your body language. I know sometimes it is tempting to join with your camera off, but trust me - it helps!\n\nAnother way you can be kind to others is by scheduling meetings with a 5-minute buffer at the end. So, for example, instead of blocking 30 minutes of time with someone, schedule them for 25 minutes. There is nothing worse having back-to-back meetings without time for making coffee, taking a bio break, or just walking around and stretching (hopefully toward some place that has a snack you can bring with you to the next meeting). \n\n**_Matej:_** If you need to collaborate often with the same teammates, schedule your syncs as recurring in a consistent cadence and have an agenda. This allows participants to be intentional in advance about what they’d like to cover during that set time, so they can understand expectations and be prepared - which enables everyone to collaborate on more items!\n\n**_Alexis and Holly:_** Lean into the fact that most coworkers may only be seeing your upper half and anything behind you, and fill that space with your personality (we like to wear outrageously silly sweaters or put our favorite art behind us)! Dogs or family walking behind you or interacting with the camera to say hi to colleagues is not only accepted at GitLab but encouraged. Working outside of an office means that coworkers can get to know you outside of the office “version” of you, if that is something you feel comfortable with.\n\n\n## 🦊 How do you do remote?\n\nFeel free to ping us on Twitter at [@gitlab](https://twitter.com/gitlab?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) with any remote synchronous collaboration tips and tricks in your toolbox that you think our team could learn from. See you in GitLab! \n\n###### [Alexis Ginsberg](https://gitlab.com/uhlexsis) (Chicago, IL, USA GMT-5), [Holly Reynolds](https://gitlab.com/hollyreynolds) (Roswell, Georgia, USA GMT-4), [Becka Lippert](https://gitlab.com/beckalippert) (Austin, TX, USA - and looking forward to working outside of the States when possible and responsible -  GMT-5), [Matej Latin](https://gitlab.com/matejlatin) (Ljubljana, Slovenia GMT+2)\n\nCover image by [Sincerely Media](https://unsplash.com/photos/ylveRpZ8L1s) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[732,734,733,9,731],{"slug":2247,"featured":6,"template":687},"synchronous-collaboration-as-a-remote-designer-at-gitlab","content:en-us:blog:synchronous-collaboration-as-a-remote-designer-at-gitlab.yml","Synchronous Collaboration As A Remote Designer At Gitlab","en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab.yml","en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab",{"_path":2253,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2254,"content":2260,"config":2265,"_id":2267,"_type":14,"title":2268,"_source":16,"_file":2269,"_stem":2270,"_extension":19},"/en-us/blog/the-case-for-all-remote-companies",{"title":2255,"description":2256,"ogTitle":2255,"ogDescription":2256,"noIndex":6,"ogImage":2257,"ogUrl":2258,"ogSiteName":673,"ogType":674,"canonicalUrls":2258,"schema":2259},"The case for all-remote companies","Remote teams offer flexibility, reduce company costs, and increase productivity.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668018/Blog/Hero%20Images/allremote.jpg","https://about.gitlab.com/blog/the-case-for-all-remote-companies","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The case for all-remote companies\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-10-18\",\n      }",{"title":2255,"description":2256,"authors":2261,"heroImage":2257,"date":2262,"body":2263,"category":705,"tags":2264},[2140],"2018-10-18","\nI’m writing this post while I sit under a mango tree and listen to\n[Tchaikovsky’s Piano Concerto No. 1](https://www.youtube.com/watch?v=xZYYqUssAVw).\nI don’t have to worry about my music bothering anyone around me, and I don’t\nthink twice about my attire (yoga pants, Beatles shirt, [Time-Turner](https://www.harrypottershop.com/products/time-turner-trade-by-noble-collection),\nand a pair of boots I'm trying to break in). I get to work wherever I’m most productive, because GitLab is an\n[all-remote company](/blog/the-remote-manifesto/). My 350 team members and\nI work wherever we’re most comfortable – whether that’s in a small cafe in\nUtrecht, Netherlands or in a bookstore in Santa Monica, California. We’re\npassionate about working remotely and believe that it has the power to\n[change the workforce](/company/culture/all-remote/#how-remote-work-is-changing-the-workforce).\n\n## Why all-remote works\n\nAll-remote organizations [empower team members](/company/culture/all-remote/benefits/) to work in settings that allow\nthem to balance their personal and professional lives. A completely remote\nenvironment allows organizations to retain team members as they move to be closer to parents,\ntravel the world, or follow their significant other if they have a job transfer. People don’t have to choose\nbetween their happiness and their career.\n\n> \"Remote working offers flexibility in every part of people’s lives. If you need\nto suddenly take care of your family or friends, the flexibility to travel to\nthem, move to them, be there when they need you there. And I think that's a\nreally beautiful thing.\" — Sid Sijbrandij\n\n1. **Equivalence**: The problem with hybrid setups, in which there are a few\nremote workers who collaborate with a larger on-site team, is that the remote\nteam feels isolated and often misses out on discussions. When there’s no HQ, no\none is in a satellite office and everyone's on equal footing, so no one is left\nout of impromptu meetings over lunch or quick brainstorming sessions down the hall.\n\n1. **Communication**: When everyone is remote,\n[effective communication](/handbook/communication/#introduction) becomes a\nnecessity, which helps instill good, scalable working practices. At GitLab, we\ndocument best practices in our [handbook](/handbook/) and we work in\n[issues](https://docs.gitlab.com/ee/user/project/issues/), allowing us to work\nasynchronously, which we need since we’re a global company with team members in\nevery time zone. Working in issues means our discussions are written, so we don't\nendure long meetings, which run the risk of team members forgetting information\nor decisions.\n\n1. **Hiring**: All-remote companies have an advantage over traditional work\nenvironments, because they can hire people irrespective of location, so they’re\nable to find the most talented people in the world rather than within a commutable\ndistance.\n\n1. **Cost-effective**: When you can hire around the world, you can pay market\nwages and offer people an at-market or above-market wage while still reducing\ncosts for the company. Furthermore, without office rent, an organization saves\na significant amount of money. GitLab, for example, has experienced\n[rapid growth](/jobs/) and would've had to move offices seven times in the last\nfew years. We save a significant amount of money on rent, utilities, office\nequipment, and additional team members to manage the office.\n\n## Overcoming the challenges\n\nThe biggest disadvantage to remote working is that isolation can set in if there\nisn't a concerted effort to create a social connection between people. In a\nco-located company, people can mingle in break rooms, sit together at lunch, and\nbriefly chat in hallways. At all-remote companies, the social fiber of a [culture\nhas to be actively cultivated](/company/culture/all-remote/building-culture/) and time must be set aside for it or team members\nwill feel alone in their work and disconnected from the organization.\n\nGitLab has [Group Conversations](/handbook/group-conversations/)\nevery day at the time when West Coast and Europe overlap. The most-wanted hours\nin the company to organize meetings are dedicated to talking about different\nareas of the company and learning how they're performing. We also do a\n[Company Call](/handbook/communication/#company-call) every day, which\ncomprises about five minutes of announcements and 25 minutes of people chatting.\n\nOur [Coffee Break Calls](/company/culture/all-remote/tips/#coffee-chats) encourage\nteam members to spend several hours a week socializing and building a relationship\nthat's separate from work. Since working remotely can also lead to team members\nnever meeting in person, we have a [visiting grant](/handbook/incentives/#visiting-grant)\nto cover transportation costs, and every nine months, the entire team gets\ntogether for the [GitLab Summit](/events/gitlab-contribute/).\n\nWhen I worked in-office, there was a stigma to wanting to chat with people,\nbecause my manager would wonder why I wasn't working. Now, my manager praises my\nability to connect with people. Our coffee chats give us permission to talk to\nteam members about anything.\n\n> \"Instead of it being a stigma,\nwe support it. We force you to do it when you onboard by asking you to set up\nfive coffee breaks with team members. It's totally legitimized, and everyone thinks it's acceptable. And, one thing I\nlike a lot is that it's personal. People tell stories, and sometimes they're fun,\nsometimes they're beautiful, sometimes they're really sad, and I love them all.\" -- Sid Sijbrandij\n\n## The investor perspective\n\nWe'll admit that investors have expressed concern about our dreamy all-remote\natmosphere. In considering GitLab, investors usually have these three concerns:\nwe don't match their pattern, whether the executive team has enough interaction,\nand the 50 percent loss in value in case of an acquisition. Investors are interested in\npattern-matching, and since the majority of their companies are traditional\nin-office organizations, investors are reluctant to deviate from what has\nhistorically worked well.\n\n![Sid responds to a Hacker News comment, writing that all-remote companies are the future and that one day, in-office companies will have to discuss why they are not remote](https://about.gitlab.com/images/blogimages/sidhn.png){: .shadow}\n  *\u003Csmall>Sid replies to a [Hacker News comment](https://news.ycombinator.com/item?id=18158896) about all-remote companies.\u003C/small>*\n\nWhen it comes to the executive team, investors wonder whether GitLab's leadership\nis able to effectively work together when they're distributed. Leadership needs\nhigh-bandwidth communication since they represent different functions, and in\nthe eyes of investors, remote cultures are not conducive to this level of interaction.\nOur executive team has quarterly in-person meetings and regular video calls.\n\nThe concerns about acquisition are true, but they help both investors and GitLab\ndetermine whether their goals are aligned. When a company gets acquired,\nespecially in the Bay Area, the presumption is that all the employees move to\nthe acquiring company. This would be hard in our case – people don't have work\nvisas, others are used to a remote lifestyle, and a lot of people just wouldn't\nwant to move. The industry estimate is that an all-remote team halves the value\nof a company in the case of an acquisition. Although this may sound terrifying\nto some, this fact helps us select the investors that believe in our goal: to\nbecome a [public company](/company/strategy/#sequence). So, if investors are interested\nin acquisition, investing with GitLab isn't the right move for them, because our\ngoals are misaligned.\n\n## Interested in changing the workforce?\n\nAn increasing number of the workforce wants to be a part of a remote team. One\nstudy found that\n[\"searches for flexible work arrangements is up 32 percent year over year,\"](https://www.hiringlab.org/2017/07/27/flexible-work-arrangements-searches-up/)\nan indication that the appeal of remote working is on the mind of jobseekers.\n\nIf you’re considering creating an all-remote environment, please borrow heavily\nfrom our 1,500-page [handbook](/handbook/)! We discuss which [tools](/handbook/tools-and-tips/)\nwe use, our [expense policy](/handbook/spending-company-money/), and our\n[onboarding template](https://gitlab.com/gitlab-com/people-ops/employment/blob/master/.gitlab/issue_templates/onboarding.md).\nIf you think of ways we can improve our remote working culture, we’d love it if\nyou [contributed](/company/strategy/#why) your thoughts!\n",[683,9],{"slug":2266,"featured":6,"template":687},"the-case-for-all-remote-companies","content:en-us:blog:the-case-for-all-remote-companies.yml","The Case For All Remote Companies","en-us/blog/the-case-for-all-remote-companies.yml","en-us/blog/the-case-for-all-remote-companies",{"_path":2272,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2273,"content":2278,"config":2284,"_id":2286,"_type":14,"title":2287,"_source":16,"_file":2288,"_stem":2289,"_extension":19},"/en-us/blog/there-and-back-again-in-one-release",{"title":2274,"description":2275,"ogTitle":2274,"ogDescription":2275,"noIndex":6,"ogImage":932,"ogUrl":2276,"ogSiteName":673,"ogType":674,"canonicalUrls":2276,"schema":2277},"There and back again in one release","One GitLab team-member spent 5 weeks visiting and working with 6 different colleagues in 5 cities, in 4 countries across Europe and Asia","https://about.gitlab.com/blog/there-and-back-again-in-one-release","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"There and back again in one release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dimitrie Hoekstra\"}],\n        \"datePublished\": \"2017-06-30\",\n      }",{"title":2274,"description":2275,"authors":2279,"heroImage":932,"date":2281,"body":2282,"category":299,"tags":2283},[2280],"Dimitrie Hoekstra","2017-06-30","\n\nInspired by [Robert][robert] and [Douwe][douwe] and their trip called [Around the world in 6 releases][6-releases], another GitLab team-member [Dimitrie][dimitrie] accepted the challenge of pursuing the \"[Travel to visit GitLab team-members][travel-policy]\" company policy by making use of the \"[visiting grant][visiting-grant]\". Visiting 6 different colleagues in 5 cities, in 4 countries across Europe and Asia he has a story to tell. Read on for the why, how, who and where.\n\n\u003C!-- more -->\n\n## The incentive\n\nThis year has been an amazing journey for me, with one of the highlights being the [GitLab summit][summit] in [Cancun, Mexico][cancun]. This event, at which I could bring along my \"significant other\" to the other side of the world was an amazing opportunity. Meeting people you already know online for the first time is a strange, but wonderful experience.\n\n![foto van mexico met iedereen](https://about.gitlab.com/images/8_16/pic.jpg)\n\nThis brings me to meeting [Arihant][arihant], which is one of our support engineers. We met in the back of a van, which was driving us back from [ziplining and swimming in the jungle](/images/blogimages/gitlab-mexico-summit-2017/dimitrie-hoekstra-cenote.gif). [Arihant][arihant] told me about the wonders of [India][india] and made sure I knew I was welcome if I ever thought of visiting him. Working at a fully remote company such as GitLab, where this is an actual possibility, set my mind to work...\n\nThinking about going and actually making it real for yourself, is something else. Who will I meet, where can I go? As a bonus, two of my best friends were and are still backpacking the world. Meeting them so far away from home would be awesome.\n\nBeing one of the UX designers at GitLab, I remembered that one person of the UX team couldn't make it to the [summit][summit] back in January. [Hazel][hazel], who resides in [Taipei, Taiwan][taipei], was the only one which I didn't meet in real life yet. So I reached out to see if I could visit her. She loved the idea!\n\nMeanwhile [Collen][collen], another support engineer living in [Kampot, Cambodia][kampot], made my eyes roll out of their sockets with pictures of [Angkor Wat][angkorwat].\n\nLastly, both [Kushal][kushal] from [Pune, India][pune] and [Jen-shin][jen-shin] from [Taipei, Taiwan][taipei] were happy to meet me as well, when I would be nearby.\n\n## Planning\n\nKnowing who I was going to visit, I had to make sure that dates and people where going to match. Not being the first one in the company to do such a trip, I could see how my colleagues had planned ahead. I expanded and built on their spreadsheet concept, until it became my master plan!\n\nPerson availability, general trip timeline and total cost estimation were the first things I created. I needed them to get my plan approved. Eventually it got upgraded with people and personal travel information to make it more useful for myself. As a bonus, there are some nifty little automation features in there as well.\n\nYou can check out a template copy of it [here][template-copy]!\n\n[Google spreadsheets](https://www.google.com/sheets/about/) allows you to assign people to certain tasks and cells. This made it very easy for people to put in their own information, while being able to see information from others. In other words, efficient team collaboration!\n\nThe result was an approved plan, where everybody was on the same page, by following [the six core values of GitLab][values]: \"Collaboration, Results, Efficiency, Diversity, Iteration, and Transparency (CREDIT)\". Thanks GitLab!\n\n## The scale of remoteness\n\n![worldmap photo](https://about.gitlab.com/images/blogimages/there-and-back-again-in-one-release/full-globe-map-people.jpg){: .vista}\n\nWith my first one-way trip tickets booked, preparing and working eating up most of my time, it was suddenly time to go!\n\nOff to [London][london] it was, for an overnight transit. GitLab, it seems, is everywhere. So I met up with James to make the most of it. Some pints and laughs to celebrate the beginning of this journey, cheers!\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-1\" class=\"carousel slide\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-1\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-1\" data-slide-to=\"1\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/london.jpg\" alt=\"London\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/james-cheers.jpg\" alt=\"Cheers with James\">\n    \u003C/div>\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-1\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-1\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\n### Mumbai\n\nNext up [Mumbai, India][mumbai]. With a flight of around 9 hours, just the sheer scale of the distance we communicate over each day across the web suddenly becomes very real. After receiving a lot of help from [Arihant][arihant], I had a safe place to sleep in the busiest city I have ever seen. [Kindness][kindness] really is one of our core values.\n\n[Mumbai][mumbai] was a fascinating city, one of absolutes. A city where there is a lot of everything, good and bad. It has and still is growing at such a pace, that reality can't really keep up. There is however so much potential!\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-2\" class=\"carousel slide\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-2\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-2\" data-slide-to=\"1\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/mumbai_1.jpg\" alt=\"Mumbai highway\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/mumbai_food.jpg\" alt=\"Indian food\">\n    \u003C/div>\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-2\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-2\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\nThe amount of people is staggering, which results in the worst traffic I have ever seen. However as [Arihant][arihant] showed me, has the most delicious variety in food I have ever tasted. People are always ready to help you and after some time, you know how to get around!\n\nWhen you are working remotely while traveling, you are very reliant on a decent internet connection. In [India][india] apparently, you can depend fully on mobile internet, rather than on wifi. Working together with [Arihant][arihant] has been a blast and gave some insights as to how others plan out their days.\n\nI am very thankful to have had the opportunity to be introduced to his family, even cook with them, and to experience [India][india] as he does. Thanks [Arihant][arihant]!\n\n__Fun facts:__\n- My hotel, made use of a new concept called pods. It was like sleeping in a spaceship. [See for yourself][urbanpod]!\n- Driving on a scooter in [Mumbai][mumbai] is not for the faint of heart.\n- Tessa, my girlfriend back home who was very supportive of my intentions to make this trip, asked a favour of me while I was in [Mumbai][mumbai]. To try and watch Netflix together, as with traveling comes some form of a remote bonding. Soon we found out that the content library in [India][india] is not the same as back home. Why Netflix, why? [Google Duo][googleduo] to the rescue though, as I managed to watch an episode of \"The Americans\" through her phone on our tv back home. Speaking of perseverance. Thanks Google!\n\nIn the last days in [Mumbai][mumbai], my friends from home decided to join me. After enjoying the market and various street food it was time to travel to [Pune][pune], to meet with [Kushal][kushal].\n\n![mumbai photo](https://about.gitlab.com/images/blogimages/there-and-back-again-in-one-release/mumbai_2.jpg)\n\n### Pune\n\nIn [Mumbai][mumbai] I mostly worked from my Hotel. It had AC which is something you learn to appreciate when it's there. In [Pune][pune], [Kushal][kushal] arranged for a nice workplace at a flex workspace called [Bootstart][bootstart]. While my friends updated their blogs, me and [Kushal][kushal] collaborated on and discussed GitLab. A typical workday in [India][india].\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-3\" class=\"carousel slide\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-3\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-3\" data-slide-to=\"1\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/pune_1.jpg\" alt=\"Having dinner with Kushal and friends\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/goa_bus.jpg\" alt=\"Indian sleeper bus\">\n    \u003C/div>\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-3\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-3\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\nAfter a day with more awesome Indian food, me and my friends had to catch our bus to [Goa][goa]. This seemed easy, but was in the end quite the adventure. Quickly having to move to various locations where the bus might stop, jumping in and out auto rickshaws (Indian tuk tuks), plus [Kushal][kushal] speaking with the bus driver in yet another language, resulted in. Thanks [Kushal][kushal]!\n\n### Goa\n\nJust 12 hours and a flat tire later, we arrived in a [Goa][goa]. This was my in between mini-holiday. Mainly having a good time with my friends and converting from a digital nomad to a backpacker.\n\nThis proved to be quite the change, in a fun way. Hostels instead of hotels, and the cheaper the better. Our first hostel was just 100 INR, which is around 1.5 USD!\n\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-4\" class=\"carousel slide\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-4\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-4\" data-slide-to=\"1\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/goa_beach.jpg\" alt=\"On the beach with friends\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/goa_market.jpg\" alt=\"Indian nightmarkets\">\n    \u003C/div>\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-4\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-4\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\nSwimming, clubbing and enjoying the sun. Meeting a lot of new people and driving around on scooters. Eating mango's falling right off the trees. Visiting night markets and getting all relaxed. Leaving the chaos of the big cities behind.\n\n![enjoying the sun](https://about.gitlab.com/images/blogimages/there-and-back-again-in-one-release/goa_sun.jpg){: .vista}\n\n### Siem Reap\n\nTime flies and I do too! [Siem Reap, Cambodia][siemreap] was up next, with a small transit in [Hyderabad][hyderabad] and [Singapore][singapore]. [Collen][collen] soon picked me up at the airport with a Cambodian Tuk tuk. Having met each other in Mexico, it was easy to fall into the same flow as back there. In other words, great times ahead.\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-5\" class=\"carousel slide\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"1\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"2\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/siemreap_airportcollen.jpg\" alt=\"siem reap tuk tuk photo\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/siemreap_crocodiles.jpg\" alt=\"Crocodile farm in residential neighbourhood\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/siemreap_angkorwat_tree.jpg\" alt=\"tree in Angkor Wat\">\n    \u003C/div>\n\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\nCynthia, Collen's significant other, had arranged a wonderful AirBnb. Pure luxury after my time in [Goa][goa]. Oh, and did I tell about our crocodile neighbours?\n\nSoon I came to know this touristy little city booming with activity, by working together at the [Angkor Hub][angkorhub], eating at various Australian food joints like [this one][sistersreycafe], and going to the highlight of the area; [Angkor Wat][angkorwat].\n\nI would be the first to admit that this place is incredible. It is another ancient civilisation's legacy of which there are massive remains in the middle of the jungle. The sheer scale is enormous and captivating. Being used myself to the Roman and Celtic ruins scattered throughout Europe, this was an eye opener. Especially the old buildings covered with trees are a sight to behold.\n\nAll of this pleasantry must come to an end of course. Thanks for the awesome times [Collen][collen] and Cynthia!\n\n![siem reap tuk tuk photo](https://about.gitlab.com/images/blogimages/there-and-back-again-in-one-release/siemreap_angkorwat.jpg)\n\n### Bangkok\n\nLast up my list was [Taipei, Taiwan][taipei], with a small transit through [Bangkok, Thailand][bangkok]. At the airport I met [Patai][patai], who was familiar with GitLab. With our flight being delayed, this was a nice way to kill the time and do a bit of evangelising.\n\n![evangelising](https://about.gitlab.com/images/blogimages/there-and-back-again-in-one-release/thailand_patai.jpg)\n\n### Taipei\n\nI arrived late at night and got fairly quickly to my Hostel, where I would stay the rest of my days in [Taipei][taipei]. Both the city and the [Hostel][meander] were very modern, clear and approachable. I soon came to know about the excellent subway system and again lovely food.\n\nThe next day I met up with [Hazel][hazel], which was a happy moment. Apparently, I was the first GitLab team-member she has ever met! Soon we were going about the city, sightseeing temples and local markets. After working together we even did some ice skating, which I love to do!\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-6\" class=\"carousel slide\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-6\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-6\" data-slide-to=\"1\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-6\" data-slide-to=\"2\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/taipei_working.jpg\" alt=\"taipei working together\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/taipei_happy.jpg\" alt=\"Me and Hazel meet\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/there-and-back-again-in-one-release/taipei_hazel_and_jenshin.jpg\" alt=\"Hazel and Jen-shin meet\">\n    \u003C/div>\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-6\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-6\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\n[Jen-shin][jen-shin] lives in the same city, another opportunity! As I was not feeling too well on that day, we saw some of the more controversial structures in the city. The original plan was to go to one of the many waterfalls around there. A good reason to return one day.\n\nOn the last day we all managed to meet up, making it so, that [Hazel][hazel] and [Jen-shin][jen-shin] finally met each other as well. In other words, interconnecting GitLab. Thanks [Hazel][hazel] and [Jen-shin][jen-shin], for this awesome time together.\n\n## Going back again\n\nMy way back, was a bit rough, with a transit time of 16 hours in [Shanghai, China][shanghai]. It is strange how different the internet feels without services like Google, Facebook and so on, because of [the great firewall of China][greatfirewall]. I can only say that, this was by far the worst online experience I have had throughout my trip. Time to step up [China][china], openness is the answer!\n\nArriving back in the [Netherlands][netherlands], I quickly came to appreciate things that before went by unnoticed. This trip has opened up new insights into how things are and could be. Differences in culture and the way people live and work is what breathes character and what enriches the world. I hope we all interconnect even more, to see what great things are yet to be.\n\n![worldmap photo](https://about.gitlab.com/images/blogimages/there-and-back-again-in-one-release/full-globe-map-trip.jpg){: .vista}\n\nLooking at the complete journey I have made, it becomes clear that no distance is too big in order to connect, work together and have fun. It has been a life enriching experience for which I am happy and thankful to have had the opportunity. Thanks GitLab and all the people that I could visit and meet, it was an absolute pleasure to [get to know each other][gettoknow].\n\n## Sharing experience\n\nA trip is not complete without finding what works and what doesn't. I want to see others succeed in working abroad as well, therefore I created a separate section in the [GitLab handbook][handbook-workingabroad] with tips and tools that I found most helpful on such journeys.\n\nDo you love the GitLab way of working? [Join our team](/jobs/)!\n\n",[683,9],{"slug":2285,"featured":6,"template":687},"there-and-back-again-in-one-release","content:en-us:blog:there-and-back-again-in-one-release.yml","There And Back Again In One Release","en-us/blog/there-and-back-again-in-one-release.yml","en-us/blog/there-and-back-again-in-one-release",{"_path":2291,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2292,"content":2297,"config":2302,"_id":2304,"_type":14,"title":2305,"_source":16,"_file":2306,"_stem":2307,"_extension":19},"/en-us/blog/tips-for-managing-engineering-teams-remotely",{"title":2293,"description":2294,"ogTitle":2293,"ogDescription":2294,"noIndex":6,"ogImage":1191,"ogUrl":2295,"ogSiteName":673,"ogType":674,"canonicalUrls":2295,"schema":2296},"Tips for managing remote working engineering teams","Newly remote engineering managers – how's it going? We offer some tips from our team members who manage remotely.","https://about.gitlab.com/blog/tips-for-managing-engineering-teams-remotely","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tips for managing remote working engineering teams\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2021-01-29\",\n      }",{"title":2293,"description":2294,"authors":2298,"heroImage":1191,"date":2299,"body":2300,"category":705,"tags":2301},[812],"2021-01-29","\n\nThe transition from working in an office to working for an all-remote company [isn’t always easy](/company/culture/all-remote/hybrid-remote/). Many engineers are used to whiteboarding a troublesome piece of code with their colleagues and being able to tap their manager on the shoulder when they get really stuck. In-office engineering managers are accustomed to reading body language and following verbal clues when interacting with the team members they supervise. For developers used to working in an office, it takes some time to adjust to working autonomously from home, instead of in a pod of desks with a team.\n\nGitLab team members share how they managed the shift from in-person, colocated work to working and managing teams remotely at GitLab to help others make the transition to remote work more easily.\n\n\"My day-to-day role is very similar,\" says [Max Woolf](/company/team/#mwoolf), senior backend engineer on the Manage:Compliance team at GitLab. \"I work closely with product owners or product managers deciding, refining work, and then writing the code to make those things happen on a daily basis. The main difference was that I worked in an office with 10, 11 other people, and now I work on my own with about 1,200 other people.\"\n\nOverall, engineering managers say the goals of leading the team are the same, but the way you achieve those goals differs while working in-person and working remotely.\n\n## When remote working, clear communication is key\n\nWhen working in-person, some of the hallmarks of asynchronous communications (document everything, be sensitive to your colleagues' time) are often sacrificed in favor of the ease of informal, verbal exchanges.\n\nThe reality is, there are times when an engineer's question just requires a quick, 30-second answer, says [Cheryl Li](/company/team/#cheryl.li), backend engineering manager for Verify at GitLab. It's easier when working in an office to just answer the question immediately, even if the question might be frequently asked or otherwise merits a documented response.\n\n[Corine Tan](https://twitter.com/itscorine), cofounder of Kona, [interviewed 500 remote managers in tech and summarized 21 key findings in a blog post](https://www.sikeinsights.com/post/21-tips-for-managing-remote-teams-in-2021) and on Twitter. She learned that a bias toward overcommunication and rigorous standards for documentation is key to successfully managing a remote team.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">#2 - Trust creates remote synergy. Low visibility can seed doubt.\u003Cbr>\u003Cbr>To build a culture of trust:\u003Cbr>- Assume positive intent 👍\u003Cbr>- Over-communicate 📣\u003Cbr>- Prioritize > micromanage 📋\u003Cbr>- Set documentation standards 📚\u003Cbr>- Address issues as trends 📉\u003Cbr>- Learn fast(er) 🏎\u003Cbr>- Ask for feedback ❓\u003C/p>— Corine Tan 🍜 (@itscorine) \u003Ca href=\"https://twitter.com/itscorine/status/1354121806395805697?ref_src=twsrc%5Etfw\">January 26, 2021\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n[Craig Gomes](/company/team/#craig-gomes), backend engineering manager for Memory and Database at GitLab, echoes Corine's findings: Defining communication channels and setting clear expectations around communication is essential for successfully managing a remote team.\n\n\"If your team has a deployment issue to fix, it is easier in an in-person environment to gather everyone to quickly resolve it,\" says Craig. \"In an asynchronous/distributed environment it is important to provide as much information in an established communication channel as possible to resolve the issue in an efficient amount of time. The same goes for planning, goal setting, bug fixes, etc.\"\n\n## The biggest challenge: Building connected and engaged teams\n\nOne of the key benefits to managing a team in person is the interpersonal aspect. It is easier to build a connection and maintain team engagement when everyone is in the same place and there are more opportunities for small talk and shared laughs. Both Cheryl and [Rachel Nienaber](/company/team/#rnienaber), engineering manager: Scalability at GitLab, mentioned relying a lot of verbal cues and body language to decipher when a team member might be struggling with burnout or a personal challenge. Non-verbal cues are not easily replicated via Zoom, which means managers need to overcommunicate with their team members to learn about stress styles. The best way to do this? Ask.\n\n\"Just as teammates have preferences for feedback or learning, they also have different reactions to stress. Knowing whether to give space, lend an ear, or take action often starts with asking the person,\" writes [Corine in her blog post](https://www.sikeinsights.com/post/21-tips-for-managing-remote-teams-in-2021).\n\nIt takes intentionality and effort to build postive interpersonal connections in an all-remote team. At GitLab, we encourage team members to set up [coffee chats via Zoom](/company/culture/all-remote/informal-communication/#coffee-chats), and when Zoom fatigue hits we also have informal Slack channels that allow people to share photos and chat about shared interests. We will be exploring in depth how engineers can collaborate remotely in an upcoming blog post, so keep an eye out!\n\n### Leverage transparency\n\n\"From personal experience, one of the biggest challenges of remote work is ensuring engagement at a team and individual level,\" says Craig. One of the ways that Craig maintains transparency is by documenting team processes and expectations in the GitLab handbook, and by holding routine team processes reviews to check that everyone on the team is operating from a shared context.\n\n \"This level of transparency helps to improve shared context across stakeholders as well,\" he adds \"By shared context I mean that we have a shared communication platform, written and asynchronous, rather than having the context spread across multiple different channels (meetings, hallway conversations, emails, etc).\"\n\nRachel says that it was easier for her to know what her team was working on during the day while working as an engineering manager in an office setting. She was able to walk around the room and get a good sense of who was busy with what projects. But by the same token, she had to be prepared to be interrupted at any time by some of the engineers she supervised.\n\n\"When team members need help, it felt helpful and effective to unblock them quickly,\" says Rachel, who currently works as an engineering manager at GitLab. \"But this meant that if I needed time to focus and get a piece of work done, I would need to book out a meeting cubicle for myself.\"\n\nIf both parties are available, [hopping on a video call](/handbook/communication/#video-calls) to discuss the problem and share a screen in real-time is a good way for engineering managers like Rachel to help team members who are blocked on a particular piece of code. Video calls on an as-needed basis are far more effective than recurring meetings which people might feel obligated to fill, even if they don't have anything pressing to discuss. Speaking of which...\n\n## Shift from meetings to async\n\nThe three engineering managers we spoke with for this blog post agreed: Working as an engineering manager in an office setting meant _a lot_ of time spent in meetings.\n\n\"When I worked in a co-located environment, I largely performed the same duties, but I had a lot of more meetings,\" says Cheryl. \"Working asynchronously wasn't part of the culture, so every discussion or decision had to be vetted in a synchronous meeting, sometimes in a meeting with 20+ people. Meeting rooms became scarce due to the nature of how the company operated.\"\n\nRachel agreed, noting that she was devoting the majority of her time to different types of meetings, from standups, to 1-1s, project meetings, coordination meetings. Managing her calendar became a significant part of her role as engineering manager.\n\n\"Synchronous meetings were seen as a more effective way to get things done, but they took up a lot of time,\" says Rachel.\n\nInstead of defaulting to synchronous meetings by video call, we prefer asynchronous communication at GitLab. The core of asynchronous communication is documentation, as opposed to verbal communication. Documenting questions, answers, and discussions in one preferred communication channel allows team members to work on the time table that is most efficient for them, and helps projects move forward across time zones. We explain in depth [how asynchronous communication works at GitLab](/handbook/communication/#asynchronous-communication) in our company handbook, but these tips in particular are useful for reducing the number of synchronous meetings for your team:\n\n* Prioritize communication channels: By identifying a first-choice platform for discussion, everyone in the company is on the same page. [We discuss projects and questions in issues and merge requests](/handbook/communication/#start-with-a-merge-request), which are public by default, instead of using private messages on Slack or email.\n* Document everything: Being all-remote and globally distributed, we have a bias toward overcommunication. At any all-remote company, it is best to [define your thoughts clearly in written text](/company/culture/all-remote/effective-communication/) so discussion can continue even when everyone is not online at the same time.\n\n## More tips for engineering teams making the switch to remote\n\nThis video gives the full run-down to engineering companies or teams that are considering making the switch from colocated working to all-remote permanent.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/MSj6-wC4f9w\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[9],{"slug":2303,"featured":6,"template":687},"tips-for-managing-engineering-teams-remotely","content:en-us:blog:tips-for-managing-engineering-teams-remotely.yml","Tips For Managing Engineering Teams Remotely","en-us/blog/tips-for-managing-engineering-teams-remotely.yml","en-us/blog/tips-for-managing-engineering-teams-remotely",{"_path":2309,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2310,"content":2315,"config":2320,"_id":2322,"_type":14,"title":2323,"_source":16,"_file":2324,"_stem":2325,"_extension":19},"/en-us/blog/tips-for-mastering-video-calls",{"title":2311,"description":2312,"ogTitle":2311,"ogDescription":2312,"noIndex":6,"ogImage":1050,"ogUrl":2313,"ogSiteName":673,"ogType":674,"canonicalUrls":2313,"schema":2314},"5 Tips for mastering video calls","All-remote work wouldn't be possible without communication tools like video conferencing. Here are a few tips we use at GitLab.","https://about.gitlab.com/blog/tips-for-mastering-video-calls","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Tips for mastering video calls\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Betsy Church\"}],\n        \"datePublished\": \"2019-08-05\",\n      }",{"title":2311,"description":2312,"authors":2316,"heroImage":1050,"date":2317,"body":2318,"category":705,"tags":2319},[852],"2019-08-05","\nAs remote and distributed work becomes more popular around the world, technology is\nconstantly evolving to support it. Communication tools, particularly video conferencing, allow\npeople to [connect and collaborate from anywhere with an internet connection](/blog/how-remote-work-at-gitlab-enables-location-independence/).\n\nFor an [all-remote](/company/culture/all-remote/), global company like\nGitLab, video calls are even more crucial to how\nwe [communicate](/handbook/communication), get work done as a team,\nand get to know each other.\n\nWhile best practices for video calls may seem obvious to the experienced remote\nprofessional, they often don’t come naturally to someone who’s used to working in a\ntraditional office setting. Here are some of the tips and tricks we use at\nGitLab to help you master the art of a successful video call.\n\n## 1. Know when a call is necessary\n\nFirst things first: Do you even need to have a video call? We’ve all had those\nwork weeks that are overloaded with calls or meetings, when oftentimes the\ntopic could have been discussed asynchronously in an email, Google Doc, or even a GitLab issue.\n\nWe default to [asynchronous communication](/handbook/communication/) at\nGitLab for many reasons. For one, it means there is far more documentation of your project\nand the work being done. On a global team, asynchronous communication allows for progress to continue even after\none person’s working day ends. Asynchronous work is also naturally more inclusive\nbecause [everyone can contribute](/company/mission/#mission).\n\nBut that doesn’t mean it works for every conversation. At GitLab, our rule of thumb is\nthat if you go back and forth about a topic three times, it’s time for a video call to\ntalk it out in real time.\n\n## 2. Use the right equipment correctly\n\nThe headphones and equipment you use can make a big difference in a successful video call,\nbut only if you use them the right way.\n\nIt's tempting to join a call using the built-in mic in your laptop, but grab a set of headphones instead. \nThey help eliminate interference and background noise for others on the call, making the conversation flow more smoothly.\n\nWhen you're preparing for your call, allow yourself a few minutes to test your audio and video, especially if it's the first time you've used that video conferencing tool. \n\nAnother equipment misstep that happens often, particularly in companies with a mix of in-office and remote\nemployees, is what we call “hybrid calls.” A [hybrid call](/handbook/communication/#hybrid-calls-are-horrible)\n is when two (or more) people in one room try to share the same equipment during a call\n – laptops, cameras, even headphones. Not only does this create a negative and non-inclusive\n  experience for anyone who’s not in the room, it rarely works well for the people sharing the equipment.\n\nDo your remote team members a favor: Use your own laptop, camera, and headphones (and\npreferably, your own conference room) so that you can talk, screen share, take notes, and be seen clearly.\n\n## 3. Turn on your video\n\nOne of the best aspects of video calls is that they allow us to have high-fidelity conversations without being in the same location. \nBut if you don't use your camera, it's tough to get to know the person you're meeting with. \nThis is especially important at GitLab or any all-remote company, since we only get together in person every\nso often. \n\nWhile it's certainly not required, we encourage team members to default to using their cameras whenever possible.\nWhether you just came back from the gym, you’re eating lunch at your desk, or your dog,\nspouse, or child is in the room (have them wave!), still consider turning on your camera.\nThese are all typical parts of a remote workday, and might even spark a conversation that\nhelps you get to know a member of your team better.\n\n## 4. Speak up\n\nIt might go against your instincts around meeting etiquette, but (politely) speaking up or\neven interrupting someone on a video call is perfectly okay.\n\nThis takes some getting used to because the latency on video calls means you may be\ntalking over someone for longer than you would in person. But you can’t have a dynamic,\ncollaborative meeting unless people are able to contribute, ask questions, and add context in the moment.\n\nIf you’re on a call and you notice a team member who appears to be struggling to get a word in,\ndon’t hesitate to specifically invite them into the conversation so that they have a\nchance to speak as well. Your call will be more productive if everyone feels able to participate.\n\n## 5. Watch the clock\n\nIt’s hard to decide which is more important: starting a call on time or ending it on time.\nSo we aim for both. A meeting that runs even two or three minutes over can put someone’s entire schedule behind.\n\nIf your team regularly struggles to end on time, try assigning someone ahead of each meeting to\nbe the time keeper and give everyone a heads up when the call is almost over. If you weren’t\nable to get through your whole agenda in the allotted time, either schedule an additional call,\nor continue to communicate about it asynchronously instead.\n\n___\n\nLearn more about GitLab’s approach to [all-remote work](https://about.gitlab.com/company/culture/all-remote/).\nInterested in joining our team? Browse our [vacancies](https://about.gitlab.com/jobs/).\n\nCover image by [Trust \"Tru\" Katsande](https://unsplash.com/@iamtru?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[9,683,731],{"slug":2321,"featured":6,"template":687},"tips-for-mastering-video-calls","content:en-us:blog:tips-for-mastering-video-calls.yml","Tips For Mastering Video Calls","en-us/blog/tips-for-mastering-video-calls.yml","en-us/blog/tips-for-mastering-video-calls",{"_path":2327,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2328,"content":2333,"config":2338,"_id":2340,"_type":14,"title":2341,"_source":16,"_file":2342,"_stem":2343,"_extension":19},"/en-us/blog/tips-for-working-from-home-remote-work",{"title":2329,"description":2330,"ogTitle":2329,"ogDescription":2330,"noIndex":6,"ogImage":1050,"ogUrl":2331,"ogSiteName":673,"ogType":674,"canonicalUrls":2331,"schema":2332},"How to live your best remote life","GitLab team members offer their best advice on working from home (and it might surprise you).","https://about.gitlab.com/blog/tips-for-working-from-home-remote-work","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to live your best remote life\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jarka Košanová et al\"}],\n        \"datePublished\": \"2019-07-09\",\n      }",{"title":2329,"description":2330,"authors":2334,"heroImage":1050,"date":2335,"body":2336,"category":705,"tags":2337},[772],"2019-07-09","\nIf there’s one thing GitLab team members ought to be experts at by now it’s [how to work from home](/company/culture/all-remote/).\n\nThat’s why we asked for your single best [work-from-home](/blog/eliminating-distractions-and-getting-things-done/) tip. The answers – involving cars, snacks, clothing, exercise, and the importance of a closed door – just might surprise you.\n\n## The definition of done\n\nThis well-known software development concept applies equally to working at home. [Jarka Košanová](/company/team/#jajina_k), backend engineer, stresses the importance of flexibility when it comes to deciding when to end the work day. “Many people who start working remotely have a problem recognizing they should stop working for the day. It is easy to advise setting a time when you finish your work in the same way as if you were in an office. But then you kind of lose the flexibility working from home is about. What helped me was my husband returning home from his work. If I had a day without any big break I knew it was time to finish my work as well. If I had a day with a break, I knew, on the other hand, I still could work a bit more and it would be ok.”\n\n## Start your engines\n\nIf you’ve been used to a commute as the first part of your day, this tip senior content editor [Valerie Silverthorne](/company/team/#valsilverthorne) borrowed from a friend is for you. “A work-at-home friend starts his day off by jumping in his car and driving around his neighborhood. When he pulls back in to his driveway, his ‘commute’ is complete and he’s ready to start his day.”\n\nOthers at GitLab have their own, perhaps more carbon-friendly, versions of this ritual. [Daniel Gruesso](/company/team/#danielgruesso), Configure product manager, has a good plan that involves a different kind of locomotion. “Getting out of the house before I start my day is very important for me. Either walking the dog or going for a swim to clear my head and get the blood flowing.”\n\n## Literally dressing for success\n\n### No PJs\n\nClothes make the person, even, apparently, in a work-from-home culture. No PJs for Secure frontend engineer [Sam Beckham](/company/team/#samdbeckham), at least. His top tip: “Getting dressed. It might be tempting to work in your pyjamas all day (and I occasionally still do) but getting dressed and presenting yourself as if you were to be going to an office job can go a long way towards getting you into a working mindset.”\n\n### Dress comfy\n\nOf course, there’s dressed, and then there’s dressed up, which is a significant difference according to [Heather Simpson](/company/team/#Heatherswall), senior external communications analyst, Security. “(I) agree, getting dressed is crucial for me… although I appreciate the attire I feel comfortable with wearing here at GitLab vs at my old company (where I worked remotely for 10 years). I now feel completely comfortable in a hoodie.”\n\n### Have a uniform\n\nContent marketing associate [Suri Patel](/company/team/#suripatel) takes a different tack with her clothing. She’s assembled a work uniform that draws a distinct line between time on and time off. “I have a hard time not thinking about work after I close my computer, so I have 10 black shirts (they were on sale), specific sweaters, and trousers that I only wear while working. The last thing I want to do is pair my favorite dress with a stressful project and be reminded of that while at the beach.”\n\n## A routine routine\n\nWe know we like [boring solutions](https://handbook.gitlab.com/handbook/values/#boring-solutions) and a lot of us really like/need/want a routine, particularly when it comes to working from home. [Carol Wainana](/company/team/#carowangar), service support agent, likes a routine. “Having a fixed routine that is time to wake up, time to start working, time for lunch and time to log off has been really beneficial for me.” And Heather agrees. “For me, a routine is helpful too – I start my day with coffee and checking out Twitter for interesting articles to read and/or share. This eases me into the day but still helps me stay informed and able to share thoughtful articles, etc., on the regular (mostly).”\n\nBut a routine doesn’t necessarily work for everyone, as [Tanya Pazitny](/company/team/#tpazitny), interim quality engineering manager, Secure & Enablement, points out. “I think you need to throw the concept of “nine to five” out the window and actively experiment to find what schedule lets you make the most of your time. I often find the midday slump to be so real, so if i'm feeling this way I step away for a while and then come back for a few hours in the evening when I generally feel supercharged.”\n\n## The magic of a door\n\nFor some of us work at home productivity starts with a closed door. That’s definitely true for Create senior backend engineer [Nick Thomas](/company/team/#nick.thomas). “(There need to be) clear signals to other inhabitants about whether you can be disturbed or not. When I'm in the spare room, the rule is simple – if the door is closed, do not come in.”\n\nHis other tip involves walking through the door and to somewhere else. “Also, I find it really helpful to work from ‘not home’ every now and again. A change is as good as a rest.”\n\n## The snack struggle is real\n\nTanya and [Mario de la Ossa](/company/team/#mdelaossa) both think remote work peril lies in the cupboard. “Keep junk food out of your house or you'll graze all day,” Tanya warns. Mario, backend engineer, Plan, agrees: “If I know there are snacks I WILL eat them, so I keep none in the house.”\n\n## The takeaway\n\nPerhaps [Brad Downey](/company/team/#TechBradD), strategic account leader, southern California, sums it up best: “Get dressed, have a proper work area (not the couch), and don’t eat lunch at your desk.”\n\nHave a great idea we didn’t mention? Leave it below and we’ll add it, and these, to the handbook.\n",[707,683,9],{"slug":2339,"featured":6,"template":687},"tips-for-working-from-home-remote-work","content:en-us:blog:tips-for-working-from-home-remote-work.yml","Tips For Working From Home Remote Work","en-us/blog/tips-for-working-from-home-remote-work.yml","en-us/blog/tips-for-working-from-home-remote-work",{"_path":2345,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2346,"content":2352,"config":2358,"_id":2360,"_type":14,"title":2361,"_source":16,"_file":2362,"_stem":2363,"_extension":19},"/en-us/blog/virtual-reality-team-building",{"title":2347,"description":2348,"ogTitle":2347,"ogDescription":2348,"noIndex":6,"ogImage":2349,"ogUrl":2350,"ogSiteName":673,"ogType":674,"canonicalUrls":2350,"schema":2351},"How to use virtual reality for team building","Zoom meetings are fine, but are there better options for team bonding? We tested a few virtual reality games. Here's what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682413/Blog/Hero%20Images/jeshoots-com-xGtHjC_QNJM-unsplash.jpg","https://about.gitlab.com/blog/virtual-reality-team-building","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use virtual reality for team building\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Nohr\"}],\n        \"datePublished\": \"2022-08-09\",\n      }",{"title":2347,"description":2348,"authors":2353,"heroImage":2349,"date":2355,"body":2356,"category":705,"tags":2357},[2354],"Matt Nohr","2022-08-09","\nSince GitLab is [All Remote](/company/culture/all-remote/), we are frequently looking for new ways to stay connected with each other. A short time ago, our chief technology officer attended a virtual reality (VR) networking session and saw some potential for this type of [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) within GitLab. As the [acting chief of staff to the CTO](/handbook/engineering/cto-staff/#acting-chief-of-staff-to-the-cto-rotation), I got the fun task of testing out how we could use VR as a team-building tool.\n\nFor this initial trial, I reached out to existing VR users at GitLab, using the #vr-pals slack channel. We also honed in on people who already had an Oculus Quest 2.\n\nHere are some of the things we tried, and what I found worked well:\n\n## Picking games\n\nI had some criteria when trying to find games to use for team building. First and foremost, I wanted games that felt inclusive to GitLab team members. Because of this, I ruled out shooting or other fighting games. I also stayed away from games that required a high level of physical activity. I found some games that had a long initial tutorial or game setup, which could have been appropriate but would have needed participants to do work in advance of any team-building sessions.\n\n## Explore the world - Wander\n\nThe first game we tried as a group was [Wander](https://www.oculus.com/experiences/quest/2078376005587859). This is basically a VR version of [Google Street View](https://www.google.com/streetview/). Our group took turns leading mini tours. I showed a place from a recent vacation, someone else gave us a tour of his hometown, and then we did one of the pre-built tours that come with the game. While we were using the game we could talk to each other, see where everyone else was looking, and even point things out.\n\nOne of the reasons I picked this game is that I've done something similar with team members over Zoom in the past. This felt more interactive since each person could look around on their own, and we weren't watching someone just screen-share a browser window.\n\nOne issue we had was that only five people could be in a room, which was a limitation of the game itself. We had more people than the room size allowed for, so some people did not get to participate. Now that we know this, we could work around it by splitting up into smaller groups in advance.\n\nIt also took a bit of time to become familiar with the controls. This was not a major concern, but we did have to explain the details to each other. This would happen with any game, and having teams familiarize themselves in advance would fix this problem. On the other hand, we did not want to have people required to do work before a team-building session.\n\nAnother challenge with this – and any other – game was identifying team members by their Oculus usernames and avatars. I would recommend players temporarily change their username for this type of team building.\n\nIf we wanted to do this again, it would be helpful to have people do a bit of planning in advance. For example, I could build a mini tour in the game using the \"favorites\" feature and then walk through that. It would make it flow a bit better and could be more inclusive if people felt more prepared. We could also have different sessions with themes like \"favorite vacation spots\" or \"best local food.\"\n\n## Bowling party - ForeVR Bowl\n\nThe other game we tried as a group was [ForeVR Bowl](https://www.oculus.com/experiences/quest/3420508614708029/). This was fun because, while we were bowling, we were mostly using the time together to tell stories and get to know each other. In this game, there are different bowling balls that are hidden for you to find and unlock, and after a couple of rounds of bowling, we decided just to go search for all the hidden balls. It was fun to be able to do this joint treasure hunt, and there are probably other good games that fit this theme as well.\n\nWe had some audio issues that we needed to work through on this game, but once we got that sorted out it was very smooth. I'm not sure how great the bowling mechanics/physics of the game are, but we were not trying to get high scores, just to socialize.\n\nLike Wander, there is a limit on the number of people in a bowling party, which is something to keep in mind. The controls also take a bit of getting used to for moving around the bowling alley, but that did not get in the way.\n\n## Other games\n\nThere were a couple of other games that were suggested that we did not get a chance to try.\n\nFirst is [Beat Saber](https://www.oculus.com/experiences/quest/2448060205267927/). I really enjoy playing this game, but it seems to work best as a single-player game. There is not a ton of collaboration. \n\nAnother game is [Rec Room](https://www.oculus.com/experiences/quest/2173678582678296/). This is something we could try in the future as it has a bunch of mini-games within it. It does take a bit of practice to get used to the game and controls, and that is why I did not include it in our trial.\n\nTo be more business-focused, I also tried out [Immersed](https://www.oculus.com/experiences/quest/2849273531812512/). I mainly used the desktop feature, which mirrors your computer to VR and you can have many virtual monitors. It was interesting, but I found that I got fatigued when trying to do actual work in this mode. There is also a virtual meeting room we could try, but for that, it seems our current Zoom setup is more efficient. \n\n## Going forward\n\nOverall, I think using VR is a fun way to connect with team members from all over the world, and something we should continue to explore. Over the past few years meeting in person has been difficult, so finding new ways to connect with each other virtually is something we should keep working on.\n\nOne major consideration is the price and availability of VR headsets for team members in different parts of the world. To give just one example, in South Africa the headsets cost about 2.5 times more than they do in the United States – if you can find them in stock. If we wanted to use this tool, we would need to ensure all team members had equal access to the hardware.\n\nCover image by \u003Ca href=\"https://unsplash.com/@jeshoots?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">JESHOOTS.COM\u003C/a> on \u003Ca href=\"https://unsplash.com/s/photos/virtual-reality?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>\n{: .note}\n",[9],{"slug":2359,"featured":6,"template":687},"virtual-reality-team-building","content:en-us:blog:virtual-reality-team-building.yml","Virtual Reality Team Building","en-us/blog/virtual-reality-team-building.yml","en-us/blog/virtual-reality-team-building",{"_path":2365,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2366,"content":2372,"config":2378,"_id":2380,"_type":14,"title":2381,"_source":16,"_file":2382,"_stem":2383,"_extension":19},"/en-us/blog/watch-the-gitlab-summit-from-your-desk",{"title":2367,"description":2368,"ogTitle":2367,"ogDescription":2368,"noIndex":6,"ogImage":2369,"ogUrl":2370,"ogSiteName":673,"ogType":674,"canonicalUrls":2370,"schema":2371},"We're coming to you live from Crete, at the GitLab Summit!","Read on for all the events you can watch and participate in.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680330/Blog/Hero%20Images/greece-summit-2017.png","https://about.gitlab.com/blog/watch-the-gitlab-summit-from-your-desk","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We're coming to you live from Crete, at the GitLab Summit!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2017-10-17\",\n      }",{"title":2367,"description":2368,"authors":2373,"heroImage":2369,"date":2375,"body":2376,"category":299,"tags":2377},[2374],"Emily von Hoffmann","2017-10-17","\n\nIt's that time again! Every nine months, our entire remote workforce descends on one location for the [GitLab Summit](/events/gitlab-contribute/). This year, we'll be in Crete, and you're invited!\n\n\u003C!-- more -->\n\nBefore you go off and buy a plane ticket, we should clarify that there probably isn't room for all of you on the island. But we're trying something new this Summit — we're live streaming every day to bring the experience to as many of our remote friends as possible.\n\n## Watch\n\nWe'll be streaming on [YouTube](https://rebrand.ly/gitlab-summit-stream). You can watch [Sid](/company/team/#sytses) and [Dmitriy](/company/team/#dzaporozhets)'s keynotes, our Santorini trip, [GitLab team-member-led user generated content (UGC) sessions](https://docs.google.com/forms/d/e/1FAIpQLSf9PSEMkxdlYQnAmDcXvsqeeXe-O1kRECZopG9nmwfn_O5qgA/viewform), the 10.1 release, and our final party can all be viewed in one place.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/95FuYdcziLQ\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\n## Schedule\n\nWe'll likely make some changes to this schedule as we close in on kickoff, so please keep in mind it's a WIP!\n\n#### [Thursday, October 19](https://www.youtube.com/watch?v=3EegHi0fdPQ)\n\nWatch Thursday's live stream [here](https://www.youtube.com/watch?v=3EegHi0fdPQ)\n\n* 10am-6pm UTC - Arrivals and getting to know GitLab team-members\n\n#### [Friday, October 20](https://www.youtube.com/watch?v=AopRnEbvgzE)\n\nWatch Friday's live stream [here](https://youtu.be/AopRnEbvgzE)\n\n* 7am UTC - Welcome & keynote with GitLab CEO Sid Sijbrandij ([@sytses](https://twitter.com/sytses))\n* 8am UTC - AMA with GitLab CEO Sid Sijbrandij (chat your questions here or on Twitter using #GitLabSummit)\n* 9am UTC - Eat lunch with us!\n* 10am UTC - Join us live for our Amazing Race challenge\n* 12pm UTC - How GitLab Started keynote with CTO & Co-founder Dmitriy Zaporozhets ([@dzaporozhets](https://twitter.com/dzaporozhets);chat your questions on YouTube or on Twitter using #GitLabSummit)\n* 1:15pm UTC - Award Ceremony and Happy Hour\n* 3pm UTC - GitLab BBQ\n\n#### Saturday, October 21\n\n**Due to WIFI issues, we were not able to live stream Saturday's events. However,\nwe'll be showing re-runs and highlight footage during [Sunday's stream](https://www.youtube.com/watch?v=95FuYdcziLQ).**\n\n* 4am - 5pm UTC Day trip to Santorini\n* 5:15 pm UTC - Join us for dinner and hallway conversations\n\n#### [Sunday, October 22](https://www.youtube.com/watch?v=95FuYdcziLQ)\n* 6-7am UTC - AMAs - Send us your questions ahead of time on Twitter with #GitLabSummit\n * 6-6:15am Mark Pundsack (@MarkPundsack), Head of Product\n * 6:15-6:30am Barbie Graver (@BarbieGraver), Chief Culture Officer\n * 6:30-6:45am Sarrah Vesselov (@SVesselov), UX Lead\n* 7am UTC - Chat with our developers and engineers as they release GitLab 10.1\n* 9am-3pm UTC - Day trip to Heraklion\n\n#### [Monday, October 23](https://www.youtube.com/watch?v=7r9mo-QwBbM)\n\n[Vote for the UGC Sessions you want to see on the live stream!](https://docs.google.com/forms/d/e/1FAIpQLSf9PSEMkxdlYQnAmDcXvsqeeXe-O1kRECZopG9nmwfn_O5qgA/viewform)\n\n* 6-11am UTC - Send us your questions to have them answered live\n* 11am UTC - UGC Session 1\n* 12pm UTC - UGC Session 2\n* 1pm UTC - UGC Session 3\n* 2pm UTC - UGC Session 4\n* 3pm UTC - Join us for dinner\n* 5pm UTC - Join us for Game Night and a Gitter AMA\n\n#### [Tuesday, October 24](https://www.youtube.com/watch?v=LRpkLBWA_sI)\n\n[Vote for the UGC Sessions you want to see on the live stream!](https://docs.google.com/forms/d/e/1FAIpQLSf9PSEMkxdlYQnAmDcXvsqeeXe-O1kRECZopG9nmwfn_O5qgA/viewform)\n\n* 6-11am UTC Send us your questions to have them answered live\n* 11am UTC - UGC Session 1\n* 12pm UTC - UGC Session 2\n* 1pm UTC - UGC Session 3\n* 2pm UTC - UGC Session 4\n* 3pm UTC - Join us for dinner\n* 5pm UTC - Join the Toga Party!\n\n## Get involved\n\nWe want to see you there! [Tweet us](https://twitter.com/gitlab) using #GitLabSummit to let us know your questions and comments. We'll be giving away limited edition swag to people who chime in and ask questions on social, and we'll also poll you to ask which UGC sessions you want live streamed. We're so excited to share the Summit with our community for the first time, and we hope you'll join us!\n\nRead more about our company values in our [open source](/blog/our-handbook-is-open-source-heres-why/) [handbook](https://handbook.gitlab.com/handbook/values/), licensed by [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/).\n",[9,683],{"slug":2379,"featured":6,"template":687},"watch-the-gitlab-summit-from-your-desk","content:en-us:blog:watch-the-gitlab-summit-from-your-desk.yml","Watch The Gitlab Summit From Your Desk","en-us/blog/watch-the-gitlab-summit-from-your-desk.yml","en-us/blog/watch-the-gitlab-summit-from-your-desk",{"_path":2385,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2386,"content":2392,"config":2397,"_id":2399,"_type":14,"title":2400,"_source":16,"_file":2401,"_stem":2402,"_extension":19},"/en-us/blog/whats-in-your-backpack",{"title":2387,"description":2388,"ogTitle":2387,"ogDescription":2388,"noIndex":6,"ogImage":2389,"ogUrl":2390,"ogSiteName":673,"ogType":674,"canonicalUrls":2390,"schema":2391},"GitLab's top tools for remote workers","GitLab team members open their backpacks to share their top tools for remote work.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678459/Blog/Hero%20Images/darren_backpack_iceland.jpg","https://about.gitlab.com/blog/whats-in-your-backpack","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's top tools for remote workers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-10-10\",\n      }",{"title":2387,"description":2388,"authors":2393,"heroImage":2389,"date":2394,"body":2395,"category":705,"tags":2396},[812],"2019-10-10","\n_At GitLab, our team doesn’t wake up at the same time and commute the same routes to sit in the same office. In fact, some of our team members don’t have an office at all! As a globally distributed company with an all-remote workforce, we have an exceptionally diverse set of team members spread over multiple continents. In other words, we're uniquely positioned to identify the top tools for remote workers. In this series, we explore how GitLab team members use the autonomy our company affords them to create workspaces that suit their lifestyle and cater to their hierarchy of needs, whether that involves creating a cozy home office space or diving into the unknown by working while traveling. See how we make it work by reading [part 1](/blog/not-everyone-has-a-home-office/) and [part 2](/blog/how-to-push-code-from-a-hammock/) of our remote work series._\n\nWhen you’re working far from home sometimes you wind up at a sleek coworking space and other times you land in the – literal – middle of nowhere. GitLab team members that work from the road will tell you that while leaning into adventure is a rush, it’s best to come prepared.\n\n![Middle of Nowhere](https://about.gitlab.com/images/blogimages/backpack/nowhere.jpg){: .shadow.small.center}\nKerri Miller is fond of exploring small quirky towns by motorcycle, but every once in a while she ends up someplace she'd never expected.\n{: .note.text-center}\n\n“I’m always re-evaluating what I bring, and every trip involves experimenting with some new piece of gear or different approach to the routine,\" says [Kerri Miller](/company/team/#kerrizor), Create backend engineer at GitLab. Kerri lives in Seattle, Washington but spends almost half the year adventuring across North America on her motorcycle.\n\n“I have a bit more leeway than most travelers, since I’m not limited to just a backpack or a single piece of luggage, but I do have to carry quite a bit of other gear to support the motorcycle – tools, spare tubes for the tires, rain gear, camping gear, etc. – so space and weight are still a premium,\" says Kerri. \"I take a lot of inspiration from the ultralight backpackers and the ‘1 bag’ traveler.\"\n\n## Favorite remote work backpacks\n\nLet’s face it: The backpack or bag itself is critical to the digital nomad experience. The type of bag you require will vary in texture, size, and durability depending upon where and under what conditions you’re traveling, how much you’re packing, and whether you’re prioritizing sturdiness or style – but truly, why compromise on either?\n\nJust like Kerri, professional services engineer [Mike Lindsay](/company/team/#mlindsay) enjoys hitting the open road by motorcycle.\n\n“I road warrior it up to customer engagements probably once a month,\" says Mike. “The bag is a Swiss Army backpack, I love it. It opens up like a clam shell, so you can expose the laptop without actually taking it out. The back **AND** the bottom are padded, so my laptop doesn't take any hard knocks, even when dropping it on the ground. The big non-laptop pockets usually get whatever reading material or swag I'm taking with me.\"\n\n[Justin Boyson](/company/team/#jboyson), frontend engineer for Create:Source Code, uses a roll-top waterproof[ Kriega](https://kriega.us/us10) bag, which, incidentally, is a favorite of many motorcyclists: “It's awesome because it looks cool and is completely rainproof,\" Justin says.\n\n[Taylor Medlin](/company/team/#tmedlin), solutions architect, Americas, uses the [Topo Designs Rover Pack](https://topodesigns.com/collections/laptop-bags/products/rover-pack?variant=12789839953973), which is locally crafted in her home state of Colorado and has bright colors for a fun, retro vibe.\n\n[Jackie Gragnola](/company/team/#jgragnola), marketing programs manager at GitLab, is based in San Francisco, California but seems to always be on the move from one city to the next. She can fit most everything she needs inside her go-to purse, which she bought while abroad in Lima, Peru.\n\n![What's in your purse](https://about.gitlab.com/images/blogimages/backpack/whats-in-your-purse.jpg){: .shadow.small.center}\nSometimes you stumble upon the perfect purse at your neighborhood boutique or a big box store. Othertimes, you find it in Peru.\n{: .note.text-center}\n\nIf Jackie needs to bring along more than her usual set-up, she’ll use her backpack of choice: The [Nomatic day backpack](https://www.nomatic.com/products/the-nomatic-backpack).\n\n“It can be locked and attached to a table and is great if working out of a coffee shop,\" Jackie says. \"It has lots of compartments and is perfect for safety and security while traveling.\"\n\n## GitLab: Tools for remote workers unpacked\n\nIn order to effectively work from anywhere, the remote worker really only needs four things: a backpack or bag of sorts, a laptop, WiFi, and power. While the rest of the things in your backpack might be non-essentials in terms of work, being uncomfortable or less effective for the sole reason of traveling light is not always the best way to go. GitLab team members unpacked their bags to show us the equipment they use to set up a satellite workspace from just about anywhere.\n\nMike gave us a tour inside his beloved Swiss Army backpack.\n\n![Swiss Army Backpack](https://about.gitlab.com/images/blogimages/backpack/mike.jpg){: .shadow.small.center}\nMike Lindsay's backpack is durable and can withstand the elements on the back of his motorcycle.\n{: .note.text-center}\n\n*   **Top pocket**: Network cable, dual port USB charger with squid cable (in case I make friends!), extra thumb drives, wired earphones (maybe earbuds are dead, or inflight screen can use them).\n*   **Left side pocket**: battery backup, bandaids, glasses cleaner and cloth, toothpaste.\n*   **Right side pocket**: Spare Mac power brick with extension cable adapter.\n*   **Lower middle pocket**: Bag of geek stickers, snap on key ring, pens, Mac USB-C adapter.\n\nThe bright colors of Taylor's Topo Designs backpack are matched by its brightly colored contents.\n\n\"I use the black notebook for GitLab-specific notes and an orange notebook for daily planning,\" she says. \"GitLab stickers, peppermint chapstick, lipstick, USB-C adaptor, [Thread wallet](https://www.threadwallets.com/), [Apple Pencil](https://www.apple.com/apple-pencil/), [iPad Pro](https://www.apple.com/ipad-pro/), [Apple Magic trackpad](https://www.apple.com/shop/product/MRMF2LL/A/magic-trackpad-2-space-gray), MacBook Pro, Nalgene bottle.\"\n\n![Topo Designs Backpack](https://about.gitlab.com/images/blogimages/backpack/taylor.jpg){: .shadow.small.center}\nInside Taylor's colorful backpack we find something that isn't mentioned by any other GitLab team members: pen and paper!\n{: .note.text-center}\n\nKerri has a few necessities to make engineering from the road a little less hectic than it might otherwise be with just a laptop and charger.\n\n“I always travel with a small power strip that has 3 AC plugs and 3 USB ports, and a short 8\" cable. This is essential for charging all my devices and accessories without hogging all the plugs!\" says Kerri. She also brings a compact mechanical keyboard. “Most laptop keyboards I find not only fatiguing, but their delicate keys don’t always hold up to the demands of a nomad traveler,\" she explains.\n\n![Kerri and her motorcycle](https://about.gitlab.com/images/blogimages/backpack/kerri.jpg){: .shadow.small.center}\nKerri working on GitLab from the back of her motorcycle.\n{: .note.text-center}\n\n“I get stopped in coffee shops and coworking spaces all the time about my setup,\" says Jackie. “It’s not great for productivity, but if I was making a commission from these convos this would be a solid side gig.\"\n\n![Jackie's workplace setup](https://about.gitlab.com/images/blogimages/backpack/dual-screen-setup.jpg){: .shadow.small.center}\nJackie's dual screen setup in Valencia, Spain.\n{: .note.text-center}\n\nTo set-up her typical workplace, Jackie uses:\n\n*   [Roost stand](https://www.therooststand.com/)\n*   [Anker bluetooth keyboard](https://www.anker.com/products/variant/anker-bluetooth-ultraslim-keyboard/A7726111)\n*   [Apple magic mouse](https://www.apple.com/shop/product/MRME2LL/A/magic-mouse-2-space-gray)\n*   [Asus external monitor 169B+](https://www.asus.com/us/Monitors/MB169BPlus/HelpDesk_Download/)\n*   [Apple airpods](https://www.apple.com/airpods/)\n*   Backup wired earpods if needed\n\n[Erich Wegscheider](/company/team/#ewegscheider), talent operations specialist at GitLab, is [currently in Bali on a coworking adventure with WiFi Tribe](/blog/not-all-remote-is-created-equal/). Like Jackie, Erich uses the Apple magic mouse 2, and also the [Apple magic keyboard](https://www.apple.com/shop/product/MLA22LL/A/magic-keyboard-us-english), along with universal power adapters and a power bank in case the power goes out.\n\nErich also brought a laptop stand with him on his journey. He says the [Tiny Tower Laptop Stand](https://tinytowerstand.com) is “key to helping maintain a healthy posture while working _without_ a proper monitor.\" Sadly, not everything fits comfortably in a backpack.\n\n![Bali workspace](https://about.gitlab.com/images/blogimages/baliworkspace.png){: .shadow.small.center}\nErich managed to configure an ergonomic workspace in Bali.\n{: .note.text-center}\n\nPeople experience associate at GitLab, Caroline, is working as she explores Europe, and if there is one thing that she always, without fail, has in her backpack, it’s power adapters.\n\n\"Call it paranoia but I always pack US, UK, and EU extra adapters/converters,\" says Caroline. There is a background story here. Caroline, who lives in Kenya, traveled to South Africa for the first time last year to meet up with some GitLab colleagues.\n\n\"I got to my room in South Africa five minutes before a meeting only for the outlets to look totally alien to me,\" she says. \"I didn't know they were the **only country in the world** that used such plugs and needless to say, I missed the meeting.\"\n\nShe also has an extra phone with her so she can easily create a WiFi hotspot.\n\n## GitLab’s roadtrip essentials\n\nIt’s not _quite_ the same as working out of a backpack, but GitLab product manager Nicole Schwartz has been on a months-long roadtrip across the United States, living out of a suitcase and the trunk of her car as she visits friends, GitLab team members, and speaks at conferences along the way.\n\nLike Caroline, Nicole also has an extra phone for WiFi tethering and also recommends a nice set of noise-cancelling headphones (a must-have even if you’re working at home!), a portable mouse and mousepad, extension cord and powerstrip, and, if you have room, a USB monitor which is great for when you can work from a hotel room.\n\n“Download podcasts and YouTube videos to listen to on the drive since the radio will cut in and out and you might as well be productive,\" Nicole says.\n\nSince GitLab is a global, asynchronous team, most team meetings are recorded and uploaded to our [GitLab Unfiltered channel on YouTube](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A), and a few teams even use the [audio from meetings to create podcasts](/blog/how-we-turned-40-person-meeting-into-a-podcast/) to make it easy to stay up-to-date on what’s happening.\n\nNicole has a few recommendations for anyone considering working and traveling for an extended period of time, including packing laundry detergent (she uses TidePods) and having dollars and quarters on-hand to pay bridge and road tolls (and also feed washers and dryers).\n\n## Outreach, from your backpack\n\nThere are so many perks that come with working at GitLab: The fact that we are family-first not just in principle, but in practice; the personal and professional autonomy our company affords us; unlimited PTO and being encouraged to _actually use it_; and of course, the fact that we are all remote. But at the end of the day, the best brand ambassadors are all of us.\n\nInside his rolltop, rain-proof Kriega backpack, Justin brings a laptop and charger, as well as “backup wired earbuds, because airpods don't last forever. Oh, and a bag of GitLab stickers!\"\n\n![Stickers](https://about.gitlab.com/images/blogimages/backpack/justin.jpg){: .shadow.small.center}\nNo backpack is fully packed without GitLab swag.\n{: .note.text-center}\n\nJustin is certainly not the only GitLab team member who carries stickers in his backpack. You may have noticed in our photos that, like laptop stands and bluetooth headphones, GitLab stickers and other treats often come along with our team members, whether they're just stopping in their neighborhood coffee shop or traveling thousands of miles from home.\n\n“It isn’t a work essential per se, but I also try to have a stash of stickers, and some kind of snack treats from Seattle – small packs of salmon, bonbons from a local manufacturer, or small sample packs of coffee from a local roaster,\" says Kerri. “I’ll try to gift these to the folks who help me out on the road, who give me directions, provide a place to stay, or to cafe managers who turn a blind eye to me staying in one place for several hours.\"\n\n**More tips for productive remote working:**\n\n[5 remote work best practices](/blog/mastering-the-all-remote-environment/)\n[Tried and true remote work productivity hacks](/blog/how-to-build-a-more-productive-remote-team/)\n[Be the boss of your video call](/blog/tips-for-mastering-video-calls/)\n\nCover image by Darren Murph\n{: .note}\n",[9,683],{"slug":2398,"featured":6,"template":687},"whats-in-your-backpack","content:en-us:blog:whats-in-your-backpack.yml","Whats In Your Backpack","en-us/blog/whats-in-your-backpack.yml","en-us/blog/whats-in-your-backpack",{"_path":2404,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2405,"content":2411,"config":2418,"_id":2420,"_type":14,"title":2421,"_source":16,"_file":2422,"_stem":2423,"_extension":19},"/en-us/blog/whiteboarding-remote-work-superpower",{"title":2406,"description":2407,"ogTitle":2406,"ogDescription":2407,"noIndex":6,"ogImage":2408,"ogUrl":2409,"ogSiteName":673,"ogType":674,"canonicalUrls":2409,"schema":2410},"Virtual whiteboarding is a remote work super power","Want to master a collective understanding of technical explanations remotely? Learn how to use virtual whiteboards to their maximum capabilities in this tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682431/Blog/Hero%20Images/kvalifik-5Q07sS54D0Q-unsplash.jpg","https://about.gitlab.com/blog/whiteboarding-remote-work-superpower","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Virtual whiteboarding is a remote work super power\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2022-09-01\",\n      }",{"title":2406,"description":2407,"authors":2412,"heroImage":2408,"date":2414,"body":2415,"category":940,"tags":2416},[2413],"Darwin Sanoy","2022-09-01","\n\nAt one point in my career I had a solo business in technology training. During this time, I went through a transition from live, in-person classes to live-delivered virtual classes. One of the things that I dearly missed in virtual delivery was unpacking explanations through whiteboarding. The difference in the speed and completeness of achieving common understanding across the group was very evident by the nature of the questions and discussions that occured immediately afterward. \n\nAt that time, it was difficult to find solutions that enabled me to do this as fluidly as an in-person classroom experience. I persisted and came up with an elaborate solution involving software and hardware – but the results of a fluid whiteboarding experience for both presenter and participants were preserved.\n\n## Explaining and collaborating through drawings\n\n“[The Back of the Napkin: Solving Problems and Selling Ideas with Pictures](https://www.penguinrandomhouse.com/books/300247/the-back-of-the-napkin-expanded-edition-by-dan-roam/)” is a great book on the topic of leveraging drawing in business meetings. The title contains two main themes. “Selling Ideas” is about explaining something you already understand in a highly effective way that creates shared understanding. “Solving Problems” is a very different mode, that of collaborating to create a new visual model that documents the structure of a problem or envisions a new solution. While there are variations on these two themes, these appear to be two most fundamental modes of using drawing in a group context.\n\n## The importance of progressive disclosure in understanding technical explanations \n\nTechnical explanation is challenging on its own - but the situation is made much worse by presenting complex visuals fully formed. Using a whiteboard for the same explanation leverages the progressive disclosure element of storytelling and overlays it on a technical visualization. This has a fundamental effect of enhancing understanding because when a complex visual appears completely formed, the visual cortex hijacks all neurological attention resources (including listening) as it attempts to make sense of the scene. Progressive disclosure allows the minds of listeners to focus on the verbal explanation because only the component being described is visible. As the narrator reveals the next chunk by drawing while explaining the relationship to the last chunk, the audience naturally shifts their full attention.\n\nYou could think of this effect as being the same as what a cartoon strip does to create a sense of progressive disclosure. By simply framing the scenes, our mind automatically focuses on one frame at a time in the intended sequence. The difference with technical explanations is that the final view is extremely informative without frames - it paints a global picture of the sum of the parts.\n\nThe magic of infographics is also the enforcement of progressive disclosure on their topic matter by purposely creating a visual so long that it must be scrolled. Frequently they are also organized around a natural or contrived timeline that the disclosure of the component parts progresses through. They frequently also create frames through visual effects such as lines, shapes, and whitespace.\n\nTechnical visualizations frequently have the characteristic that a big-picture visual is very valuable for complete understanding. Progressive disclosure resolves the contradictory requirements for both a “parts-level understanding” and a “big-picture understanding” of a technical design visualization. This is accomplished by layering up the big picture through many bite-sized explanations - exactly like how the mind's eye creates the world of a story when it is narrated in a sequence of small parts.\n\nWhiteboarding, by nature, can only be done as progressive disclosure and, in doing so, it transforms technical explanation into much more digestible and memorable frames for the audience to consume.\n\n## Maintaining a common understanding of the composite vision\n\nIn order to have the best chance to foster a \"group creative flow,\" everyone who is collaborating needs to maintain a common understanding of the composite vision as rapidly emerging ideas and insights are iteratively worked in. Whiteboarding fulfills this need in a way that is not distracting to the effort because a visualization of the vision is maintained in real-time during collaboration.\n\nFrequently group insights compound on each other as ideas are expanded by building on idea expressed by someone else in the group. Whiteboarding provides a real-time composite visualization which accelerates more new and valuable insights. Drawing frequently enables collaborators to draw things they can't find the words for at the moment. If the conditions are right, there is the potential for a snowball effect of synergistic ideas being incorporated into the composite whole.\n\nThis is where the need for the mechanism for holding the common understanding needs to be fluid and non-distracting.\n\n## Solutions architecture requires both technical explanation and collaboration\n\nIn my job as a Solutions Architect, it turns out that explanation of technical visuals and collaboration in creating technical designs are critical to making helpful contributions to colleagues, customers, and partners.\n\nIt is truly amazing how much more quickly a group of people can get on the same page and innovate when whiteboarding is available.\n\nWhen there are language barriers, it takes on an even higher value as visuals are not dependent on language and can help store the real-time common understanding between different language speakers. Multiple times, I’ve found that speakers who are working through a translator get excited and are emboldened to start talking in English (my native tongue). Generally, the technical terms are recognized in any language and adding them to the diagram fuels more mutual understanding.\n\nWhen I came to GitLab as a Solutions Architect, I, once again, began to experiment with ways to make fluid whiteboarding easy to do in any meeting.\n\n## Better than real whiteboards for in-person meetings\n\nOccasionally, when working hard for one objective, you accidentally achieve some objectives you didn’t even know you should or could have. This is known as serendipity.\n\nThis is what has happened in my pursuit of very fluid virtual whiteboarding. I found virtual whiteboarding handles a lot of logistics and practical considerations for whiteboarding for in-person meetings such as:\n\n* Verifying availability of whiteboards at a meeting venue\n* Simultaneous whiteboards and computer projection visibility (I’ve been in rooms where you had to stop projecting use the whiteboard)\n* You don’t even need a projector if you do an in-person virtual meeting to share your screen\n* Marker management - smell, mess, dried-out markers\n* The inability to preserve every whiteboard that you draw due to needing to erase for the next one\n* The inability to electronically store or share the visuals\n\n## The challenges of hardware and software selection\n\nI wish I could honestly say the process of putting together a fluid virtual whiteboard setup is now easy but I have not found that to be the case.\n\n### Mental flow requires fluid technology\n\nWhether explaining or collaborating the concept of mental flow is very critical. If the need for flow is interrupted by things that should be transparent, it is frustrating for everyone and the audience quickly loses attention. It interrupts the thoughts of both the whiteboarder and the participants.\n\nThink of the times that someone starts whiteboarding and the one and only marker goes dry and they have to hunt for one. Virtual whiteboarding can actually make the problem of interrupting flow much worse. This is because if there are delays in the hardware or software, the shape of what you are drawing gets incorrectly “smoothed”. \n\nA lack of fluidity will generally make your shapes challenging to draw and then you slow down to allow the system to recognize your strokes and, well, it’s not fluid anymore - it’s distracting and effortful. And the rending of shapes aren’t the worst of it, when trying to add text to label diagram parts, lack of fluidity causes the smaller strokes of text to be unrecognizable. A lack of fluid drawing completely kills the presenters desire to use drawing and the audiences desire to listen to the pictures.\n\n### Fluidity of the drawing activity\n\nIn trying to devise a cost-effective, yet fluid, setup I’ve tried all the shortcuts - such as using capacitive touchscreens with a stylus and using web apps as the primary whiteboarding software. Both of these are deal breakers for me because after trying many instances on these two options, they just never work out to have sufficient fluidity. \n\nSo here are the constraints I ended up adopting to make drawing itself very fluid:\n\n* **Use an iOS or Android mobile platform tablet** - as it has the following advantages:\n    * Native mobile apps are much, much more fluid than web apps.\n    * Many more native software options than there are for laptops.\n    * More modular and cheaper hardware in the long run than attempting to gain these capabilities in a laptop or desktop.\n* **Must support active pen technology** - capacitive touchscreens, even with a stylus, don’t cut it. When working rapidly, the smoothing algorithms aren’t very smooth - this makes drawing shapes difficult, but more importantly it makes writing words especially difficult.\n* **Having a stylus that is the correct length and thickness** is important for fluid writing and drawing. The stylus that comes with tablets is frequently not the conventional length or thickness of real pens or pencils.\n\n### Fluidity of integrating the act of drawing into virtual meetings\n\nUsing drawing needs to be easy for the meeting host and for the participants.\n\n* For easy virtual sharing, it helps if the native app also has a collaborative web app that updates quickly as it avoids the complications of joining the tablet to the meeting and sharing from there. \n* This enables other meeting participants to whiteboard on the same virtual whiteboard without specialized hardware.\n* Some systems allow guests to join and whiteboard without having to setup an account.\n\n### Fluidity of availability of whiteboarding across teams\n\nThere are multiple elements of what will ensure fluid whiteboarding is available to everyone for collaborations. A primary one is cost, followed by local device availability of active pen tablet options in international markets. Thankfully, the applications covered later support both iOS and Android which helps in finding affordable and locally available options.\n\n* Cost\n* Mobile apps tend to be more likely to be available for both major mobile operating systems compared to a native desktop-only solution being available on multiple desktop platforms\n* Mobile platform flexibility and global cost and availability compared to pursuing laptops with the same capability\n\n## A working example setup\n\n![](https://about.gitlab.com/images/blogimages/virtualwhiteboarding/whiteboarding-setup-samsung8.jpg)\n\n### Tablet\n\n* My first tablet was a [Samsung Galaxy Tab A 8.0 with Spen (SM-P200)](https://www.amazon.com/gp/product/B07TS2N27S/) that cost me USD $235. It is actually an international edition as the US market does not seem to offer an active pen tablet in the 8” format. In this case, the stylus fits inside the tablet so is really not appropriate for fluid drawing and writing. \n* Since my first purchase, Samsung has come out with a less expensive line of large tablets with active pen technology, so I now also have the [Samsung Galaxy Tab S6 Lite 10.4 inch (SM-P610NZBAXAR)](https://www.amazon.com/SAMSUNG-Android-Included-Speakers-SM-P610NZBAXAR/dp/B086Z3S3MY/), which I obtained for USD $250. While the stylus in this unit is considered more full-sized, the thickness, feel, forefinger button and length all cause me to reach for my after-market stylus for the most fluid experience.\n\n### Stylus\n\n* For a stylus, I use the [STAEDTLER 180 Noris digital classic EMR Stylus](https://www.amazon.com/STAEDTLER-22-1-digital-compatibility-purchase/dp/B0728HBD7F). I find the length, weight, and lack of buttons all helpful in handling drawing and writing smoothly. The color makes it a little less easy to lose. The downsides include that there are very few tablet cases that can accommodate it and that it looks so much like a pencil that someone in your household may accidentally toss it in the regular pen jar. Always be sure to verify stylus compatibility with your device's active pen technology.\n\n### Settings\n\nI almost returned the 10” tablet due to a behavior that a couple settings fixed. Android tablets with no physical buttons put a navigation bar on the bottom part of the screen. I found that I was having my palm be picked up by the Home Screen button, which would close the whiteboarding app. Also, when any of these buttons are activated by the stylus, it is equally disruptive to the flow. For the Navigation Bar settings, I set “Navigation type” to “Swipe gestures” and I enable “Block gestures with S Pen” (Android 12, Samsung OneUI v4.1).\n\n### Collaborative whiteboard options\n\nThere are multiple options for the collaborative whiteboard options - some completely free and paid options that carry enough value-add features to consider it for heavy users.\n\n\n\u003Ctable>\n  \u003Ctr>\n   \u003Ctd>\n   \u003C/td>\n   \u003Ctd>\u003Ca href=\"https://www.liveboard.online\">Liveboard Online\u003C/a>\n   \u003C/td>\n   \u003Ctd>\u003Ca href=\"https://support.google.com/jamboard/answer/7424836?hl=en\">Google Jamboard\u003C/a>\n   \u003C/td>\n   \u003Ctd>\u003Ca href=\"https://miro.com\">Miro\u003C/a>\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Long Term Usage of Free Tier\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>No - Only 3 Boards\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Native Mobile Apps\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Native Desktop Apps\n   \u003C/td>\n   \u003Ctd>No\n   \u003C/td>\n   \u003Ctd>No\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Web App (for screen sharing)\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Fluidity Extras\n   \u003C/td>\n   \u003Ctd>\n   \u003C/td>\n   \u003Ctd>\n   \u003C/td>\n   \u003Ctd>Multiple pens on deck\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Pages / Canvas\n   \u003C/td>\n   \u003Ctd>Pages\n   \u003C/td>\n   \u003Ctd>Pages\n   \u003C/td>\n   \u003Ctd>Endless Canvas\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Presentation Mode\n   \u003C/td>\n   \u003Ctd>No\n   \u003C/td>\n   \u003Ctd>No\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Direct Import From Google Slides\n   \u003C/td>\n   \u003Ctd>No\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>No\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Shape Recognition from hand drawing\n   \u003C/td>\n   \u003Ctd>Light Duty\n   \u003C/td>\n   \u003Ctd>Light Duty\n   \u003C/td>\n   \u003Ctd>Awesome\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Reusability of Drawing as Formal Technical Diagrams\n   \u003C/td>\n   \u003Ctd>No\n   \u003C/td>\n   \u003Ctd>No\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>Viewers Synchronized To Drawing Location\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>Yes\n   \u003C/td>\n   \u003Ctd>Manual\n   \u003C/td>\n  \u003C/tr>\n\u003C/table>\n\nSee here for more [GitLab remote work whiteboarding information](/company/culture/all-remote/collaboration-and-whiteboarding/).\n\nPhoto by [Kvalifik](https://unsplash.com/@kvalifik?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/whiteboard?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[2417,731,9],"solutions architecture",{"slug":2419,"featured":6,"template":687},"whiteboarding-remote-work-superpower","content:en-us:blog:whiteboarding-remote-work-superpower.yml","Whiteboarding Remote Work Superpower","en-us/blog/whiteboarding-remote-work-superpower.yml","en-us/blog/whiteboarding-remote-work-superpower",{"_path":2425,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2426,"content":2432,"config":2438,"_id":2440,"_type":14,"title":2441,"_source":16,"_file":2442,"_stem":2443,"_extension":19},"/en-us/blog/why-we-pay-local-rates",{"title":2427,"description":2428,"ogTitle":2427,"ogDescription":2428,"noIndex":6,"ogImage":2429,"ogUrl":2430,"ogSiteName":673,"ogType":674,"canonicalUrls":2430,"schema":2431},"Why GitLab pays local rates","Our compensation structure is known to spark controversy, so we want to give an update on our latest iteration on team member salaries.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680461/Blog/Hero%20Images/local-rates.jpg","https://about.gitlab.com/blog/why-we-pay-local-rates","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why GitLab pays local rates\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n        \"datePublished\": \"2019-02-28\",\n      }",{"title":2427,"description":2428,"authors":2433,"heroImage":2429,"date":2435,"body":2436,"category":705,"tags":2437},[2434],"Aricka Flowers","2019-02-28","\n\nOur [compensation calculator](/handbook/total-rewards/compensation/compensation-calculator/) is a regular [hot topic on places like Hacker News](https://news.ycombinator.com/item?id=18441768#18443167) – pretty much any thread about GitLab has a comment about us paying local rates. As with everything GitLab does, we continue to [iterate](https://handbook.gitlab.com/handbook/values/#iteration) on our compensation model, and implemented a number of changes at the start of 2019. In addition to adjusting the salaries of backend developers, which were [raised considerably](https://gitlab.com/gitlab-com/www-gitlab-com/commit/9382348c3c81b92b598b0a6da0994d387bdfc404) so that we are [\"at or above market,\"](/handbook/total-rewards/compensation/#competitive-rate) according to GitLab CEO [Sid Sijbrandij](/company/team/#sytses), the location factor was also revised to better reflect the respective areas covered.\n\nBut first, let's take a step back to see how we got to here.\n\n### Why did GitLab start paying team members according to location in the first place?\n\n\"It’s something that kind of happened organically,\" Sid says. \"Every time we hired someone, we’d discuss what a reasonable compensation would be. And many times, it came back to what they were making beforehand, and that really depended a lot on where they were. So we kind of started out having local market salaries as we grew. At a certain point, we said, 'Okay, this is apparently the standard. We’re basing it not just on your function and the seniority you have in the function, but also where you live.'\"\n\nGitLab no longer uses salary history as a factor in compensation offers and does not ask candidates about their previous pay. Instead, we ask all candidates, regardless of location, for their salary expectations.\n\n### Understanding the rent index\n\nThe compensation calculator's rent index came from a noted correlation between the aforementioned local market rate salaries and rent prices in the area. Using limited data sets with more than 100 locations across the globe, an analysis was run to determine the best gauge for local rates. The rent as listed on Numbeo was found to have the highest correlation.\n\n\"When you think about it, the correlation we found made sense,\" Sid explains. \"If there’s a place where people pay high wages, it tends to attract people. And then the rents, almost by force of nature, start rising. It’s not that we want to pay you based on your rent or compensate your cost of living. We want to make sure that we pay at or above market. We found that the rent was a great way to calculate that, and it’s why there’s a rent index as part of our global compensation formula.\"\n\n### New improvements on local market calculations\n\nGitLab compensation is calculated by delving into [local market data, when possible](/handbook/total-rewards/compensation/compensation-calculator/#location-factor), to ensure that [salaries are being tabulated](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/17460) fairly.\n\n\"Instead of using [just the rate index], what we do now is look at a number of different sources, usually four or five, to get market data for a city,\" says GitLab's outgoing Chief Culture Officer [Barbie Brewer](/company/team/#BarbieJBrewer). \"Then we find the median of that, and use it as our benchmark. That being said, you can't do this in all cities. We have a lot of employees in jobs that aren't typically available where they are located. In those instances, we fall back on the other equation. Generally speaking, it's pretty close. When we've had to go back and check those benchmarks, we found that it required very few adjustments. We were getting it right 95 percent of the time, so doing that check was good. It helped us understand that we were not that far off.\"\n\nBarbie also noted that some employees in low-income communities could fare better than expected because people in towns within 90 minutes of a large city will have their salaries calculated according to the higher metropolitan factor.\n\nNow that we know how GitLab got started with local rates, here's a look at why we have continued down this path.\n\n### Standard pay eats away at production and personnel\n\nIf everyone is paid the same role-based salary, the company would not be able to hire as many team members, and those that are brought on would not be as widely distributed, according to Sid. Ultimately, this approach would cut away at GitLab's ability to produce as well as be geographically diverse, he argues.\n\n\"If we pay everyone the San Francisco wage for their respective roles, our compensation costs would increase greatly, and we would be forced to hire a lot fewer people. Then we wouldn’t be able to produce as much as we would like,\" Sid explains. \"And if we started paying everyone the lowest rate possible, we would not be able to retain the people we want to keep.\n\n\"So you end up in a place where the compensation is somewhere in between. And that would cause us to have a concentration of team members in low-wage regions because it’s a better deal for them. They’re getting more than the market rate, so they’re more likely to apply and accept an offer. And they’re more likely to stay regardless of how happy they are, which is not healthy for them or the company.\"\n\n### Standard pay for all roles may not be as fair as it seems\n\nAnother problem with paying everyone the same salary, Sid says, comes down to how far a dollar goes in one place compared to another. If everyone is paid a standard salary, those who live in high-income areas would have less discretionary income when compared to their counterparts in lower-income communities. \n\nRemote companies using a standard pay structure are reportedly running into problems with their compensation plans. \n\n\"The most recent company I talked to has everybody getting paid the same, no matter where they're located. It's very, very different from GitLab, and it is causing problems for them,\" says Barbie. \"We have very strong communication with that company. They're hoping that we can help influence them to move away from paying everyone the same no matter their location. They're finding that it's extremely inequitable.\"\n\n### Closing the gap on local rates for distributed workers\n\nAs remote, or distributed, workplaces continue to take hold and grow across all industries, Sid hopes the location-based compensation gaps will narrow.\n\n\"I think the core difference is there’s people saying, 'Same work, same pay.' And there’s people like us saying we should be at market,\" Sid says. \"I hope the distance between those stances becomes smaller as more companies offer remote work opportunities. I think that’s the way to fix it – just make sure the market rates become higher and consistent.\n\n\"And that’s why we will be promoting remote work a lot. We have a great [page in our handbook about running an all-remote company](/company/culture/all-remote/). Hopefully, that is the way we will contribute to having people across the world get paid the same wages. We will track with that trend; but we won't be ahead of it or behind it. If you see what remote work is doing in a country like the Ukraine, it’s a great source of income for the people there. And I want to contribute to that.\"\n\nStill have questions or thoughts on GitLab's compensation structure? Sound off in the comments below (or on HN, inevitably 😁) or ping us on Twitter [@gitlab](https://twitter.com/gitlab).\n\n[Cover image](https://unsplash.com/photos/uCMKx2H1Y38) by [AbsolutVision](https://unsplash.com/@freegraphictoday) on Unsplash\n{: .note}\n",[708,683,9,684],{"slug":2439,"featured":6,"template":687},"why-we-pay-local-rates","content:en-us:blog:why-we-pay-local-rates.yml","Why We Pay Local Rates","en-us/blog/why-we-pay-local-rates.yml","en-us/blog/why-we-pay-local-rates",{"_path":2445,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2446,"content":2452,"config":2458,"_id":2460,"_type":14,"title":2461,"_source":16,"_file":2462,"_stem":2463,"_extension":19},"/en-us/blog/without-a-shadow-of-a-doubt",{"title":2447,"description":2448,"ogTitle":2447,"ogDescription":2448,"noIndex":6,"ogImage":2449,"ogUrl":2450,"ogSiteName":673,"ogType":674,"canonicalUrls":2450,"schema":2451},"Without a shadow of a doubt: Inside GitLab's CEO shadow program","Technical marketing manager Tye Davis did everything from joining investor meetings to battling with the flight simulator at GitLab Mission Control.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680653/Blog/Hero%20Images/sfbaybridge.jpg","https://about.gitlab.com/blog/without-a-shadow-of-a-doubt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Without a shadow of a doubt: Inside GitLab's CEO shadow program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tye Davis\"}],\n        \"datePublished\": \"2019-07-11\",\n      }",{"title":2447,"description":2448,"authors":2453,"heroImage":2449,"date":2455,"body":2456,"category":299,"tags":2457},[2454],"Tye Davis","2019-07-11","\n\nWalking up to the iconic Millennium tower on Monday, [I](/company/team/#TyeD19) was a bit nervous for my first day of the [GitLab CEO shadow program](/handbook/ceo/shadow/). Sometimes, our impression of the CEO is someone who is intimidating and strictly business; they only care about things work related. That persona often results from not having access to the CEO, and the fear that one mistake in their presence may cost your job. The GitLab CEO shadow program proved to be a pleasant departure from this mindset.\n\nEntering GitLab “Mission Control,” I was met with a large apartment turned into a hybrid boardroom with a touch of living space. This is a unique working environment because GitLab is an [all-remote](/company/culture/all-remote/) company that allows GitLab team members to work from their choice of location (home, coffee shop, [van](/blog/how-remote-work-at-gitlab-enables-location-independence/), shared workspaces, surfboard, etc.). So, although you are physically at \"Mission Control,\" most of the CEO shadow program is done via video conferencing. There is no need to go from physical meeting room to meeting room, you simply go from conference call to conference call (woo efficiency!). Six monitors add to the office-like feel of the living room, displaying (amazing) sales data, locations of team members in over 50+ countries, and the DevOps toolchain landscape that GitLab replaces. The boardroom also offers access to gaming systems, a [flight simulator](https://en.wikipedia.org/wiki/X-Plane_(simulator)) and readily available drinks and snacks. I was able to calm my excitement and I settle into the room with the fellow CEO shadow, [Mayank](/company/team/#mayanktahil).\n\n![Mission Control center](https://about.gitlab.com/images/blogimages/ceoshadow_graphs.jpg){: .shadow.medium.center}\nInside GitLab's \"Mission Control.\"\n{: .note.text-center}\n\n### Hitting the ground running\n\nMy first face-to-face meeting with CEO [Sid Sijbrandij](/company/team/#sytses) was on our first CEO-specific call of the day, a public live stream on \"Sid's three biggest remote work challenges\" with [Leo Widrich](https://twitter.com/leowid), co-founder of Buffer. This was the first ice breaker into the CEO shadow program and helped me understand just how inclusive the shadow program is. Sid really made us feel like we belonged on the call by incorporating us into the discussion. His inclusivity lowered my stress a few notches, and I began to understand what was to come in the next few weeks: [transparency](https://handbook.gitlab.com/handbook/values/#transparency).\n\nThe second meeting took the inclusivity of the program a step further, as we joined a group call with the executive team from across the GitLab organization (aka the [E-group](/company/team/structure/#e-group)). You might expect some hesitation in allowing someone who is not an executive to join a meeting where top-level matters are discussed, but the CEO shadow program was made exactly for these types of experiences. The program gives participants full visibility into every working part of building an enterprise company. There was no resistance from the E-group team and upon joining the meeting, I was met with an overwhelming ‘welcome’ to our working session. This alleviated most of my nervousness and truly showcased GitLab’s [collaboration value](https://handbook.gitlab.com/handbook/values/#collaboration) by displaying ‘no ego’ and ‘kindness’ from the executive team.\n\n### The feeling of welcomeness was constant\n\n There were very few circumstances where Mayank and I were not included in meetings due to the sensitivity of the subject. The most eye-opening experience for me was meeting with potential investors in GitLab that represent some of the largest and best-known investment firms in the world. These organizations discussed topics around GitLab’s vision and technology and the firms said they see the incredible upside of GitLab. If I was only able to attend one meeting during the whole program, I would choose this one. My confidence in the direction this company is taking has increased after seeing firsthand how much interest there is from investors in GitLab’s growth. Observing the amount of planning leading up to these meetings between Sid and [Paul, our CFO](/company/team/#pmachle) was a great learning experience. Investors are excited about the future of GitLab as a result of all of the hard work of every GitLab team member. My only disappointment is that the program is only two weeks long and that I won’t get to continue to be part of these developing relationships.\n\n![Shadowing the CEO](https://about.gitlab.com/images/blogimages/tyeshadowingceo.jpg){: .shadow.small.center}\nDoing my best impression of shadowing the CEO's activity in his everyday engagements\n{: .note.text-center}\n\n### Takeaways\n\nThe shadow program was an incredibly enlightening experience. Joining this program gave me an accurate and deeply intuitive understanding of the life of a CEO. Sid has mastered the high velocity of responsibility and full situational awareness that is needed to effectively lead our company as CEO. He also acknowledges that he always has room for improvement – so much so that he has a section of flaws that are listed on the GitLab [CEO handbook page](/handbook/ceo/#flaws). One big takeaway from the shadow program is listed on the CEO page. This is something I believe is the biggest factor to collaborate effectively is what Sid notes about his approach, “Not a flaw but something to know about me, I have [strong opinions weakly held](https://blog.codinghorror.com/strong-opinions-weakly-held/). Or, as someone said, I come in hot but am open to new evidence.” This is applicable across the company (and personally) as we all [iteratively](https://handbook.gitlab.com/handbook/values/#iteration) build a tool that best fits our customer needs, and we must be receptive of adjusting accordingly if new evidence corrects our product vision.\n\nBusiness aside, Sid has some pretty funny GitLab stories. If you ever get the chance to ask him about Burning Man, I promise it’ll be a good laugh. My time in the CEO shadow program was unique, educational, and inspirational. I am thankful for this opportunity and hope that one day I’ll reciprocate in a future exec role. Extra shout out to [Cheri](/company/team/#cheriholmes) who coordinates diligently so that all of us CEO shadows are set up for success. Looking back, the most stressful part of the CEO shadow program was the anxiety the X-Plane flight simulator brought when trying to land an airplane (the landing didn't go well).\n\nPhoto by [Landry Gapangwa](https://unsplash.com/@gapangwa91?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/@gapangwa91?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[683,684,9],{"slug":2459,"featured":6,"template":687},"without-a-shadow-of-a-doubt","content:en-us:blog:without-a-shadow-of-a-doubt.yml","Without A Shadow Of A Doubt","en-us/blog/without-a-shadow-of-a-doubt.yml","en-us/blog/without-a-shadow-of-a-doubt",{"_path":2465,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2466,"content":2472,"config":2477,"_id":2479,"_type":14,"title":2480,"_source":16,"_file":2481,"_stem":2482,"_extension":19},"/en-us/blog/working-in-vastly-different-timezone",{"title":2467,"description":2468,"ogTitle":2467,"ogDescription":2468,"noIndex":6,"ogImage":2469,"ogUrl":2470,"ogSiteName":673,"ogType":674,"canonicalUrls":2470,"schema":2471},"A matter of perspective","What I learned while working remotely in a vastly different time zone.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680973/Blog/Hero%20Images/harbour_shadows.jpg","https://about.gitlab.com/blog/working-in-vastly-different-timezone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A matter of perspective\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erich Wegscheider\"}],\n        \"datePublished\": \"2020-01-06\",\n      }",{"title":2467,"description":2468,"authors":2473,"heroImage":2469,"date":2474,"body":2475,"category":705,"tags":2476},[1842],"2020-01-06","\n\nImagine you’re a morning person. The type that, for better or worse, is unconsciously in sync with sunrise. Your mornings offer ample time for personal pursuits, such as a workout, a side hustle, or undisturbed personal time. When your devices are powered on, your inbox loosely resembles the same notification count that it did the night before.\n\nNow, flip it upsidedown. Literally. Every morning meeting is now an evening meeting. Or, more accurately, a middle of the night meeting. Your inbox is laughably far away from inbox zero and your working hours hardly overlap with those of your team members.\n\nThat’s basically been my experience as I transition from North American to Asia Pacific working hours - it’s nothing short of drastic. Fortunately, the things that challenge my perceived norms generally present the best opportunities for learning.\n\nHere are three things I learned while managing a 14- to 17-hour time difference for the greater part of two months.\n\n\n\n## Lesson #1: Be true to yourself\n\nIf GitLab didn’t live and breathe [asynchronous communication](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication), managing such timezone differences would have been tricky. Instead, the differences provided a tangible experience from which to grow and practice the principle.\n\nWhen comparing a typical *\"9 to 5\"* workday, here’s how many hours my home timezone (Mountain Time) overlapped with each location:\n\n*  Bali (+14 hours): **0 hours**\n*  Australia (+17 hours): **2 hours**\n\nAfter making the timezone switch, I decided to keep attending regularly scheduled meetings. To balance things out, I took time off in the middle of the day and stayed online as late as 1 am. Such a scenario might work for some people, but not me. I felt weird, innate guilt for not working during the day when it wasn’t a planned day off, but more so for going against a well-known personal trait: I’m not a night owl.\n\nThat’s when I learned my first lesson: Be true to yourself.\n\nI know when I’m most productive and when I need to unplug and rest. Going against these knowns wasn’t going to benefit GitLab or me. If anything, going against what I know about my productive work patterns had the potential for the opposite effect: burnout. Therefore, rather than accept and attend every meeting, as I generally would stateside, I started declining most everything.\n\nInstead, I reviewed and commented on meeting agendas, issues, and Slack threads where my participation was necessary. This was my first step toward understanding asynchronous work firsthand and actually doing it.\n\nAdmittedly, I had an irrational fear that team members would think that I wasn’t doing my job or slacking off. Fortunately, my fears were just that – irrational.\n\n## Lesson #2: Productivity is not linear\n\nOutside of the confined *\"9 to 5\"* workday, there’s a waning window of productivity across timezones – one region is getting up to speed while the other is winding down. While I could enjoy the fruits of completely asynchronous work, the truth is, if I wanted to push things forward more quickly, then I needed to stop working in well-defined windows. Namely, the *\"9 to 5\"* window.\n\nIn the states, I would intentionally avoid looking at my phone or opening my laptop when I first woke up. Only when I felt ready to settle-in, after my morning routine, would I engage with technology. At home, my productivity is linear, and I would tread the well-worn path of traditional business hours. As I zoom out and think about that structured approach, I can't help but think of that as *\"corporate conditioning\".*\n\nThat connotation is neither positive or negative – just calling it as I see it.\n\nAnyway, given the timezone shift and the awareness of when I’m most – and least – productive, I let go of the marathon workday notion and chunked my work. For example, shortly after I woke up, I’d go straight to Slack and email. From there, I’d categorize every item as either, **1) Do it now** or **2) Do it later**.\n\nSome mornings required about an hour’s worth of work and prioritization, while other mornings occupied three times that. After a productive morning, I intentionally stepped away to workout, connect with loved ones, and discover the local brunch scene. Later, I returned to my laptop and carried on with work.\n\nOverall, I started to really love and embrace this alternative workday. In retrospect, plus full transparency, it wasn’t uncommon that I’d fall into a productivity black hole and struggle to stay awake during marathon workdays. You know, the times where you become acutely aware of how heavy your head actually is when you snap it back to the upright position.\n\nWell, that thankfully disappeared from my late mornings and early afternoons as soon as marathon workdays ended. Also notable, coffee (or caffeine) was not involved in any way, shape, or form. I’ve actually never had a cup in my life (Weird, I know).\n\nRealizing this, I learned my second lesson: Productivity is not linear.\n\nI can’t maintain a high level of output throughout the course of a linear workday. It would be like expecting to run a 50-mile ultra-marathon at my half-marathon pace – it's just not realistic in endurance athletics. However, if I split up my day by balancing focused efforts with adequate personal time, I can produce a higher level of output.\n\nThat analogy isn't perfect, but hopefully you get my point.\n\nThough, if I really want to put this running analogy to the test, I should see how many quality half-marathons I could run in a day.\n\n## Lesson #3: Work/life balance is subjective\n\nWhile having dinner one evening in Brisbane, Australia, a friend asked in a tone that warranted introspection: *“What are you hoping to learn from this experience?”* If the question had been asked in a different tone or context, I imagine I would have spewed out some naive, vague garbage about \"seeing the world\". Instead, my first thought was about the concept of work/life balance.\n\nWhile I was thinking about my response, I reflected on how confusing company reviews can be. For example, on Glassdoor, \"work/life balance\" is often mentioned in both glowing – and slandering reviews.\n\nAs the conversation progressed, I realized that I didn’t have a personal definition of work/life balance. I started thinking: \"What is it about downtime that I value?\", \"What are my expectations of how an employer lets me manage my time?\", and \"What innately motivates me in the professional world?\"\n\nI thought about where I’d been and the people I met on the [WiFi Tribe](https://wifitribe.co/), the [culture](https://handbook.gitlab.com/handbook/values/) of GitLab, and started to piece together a principle.\n\nWhile I was analyzing my tendencies, I realized that my pursuit of perfectionism often impedes my ability to let good enough be enough. I take pride in what I produce, but at what cost? There are people who *\"live to work\"* and then there are those that *\"work to live\".* Neither approach is right and neither is wrong – it’s all subjective.\n\nThat’s when I learned my third lesson: Work/life balance is just as subjective.\n\nIt was a lightbulb moment for me. I work in talent operations for GitLab, and I started thinking about the typical interview processes – interviews are as much about the candidate selling themselves as they are about the company selling itself. At least, that’s how it should be in theory.\n\nWithout introspection, how can someone _really_ know whether they're making a \"good career move\" by joining a new company. Sure, money is a metric, and so is job-leveling – but those are extrinsic motivators. I’d like to think that burnout is blind to compensation and leveling. From my perspective, work/life balance is made up of many intangibles.\n\nIn a sense, [I happily stumbled into a great work culture at GitLab](/blog/not-all-remote-is-created-equal/)! I’d known about the [GitLab handbook](/handbook/) and the company principles prior to applying, but I hadn’t given my motivators enough thought. Now that I've defined my personal principles around work and life, I’m all the more appreciative of everything that GitLab has to offer.\n\nAll things considered, it's quite impressive that something as simple as shifting timezones could offer such new perspectives. I will remember these takeaways, without a doubt. How I’ll apply my work/life principles back on Mountain Time is still unknown, in the spirit of GitLab, one thing is for certain – I'll be iterating on them.\n\nCover image by Erich Wegscheider\n{: .note}\n",[9],{"slug":2478,"featured":6,"template":687},"working-in-vastly-different-timezone","content:en-us:blog:working-in-vastly-different-timezone.yml","Working In Vastly Different Timezone","en-us/blog/working-in-vastly-different-timezone.yml","en-us/blog/working-in-vastly-different-timezone",{"_path":2484,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2485,"content":2490,"config":2495,"_id":2497,"_type":14,"title":2498,"_source":16,"_file":2499,"_stem":2500,"_extension":19},"/en-us/blog/working-remotely-with-children-at-home",{"title":2486,"description":2487,"ogTitle":2486,"ogDescription":2487,"noIndex":6,"ogImage":2077,"ogUrl":2488,"ogSiteName":673,"ogType":674,"canonicalUrls":2488,"schema":2489},"How to make your home a space that works with kids","Here's our best advice on making your home/work space work for you and your kids.","https://about.gitlab.com/blog/working-remotely-with-children-at-home","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to make your home a space that works with kids\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sean McGivern\"}],\n        \"datePublished\": \"2019-08-01\",\n      }",{"title":2486,"description":2487,"authors":2491,"heroImage":2077,"date":2492,"body":2493,"category":705,"tags":2494},[2082],"2019-08-01","\n\n_In part three of our series on working remotely with children we look at how GitLab\nteam members literally make their homes work for them while children are around.\nIn part one of our series we examined [maternity/paternity leave polices around\nthe world](/blog/how-is-it-being-a-new-mom-working-for-gitlab/) and in part two Jarka Košanová shared her experiences while\n[working as a new mother](/blog/balancing-career-and-baby/)._\n\nAt [GitLab Contribute 2019](/blog/contribute-wrap-up/) in New Orleans,\nwe had an unconference\nsession about working remotely with children at home. The\nfacilitators were [Lyle Kozloff][lyle] and myself, [Sean\nMcGivern][smcgivern]. Not surprisingly, the four sessions generated a lot of good ideas.\nThe participants had all ages of children from\n'not yet, but thinking about it' to older teenagers. They also worked in\ndifferent functions at GitLab and had different tenures – some people\nhad been at GitLab for years while others had just joined the week of\nContribute. And others were community contributors or partners of GitLab team members.\n\nNo conversation about working at home with kids can fail to include ideas about how\nto structure the space. To make it all work, it's important to be creative.\n\n## Make use of what's available\n\n> I'd never had a remote job before and I didn't realize just how loud my daughter was.\nI got a noise-cancelling microphone because my daughter is in the next room to me. – [_Désirée Chevalier, test automation engineer_][dchevalier2]\n\n> I have an open-plan kitchen/dining/living room, which looks nice, but with my kids around\nit's pretty much impossible to work from any of these areas. I'm planning to try making the\nloft \"the office,\" but I haven't done it yet. – [_Marcel Amirault, technical writer_][Ravlen]\n\nIf you don't have a large house or apartment, you might need to think outside\nthe box when it comes to managing your space. And things can change again as your\nchildren age or if you have more children. Even having a room solely\nfor work might come with some additional challenges!\n\n## Designate spaces clearly\n\n> We have a one-bedroom apartment and I mostly work in the living room. When I take\ncalls I go into the bedroom. We involved the kids in the planning about communication.\nThe bedroom door has a sign with an X or an O on it. If there's an O they can come in, grab\nsomething, and close the door behind them. If there's an X they can't come in for any reason.\nWhen we moved in my son was still three, and it worked for the later stages of three –\nespecially because he was involved. – [_Lyle Kozloff, support engineering manager_][lyle]\n\n![Minimum Viable Product for indicating space usage](https://about.gitlab.com/images/blogimages/mvp-presence-signs.jpg){: .shadow.medium.center}\nHow one team member communicates whether or not he can be interrupted.\n{: .note.text-center}\n\nIf you need to be uninterrupted, it's important that that is very clear\nto everyone else – especially the children. Having a dedicated space is\ngreat, but even a shared space can be turned into a dedicated space for\nsome of the time before becoming a shared space again later.\n\n## Get out of the house if you need to\n\n> I find it better to set boundaries ahead of time instead of reacting to things that are happening.\nFour or five times a month I will work from a coffee shop to help enforce that too. – [_Mike Greiling,\nsenior frontend engineer_][mikegreiling]\n\n> I used to have a dedicated room then it became my son's room. Then I moved to the\nentrance hallway, because it's big and there was room for a desk. I tried it for one year, but\nmy wife and child were always coming past. I've started going to a coworking space. It feels\nlike a failure because I don't stay home, but it works best for us. – [_Alessio Caiazza, senior backend engineer_][nolith]\n\nThis is not a failure at all! Everyone has to do what they need to do for their\nown circumstances. [Working remotely doesn't necessarily mean working from\nhome](/company/culture/all-remote/#what-all-remote-does-not-mean), and stressed\nparents are not going to be able to be at their best.\n\n_In part four of our series we have advice on everything from time management to relationships._\n\n[dchevalier2]: /company/team/#dchevalier2\n[lyle]: /company/team/#lkozloff\n[mikegreiling]: /company/team/#mikegreiling\n[nolith]: /company/team/#nolith\n[Ravlen]: /company/team/#ravlen1\n[smcgivern]: /company/team/#mcgivernsa\n\nPhoto by [Baby Natur](https://unsplash.com/@babynatur?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/kids-toys?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,708,683],{"slug":2496,"featured":6,"template":687},"working-remotely-with-children-at-home","content:en-us:blog:working-remotely-with-children-at-home.yml","Working Remotely With Children At Home","en-us/blog/working-remotely-with-children-at-home.yml","en-us/blog/working-remotely-with-children-at-home",{"_path":2502,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2503,"content":2509,"config":2515,"_id":2517,"_type":14,"title":2518,"_source":16,"_file":2519,"_stem":2520,"_extension":19},"/en-us/blog/zapier-pick-your-brain-interview",{"title":2504,"description":2505,"ogTitle":2504,"ogDescription":2505,"noIndex":6,"ogImage":2506,"ogUrl":2507,"ogSiteName":673,"ogType":674,"canonicalUrls":2507,"schema":2508},"Scaling communication at Zapier","GitLab CEO Sid Sijbrandij sits down with Zapier team members to chat about communication challenges in each growing company.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680279/Blog/Hero%20Images/zapier-pyb-post.jpg","https://about.gitlab.com/blog/zapier-pick-your-brain-interview","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Scaling communication at Zapier\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Noah Manger\"}],\n        \"datePublished\": \"2018-01-08\",\n      }",{"title":2504,"description":2505,"authors":2510,"heroImage":2506,"date":2512,"body":2513,"category":705,"tags":2514},[2511],"Noah Manger","2018-01-08","\n_On November 17, Mike Knoop and Noah Manger of Zapier [sat down with GitLab’s CEO Sid Sijbrandij](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings) to discuss the way the two companies approach the challenge of scaling communication as a company grows. This transcript has been lightly edited for clarity._\n\n\u003C!-- more -->\n\n**The heartbeat of our organization is our weekly Friday Update posts that everyone at the company writes. The problem is that as we’ve grown, it’s become a tremendous amount of information. We’re really good at generating the firehose of content, but not as good at consuming it. So I’d love to learn what processes you use at GitLab and if you feel like you’ve got a good grip on this problem?**\n\nWe have a #working-on Slack channel but I’m working on killing it because I just don’t care what people in another part of the company are working on. I just don’t care. There are just too many people at 200 people.\n\nWhat works really well for us are the [functional group updates](/handbook/group-conversations/). Every day of the week there’s a presentation (for a maximum of 25 minutes) by a team lead with a slide deck of what they’re working on, and there's an opportunity to ask questions. So you get to stay updated about what all the development teams are doing, what sales is doing, what marketing is doing, what legal is doing, what partnerships is doing. It’s on a three-week rotation so 15 different functional areas and then we start over from the top.\n\n**Do you measure how many people consume this content?**\n\nLive in the call it’s about 50 but it differs on the matter. It’s planned for every single day. We hadn’t scheduled them for a month or two and everyone in the company reported feeling out of touch about where the company was going and what people were working on.\n\nWe are doing asynchronous stand-ups, but it’s just for something that’s a high priority project and there’s a chance of delay that we can’t afford. Right now there are three groups on asynchronous stand-ups that are super high-priority projects and we want to make sure that nobody’s blocked. So someone posts a message saying “Asynchronous stand-up for today” and then everyone posts in the thread what they’re working on and may be blocked on.\n\nNormally we don’t do it and we just work in [GitLab issues](https://docs.gitlab.com/ee/user/project/issues/). When you start working on something you assign your name to it, and so if you want to know what someone is working on you see what issues are assigned to them.\n\n**Why did you choose to do functional updates as videos rather than written?**\n\nIt allows for more interaction. Yesterday my update had three topics and I had a slide for each. People ask questions mostly in the chat feed in Zoom. Sometimes if they have an elaborate question I’ll ask them to explain more verbally. We spend 15-20 minutes on people asking questions. That’s what we want — it’s not typical — but that’s where we want to go. Sometimes people have a lot to present and talk for 20 minutes, but we want to try to split those up and constrain the presenting part to 10 minutes.\n\nAnd if they’re over in 10 or 15 minutes and nobody has any questions, that’s great.\n\nAnd one thing: the presentation slides have to be linked to in the invite before the presentation starts. People have to be able to invest one minute to click through the presentation to see if they need to join the call, or they can just say “This is great and I don’t need to join.” And obviously everything is recorded: it’s put into our Google Drive and you can see everything and the ones that are able to be public will be posted every Friday.\n\n**Is it typical for someone to join every update?**\n\nI join about two thirds of them.\n\n**So if someone were to join every one it’d be a two-and-a-half-hour time commitment every week?**\n\nYeah, but you won’t be asked any questions so you’re able to multitask and zone out if you don’t need to pay attention.\n\n**You’re global, so how do you deal with time zones? Do you rotate it around so other people are able to join?**\n\nYou’re not expected to join at all. These are optional; join them if you want to. But time zones are the bane of our existence. Most of our people are either in Europe or the Americas, so we do this in our most convenient time zones. So our functional updates are at 8am Pacific and our team call is at 8:30am Pacific. There’s been a trend of scheduling meetings over this but we’re trying to prevent that.\n\n**What percentage of content about the company do people consume over video versus writing?**\n\nIt depends. It depends on how they like to consume content. If you’re good with written content, you can get by with the handbook and the presentations. If you like to consume it by listening and hearing people interact, then the video calls are a good way to do it. What’s important is that we make both ways available and then people can do it as they please.\n\n>If you’re good with written content, you can get by with the handbook and the presentations. If you like to consume it by listening and hearing people interact, then the video calls are a good way to do it. What’s important is that we make both ways available and then people can do it as they please.\n\nAnd some people might not care so much! Some people are happy being an open source developer and don’t care about the machinations of a company and that is A-OK. We’re not going to force you to sit through this or check your attendance rate. That is just fine.\n\nBut some people really care and they care about all the aspects. They joined a startup because they want to know what’s happening. For example, when we were doing fundraising we had a fundraising Slack channel and people were asking questions like “What’s the liquidation preference?” And that’s great. If you’re interested we’re not trying to shield you; we don’t want you to get too distracted but it’s there if you want to dive in.\n\n**Do you find people have anxiety around keeping up with information and being concerned they’re not missing things?**\n\nWhat people report is that starting here is overwhelming. The first month is a dark place. We never have people quit during that time but everyone reports that it’s super hard on them. We have one onboarding issue that has about 100 checkboxes you need to check off. And we try to have it all go by what you do on Day 1, Day 2. But it’s very overwhelming. We try to figure out what to cut, but everyone says “No, it’s good to have it all there.” When you first join you have access to the entire map of GitLab so you have to constrain your view.\n\n**Are there other things that you do to help teams know what other teams are doing around the organization?**\n\nWell the [handbook](/handbook/) is really important. That contains all our processes, all the different departments, how they operate, who’s responsible, what Slack channels they’re on, which issue trackers they use; our definitions; our stages in the sales process. Everything should be in there. It’s hard to get right, so it’s a constant focus of my attention. But the idea is if you want to make a change to the company you propose an edit to the handbook, make a merge request, and then if you merge it you announce it. It’s the best handbook in the world; there’s lots of room for improvement, but it’s good and lets you see how lots of different parts of the company operate.\n\nAnd of course we use our own tools. So our customer success team uses an [issue board](https://gitlab.com/gitlab-com/customer-success/sa-service-desk/boards/339477?=) so you can see what they’re doing and what stage it’s in. So we try to use our issue boards and our static websites so you can peer into any part of the company.\n\nOne thing we’re still getting better at is how to expose metrics. We already have a good metrics sheet that’s up to date, consuming all the revenue models and everything we have, but I want that to be a real-time thing that looks a bit prettier and has some better graphs.\n\nAnother thing we do to keep everyone posted is everyone gets the investor update. So every single month, between the 10th and 15th, we send out an investor update about what was good, what was bad, and all our core metrics and everyone in the company gets it.\n\n**Do people find that helpful?**\n\nI think people find it helpful. I believe if you want people to invest in the company you have to treat them like investors – which they are, because they have options. I think what people pay attention to most is runway (months of cash remaining) and what’s bad.\n\n**One thing we’ve heard is that people want a weekly set of highlights of the things that they need to know. Do you do anything like that?**\n\nI’ve never heard that. If your communication is any good, you repeat yourself a lot. I have a #ceo Slack channel, so hopefully what I say there is congruent with what I say in the investor update is congruent with what the leaders in marketing and sales are saying, etc. We’re not trying to make it the same message, but in a perfect world it’d be the same message.\n\n>If your communication is any good, you repeat yourself a lot.\n\nSo no, I’ve never heard the need for a summary. If I ever need to go find what sales was doing two weeks ago, I’d go find their functional update from two weeks ago.\n\n**If I switched to a new product team and I wanted to know what my new team has been working on, what would I do?**\n\nYou’d look at the functional updates. And also you could join the kickoffs and retrospectives, which happen every month and are broadcast live on [YouTube](https://www.youtube.com/c/Gitlab). So that’s another channel you could use.\n\n**At which stage in your growth did you start doing those functional updates?**\n\nI don’t know exactly. About 50 engineers. But it’s also because this is an open source project and people who are contributing to the project but aren’t part of GitLab are wondering what’s in the pipeline and what’s happening.\n\n**Do you have any internal blog or tools that people log into to get information about what the company is up to?**\n\nNo. There’s the handbook, but for regular updates that’s what the functional team updates and issue boards are for.\n\n**Do you feel like there’s things that aren’t shared that should be? Are those functional updates high enough bandwidth or frequent enough to get everything across?**\n\nWith our kickoffs, because they’re live broadcast, some of our product managers would get into presentation mode, like “Everything’s going to be wonderful!” There’s going to be some of that, but I think it could be more measured and raw. In our retrospectives there’s a more of that. People are also used to asking hard questions and getting praised for that. You say things like “Wow, that’s a hard question. That’s the best question we’ve got.”\n\n**If I’m a product manager and I’m about to release something that will affect the product and I don’t have a functional update this week, what’s the best way to do that?**\n\nFor the company, post in the general chat channel that will be consumed by many people and you mention the related people. If you need it externally you could do a blog post, but usually you could just do it in the issue and then tweet it from your personal account and it will be retweeted by GitLab.\n\n**So you depend on Slack for urgent notifications?**\n\nSlack is great for urgency. It’s its downfall as well.\n\n**What have been either pain points or surprises as you’ve gone from 100 to 200 people?**\n\nI think a pain point we’re experiencing right now is our team call. It’s too many people. We try to rotate people now, but after about 150 people, people lost track. And if you lose track you lose interest. So we’re thinking about getting a smaller group of people together, maybe even 7-15, and having them talk every day for a sustained period so you get to know them and then you switch up the groups.\n\nAlso, overuse of @channel mentions is a pet peeve. It’s only allowed if it’s urgent *and* important but people use them if it’s *only* urgent or *only* important. Those should just be posted without an @channel or @here mention. If my Slack always has a constant red thing then I’ll stop paying attention. It’s a tragedy of the commons.\n\n**Do you have any tricks for organizing Slack?**\n\nThere’s a few special channels: #thanks where we call people out for helping that gets about 10 posts a day and that’s one of my favorite channels.\n\nThere’s an #emotional channel where you can just complain about shit. And that’s allowed and encouraged and we give teddy bear emojis back.\n\n**How many channels do you have?**\n\nHundreds. More channels than people.\n\n**How do people navigate that when they join? Do you do anything to help them figure out which channels to join?**\n\nIt’s organic. These people already feel overwhelmed, do you want to give them more channels? It just gets worse. And in the handbook you can see what the channels are for your group.\n\n**Since we’re talking about cross-team collaboration, can you tell us about your summit?**\n\nWe try to do it every nine months and it’s forbidden to organize functional meetings there. So you can’t meet with the just sales or marketing team. Instead we have an '[unconference](https://en.wikipedia.org/wiki/Unconference)' based on the Lobby Conference, that’s built on user-generated content. We have two half days where people propose subjects, people vote on them, and someone kicks things off for five minutes and then a group of 15-20 people discuss it for 50 minutes.\n\nYou know the people in your team already, so we said “Please, please, please meet with other people.” The top two sessions at the last one were on avoiding burnout and how to keep yourself motivated while working at home. I was glad to see people organized sessions like that because we can do the purely job-related stuff at other times.\n\n**Well thanks. This has been really great and has challenged some of our assumptions. We’ve been assuming that we’re generating all this content and we need to figure out what the right curation layer is. But it sounds like you’ve been very successful at reducing the amount of content that’s generated in the first place but forcing it all to go through those channels, which solves the curation problem that way.**\n\n\n## About the guest author\n\nNoah Manger is a product manager, designer and developer, currently leading the Internal Tools team at Zapier. He lives in Portland, Oregon.\n\nCover image by [Alexandr Bormotin](https://unsplash.com/@bormot) on [Unsplash](https://unsplash.com/photos/Hd8b_WtKIck).\n",[1925,9,731],{"slug":2516,"featured":6,"template":687},"zapier-pick-your-brain-interview","content:en-us:blog:zapier-pick-your-brain-interview.yml","Zapier Pick Your Brain Interview","en-us/blog/zapier-pick-your-brain-interview.yml","en-us/blog/zapier-pick-your-brain-interview",{"_path":2522,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2523,"content":2529,"config":2534,"_id":2536,"_type":14,"title":2537,"_source":16,"_file":2538,"_stem":2539,"_extension":19},"/en-us/blog/agile-for-remote-work",{"title":2524,"description":2525,"ogTitle":2524,"ogDescription":2525,"noIndex":6,"ogImage":2526,"ogUrl":2527,"ogSiteName":673,"ogType":674,"canonicalUrls":2527,"schema":2528},"How async and all-remote make Agile simpler","Engineers at GitLab and IssueTrak share their tips on adopting Agile while working remotely.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681930/Blog/Hero%20Images/runlanes.jpg","https://about.gitlab.com/blog/agile-for-remote-work","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How async and all-remote make Agile simpler\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2021-03-02\",\n      }",{"title":2524,"description":2525,"authors":2530,"heroImage":2526,"date":2531,"body":2532,"category":705,"tags":2533},[812],"2021-03-02","\n\nWhether you have the [Agile manifesto](https://agilemanifesto.org/) memorized or thought agility was a sport for dogs, there are a few core principles that engineers and non-engineering folks can adopt to improve communication, collaboration, and efficiency in their work – whether or not they’re working from the same office.\n\nInterestingly, the first piece of advice GitLab team members shared for engineers (or content developers) using Agile or working remotely is the same: Over-communicate!\n\n\"Provide maximum context in discussions and document the outcomes in the most appropriate location,\" says [Lindsay Kerr](/company/team/#lkerr), frontend engineering manager for Threat Management at GitLab. \"This allows other members of the team to benefit from synchronous conversations while giving stakeholders insight into the progress of the team.\"\n\n## How Agile keeps development lean\n\n[Agile software development](/topics/agile-delivery/) is all about developing solutions through collaboration and iteration, with some of the techniques being stand-ups, sprints, and more. Another key principle of Agile: Making processes more lean.\n\nDuring our annual user conference [GitLab Commit](https://www.youtube.com/watch?v=t8BvRMalbkM&list=PLFGfElNsQthYQaTiUPQcu4O0O20WHZksz&index=10), the software company [IssueTrak](https://www.issuetrak.com/) explained how migrating to GitLab helped the company embrace Agile software development. Before, IssueTrak was using five tools to manage their ticketing and repositories and power their [CI/CD pipelines](/solutions/continuous-integration/), at a substantial monthly cost. After IssueTrak migrated to GitLab, they reduced their monthly costs by 80% and simplified their toolchain by adopting GitLab for all their software development needs. You can [read more about their experience below](#how-two-teams-use-sprints-with-gitlab).\n\n### Why all-remote and Agile pair well together\n\nGitLab has embraced the principles of Agile software development in two key ways. The first way we've built agility and efficiency into our culture is by embracing all-remote, asynchronous work. By working remotely, team members can work when they want and in places and spaces that best suit them. Remote work has become more widely adopted since the COVID-19 pandemic has disrupted the traditional office, explains [Lauren Barker](/company/team/#laurenbarker), fullstack developer working on the Website.\n\nRemote work is a simple concept to grasp, but asynchronous (async) work is a bit more complicated. At GitLab, working async looks like optional meetings with detailed agendas and Slack channels are busy but without the pressure of an immediate reply. Zoom meetings are recorded and posted on the [GitLab Unfiltered channel](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A), which supports our commitment to transparency and breaks down silos by improving communication across teams.\n\n\"Working asynchronously enables an individual to contribute when they’re 'on',\" says Lauren. \"Sometimes you’re feeling super productive and motivated on a certain project at 2 AM, not during normal business hours such as 9-5.\"\n\nThe core of effective async, all-remote, and Agile workflows is documentation. By clearly defining project scope and needs in writing, processes are easy to follow and replicable for all users. At GitLab, perhaps the most important rule of all is our [handbook-first principle](/company/culture/all-remote/handbook-first-documentation/), which states that our handbook is the single source of truth in the organization and challenges team members to document everything. [Tyler Williams](/company/team/#tywilliams), website fullstack developer at GitLab, discussed the value he’s derived from the handbook-first mentality at a [recent Inbound Marketing team meeting](https://www.youtube.com/watch?v=qhsdwlqvuN4&list=PL05JrBw4t0KrurHzoPhov77x3_P26Ncz1) and said that handbook-first coupled with async work is what powers Agile for him.\n\n## Insights on remote team building with Agile\n\nTyler and Lindsay both acknowledge it can be challenging to build team camraderie remotely when applying Agile principles like stand-ups when you're not in-person.\n\n\"It is easier to implement the human-connectivity pieces of an Agile mindset when you are in person,\" says Tyler. \"It is easier to implement the process-focused pieces of Agile techniques when you are all-remote and asynchronous.\"\n\n\"Distance can remove people from consequences,\" adds Brandon. \"A bad manager could drop a project on you, turn off remote messaging, and go on vacation. I've experienced this at previous workplaces.\"\n\nBut working alongside humans in the same space isn’t always an upside. In-person work can make personality clashes more commonplace, says Lindsay.\n\n### Remembering when Agile was analog\n\nBefore project management tools like Jira and GitLab, scrum teams had to plan sprints manually using things like post-its, index cards, and white boards. While this analog approach to sprint planning can be good for team-building, it was less efficient in the long-run.\n\n\"When I started working on scrum teams in 2008 we actually stood up together in a room during stand-up. We looked at post-it notes (tasks) associated with index cards (stories) when discussing the answers to our three questions (what did I do yesterday, what am I doing today, and what is blocking me),\" says Lindsay.\n\n\"We used an egg-timer to make sure our stand-up didn't go longer than 10 minutes each day. I drew our burndown on paper each day, across every two-week sprint, for the course of a three-month project. We looked each other in the eyes when we gave our answers, watched our teammates move the post-it note from 'to-do' to 'in progress', and celebrated together when a post-it moved to the 'done' column.\"\n\nIt is hard to document progress using the analog approach to sprint planning. When one team member is out sick or on vacation, they lose the historical context of a project as post-its move columns, and meetings happen without thorough notes or recordings.\n\n\"In an office setting, it may be easier to adopt the human-focused mindset, but it is much more challenging to adopt appropriate processes to keep Agile techniques running, and it is a much less enjoyable endeavor to coach people around process,\" says Tyler.\n\n### GitLab is designed for Agile\n\nThe other way we've embraced Agile principles at GitLab: [we've baked many Agile artifacts into different features of our DevOps Platform](/blog/gitlab-for-agile-software-development/) such as issues, labels, milestones, and weights, etc. \"These words seem somewhat abstract but they are all different ways to help you categorize and organize information to help you work agilely,\" explains [Brandon Lyon](/company/team/#brandon_lyon), frontend engineer for Marketing at GitLab.\n\nThese Agile features coupled with robust CI/CD help us keep GitLab lean and allow _our customers_ to continuously deliver software to _their customers_.\n\n\"If the main point of Agile is to continuously deliver working software as value to customers, GitLab enables teams to be Agile because it has the best CI/CD tools I've ever used, and they're integrated directly in my day-to-day task management workflow,\" says Tyler.\n\n## How two teams use sprints with GitLab\n\nIn their GitLab Commit presentation, IssueTrak team members Lisa Cockrell, director of development, and Jordan Upperman, fullstack developer, said that they created two custom issue boards using GitLab, one of which is the \"Ready for Sprint\" column and board. Sprint planning meetings are much shorter now because the team can just look at the \"Ready for Sprint\" board to identify which issues are ready to enter the development process.\n\n\"Our use of these two Kanban boards allows us to pivot with ease when necessary. As bugs are found during testing it's easy for us to quickly weigh the new ticket, remove an item with equal weight, and send it back to the top of the 'Ready for Sprint' column,\" says Lisa. She explains that this process prevents scope creep and helps stakeholders remember that when work is added to the sprint, something else must come out. Watch the entire presentation to learn more about how IssueTrak uses GitLab tools for Agile development:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/t8BvRMalbkM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nBrandon, Tyler, and Lauren all work on the [Digital Experience team at GitLab](/handbook/marketing/digital-experience/), which is responsible for our marketing website. In the spirit of iteration and efficiency (two of our values at GitLab), the team is in the process of updating the way they conduct sprints. Tyler [opened an MR to facilitate the discussion](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/74534) – share your tips for sprints by commenting on the MR or suggesting a change.\n\nWe are constantly looking for new strategies to communicate and engineer with clarity and efficiency. If you have any suggestions for how to better embrace Agile, async, and all-remote work, let us know in the comments or tweet at us @GitLab. If you are still new to this topic, our advice is to try and go with the flow, and leave your expectations at the door.\n\n\"If you keep in mind that Agile is a flexible, human-focused approach to knowledge work and delivering value to customers, the rest will fall in place,\" says Tyler. \"Take strong opinions with a grain of salt, and give yourself room to make mistakes and remember that [it's impossible to know everything](https://handbook.gitlab.com/handbook/values/#its-impossible-to-know-everything).\"\n",[1630,9,683],{"slug":2535,"featured":6,"template":687},"agile-for-remote-work","content:en-us:blog:agile-for-remote-work.yml","Agile For Remote Work","en-us/blog/agile-for-remote-work.yml","en-us/blog/agile-for-remote-work",11,[666,692,715,741,761,782,802,822,842],1753981660900]