[{"data":1,"prerenderedAt":3110},["ShallowReactive",2],{"/en-us/blog/categories/culture/":3,"navigation-en-us":22,"banner-en-us":451,"footer-en-us":468,"culture-category-page-en-us":678},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":16,"_type":17,"title":9,"_source":18,"_file":19,"_stem":20,"_extension":21},"/en-us/blog/categories/culture","categories",false,"",{"title":9,"description":10},"Culture","Browse articles related to Culture on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":15},"BlogCategory","culture",true,"content:en-us:blog:categories:culture.yml","yaml","content","en-us/blog/categories/culture.yml","en-us/blog/categories/culture","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":447,"_type":17,"title":448,"_source":18,"_file":449,"_stem":450,"_extension":21},"/shared/en-us/main-navigation","en-us",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":378,"minimal":409,"duo":428,"pricingDeployment":437},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/","gitlab logo","header",{"text":32,"config":33},"Get free trial",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"Talk to sales",{"href":39,"dataGaName":40,"dataGaLocation":30},"/sales/","sales",{"text":42,"config":43},"Sign in",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,188,193,299,359],{"text":48,"config":49,"cards":51,"footer":74},"Platform",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"The most comprehensive AI-powered DevSecOps Platform",{"text":55,"config":56},"Explore our Platform",{"href":57,"dataGaName":50,"dataGaLocation":30},"/platform/",{"title":59,"description":60,"link":61},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":62,"config":63},"Meet GitLab Duo",{"href":64,"dataGaName":65,"dataGaLocation":30},"/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":70,"config":71},"Learn more",{"href":72,"dataGaName":73,"dataGaLocation":30},"/why-gitlab/","why gitlab",{"title":75,"items":76},"Get started with",[77,82,87],{"text":78,"config":79},"Platform Engineering",{"href":80,"dataGaName":81,"dataGaLocation":30},"/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"Developer Experience",{"href":85,"dataGaName":86,"dataGaLocation":30},"/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/topics/devops/the-role-of-ai-in-devops/",{"text":92,"left":15,"config":93,"link":95,"lists":99,"footer":170},"Product",{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"View all Solutions",{"href":98,"dataGaName":94,"dataGaLocation":30},"/solutions/",[100,125,149],{"title":101,"description":102,"link":103,"items":108},"Automation","CI/CD and automation to accelerate deployment",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":30},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[109,113,117,121],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":30,"dataGaName":110},"/solutions/continuous-integration/",{"text":114,"config":115},"AI-Assisted Development",{"href":64,"dataGaLocation":30,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Source Code Management",{"href":120,"dataGaLocation":30,"dataGaName":118},"/solutions/source-code-management/",{"text":122,"config":123},"Automated Software Delivery",{"href":106,"dataGaLocation":30,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Security","Deliver code faster without compromising security",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":30,"icon":132},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":30},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Software Supply Chain Security",{"href":142,"dataGaLocation":30,"dataGaName":143},"/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":148,"dataGaLocation":30},"/solutions/software-compliance/","software compliance",{"title":150,"link":151,"items":156},"Measurement",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":30},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[157,161,165],{"text":158,"config":159},"Visibility & Measurement",{"href":154,"dataGaLocation":30,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Value Stream Management",{"href":164,"dataGaLocation":30,"dataGaName":162},"/solutions/value-stream-management/",{"text":166,"config":167},"Analytics & Insights",{"href":168,"dataGaLocation":30,"dataGaName":169},"/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab for",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":30,"dataGaName":177},"/enterprise/","enterprise",{"text":179,"config":180},"Small Business",{"href":181,"dataGaLocation":30,"dataGaName":182},"/small-business/","small business",{"text":184,"config":185},"Public Sector",{"href":186,"dataGaLocation":30,"dataGaName":187},"/solutions/public-sector/","public sector",{"text":189,"config":190},"Pricing",{"href":191,"dataGaName":192,"dataGaLocation":30,"dataNavLevelOne":192},"/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"Resources",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"View all resources",{"href":200,"dataGaName":196,"dataGaLocation":30},"/resources/",[202,235,258],{"title":203,"items":204},"Getting started",[205,210,215,220,225,230],{"text":206,"config":207},"Install",{"href":208,"dataGaName":209,"dataGaLocation":30},"/install/","install",{"text":211,"config":212},"Quick start guides",{"href":213,"dataGaName":214,"dataGaLocation":30},"/get-started/","quick setup checklists",{"text":216,"config":217},"Learn",{"href":218,"dataGaLocation":30,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Product documentation",{"href":223,"dataGaName":224,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Best practice videos",{"href":228,"dataGaName":229,"dataGaLocation":30},"/getting-started-videos/","best practice videos",{"text":231,"config":232},"Integrations",{"href":233,"dataGaName":234,"dataGaLocation":30},"/integrations/","integrations",{"title":236,"items":237},"Discover",[238,243,248,253],{"text":239,"config":240},"Customer success stories",{"href":241,"dataGaName":242,"dataGaLocation":30},"/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":30},"/blog/","blog",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":30},"/teamops/","teamops",{"title":259,"items":260},"Connect",[261,266,271,276,281],{"text":262,"config":263},"GitLab Services",{"href":264,"dataGaName":265,"dataGaLocation":30},"/services/","services",{"text":267,"config":268},"Community",{"href":269,"dataGaName":270,"dataGaLocation":30},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Events",{"href":279,"dataGaName":280,"dataGaLocation":30},"/events/","events",{"text":282,"config":283},"Partners",{"href":284,"dataGaName":285,"dataGaLocation":30},"/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","Insights for the future of software development",{"altText":291,"config":292},"the source promo card",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"Read the latest",{"href":297,"dataGaName":298,"dataGaLocation":30},"/the-source/","the source",{"text":300,"config":301,"lists":303},"Company",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"About",{"href":309,"dataGaName":310,"dataGaLocation":30},"/company/","about",{"text":312,"config":313,"footerGa":316},"Jobs",{"href":314,"dataGaName":315,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":30},{"text":320,"config":321},"Leadership",{"href":322,"dataGaName":323,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":325,"config":326},"Team",{"href":327,"dataGaName":328,"dataGaLocation":30},"/company/team/","team",{"text":330,"config":331},"Handbook",{"href":332,"dataGaName":333,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Investor relations",{"href":337,"dataGaName":338,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Trust Center",{"href":342,"dataGaName":343,"dataGaLocation":30},"/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":30},"/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":30},"/company/contact/","newsletter",{"text":355,"config":356},"Press",{"href":357,"dataGaName":358,"dataGaLocation":30},"/press/","press",{"text":360,"config":361,"lists":362},"Contact us",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":37,"config":366},{"href":39,"dataGaName":367,"dataGaLocation":30},"talk to sales",{"text":369,"config":370},"Get help",{"href":371,"dataGaName":372,"dataGaLocation":30},"/support/","get help",{"text":374,"config":375},"Customer portal",{"href":376,"dataGaName":377,"dataGaLocation":30},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":379,"login":380,"suggestions":387},"Close",{"text":381,"link":382},"To search repositories and projects, login to",{"text":383,"config":384},"gitlab.com",{"href":44,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Suggestions",[390,392,396,398,402,406],{"text":59,"config":391},{"href":64,"dataGaName":59,"dataGaLocation":386},{"text":393,"config":394},"Code Suggestions (AI)",{"href":395,"dataGaName":393,"dataGaLocation":386},"/solutions/code-suggestions/",{"text":110,"config":397},{"href":112,"dataGaName":110,"dataGaLocation":386},{"text":399,"config":400},"GitLab on AWS",{"href":401,"dataGaName":399,"dataGaLocation":386},"/partners/technology-partners/aws/",{"text":403,"config":404},"GitLab on Google Cloud",{"href":405,"dataGaName":403,"dataGaLocation":386},"/partners/technology-partners/google-cloud-platform/",{"text":407,"config":408},"Why GitLab?",{"href":72,"dataGaName":407,"dataGaLocation":386},{"freeTrial":410,"mobileIcon":415,"desktopIcon":420,"secondaryButton":423},{"text":411,"config":412},"Start free trial",{"href":413,"dataGaName":35,"dataGaLocation":414},"https://gitlab.com/-/trials/new/","nav",{"altText":416,"config":417},"Gitlab Icon",{"src":418,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":416,"config":421},{"src":422,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":424,"config":425},"Get Started",{"href":426,"dataGaName":427,"dataGaLocation":414},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"Learn more about GitLab Duo",{"href":64,"dataGaName":432,"dataGaLocation":414},"gitlab duo",{"altText":416,"config":434},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":436},{"src":422,"dataGaName":419,"dataGaLocation":414},{"freeTrial":438,"mobileIcon":443,"desktopIcon":445},{"text":439,"config":440},"Back to pricing",{"href":191,"dataGaName":441,"dataGaLocation":414,"icon":442},"back to pricing","GoBack",{"altText":416,"config":444},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":446},{"src":422,"dataGaName":419,"dataGaLocation":414},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":452,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":453,"button":454,"image":459,"config":463,"_id":465,"_type":17,"_source":18,"_file":466,"_stem":467,"_extension":21},"/shared/en-us/banner","is now in public beta!",{"text":455,"config":456},"Try the Beta",{"href":457,"dataGaName":458,"dataGaLocation":30},"/gitlab-duo/agent-platform/","duo banner",{"altText":460,"config":461},"GitLab Duo Agent Platform",{"src":462},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":464},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":469,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":470,"_id":674,"_type":17,"title":675,"_source":18,"_file":676,"_stem":677,"_extension":21},"/shared/en-us/main-footer",{"text":471,"source":472,"edit":478,"contribute":483,"config":488,"items":493,"minimal":666},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":473,"config":474},"View page source",{"href":475,"dataGaName":476,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":479,"config":480},"Edit this page",{"href":481,"dataGaName":482,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":484,"config":485},"Please contribute",{"href":486,"dataGaName":487,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":489,"facebook":490,"youtube":491,"linkedin":492},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[494,517,573,602,636],{"title":48,"links":495,"subMenu":500},[496],{"text":497,"config":498},"DevSecOps platform",{"href":57,"dataGaName":499,"dataGaLocation":477},"devsecops platform",[501],{"title":189,"links":502},[503,507,512],{"text":504,"config":505},"View plans",{"href":191,"dataGaName":506,"dataGaLocation":477},"view plans",{"text":508,"config":509},"Why Premium?",{"href":510,"dataGaName":511,"dataGaLocation":477},"/pricing/premium/","why premium",{"text":513,"config":514},"Why Ultimate?",{"href":515,"dataGaName":516,"dataGaLocation":477},"/pricing/ultimate/","why ultimate",{"title":518,"links":519},"Solutions",[520,525,527,529,534,539,543,546,550,555,557,560,563,568],{"text":521,"config":522},"Digital transformation",{"href":523,"dataGaName":524,"dataGaLocation":477},"/topics/digital-transformation/","digital transformation",{"text":135,"config":526},{"href":137,"dataGaName":135,"dataGaLocation":477},{"text":124,"config":528},{"href":106,"dataGaName":107,"dataGaLocation":477},{"text":530,"config":531},"Agile development",{"href":532,"dataGaName":533,"dataGaLocation":477},"/solutions/agile-delivery/","agile delivery",{"text":535,"config":536},"Cloud transformation",{"href":537,"dataGaName":538,"dataGaLocation":477},"/topics/cloud-native/","cloud transformation",{"text":540,"config":541},"SCM",{"href":120,"dataGaName":542,"dataGaLocation":477},"source code management",{"text":110,"config":544},{"href":112,"dataGaName":545,"dataGaLocation":477},"continuous integration & delivery",{"text":547,"config":548},"Value stream management",{"href":164,"dataGaName":549,"dataGaLocation":477},"value stream management",{"text":551,"config":552},"GitOps",{"href":553,"dataGaName":554,"dataGaLocation":477},"/solutions/gitops/","gitops",{"text":174,"config":556},{"href":176,"dataGaName":177,"dataGaLocation":477},{"text":558,"config":559},"Small business",{"href":181,"dataGaName":182,"dataGaLocation":477},{"text":561,"config":562},"Public sector",{"href":186,"dataGaName":187,"dataGaLocation":477},{"text":564,"config":565},"Education",{"href":566,"dataGaName":567,"dataGaLocation":477},"/solutions/education/","education",{"text":569,"config":570},"Financial services",{"href":571,"dataGaName":572,"dataGaLocation":477},"/solutions/finance/","financial services",{"title":194,"links":574},[575,577,579,581,584,586,588,590,592,594,596,598,600],{"text":206,"config":576},{"href":208,"dataGaName":209,"dataGaLocation":477},{"text":211,"config":578},{"href":213,"dataGaName":214,"dataGaLocation":477},{"text":216,"config":580},{"href":218,"dataGaName":219,"dataGaLocation":477},{"text":221,"config":582},{"href":223,"dataGaName":583,"dataGaLocation":477},"docs",{"text":244,"config":585},{"href":246,"dataGaName":247,"dataGaLocation":477},{"text":239,"config":587},{"href":241,"dataGaName":242,"dataGaLocation":477},{"text":249,"config":589},{"href":251,"dataGaName":252,"dataGaLocation":477},{"text":262,"config":591},{"href":264,"dataGaName":265,"dataGaLocation":477},{"text":254,"config":593},{"href":256,"dataGaName":257,"dataGaLocation":477},{"text":267,"config":595},{"href":269,"dataGaName":270,"dataGaLocation":477},{"text":272,"config":597},{"href":274,"dataGaName":275,"dataGaLocation":477},{"text":277,"config":599},{"href":279,"dataGaName":280,"dataGaLocation":477},{"text":282,"config":601},{"href":284,"dataGaName":285,"dataGaLocation":477},{"title":300,"links":603},[604,606,608,610,612,614,616,620,625,627,629,631],{"text":307,"config":605},{"href":309,"dataGaName":302,"dataGaLocation":477},{"text":312,"config":607},{"href":314,"dataGaName":315,"dataGaLocation":477},{"text":320,"config":609},{"href":322,"dataGaName":323,"dataGaLocation":477},{"text":325,"config":611},{"href":327,"dataGaName":328,"dataGaLocation":477},{"text":330,"config":613},{"href":332,"dataGaName":333,"dataGaLocation":477},{"text":335,"config":615},{"href":337,"dataGaName":338,"dataGaLocation":477},{"text":617,"config":618},"Sustainability",{"href":619,"dataGaName":617,"dataGaLocation":477},"/sustainability/",{"text":621,"config":622},"Diversity, inclusion and belonging (DIB)",{"href":623,"dataGaName":624,"dataGaLocation":477},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":626},{"href":342,"dataGaName":343,"dataGaLocation":477},{"text":350,"config":628},{"href":352,"dataGaName":353,"dataGaLocation":477},{"text":355,"config":630},{"href":357,"dataGaName":358,"dataGaLocation":477},{"text":632,"config":633},"Modern Slavery Transparency Statement",{"href":634,"dataGaName":635,"dataGaLocation":477},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":637,"links":638},"Contact Us",[639,642,644,646,651,656,661],{"text":640,"config":641},"Contact an expert",{"href":39,"dataGaName":40,"dataGaLocation":477},{"text":369,"config":643},{"href":371,"dataGaName":372,"dataGaLocation":477},{"text":374,"config":645},{"href":376,"dataGaName":377,"dataGaLocation":477},{"text":647,"config":648},"Status",{"href":649,"dataGaName":650,"dataGaLocation":477},"https://status.gitlab.com/","status",{"text":652,"config":653},"Terms of use",{"href":654,"dataGaName":655,"dataGaLocation":477},"/terms/","terms of use",{"text":657,"config":658},"Privacy statement",{"href":659,"dataGaName":660,"dataGaLocation":477},"/privacy/","privacy statement",{"text":662,"config":663},"Cookie preferences",{"dataGaName":664,"dataGaLocation":477,"id":665,"isOneTrustButton":15},"cookie preferences","ot-sdk-btn",{"items":667},[668,670,672],{"text":652,"config":669},{"href":654,"dataGaName":655,"dataGaLocation":477},{"text":657,"config":671},{"href":659,"dataGaName":660,"dataGaLocation":477},{"text":662,"config":673},{"dataGaName":664,"dataGaLocation":477,"id":665,"isOneTrustButton":15},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"featuredPost":679,"allPosts":705,"totalPages":3108,"initialPosts":3109},{"_path":680,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":681,"content":689,"config":698,"_id":701,"_type":17,"title":702,"_source":18,"_file":703,"_stem":704,"_extension":21},"/en-us/blog/developer-relations-at-gitlab-what-weve-learned-since-our-start",{"title":682,"description":683,"ogTitle":682,"ogDescription":683,"noIndex":6,"ogImage":684,"ogUrl":685,"ogSiteName":686,"ogType":687,"canonicalUrls":685,"schema":688},"Developer Relations at GitLab: What we've learned since our start","DevRel is key to success for many tech companies. Find out how GitLab's DevRel program has evolved to stay aligned with the industry and our customers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672008/Blog/Hero%20Images/AdobeStock_204527293.jpg","https://about.gitlab.com/blog/developer-relations-at-gitlab-what-weve-learned-since-our-start","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developer Relations at GitLab: What we've learned since our start\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Coghlan\"}],\n        \"datePublished\": \"2024-03-13\",\n      }",{"title":682,"description":683,"authors":690,"heroImage":684,"date":692,"body":693,"category":14,"tags":694},[691],"John Coghlan","2024-03-13","Earlier this year, a tweet (are they still called that?) by [Kelsey Hightower](https://twitter.com/kelseyhightower) sparked discussion on social media and internally at GitLab. \n\n![Kelsey Hightower tweet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678041/Blog/Content%20Images/Screenshot_2024-03-08_at_8.19.09_AM.png)\n\nAt first, Kelsey's response might seem a bit flippant, but there’s an underlying truth to it: Developer Relations (short: DevRel) – and other business functions – must meet the needs of the business and your customers. However, what your stakeholders and customers need will be different in the future. Therefore, to be successful, you have to iterate to stay aligned with them. \n\nReflecting back on my five years working in Developer Relations (formerly known as Community Relations) at GitLab, our team has continuously evolved to stay aligned with the needs of our customers, our community, and the business. GitLab CEO and founder Sid Sijbrandij explains how North Star Metrics evolve in his blog post on goal-setting for startups: [Artificially constraining your company to one goal creates velocity and creativity](https://opencoreventures.com/blog/2023-06-05-artificially-constrain-one-goal-to-create-creativity-velocity/). He details the shift from attention to active users to revenue to profit. The evolution of DevRel at GitLab in many ways maps to that same journey.\n\n![What is DevRel - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678041/Blog/Content%20Images/image1.png)\n\n## Early DevRel at GitLab\n\nWhen I joined GitLab in 2018, our team was largely made up of Community Advocates, an Evangelist Program Manager (me), a Code Contributor program manager, and a director. The Community Advocates were tasked with monitoring and engaging with GitLab community members across various online channels but primarily [Hacker News](https://handbook.gitlab.com/handbook/marketing/developer-relations/developer-evangelism/hacker-news/) and Twitter. Answering questions and creating issues based on comments served to increase awareness and attention for GitLab. In addition, users learned that their questions would be answered and feedback was being heard and, frequently, acted on.\n\nAt the same time, the Code Contributor program and Evangelist program were driving growth and interest in GitLab by helping our contributors navigate the contribution process, organizing events and meetups to connect our community, and deepening our relationship with our community champions, also known as [GitLab Heroes](https://about.gitlab.com/community/heroes/). \n\nFor companies in early stages, this is how DevRel often looks. The key tactics in this phase are:\n- use low-cost tools (blogs and social media) to drive attention\n- capitalize on people’s interest to deepen relationships and create advocates and champions\n- smooth the pathways to contribute or discover content\n\n> **Tip:** Direct engagement with your community through social media and online forums drives awareness, builds trust, and increases the quality and volume of feedback on your product. \n\n## Expanding DevRel's reach \n\nNext, we ramped up programs like GitLab for Open Source and GitLab for Education. These programs helped attract to our platform key open source projects and many large academic institutions, both with large numbers of engaged users. More users meant more feedback to help us improve the product and more contributors. \n\nAs attention grew and the breadth and depth of our platform increased, we needed to better enable our customers to leverage the capabilities of GitLab’s DevSecOps Platform. This stage roughly maps to the revenue North Star Metric. To drive greater awareness and adoption, the Community Relations team underwent a critical change.\n\n> **Tip:** When looking to grow your active users, engage with partners who can bring their community to your product or platform. This strategy is often overlooked but can be a big boost to awareness and growth, setting you up for success. \n\n## Deepening the DevRel bench\n\nAs our next move, we formed a team of technical experts, known as Developer Evangelists. This team engaged in more traditional DevRel practices, those that might come to mind when asking yourself “What is DevRel?”. Internally, we referred to this team’s role as the three Cs: \n- Content creation - creating blog posts, technical talks, demos, and other content to enable our customers\n- Community engagement - engaging online and at events with our customers and community\n- Consulting - serving as internal advocates for and experts on the wider GitLab community\n\nHaving technical experts who could connect directly with customers and escalate that feedback internally helped improve the feedback loop between users and product teams. This team also deeply understood GitLab users, which improved the company's ability to enable our customers and community through content.\n\n> **Tip:** Early in your company journey, executives, product managers, and engineers play a vital role in engaging with community. As the number of users grows, you’ll need technical experts on your team who can directly engage with users and ensure customer feedback reaches key stakeholders (executives and product owners).\n\n## Continuously evolving DevRel at GitLab\n\nOver the past year, the team has evolved again.\n\n- A new vice president joined our team and has helped us become more strategic and better aligned cross-functionally.\n\n- A Contributor Success team was established to better engage and align with our customers around contributions to GitLab. Evolving from a one-person function to a full-fledged team of engineers with deep experience in open source (including multiple past contributors to GitLab), this team continuously improves the contribution experience and engages directly with customers who wish to contribute.\n\n- We updated our team name and many of our team members’ job titles to align with industry standards.\n\n- And we’ve all ramped up quite a bit on AI, perhaps you’ve heard of [GitLab Duo](https://about.gitlab.com/gitlab-duo/)? \n\nAs GitLab continues to mature as a public company, the team will continue to evolve. Through these changes, we will stay focused on increasing the efficiency and impact of our efforts for our customers, our product, and our team.\n\n## Gaining - and maintaining - executive buy-in\n\nExecutive buy-in is essential for DevRel. Look at the companies with the largest, most engaged communities and you will find that those companies also have the most active, engaged, and often highly respected founders and CEOs. This is certainly true with GitLab. \n\nGitLab’s engagement with our community began before we were even a company when Dmitriy Zaporozhets (DZ) started the open source GitLab project with [this commit](https://gitlab.com/gitlab-org/gitlab-foss/commit/9ba1224867665844b117fa037e1465bb706b3685). The engagement continued when Sid [launched GitLab on Hacker News](https://news.ycombinator.com/item?id=4428278).\n\nThe importance of community in GitLab’s success cannot be overstated, and while we’ve grown to heights that few companies reach, contributions from our customers and community remain central in [our strategy](https://handbook.gitlab.com/handbook/company/strategy/#dual-flywheels). Because of this, team members, from the highest levels of GitLab and throughout our organization, remain in active communication with our customers via issues and social forums, working hard at all times to help them succeed. Transparency is key here. Documenting our DevRel strategies in the [public GitLab handbook](https://handbook.gitlab.com/handbook/marketing/developer-relations/) enables everyone to contribute.\n\n> **Tip:** Executive support is critical when building a community.\n\n## So what is DevRel?\n\nI want to go back to the initial question that sparked this blog: What is DevRel? \n\nI’ll leave you with a quote from Emilio Salvador, vice president of Developer Relations at GitLab, which was recently merged to [our handbook page](https://handbook.gitlab.com/handbook/marketing/developer-relations): \n\n\u003Ci>\"Developer Relations (short: DevRel) operates at the intersection of technology, community, and advocacy, serving as the voice and ears of GitLab in the wider tech world. Their core mission revolves around nurturing and sustaining a vibrant, engaged community of developers, contributors, and users. This involves a multifaceted approach that includes creating educational content, organizing events and workshops, developing programs, and providing platforms for knowledge exchange and collaboration. The team not only focuses on promoting GitLab’s features and capabilities but also actively listens to and incorporates feedback from the community to inform product development and improvements.\"\u003C/i>\n\nThat’s what it is today, but if the history of DevRel at GitLab is any indication, I expect that we’ll continue to iterate going forward. \n\n> [Join our Discord community](https://discord.gg/gitlab) to continue the conversation.\n",[695,696,697],"DevOps","DevSecOps","inside GitLab",{"slug":699,"featured":15,"template":700},"developer-relations-at-gitlab-what-weve-learned-since-our-start","BlogPost","content:en-us:blog:developer-relations-at-gitlab-what-weve-learned-since-our-start.yml","Developer Relations At Gitlab What Weve Learned Since Our Start","en-us/blog/developer-relations-at-gitlab-what-weve-learned-since-our-start.yml","en-us/blog/developer-relations-at-gitlab-what-weve-learned-since-our-start",[706,728,749,770,790,812,832,850,871,891,912,930,949,968,989,1008,1026,1046,1065,1084,1106,1125,1145,1165,1185,1205,1225,1245,1264,1282,1302,1320,1340,1359,1378,1397,1416,1435,1453,1472,1492,1512,1532,1550,1570,1591,1609,1627,1646,1665,1684,1703,1723,1745,1766,1786,1807,1827,1847,1866,1886,1905,1924,1945,1964,1983,2002,2022,2041,2061,2082,2103,2123,2143,2162,2183,2203,2223,2244,2264,2285,2305,2325,2344,2364,2383,2404,2422,2440,2459,2477,2495,2513,2532,2550,2568,2584,2602,2620,2639,2657,2675,2693,2712,2730,2747,2765,2783,2801,2819,2837,2855,2873,2891,2908,2926,2944,2963,2982,2999,3018,3037,3056,3074,3091],{"_path":707,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":708,"content":714,"config":722,"_id":724,"_type":17,"title":725,"_source":18,"_file":726,"_stem":727,"_extension":21},"/en-us/blog/everyone-who-has-contributed",{"title":709,"description":710,"ogTitle":709,"ogDescription":710,"noIndex":6,"ogImage":711,"ogUrl":712,"ogSiteName":686,"ogType":687,"canonicalUrls":712,"schema":713},"Visualizing 11 years of GitLab contributions","Check out this animated video, which beautifully visualizes every contribution since our start.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682555/Blog/Hero%20Images/gitlabeveryonecontributesdna.png","https://about.gitlab.com/blog/everyone-who-has-contributed","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Visualizing 11 years of GitLab contributions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2022-12-19\",\n      }",{"title":709,"description":710,"authors":715,"heroImage":711,"date":717,"body":718,"category":14,"tags":719},[716],"Darwin Sanoy","2022-12-19","\n\nGitLab’s mission is to make it so that **[everyone can contribute](/company/mission/#mission)**. While I have been experiencing this mission for three years, I wondered if there was a way to visualize the effect of having everyone contribute over GitLab's history. It turns out there is. An open source project known as [Gource](https://gource.io/) can create an animated visualization of the commit history of a repository. I ran it against the GitLab repository and it visualizes 11 years of busy developers contributing over 300,000 commits to GitLab - covered in just under 10 minutes of video. Each node in the visualization is a file and the count of various file types is shown on the left.\n\nA big thank you to absolutely everyone who has made contributions to GitLab over the years. Hopefully this visualization helps you have a greater sense of this community.\n\nGitLab has recently published the management principles that help enable the \"everyone can contribute\" mission within GitLab. This new people management framework is called [TeamOps](/teamops/). Everyone can learn and become certified in TeamOps through GitLab’s learning portal.\n\nAs another mile marker of the power of the everyone can contribute mission, GitLab also just celebrated one year as [a public company](/blog/one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public/)!\n\nI hope you enjoy Gource’s video visualization, which is filled with the glow of light - seems very appropriate for the many global cultural festivals at this time of year that use light and fireworks to celebrate their communities!\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"1870\" height=\"937\" src=\"https://www.youtube.com/embed/QxLzyJDljpg\" title=\"\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\nIf you'd like to become a contributor, check out our [contribution guide](/community/contribute/).\n",[270,720,721],"contributors","features",{"slug":723,"featured":6,"template":700},"everyone-who-has-contributed","content:en-us:blog:everyone-who-has-contributed.yml","Everyone Who Has Contributed","en-us/blog/everyone-who-has-contributed.yml","en-us/blog/everyone-who-has-contributed",{"_path":729,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":730,"content":736,"config":743,"_id":745,"_type":17,"title":746,"_source":18,"_file":747,"_stem":748,"_extension":21},"/en-us/blog/the-many-routes-to-a-tech-career",{"title":731,"description":732,"ogTitle":731,"ogDescription":732,"noIndex":6,"ogImage":733,"ogUrl":734,"ogSiteName":686,"ogType":687,"canonicalUrls":734,"schema":735},"The many routes to a tech career","GitLab team members of different ages and backgrounds share their entry into this industry.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667236/Blog/Hero%20Images/Learn-at-GL.jpg","https://about.gitlab.com/blog/the-many-routes-to-a-tech-career","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The many routes to a tech career\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2022-10-04\",\n      }",{"title":731,"description":732,"authors":737,"heroImage":733,"date":739,"body":740,"category":14,"tags":741},[738],"Heather Simpson","2022-10-04","\nThe path to a career in technology isn’t always straight, particularly today. World and economic uncertainty, a lingering pandemic, a shift to remote work, and a need to do something that *matters* – all of these factors have caused sweeping changes in the broader workforce, in individual careers, and in the labor-shortage-plagued technology industry.\n\n## Tech career: Overview and insights\n\nEver wondered how to get into the tech world? To help try to make sense of it all, we asked three GitLab team members how they made their way into technology, and why they stay. Each has a different story to tell.\n\n### [Mark Loveless](https://gitlab.com/mloveless), Staff Security Engineer\n\nFollow Mark on [Twitter](https://twitter.com/simplenomad)\n\nI’ve been working since the age of 16 at various jobs, eventually gaining my first real tech job in 1990 as customer support at a call center. I had always had an interest in security and moved into more of a true security role in the mid-1990s, followed by my first security research job in 1999. For many in the security field, security research was fairly brand-new territory, so those of us who had been working for quite a while found ourselves reporting to individuals our own age or younger. Later on in my career this more or less became the norm, as my peers were almost always younger than me.\n\nI did, on occasion, run into prejudices involving my age, with the main two being as follows:\n- I was often overlooked for exploring new technologies as it was assumed I would not “get it.”\n\n- It was assumed that there was something wrong with me for not being in management. I love learning new things and am constantly exploring new technology. I’ve never had the desire to go into management as I preferred the independent contributor (IC) role.\n\nTo stay active and “keep up on the latest” whether it be the newest apps or what some weird meme means, well, Google is your friend. I try to stay active on at least some social media sites. I have friends and family who are much younger than me that I interact with a lot, and I ask a lot of questions. All of these steps have helped me substantially.\n\nIt is nice that when some new bit of tech comes out, I now have family and friends asking me what it's all about, and they certainly start asking if it is considered “safe” technology because they know my background. I’m fortunate that here at GitLab what knowledge I have is appreciated, no one assumes I can or cannot do something because of my age or because of preconceived ideas about what I might know at this point in my career.\n\n### [Juliet Wanjohi](https://gitlab.com/jwanjohi), Senior Security Engineer\n\nFollow Juliet on [Twitter](https://twitter.com/jay_wanjohi)\n\nI started in tech by undertaking a bachelor’s degree in Computer Science. I had an interest in software engineering before I decided to specialize in another area of interest: security. My goal was to blend my knowledge and skills in the two fields, and create a niche for myself as a security software engineer. I got the wonderful opportunity to be a part of the GitLab [Engineering Internship program](/handbook/engineering/internships/) and progressed on to become a full-time security engineer on the [Security Automation](https://handbook.gitlab.com/handbook/security/security-engineering/automation/) team in 2020.\n\nIt was both exciting and overwhelming to join such a distinguished, mature team while still being very green in the security field. I was among the youngest members of the team, which definitely drew out my imposter syndrome. Despite this, GitLab offered a welcoming environment where I felt comfortable and encouraged to bring my ideas forward, and contribute as any other team member would. About a year later, I was promoted to senior security engineer, highlighting the fact that number of years of experience does not necessarily translate to seniority; you also don’t have to be of a certain age to work at a certain level of a role. It all comes down to your skills, and a willingness to further your passion and be better at what you do.\n\nIn previous junior roles I had experienced negative effects of stereotypical thinking and unconscious bias, where my contributions were not valued because of my age. I was often overlooked when it came to opportunities to lead presentations or own projects. This made me feel like I had to work harder and put more pressure to prove myself “worthy.” Such occurrences should not discourage anyone who’s young and new to tech, but instead push you to confidently contribute your ideas, and look for ways to expand your reach by making the most of the networking and learning opportunities available to you.\n\nIt’s important to research and evaluate the culture of a company before joining it. Take a look at the initiatives the company carries out to increase awareness against these biases and the efforts to support those who are new to the field (whether they be due to age or career path). I feel lucky to be a part of GitLab, as there are [dedicated resources for team member career, growth, and development](/handbook/people-group/learning-and-development/career-development/#resources-for-team-members), including a newly created [Early Career Professionals Team Member Discussion Group](/company/culture/inclusion/tmdg-gitlab-early-career/). The group helps those that are early career professionals in the team by supporting their growth and increasing awareness in the organization around the challenges they face on a day-to-day basis.\n\n### [Pj Metz](https://gitlab.com/PjMetz), Education Evangelist\n\nFollow Pj on [Twitter](https://twitter.com/metzinaround)\n\nI made a transition into tech at 35 years old. I didn’t feel 35 when I started though because I had only just started learning about tech through coding a year before I started at GitLab. Instead, I felt 19 – brand-new and lost in a world in which I had no experience.\n\nAs a teacher, I was confident in my abilities in the classroom. I was, not to brag, a great English teacher. I was engaging, excited about the material, and worked hard to make it relatable and enjoyable for as many students as possible. Leaving after 11 years was not an easy choice, especially because my degrees felt suddenly useless. What other work could I possibly do with a Master’s degree in Secondary English Education?\n\nI joined GitLab as an Education Evangelist in our [Education Program](/handbook/marketing/developer-relations/community-programs/education-program/) and was able to draw on my former knowledge base, but not completely.\n\nAlthough I don’t have to code for my role, I have to know coding, which I had only started to learn in 2020 in between grading papers and working with a marching band at my high school. I also have to know how to talk to students and educators in a variety of concentrations. Computer Science, Information Systems, Business Analysis, and other degree programs are all looking to use [GitLab for Education](/solutions/education/), and I have to find ways to make it relevant for them.\n\nThis challenge has led to some of the hardest moments of my professional life. I can navigate an unmotivated teenager in class, a parent email about their child’s low grades that blames me, an administrator suddenly showing up for an observation, a drumline member who hasn’t figured out the rhythm for the halftime show opener, or an AP student stuck on analysis of the assigned article. However, this is different. The career I entered into is full of jargon and standards that were unfamiliar to me.\n\nI had a lot to learn. What are stock options? What is Slack? How do I structure my time if there isn’t a bell ringing to let me know the beginning and end of class? What is an expense report? People expect someone my age to know these things already.\n\nI have a sticker on my laptop case that looks like the kind you’d get at a small meetup, the kind that says “HELLO, I’m...” and then there is a space to write your name. This sticker says: “Hello, I’m Still Learning.” I have this not so people can lower their expectations of me; instead, its purpose is to highlight that we should all still be learning and I’m going to be open about what I don’t know. I’m doing my best to turn my perceived shortcomings into strengths by bringing a mindset of [iteration](https://handbook.gitlab.com/handbook/values/#iteration) to my work, something GitLab helped me realize was important.\n\nI’m still learning, and feel so far behind some of my colleagues, but GitLab and my team have worked hard to create a space for me to feel comfortable while I work through this career change. It helps that my manager is also a former educator, so she understands the change from education to the corporate world.\n\nShe reminds me to take time for myself after each conference or lecture. My onboarding buddy still meets with me regularly to help me work through something technical or to give advice about a project I’m working on. Every opportunity to connect with people as a person, whether through a [coffee chat or the “Donut-be-strangers” Slack bot](/company/culture/all-remote/informal-communication/#coffee-chats), which matches me with another, random team member, helps me remain grounded in the humanity of my work. Every team meeting I’m in has a reminder of the importance of taking time for ourselves, and a section in the agenda to cheer each other’s accomplishments. I couldn’t ask for a better place to have my first non-teaching job.\n\n### What’s your story?\n\nHow’d you get into tech? Make any pit stops along the way, or have you always been working in this industry? Let us know in the comments field. Also, if you are considering GitLab as your next step, check out our handbook to learn more about [our culture](/company/culture/), and then take a peek at our [open roles](/jobs/all-jobs/)!\n",[742,697],"careers",{"slug":744,"featured":6,"template":700},"the-many-routes-to-a-tech-career","content:en-us:blog:the-many-routes-to-a-tech-career.yml","The Many Routes To A Tech Career","en-us/blog/the-many-routes-to-a-tech-career.yml","en-us/blog/the-many-routes-to-a-tech-career",{"_path":750,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":751,"content":757,"config":764,"_id":766,"_type":17,"title":767,"_source":18,"_file":768,"_stem":769,"_extension":21},"/en-us/blog/virtual-reality-team-building",{"title":752,"description":753,"ogTitle":752,"ogDescription":753,"noIndex":6,"ogImage":754,"ogUrl":755,"ogSiteName":686,"ogType":687,"canonicalUrls":755,"schema":756},"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":752,"description":753,"authors":758,"heroImage":754,"date":760,"body":761,"category":14,"tags":762},[759],"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",[763],"remote work",{"slug":765,"featured":6,"template":700},"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":771,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":772,"content":778,"config":784,"_id":786,"_type":17,"title":787,"_source":18,"_file":788,"_stem":789,"_extension":21},"/en-us/blog/how-gitlab-iteration-value-drives-innovation-through-the-engineering-organization",{"title":773,"description":774,"ogTitle":773,"ogDescription":774,"noIndex":6,"ogImage":775,"ogUrl":776,"ogSiteName":686,"ogType":687,"canonicalUrls":776,"schema":777},"How the GitLab iteration value drives innovation through the engineering","GitLab is a unique place to be a developer. Here's why.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668224/Blog/Hero%20Images/inside-our-new-development-team-lead-persona.jpg","https://about.gitlab.com/blog/how-gitlab-iteration-value-drives-innovation-through-the-engineering-organization","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the GitLab iteration value drives innovation through the engineering\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-06-10\",\n      }",{"title":773,"description":774,"authors":779,"heroImage":775,"date":781,"body":782,"category":14,"tags":783},[780],"GitLab","2022-06-10","GitLab is focused on helping developers iterate faster and innovate more collaboratively – and that focus on enabling iteration extends to our own developer culture.\n\nAs an organization, our [CREDIT values](https://handbook.gitlab.com/handbook/values/) are hardwired into our operations and culture. This empowers our development teams to work together – using our own product – to offer QA, feedback, and strategies that make everyone’s work stronger and help our organization iterate faster. \n\nWe asked several engineers and engineering leaders at GitLab to tell us, in their own words, how our values come to life in our engineering organization and how that makes GitLab a unique place to be a developer.\n\n## What attracts engineers to GitLab\n\nTo start, we wanted to understand what attracted some of our current engineers and engineering leaders to join GitLab.\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“I was attracted to GitLab because I knew that I had the ability to make an impact. Being remote has shattered the walls between people and teams, so anybody can approach anybody. If something means something to you, you can really work on it. This culture of transparency and collaboration is really important to me.” - [Sri Rangan](/company/team/#sri19), Fullstack Engineer, Incubation Engineering Team\n\n“People are attracted to the global diversity of the team and working asynchronously. I think we have a special working culture at GitLab. When you join, whether you're the manager of multiple people or a manager of yourself, you work asynchronously regardless of where your teams are.” - [Mek Stritti](/company/team/#meks), VP, Quality\n\n“Before coming to GitLab, I was a frontend, backend, Android developer, data scientist, and machine learning engineer, among other things. But the thing about how I work is that I like to switch between those roles. And normally in companies, you can't grow across all those roles. You need to grow as a specialist, not a generalist. But within the Incubation Engineering team, I get to do that.” - [Eduardo Bonet](/company/team/#eduardobonet), Fullstack Engineer, Incubation Engineering Team\n\n“The feedback that I quite often hear from engineers is just how strong the team is around them, and how collaborative the rest of the organization is. For my team in particular, a big part of their success is to be able to collaborate effectively with both the people that they work with and other teams. A lot of candidates are attracted to GitLab by the transparency value. Transparency is something that we really try to encourage, and it becomes a big mindset.” - [Bartek Marnane](/company/team/#bmarnane), VP, Incubation Engineering\n\n## How we ensure collaboration across the organization \n\nBeyond the aspects of GitLab that attracted many of our current engineers, it was clear that the culture they experienced during their time here ensured there was collaboration across various teams within our engineering organization. \n\n\"We have an organization that supports each other. You propose a feature, you're building something, and you can collaborate very easily across the globe, across departments with people in infrastructure and security. So when you're building something it's not all on you to ensure its stability and reliability and safety – the entire organization takes ownership of that.” - [Darby Frey](/company/team/#darbyfrey), Fullstack Engineer, Incubation Engineering\n\n“We have a strong culture of collaboration, people reach out and say, “Hey, I'm looking for someone to dogfood this,” and we're always willing to pick those up. Our team has a goal to dogfood a new feature every milestone.” - [Kyle Wiebers](/company/team/#kwiebers), Manager, Engineering, Quality Team\n\n## Why we believe in iteration (and building boring solutions when they work)\n\nOur engineering teams are always thinking about how to best deliver value and receive feedback along the way. It turns out that iteration and building boring solutions that can be delivered quickly is a great way to deliver value and receive feedback. For example, our [Incubation team](/handbook/engineering/development/incubation/) is working to move away from the natural instinct to develop a prototype, get it working, then putting it into the product.\n\n“We’re asking,'how can we look at what you are planning on doing, and then divide that into milestones where every one of those milestones can be integrated into the product?' So we get value out of it and get feedback out of it as well.” - Bartek \n\nAcross other parts of GitLab’s engineering organization, the same type of approach is being embraced.\n\n“For my team, what we try to do is identify a big problem, and then identify lots of small solutions towards that problem. The embrace of efficiency and iteration really aligns with the team that I'm on.” - Kyle\n\n“We want to ship new features quickly so we can get feedback. That first version isn’t going to be perfect, but we're okay with that. We all agree that it's better to get feedback than to spend six months polishing every pixel on a feature that maybe no one wants, and then having to throw it out.” - Darby\n\nWhether it’s our Incubation Engineering team or Quality in Engineering team, embracing iteration and collaboration as a way to achieve results has become the standard approach. \n\nLearn more about how you can contribute to a culture of empathy and productivity by launching or progressing your career at GitLab by checking out our [careers page](/jobs/).\n",[695,695,697],{"slug":785,"featured":6,"template":700},"how-gitlab-iteration-value-drives-innovation-through-the-engineering-organization","content:en-us:blog:how-gitlab-iteration-value-drives-innovation-through-the-engineering-organization.yml","How Gitlab Iteration Value Drives Innovation Through The Engineering Organization","en-us/blog/how-gitlab-iteration-value-drives-innovation-through-the-engineering-organization.yml","en-us/blog/how-gitlab-iteration-value-drives-innovation-through-the-engineering-organization",{"_path":791,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":792,"content":798,"config":806,"_id":808,"_type":17,"title":809,"_source":18,"_file":810,"_stem":811,"_extension":21},"/en-us/blog/keys-to-success-for-product-operations",{"title":793,"description":794,"ogTitle":793,"ogDescription":794,"noIndex":6,"ogImage":795,"ogUrl":796,"ogSiteName":686,"ogType":687,"canonicalUrls":796,"schema":797},"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":793,"description":794,"authors":799,"heroImage":795,"date":801,"body":802,"category":14,"tags":803},[800],"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",[804,697,805,763],"collaboration","workflow",{"slug":807,"featured":6,"template":700},"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":813,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":814,"content":820,"config":826,"_id":828,"_type":17,"title":829,"_source":18,"_file":830,"_stem":831,"_extension":21},"/en-us/blog/how-gitlabs-customer-and-partner-focus-fuels-our-culture",{"title":815,"description":816,"ogTitle":815,"ogDescription":816,"noIndex":6,"ogImage":817,"ogUrl":818,"ogSiteName":686,"ogType":687,"canonicalUrls":818,"schema":819},"How GitLab's customer and partner focus fuels our culture","It’s an exciting time to be working in a customer- or partner-facing role at GitLab. Our sales team members explain why.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679412/Blog/Hero%20Images/sales_blog_image_tiny.jpg","https://about.gitlab.com/blog/how-gitlabs-customer-and-partner-focus-fuels-our-culture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab's customer and partner focus fuels our culture\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jake Foster\"}],\n        \"datePublished\": \"2022-05-03\",\n      }",{"title":815,"description":816,"authors":821,"heroImage":817,"date":823,"body":824,"category":14,"tags":825},[822],"Jake Foster","2022-05-03","\n\nIt’s an exciting time to be working in a customer- or partner-facing role at GitLab. Our role with customers is to build personalized relationships and demonstrate how we can help them solve problems with a best-in-class DevOps platform.\n\nAs we grow, our customer and partner focus plays a key role in building a healthy, connected workplace culture at GitLab. So we asked some of our leaders and team members from across the Sales, Channel Partner, and Account Management teams to share their insights. Here’s what we learned.\n\n## The opportunity we have to become the leader in DevOps means hiring more top-tier talent\n\n\"We are on a journey as a company where we believe we have got this exciting market opportunity. We've got a great product that fits the market really well, and that product is an industry leader.\n\n\"We believe a lot of companies are going to buy DevOps. We need to make sure that they buy that from us and that's a hard thing. That execution requires lots of top talent. We want to keep growing, as a team and individually, to capture more market share. That's going to take a lot of people who are great at what they do.\"\n\n- Michael McBride (a.k.a \"McB\"), Chief Revenue Officer\n\n## Why GitLab is an ideal place to grow in a sales or channel partner role\n\n\"We have an integrated GTM with our field sales teams and channels and alliances partners. I look after both the sales organization that manages those partners and supports them and their engagement with our direct selling force, as well as the programs and enablement and functions that it takes to integrate those partners into our go-to-market.\n\n\"I believe we've got great technology, great market timing, high customer need, lots of customer value, and a great product. That makes for a pretty awesome mix from a partnering perspective. It’s lots of fun to manage partners who are aiming to grow their businesses at the same time. It’s going to make the partners very happy.\"\n\n- Michelle Hodges, VP, WW Channels\n\n\"At my previous company, we were an unknown entity and you had to really pull out all the stops to get people just to take a call with you or to test the product or buy the product. Whereas, with GitLab, I would get on calls and customers are super excited to meet people from GitLab. There were quite a few cases where people were already going to buy GitLab, but they just needed someone to help them understand what they wanted to buy. It was a salesperson's dream because you are working with people who not just love the product, but love what the company stands for.\n\n\"I remember one time I was in a coffee shop, and I had a GitLab sticker on my laptop. Someone saw that – he was a developer, he came up to me and said, 'Wow, you work at GitLab. I love that company and we use it in our team.' I felt a bit like a celebrity getting spotted on the streets.\"\n\n- Anthony Ogunbowale - Thomas, Named Account Executive, EMEA\n\n## What makes our culture unique\n\n\"The things in the [company handbook](https://handbook.gitlab.com/handbook/) can be kind of unbelievable to folks from the outside, when they say there's unlimited vacation time or they value results, not hours. But after being here for three years, it's true – there’s a real emphasis on valuing productivity and results. And, when people produce results, they’re rewarded.\"\n\n- Kevin Vogt, Federal Technical Account Manager\n\n\"I am not joking when I say this: This is the most successful I've ever felt in my career. And a lot of it is down to our values.\n\n\"We have a value system that's called [CREDIT](https://handbook.gitlab.com/handbook/values/): It's collaboration; results; efficiency; diversity, inclusion, and belonging; iteration; and transparency. You will find in every engagement with a GitLab team member that they work towards exhibiting those things in a really authentic, intentional manner. It makes it a great place to build relationships, but also to get your job done. It creates innovation, speed, and teamwork in a way that I haven't found before.\"\n\n- Michelle Hodges\n\n## How GitLab sets its team members up for success\n\n\"We 'dogfood' our tools. We use GitLab for everything from HR to legal – the entire company uses GitLab as a platform.\n\n\"The company is also great with training. Any time that I've ever wanted training for any kind of need in my business role, they've always provided it and reimbursed it. I just finished a month's worth of training classes on how to be a successful manager. That's my first month going into that role, trying to make sure that I can be set up for success in it.\"\n\n- Kevin Vogt\n\n\"Every conversation with the customer is a collaboration. In pre-sales, we have a solutions architect, who's more of a technical person, and they can help lead on answering technical questions or do demos and proof of concepts. And then, depending on how the conversation is going, we might bring on someone from Product, in relation to what the customer's looking at. Everyone in the organization works together to help the customer understand and feel comfortable with the solution.\"\n\n- Anthony Ogunbowale - Thomas\n\n\"McB, our CRO, does his own Reverse Ask Me Anything session for team members that are underrepresented in tech to understand what the experience is on the GitLab Sales team. And also what upward mobility and trajectory could look like in the company.\n\n\"I feel very supported here. I feel empowered. It's one of the first jobs I've felt where they just trust me. They tell me to take things and run with it.\"\n\n- Marcus Carter, Senior Sales Recruiter\n\n## What we’re looking for as we grow our team\n\n\"I would say, curiosity is huge. Somebody who's curious and doesn't mind asking questions. I'd say somebody who is customer-focused, somebody who's excited about our customers, and somebody who's excited about technology as a whole, and in how technology is set to advance us. It's someone who is tenacious, somebody who is unrelenting and trying to offer solutions.\"\n\n- Marcus Carter\n\n\"This is a place where we believe we have a large market in every single one of our territories. There are customers that need the right DevOps solution and our product fits with those customers really well. So that leaves one last thing, sales skill.\n\n\"That’s great for a sales rep. If I've got the right product and a solid market, I'm excited, because I know I can deliver the sales skill, especially if I've got the marketing support and all the other things that GitLab has.\"\n\n- Michael McBride\n\n\nIf GitLab sounds like the place for you, there’s plenty more to learn about what it’s like to be a part of our team on our [careers site](/jobs/). You can also [learn more about open roles on our team](https://boards.greenhouse.io/gitlab).\n",[697,742,695],{"slug":827,"featured":6,"template":700},"how-gitlabs-customer-and-partner-focus-fuels-our-culture","content:en-us:blog:how-gitlabs-customer-and-partner-focus-fuels-our-culture.yml","How Gitlabs Customer And Partner Focus Fuels Our Culture","en-us/blog/how-gitlabs-customer-and-partner-focus-fuels-our-culture.yml","en-us/blog/how-gitlabs-customer-and-partner-focus-fuels-our-culture",{"_path":833,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":834,"content":840,"config":844,"_id":846,"_type":17,"title":847,"_source":18,"_file":848,"_stem":849,"_extension":21},"/en-us/blog/preventing-burnout-a-managers-toolkit",{"title":835,"description":836,"ogTitle":835,"ogDescription":836,"noIndex":6,"ogImage":837,"ogUrl":838,"ogSiteName":686,"ogType":687,"canonicalUrls":838,"schema":839},"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":835,"description":836,"authors":841,"heroImage":837,"date":823,"body":842,"category":14,"tags":843},[780],"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",[697,763,742],{"slug":845,"featured":6,"template":700},"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":851,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":852,"content":858,"config":865,"_id":867,"_type":17,"title":868,"_source":18,"_file":869,"_stem":870,"_extension":21},"/en-us/blog/advice-for-women-seeking-careers-in-tech",{"title":853,"description":854,"ogTitle":853,"ogDescription":854,"noIndex":6,"ogImage":855,"ogUrl":856,"ogSiteName":686,"ogType":687,"canonicalUrls":856,"schema":857},"Women in Tech: Use Your Uniqueness as a Career Superpower","GitLab's Women's Team Member Resource Group shares tips on how to make a mark in this industry.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677856/Blog/Hero%20Images/collaboration.png","https://about.gitlab.com/blog/advice-for-women-seeking-careers-in-tech","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Use your uniqueness as a superpower and other advice for women seeking careers in tech\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kyla Gradin Dahl\"}],\n        \"datePublished\": \"2022-04-04\",\n      }",{"title":859,"description":854,"authors":860,"heroImage":855,"date":862,"body":863,"category":14,"tags":864},"Use your uniqueness as a superpower and other advice for women seeking careers in tech",[861],"Kyla Gradin Dahl","2022-04-04","\n\nGitLab's [Women's Team Member Resource Group (TMRG)](/company/culture/inclusion/tmrg-gitlab-women/), a forum for women to find their voice and be heard, celebrated Women's History Month by reflecting on what it means to be a woman in technology, how they arrived here, and who inspires them. We also gathered advice for other women who want to enter or advance in this industry.\n\n## Tips for women in tech\n\nAt GitLab, we work within our [CREDIT values](https://handbook.gitlab.com/handbook/values/#credit) every day. The organization’s [team member resource groups](/company/culture/inclusion/erg-guide/) amplify our value of [Diversity, Inclusion, and Belonging](https://handbook.gitlab.com/handbook/values/#diversity-inclusion). And, aligned with our value of [transparency](https://handbook.gitlab.com/handbook/values/#transparency), we’re able to share the voices of our TMRG here with our wider GitLab community.\n\nBelow are perspectives from:\n- [Jane Gianoutsos](https://gitlab.com/jgianoutsos), Manager, Support Engineering\n- [Michelle Hodges](https://gitlab.com/mwhodges), VP of Global Channels\n- [Taharah Nix](https://gitlab.com/tnix), Associate Paralegal, Employment\n- [Sherrod Patching](https://gitlab.com/spatching), Senior Director, Technical Account Manager\n- [Juliet Wanjohi](https://gitlab.com/jwanjohi), Senior Security Engineer, Security Automation\n\n**What advice would you give to women who are considering a career in technology?**\n\n**Michelle:** Unapologetically go for it. The industry requires diverse collaborators and contributors to make sure that the technology that runs the world, our schools, our homes, etc. is made by people with diverse backgrounds, perspectives, and life experiences. Just by showing up in technology, you make a meaningful impact on the world today and for the future. \n\n**Sherrod:** Honestly, I believe that anyone from any background can be successful and fulfilled in tech. Before pivoting into tech, I started my career as a musician. In tech, we are constantly creating, which is incredibly fulfilling as a creative person.\n\n**Taharah:** I would say that there's a place for everyone in tech. A lot of times people can be intimidated when they think of working for a tech company because they may not have the experience that they think they need. However, just as with any other company, there are a lot of different business needs within the company and all perspectives are necessary. So, I would say think about what you're most comfortable doing and expand from there. There are endless opportunities for learning.\n\n**Juliet:** The first step when considering moving into a career in the technology industry would be to come up with a strategy - explore the different pathways available and identify your area of interest. The next step would be to look at ways of leveling up your skills and knowledge by doing certifications, reading books, and listening to podcasts/audiobooks related to your area of interest. \n\nLeverage your network and community connections by reaching out and having [coffee chats](/company/culture/all-remote/informal-communication/#coffee-chats) with individuals who are in the tech field to get more insight and advice on how they got into the industry and tips that helped them along the way.\n\n**What tips do you have for women working towards being senior leaders?**\n\n**Michelle:** Leadership requires authenticity in self while being focused on the success of those you lead. Know where you want to go and build those experiences into your CV intentionally. Grit and resilience will serve you well - so build them into your wheelhouse.\n\n**Sherrod:** Lead by example, even if you are in an individual contributor role. Some of the best leaders I know led long before they had a team. Know where you are going, determine the milestones to getting there, and follow through on execution.\n\n**Juliet:** Taking the lead in shaping conversations about your career path with your manager is definitely important. You can do this by drawing up a roadmap or a plan of what you aspire to achieve, and where you'd like to be in the future, and being accountable by making a habit of evaluating your progress towards your goal of becoming a senior leader. Another essential tip would be to work towards increasing your sphere of influence and forming a network of professional relationships outside of your immediate team, as this opens a doorway for more collaboration opportunities with other teams and a chance to continually hone and fine-tune your leadership skills.\n\n**Did you have any women mentors (formal or informal) when you were building your career? What was some key advice they gave you and how important do you think mentorship is for future leaders?** \n\n**Michelle:** Your “otherness” is your superpower. You have a unique way of approaching problems, leading people, and showing up in a team setting - lean into that. Don’t let your otherness impact your authenticity. Not always but often, boys are raised to be brave while girls are raised to be perfect. Do not let your desire to be perfect stand in the way of taking risks, being brave, and being authentic. \n\n**Sherrod:** I have had mentors, but not women mentors. I can't advocate enough for having someone further along than you that can help you see things from angles you can't yet see from.\n\n**Juliet:** Yes, and I still do! One key [piece of] advice that I received at the start of my career from one of my mentors was to leap out of my comfort zone and go where the opportunities are. Waiting for your career to build itself rarely works, it is up to you to be committed and work towards getting those opportunities that you feel will uplift you and get you one step closer to your goal. \n\nMentorship is an integral piece for future leaders because it gives them an opportunity to shadow and seek advice from women who have had more experience with climbing the tech career ladder, and can help them map out their career path in accordance with their interests and goals. Having a mentor also gives them the chance to receive honest and constructive feedback on any challenges that they may face, and how they can potentially turn these challenges into growth opportunities!\n\n**What has been the proudest moment in your career so far and why?** \n\n**Michelle:** Seeing previous employees and mentees thrive in their careers.\n\n**Sherrod:** One moment that comes to mind is having led the acquisition of another company in my previous role before GitLab. I led the process and was considerably out of my comfort zone, which is when I learn the most. \n\n**Jane:** I’m proud of:\n- Earning not only the trust but the respect of a team member who was adamant I was the wrong person for the role when I was being appointed to it.\n- The card I received at a farewell saying I was the most effective manager the highly regarded engineer had worked for.\n- The unexpected recommendation and thanks written for me on LinkedIn by someone I had encouraged to notice his leadership skills and who went on to do just that.\n- The call I got from a third party after another person’s farewell from an ex-employer to tell me how much that departing person referred to my influence during their farewell speech.\n- The customer who insisted on coming to my farewell with flowers and champagne.\n- The peer I first worked with in 2005 who I still discuss career growth and life decisions with.\n\n**How important are GitLab’s values in building an inclusive culture for women at GitLab?** \n\n**Michelle:** Vitally important. In the workplace, whether it's GitLab or not, women have a responsibility to drive the change that creates not only an equal workplace but an equitable workplace. Equitable meaning working motherhood, caretaking, many women’s belief they need to be perfect, the imbalance of gender or URG representation, etc. - all these and more need to be accounted for to create a truly equitable work environment \n\nGitLab’s culture provides a space for women to lean into this responsibility, speak up, and make iterative and incremental changes that will impact future generations of women in the workplace and women leadership.\n\n**Sherrod:** Incredibly. I am a wife and a mom of two little girls first and foremost, and GitLab makes it possible to have a career and a career trajectory while also not sacrificing my family. \n\n**Jane:** GitLab has genuinely been life-changing for me. Through necessity, I’ve always been ok with being often the only woman in the tech team or even the company - or at least I thought I was ok with it!\n\nThen I started working here and discovered what it was to have space held for every voice, where I wasn’t reliant on allies to hold space or amplify my voice or sanity-check my suspicions about bad behaviors. Where [microaggressions](https://handbook.gitlab.com/handbook/values/#understanding-the-impact-of-microaggressions) are understood and challenged if they occur, where I don’t have to fight to advocate for the [uniqueness of people](https://handbook.gitlab.com/handbook/values/#quirkiness) but am empowered to support the fulness of all my team and colleagues, where we [normalize talking to each other](https://handbook.gitlab.com/handbook/values/#see-something-say-something) when we see old bad habits in play and where we do that with kindness.\n\nI’ve been moved to tears by people’s kindness, by the depth of inclusion I have come to experience here. I am often left pondering how very different things would have been for me had I experienced this in the early years of my career. I have no doubt mine would have been a very different journey, where I could have expended less energy on battling self-doubt and on healing, and more on growth and contribution.\n\n_The Women’s TMRG also invited [Christie Lenneville](/handbook/product/ux/one-pagers/christie-readme/), GitLab VP of UX, to share her experiences during a live speaker series, open to everyone at the company. You can watch the replay of the conversation below._\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/a10N6xYB7Ps\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\n\n",[697,742,804],{"slug":866,"featured":6,"template":700},"advice-for-women-seeking-careers-in-tech","content:en-us:blog:advice-for-women-seeking-careers-in-tech.yml","Advice For Women Seeking Careers In Tech","en-us/blog/advice-for-women-seeking-careers-in-tech.yml","en-us/blog/advice-for-women-seeking-careers-in-tech",{"_path":872,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":873,"content":879,"config":885,"_id":887,"_type":17,"title":888,"_source":18,"_file":889,"_stem":890,"_extension":21},"/en-us/blog/how-to-navigate-the-great-resignation",{"title":874,"description":875,"ogTitle":874,"ogDescription":875,"noIndex":6,"ogImage":876,"ogUrl":877,"ogSiteName":686,"ogType":687,"canonicalUrls":877,"schema":878},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749679453/Blog/Hero%20Images/remote-work.png","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":874,"description":875,"authors":880,"heroImage":876,"date":882,"body":883,"category":14,"tags":884},[881],"Betsy Bula","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",[742,763],{"slug":886,"featured":6,"template":700},"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":892,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":893,"content":899,"config":906,"_id":908,"_type":17,"title":909,"_source":18,"_file":910,"_stem":911,"_extension":21},"/en-us/blog/adopt-agile-and-devops-for-ibm-z",{"title":894,"description":895,"ogTitle":894,"ogDescription":895,"noIndex":6,"ogImage":896,"ogUrl":897,"ogSiteName":686,"ogType":687,"canonicalUrls":897,"schema":898},"The benefits of DevOps practices for IBM Z","GitLab aims to provide a unified enterprise-wide DevOps platform with enhanced support for IBM Z. Here are three areas that can start to align DevOps and mainframe development.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/adopt-agile-and-devops-for-ibm-z","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The benefits of DevOps practices for IBM Z\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vick Kelkar\"}],\n        \"datePublished\": \"2021-09-10\",\n      }",{"title":894,"description":895,"authors":900,"heroImage":896,"date":902,"body":903,"category":14,"tags":904},[901],"Vick Kelkar","2021-09-10","\n\nAs more organizations adopt open source software, [DevOps](/topics/devops/) and cloud computing, teams are moving towards a hybrid approach to application development and deployments. This is a particular challenge for siloed mainframe development teams that typically work within their own development tools – and those tools are are not the same ones used by their distributed developer counterparts. These disparate toolsets are not integrated between build, package, test, and deploy steps. GitLab aims to provide a [unified enterprise-wide DevOps platform](/solutions/devops-platform/) with enhanced support for IBM z/OS® applications. Here are three critical areas to focus on that can help bridge the gap between mainframe and \"modern\" DevOps development.\n\n## Common workflows for hybrid environments\n\nDevOps is naturally aligned to Agile processes with its focus on continuous improvements, freqent releases and adherence to business objectives. As organizations adopt a hybrid infrastructure to meet their needs, it becomes extremely important to have a common workflow (and tools!) for continuous software development. The development workflow should be the same whether you are building a [cloud native](/topics/cloud-native/) container application for Red Hat OpenShift or whether you are refactoring COBOL applications on IBM Z. Ideally, in both scenarios, the same source code management, along with Git commit and merge-request workflows should be used, regardless of the type of application code or where it is deployed. The advantage of using the same software development lifecycle methodology and tools allows an organization to drive an enterprise-wide DevOps strategy.  Additionally, this helps organizations to attract mainframe developers, allowing them to move between mainframe and cloud-based application development projects,  enhancing developer job satisfaction, growth and retention.\n\n## Security and compliance vs speed\n\nIn an enterprise-wide mission critical application where security and compliance are paramount, a deployment cadence of once a quarter is considered satisfactory, but in a consumer-facing containerized application (using [microservices](https://about.gitlab.com/topics/microservices/)), multiple deployments can be easily achieved in a single day. Release speeds can differ but software security isn't negotiable. Every organization needs to ensure security by making sure best practices are followed for all application development processes. Ultimately, the ideal situation for every organization would be shortened development cycle times, while at the same time enabling developers to identify any security issues ahead of time. Rather than integrating security tools into the complex DevOps toolchain, a single application for the entire software development lifecycle can improve your security risk posture, simplify compliance/audit, and accelerate software development.  With [DevSecOps methodologies](/solutions/security-compliance/), security testing becomes an integral part of the software development lifecycle (SDLC) eliminating friction between siloed development and security teams, and dramatically improving code quality and deployment cycle times.\n\n## Increase collaboration and automation\n\nDevOps practices and elastic cloud computing resources helpdevelopers become more self-sufficient as they deploy their applications at scale. They can request identical compute resources on every new release of their application. Automating the deployment steps through a CI/CD pipeline makes rolling out the new version of an application more efficient and less prone to errors. While [CI/CD tooling](/topics/ci-cd/) increases automation for software inspection, development and delivery, resilient systems like IBM Z or RedHat OpenShift Container Platform have their own built-in automation to address application testing, reliability and availability.\n\nMost organizations have a security team that looks at the risk posture of an application. This can range from high availability of applications for business continuity reasons, to a vulnerability in a software library.  In most cases, the security team is much smaller than the application development teams and uses different tools to analyze risks. This creates an impediment for organizations to scale and applications to scale in production. Using the same workflow and shared data model between security and development teams allows knowledge sharing and helps break down team silos. For example, a Red Hat OpenShift application developer can create a security Issue in their GitLab Ultimate DevOps Platform, and the security team can comment on that same issue and analyze the risk.\n\nCloud computing and its elasticity offers advantages for certain applications and use cases while on-premise systems like IBM Z offer advantages for high transaction applications and use cases. Red Hat Openshift offers a cloud native approach to application deployments. GitLab Ultimate integrates with container platforms as well as IBM Z environments. This gives customers the flexibility to deploy their application in their desired environment while helping increase automation and Agile practices in their organization.\n\nTo learn more\n\n* Visit[ GitLab Ultimate for IBM z/OS](https://www.ibm.com/products/gitlab-ultimate/zos)\n* Hear GitLab and IBM experts discuss the benefits of integrating GitLab into your DevOps solution -[Automate your Z DevOps CI/CD pipeline with GitLab](https://mediacenter.ibm.com/id/1_djnxx05v)\n* Learn about the management of mainframe apps lifecycle with[IBM Z DevOps and GitLab](https://mediacenter.ibm.com/id/1_oxj8eseu).\n* Take advantage of the[DevOps Acceleration Program](https://ibm.github.io/mainframe-downloads/DevOps_Acceleration_Program/devops-acceleration-program.html) to partner with IBM for a successful transformation\n",[905,804,805],"agile",{"slug":907,"featured":6,"template":700},"adopt-agile-and-devops-for-ibm-z","content:en-us:blog:adopt-agile-and-devops-for-ibm-z.yml","Adopt Agile And Devops For Ibm Z","en-us/blog/adopt-agile-and-devops-for-ibm-z.yml","en-us/blog/adopt-agile-and-devops-for-ibm-z",{"_path":913,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":914,"content":919,"config":924,"_id":926,"_type":17,"title":927,"_source":18,"_file":928,"_stem":929,"_extension":21},"/en-us/blog/five-ways-to-scale-remote-work",{"title":915,"description":916,"ogTitle":915,"ogDescription":916,"noIndex":6,"ogImage":876,"ogUrl":917,"ogSiteName":686,"ogType":687,"canonicalUrls":917,"schema":918},"5 Ways to scale remote work on your team","Learn how technology businesses are embracing the future of work by going all-remote.","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":915,"description":916,"authors":920,"heroImage":876,"date":921,"body":922,"category":14,"tags":923},[881],"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",[763],{"slug":925,"featured":6,"template":700},"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":931,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":932,"content":937,"config":943,"_id":945,"_type":17,"title":946,"_source":18,"_file":947,"_stem":948,"_extension":21},"/en-us/blog/best-practices-remote-engineering",{"title":933,"description":934,"ogTitle":933,"ogDescription":934,"noIndex":6,"ogImage":855,"ogUrl":935,"ogSiteName":686,"ogType":687,"canonicalUrls":935,"schema":936},"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://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":933,"description":934,"authors":938,"heroImage":855,"date":940,"body":941,"category":14,"tags":942},[939],"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",[763],{"slug":944,"featured":6,"template":700},"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":950,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":951,"content":957,"config":962,"_id":964,"_type":17,"title":965,"_source":18,"_file":966,"_stem":967,"_extension":21},"/en-us/blog/agile-for-remote-work",{"title":952,"description":953,"ogTitle":952,"ogDescription":953,"noIndex":6,"ogImage":954,"ogUrl":955,"ogSiteName":686,"ogType":687,"canonicalUrls":955,"schema":956},"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":952,"description":953,"authors":958,"heroImage":954,"date":959,"body":960,"category":14,"tags":961},[939],"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",[905,763,697],{"slug":963,"featured":6,"template":700},"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",{"_path":969,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":970,"content":976,"config":983,"_id":985,"_type":17,"title":986,"_source":18,"_file":987,"_stem":988,"_extension":21},"/en-us/blog/considerations-for-going-hybrid-remote",{"title":971,"description":972,"ogTitle":971,"ogDescription":972,"noIndex":6,"ogImage":973,"ogUrl":974,"ogSiteName":686,"ogType":687,"canonicalUrls":974,"schema":975},"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":971,"description":972,"authors":977,"heroImage":973,"date":979,"body":980,"category":14,"tags":981},[978],"Darren Murph","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",[763,742,982],"demo",{"slug":984,"featured":6,"template":700},"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":990,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":991,"content":996,"config":1002,"_id":1004,"_type":17,"title":1005,"_source":18,"_file":1006,"_stem":1007,"_extension":21},"/en-us/blog/remote-pair-programming-tips",{"title":992,"description":993,"ogTitle":992,"ogDescription":993,"noIndex":6,"ogImage":855,"ogUrl":994,"ogSiteName":686,"ogType":687,"canonicalUrls":994,"schema":995},"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":992,"description":993,"authors":997,"heroImage":855,"date":999,"body":1000,"category":14,"tags":1001},[998],"Rebecca Dodd","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",[804,763],{"slug":1003,"featured":6,"template":700},"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":1009,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1010,"content":1015,"config":1020,"_id":1022,"_type":17,"title":1023,"_source":18,"_file":1024,"_stem":1025,"_extension":21},"/en-us/blog/tips-for-managing-engineering-teams-remotely",{"title":1011,"description":1012,"ogTitle":1011,"ogDescription":1012,"noIndex":6,"ogImage":876,"ogUrl":1013,"ogSiteName":686,"ogType":687,"canonicalUrls":1013,"schema":1014},"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":1011,"description":1012,"authors":1016,"heroImage":876,"date":1017,"body":1018,"category":14,"tags":1019},[939],"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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[763],{"slug":1021,"featured":6,"template":700},"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":1027,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1028,"content":1034,"config":1040,"_id":1042,"_type":17,"title":1043,"_source":18,"_file":1044,"_stem":1045,"_extension":21},"/en-us/blog/recruiting-tactics-and-strategies-to-build-a-more-diverse-team",{"title":1029,"description":1030,"ogTitle":1029,"ogDescription":1030,"noIndex":6,"ogImage":1031,"ogUrl":1032,"ogSiteName":686,"ogType":687,"canonicalUrls":1032,"schema":1033},"recruiting tactics and strategies to build a more diverse team","An overview of the Diversity, Inclusion, and Belonging-related tactics and strategies our recruiting team is experimenting with","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","https://about.gitlab.com/blog/recruiting-tactics-and-strategies-to-build-a-more-diverse-team","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"recruiting tactics and strategies to build a more diverse team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rupert Douglas\"}],\n        \"datePublished\": \"2020-09-28\",\n      }",{"title":1029,"description":1030,"authors":1035,"heroImage":1031,"date":1037,"body":1038,"category":14,"tags":1039},[1036],"Rupert Douglas","2020-09-28","\nAt GitLab, [one of our objectives and key results (OKRs)](/company/okrs/fy21-q3/#3-ceo-great-team) for Q3 is for more than 95% of our recruiting outreach to be directed at candidates who identify with an underrepresented group.\n\nAs recruiters and hiring managers know, outreach is only one part of the recruiting puzzle. If we’re going to build a more diverse team, we need to ensure our entire hiring process sets each and every candidate up for success.\n\nIn the spirit of transparency and iteration, we’d like to share a few tactics our recruiting team is experimenting with across different parts of the hiring process. Each tactic aims to increase the diversity of the team and ensure candidates feel like they belong at GitLab.\n\n### [Outbound only](/handbook/hiring/candidate/faq/)\n\nThe first and most important step we took was adopting an outbound-only recruiting model. With this model, we’re able to focus our recruiting team’s time on sourcing candidates who will both add to our team’s diversity and raise the bar once they’re on board.\n\nWe saw an average of 40,000 applications per month with our previous inbound model, and 99% of these applicants were rejected. Many hours were lost reviewing unqualified candidates and imbalances of representation in our funnel made it difficult to add to the team’s diversity.\n\nWe’ve been utilizing this outbound-only model since March 2020 and we’ve already seen a positive impact. Two stand-out examples come from August. We saw 60% of Sales candidates identity as non-male and 28% of Engineering candidates identify as Black. We’re encouraged by the signals we’re seeing so far and the outbound approach is here to stay.\n\n### [Inclusive language review for our job families](https://gitlab.com/gitlab-com/people-group/peopleops-eng/people-operations-engineering/-/issues/72)\n\nMoving to an outbound-only approach meant we no longer needed our traditional job adverts. It also gave us an opportunity to iterate on our job family pages. At GitLab, job families simply outlined a role’s responsibilities. Now, we’ve repurposed those pages to be more of a marketing tool for the role and work at GitLab.\n\nOne of our top priorities in iterating on these job family pages was to improve the inclusivity of the language we use. We’re incredibly fortunate to have our People Ops Engineer, [Lien](https://gitlab.com/gitlab-com/people-group/peopleops-eng/people-operations-engineering/-/issues/72), who built a tool to help us do this.\n\n[Using GitLab CI](https://gitlab.com/gitlab-com/people-group/peopleops-eng/people-operations-engineering/-/issues/72) (our Continuous Integration tool), each job family was assessed for its use of gendered language, misused words, and bias towards growth-mindset rather than fixed-mindset terms. The results were published in a YML file that gave us a starting point to improve upon.\n\nUtilizing the CLI and [UI version of the inclusive check tool](https://inclusiveness-check.herokuapp.com/) (that you can use, too!), we’ve made incremental improvements to the language we use to describe our roles. The tool also allows us to notify our team members if they’re proposing a change that will have a negative impact on the language used. It’s a win/win.\n\n### [Dedicated time to source candidates from underrepresented groups](/company/culture/inclusion/talent-acquisition-initiatives/)\n\nWe also spend time collaborating together to source candidates for our four highest priority roles as part of our Sourcing for Underrepresented Groups (SURG) initiative.\n\nThe SURG initiative increases the understanding of priority positions, enables team members to source candidates from underrepresented groups for functions they usually do not contribute to, and creates opportunities for recruiting team members to collaborate outside of the usual Recruiter: Sourcer partnership. On average we contact 100 prospective candidates from underrepresented groups each month through the initiative.\n\nWe’ve made some incredible hires and, selfishly, I’ve loved collaborating with different team members, too.\n\n### [Utilizing team member feedback to improve messaging response rates](/company/culture/inclusion/talent-acquisition-initiatives/)\n\nWhen sourcing for a Software Engineer in Test position, we noticed our response rates were lower than we’d expect.\n\nWe decided to gather feedback on four different messaging styles, assembled the different options into a GitLab issue, and shared the options in our #women and #diversity\n_inclusion_and_belonging Slack channels.\n\nThe feedback was clear: The original messaging received a resounding rebuff from the women on our team.\n\nThe themes and insights from this feedback outlined the importance of emphasizing our approach to asynchronous work as this enables our team members to balance work and personal lives.\n\nIt was also made clear we needed to make the prospective candidate feel something. The original messaging failed to do this. Fortunately, our values, culture, product, and professional growth opportunities provided a foundation for us to do this.\n\nThe good news? We saw response rates rise to 50% after incorporating this feedback.\n\n### [TMRG conversation at end of the hiring process](/company/culture/inclusion/talent-acquisition-initiatives/)\n\nAny candidate nearing the end of the recruiting process is offered a call with a team member outside of the interview panel who is part of a Team Member Resource Group (TMRG).\n\nWe recently brought in this change. There are two primary goals. The first is to provide the candidate with a unique perspective on GitLab that interview processes may not offer. We also hope these conversations can foster a relationship with someone on the team prior to them even signing a contract with us. We can’t thank the TMRG members enough for their willingness to take part in these conversations!\n\n### An environment where everyone can thrive!\n\nWe’ve been able to deliver and iterate on these tactics because of the leadership of our Diversity Inclusion and Belonging Manager, [Candace](https://gitlab.com/cwilliams3), the commitment from so many team members who ensure this is an [environment where everyone can thrive](https://handbook.gitlab.com/handbook/values/#diversity-inclusion), and our values of collaboration and iteration.\n\nI’m excited to see the impact our recruiting team can have in playing a part in our wider [Diversity, Inclusion, and Belonging strategy](/company/culture/inclusion/) while we all look forward to making the GitLab team even closer to a full representation of society.\n",[742],{"slug":1041,"featured":6,"template":700},"recruiting-tactics-and-strategies-to-build-a-more-diverse-team","content:en-us:blog:recruiting-tactics-and-strategies-to-build-a-more-diverse-team.yml","Recruiting Tactics And Strategies To Build A More Diverse Team","en-us/blog/recruiting-tactics-and-strategies-to-build-a-more-diverse-team.yml","en-us/blog/recruiting-tactics-and-strategies-to-build-a-more-diverse-team",{"_path":1047,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1048,"content":1054,"config":1059,"_id":1061,"_type":17,"title":1062,"_source":18,"_file":1063,"_stem":1064,"_extension":21},"/en-us/blog/imposter-syndrome-and-remote-work",{"title":1049,"description":1050,"ogTitle":1049,"ogDescription":1050,"noIndex":6,"ogImage":1051,"ogUrl":1052,"ogSiteName":686,"ogType":687,"canonicalUrls":1052,"schema":1053},"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":1049,"description":1050,"authors":1055,"heroImage":1051,"date":1056,"body":1057,"category":14,"tags":1058},[939],"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](https://handbook.gitlab.com/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](/diversity-inclusion-belonging/) 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",[742,763],{"slug":1060,"featured":6,"template":700},"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":1066,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1067,"content":1073,"config":1078,"_id":1080,"_type":17,"title":1081,"_source":18,"_file":1082,"_stem":1083,"_extension":21},"/en-us/blog/remote-board-meeting",{"title":1068,"description":1069,"ogTitle":1068,"ogDescription":1069,"noIndex":6,"ogImage":1070,"ogUrl":1071,"ogSiteName":686,"ogType":687,"canonicalUrls":1071,"schema":1072},"How to run an all-remote board meeting","Transitioning your board meeting from a conference room to a Zoom room is easier than you think.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683842/Blog/Hero%20Images/remoteboardmtg.jpg","https://about.gitlab.com/blog/remote-board-meeting","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to run an all-remote board meeting\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilie Schario\"}],\n        \"datePublished\": \"2020-04-15\",\n      }",{"title":1068,"description":1069,"authors":1074,"heroImage":1070,"date":1076,"body":1077,"category":14},[1075],"Emilie Schario","2020-04-15","\n\nWhile we've been operating remotely at GitLab since the beginning, for a long time we had our board meetings in person at our CEO's home and executives called in over Zoom. The result was a [hybrid call](https://handbook.gitlab.com/handbook/communication/#hybrid-calls-are-horrible), a combination of in-person and remote with suboptimal experiences for both.\n\nAs the largest [all-remote company in the world](/company/culture/all-remote/), we run our entire company without an office - getting together only 1 week a year for our annual get together known as [Contribute](/events/gitlab-contribute/) - but this crucial quarterly meeting was being run differently from everything else.\n\nIn April 2019, GitLab transitioned our board meetings to all remote. This means that none of the attendees are co-located. By doing so, we've made it as easy as possible for the right people to attend our board meetings, including board members, observers, executives, and anyone doing a [deep dive](/handbook/board-meetings/#deep-dives), which can include directors, managers, and, in some cases, individual contributors.\n\nAs an internal strategy consultant at GitLab, I got the opportunity to moderate our last board meeting and it was a really incredible experience. Based on that experience, I've got a couple of tips and tricks that might be useful if you're suddenly transitioning your board meetings to all remote.\n\n## Board meetings are meetings\n\nAt the end of the day, a board meeting is a meeting, but it is possibly your company's most important meeting every quarter. At GitLab, we run our all-remote Board meetings like we run all our other [all-remote meetings](/company/culture/all-remote/meetings/#how-do-you-do-all-remote-meetings-right).\n\nThis starts with making sure **meetings are not for presentations; they're for discussions.** When you get everyone on the same call at the same time, you're not just asking for time, you're asking for synchronous time and attention. In that time, you want to make sure you're focused on doing only things that can be done with all the people on the call.\n\nIn order to make sure our board meetings are efficient, we use an agenda to keep us on track and manage time. For the GitLab board meeting, we ensure that our members and observers have access to the agenda and the materials at least one full week ahead of the meeting so there is ample time to review the information.\n\nOur agenda has a couple of different sections:\n\n* Materials\n* Introductions\n* Questions, organized by topic\n\nThe materials section helps people avoid having to dig through emails to find the right link or reference. For us, this section includes:\n\n* [Board slides](/handbook/board-meetings/#presentation)\n* [CEO video](/handbook/board-meetings/#ceo-video-and-memo)\n* CEO memo\n\nGitLab board Members are asked to add questions in the agenda beforehand. GitLab executives are asked to respond to questions in the agenda prior to the board meeting. We move through the agenda from top to bottom. During the meeting, board members verbalize their questions and our executives respond, even if the questions have already been addressed in the agenda. This is because we recognize that it's easier to give better context and additional details when speaking. Sometimes board members may feel their question is answered by what's in the document already or reframe their question based on the additional information they've been given. In all cases, we strive to make our board meeting more efficient for all folks in it by ensuring we're spending time on things we can only accomplish when we have this particular group assembled together on the same call.\n\nLogistically, our Board meetings occur over Zoom. You can help make this transition easier by offering to practice a Zoom set up or do an audio check with participants beforehand. We sent all our board members headsets to ensure they have access to high-quality audio. For the CEO recorded video beforehand, we use an unlisted video on [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A?view_as=subscriber).\n\n## Keeping the conversation flowing with a moderator\n\nI strongly suggest **having someone moderate the meeting**. At GitLab, that is our [chief of staff](/handbook/board-meetings/#board-meeting-process) but I've heard this can also be the CFO, CEO, or a board member.\n\nThink about who might be the best person for this in your organization. Depending on the role, this person may still need to contribute to the meeting but with the added responsibility of keeping the meeting running on schedule.\n\nThe moderator makes sure to start the meeting on time, helps move through all agenda topics, and ends the meeting on time. Since the moderator helps ensure you're moving through the agenda in a timely fashion, it's a good idea to audibly keep time for folks throughout the meeting. Try a phrase like, \"We’re about a quarter of the way through the meeting but still on the first agenda item. Let's keep that in mind as we move onto this next item.\" The moderator must constantly be doing the mental math assessing what is left on the agenda and the time alloted.\n\nThe moderator should keep an eye on all participants - not just the speaker - to gauge how the discussion is going. This is best done using [Gallery View](https://support.zoom.us/hc/en-us/articles/201362323-Changing-the-video-layout-Speaker-view-and-Gallery-view-) (aka Brady Bunch view) to see all the meeting attendees.\n\n## You can transition, too\n\nTransitioning to remote without warning can be difficult on all parts of the business. With these tips, your board meetings can be one less thing to worry about.\n\nIf you're looking to improve your all-remote board meeting, whether it's your first or your fifth, I am always happy to share more about my experience and can be reached at Emilie(at)GitLab.com.\n\nFor help with all other facets of the transition, we’ve covered all the bases in [GitLab’s Remote Playbook](/company/culture/all-remote/).\n\nCover photo by [Drew Beamer](https://unsplash.com/@drew_beamer?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/meeting?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note.text-center}\n",{"slug":1079,"featured":6,"template":700},"remote-board-meeting","content:en-us:blog:remote-board-meeting.yml","Remote Board Meeting","en-us/blog/remote-board-meeting.yml","en-us/blog/remote-board-meeting",{"_path":1085,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1086,"content":1092,"config":1100,"_id":1102,"_type":17,"title":1103,"_source":18,"_file":1104,"_stem":1105,"_extension":21},"/en-us/blog/designing-in-an-all-remote-company",{"title":1087,"description":1088,"ogTitle":1087,"ogDescription":1088,"noIndex":6,"ogImage":1089,"ogUrl":1090,"ogSiteName":686,"ogType":687,"canonicalUrls":1090,"schema":1091},"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":1087,"description":1088,"authors":1093,"heroImage":1089,"date":1095,"body":1096,"category":14,"tags":1097},[1094],"Christie Lenneville","2020-03-27","\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",[1098,1099,763],"UX","UI",{"slug":1101,"featured":6,"template":700},"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":1107,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1108,"content":1114,"config":1119,"_id":1121,"_type":17,"title":1122,"_source":18,"_file":1123,"_stem":1124,"_extension":21},"/en-us/blog/going-remote-education-virtual-learning-tips",{"title":1109,"description":1110,"ogTitle":1109,"ogDescription":1110,"noIndex":6,"ogImage":1111,"ogUrl":1112,"ogSiteName":686,"ogType":687,"canonicalUrls":1112,"schema":1113},"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":1109,"description":1110,"authors":1115,"heroImage":1111,"date":1095,"body":1117,"category":14,"tags":1118},[1116],"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’](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[721,697,763],{"slug":1120,"featured":6,"template":700},"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":1126,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1127,"content":1133,"config":1139,"_id":1141,"_type":17,"title":1142,"_source":18,"_file":1143,"_stem":1144,"_extension":21},"/en-us/blog/contribute-through-the-eyes-of-a-new-gitlabber",{"title":1128,"description":1129,"ogTitle":1128,"ogDescription":1129,"noIndex":6,"ogImage":1130,"ogUrl":1131,"ogSiteName":686,"ogType":687,"canonicalUrls":1131,"schema":1132},"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":1128,"description":1129,"authors":1134,"heroImage":1130,"date":1136,"body":1137,"category":14,"tags":1138},[1135],"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",[280,763],{"slug":1140,"featured":6,"template":700},"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":1146,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1147,"content":1152,"config":1159,"_id":1161,"_type":17,"title":1162,"_source":18,"_file":1163,"_stem":1164,"_extension":21},"/en-us/blog/lessons-learned-as-data-team-manager",{"title":1148,"description":1149,"ogTitle":1148,"ogDescription":1149,"noIndex":6,"ogImage":1031,"ogUrl":1150,"ogSiteName":686,"ogType":687,"canonicalUrls":1150,"schema":1151},"Lessons learned managing the GitLab Data team","Staff Data Engineer Taylor Murphy shares his lessons and takeways from one year as the Data team manager.","https://about.gitlab.com/blog/lessons-learned-as-data-team-manager","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Lessons learned managing the GitLab Data team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor Murphy\"}],\n        \"datePublished\": \"2020-02-10\",\n      }",{"title":1148,"description":1149,"authors":1153,"heroImage":1031,"date":1155,"body":1156,"category":14,"tags":1157},[1154],"Taylor Murphy","2020-02-10","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-02-19.\n{: .alert .alert-info .note}\n\nFrom April 2018 to May 2019 I was the manager of the Data team for GitLab. I took this role after my manager left, when I started reporting directly to the CFO as a Data Engineer.\n\nI remember saying to him \"this doesn't seem like the right level of abstraction for you,\" and proposed I step up to become the manager. I also said I didn't want to do this for a long period of time, since I intentionally came to GitLab to move from a manager role to an individual contributor role and focus on Data Engineering.\n\nWhat follows are a few lessons I learned (and relearned!) in my one-year stint as the manager of the Data team. Eventually, I aim to become a manager again and I hope to remember these lessons and learn even more.\n\n### Plan for growth\n\nWhile I was Data team manager, GitLab grew in size by ~300%. Having only worked previously at established companies and at a very small startup, I was not prepared for this level of growth and the strain it would put on our resources.\n\nI recently surveyed colleagues of mine in the data community and discovered that, as a percentage of headcount, most Data teams are anywhere from 2-8%.\n\nThis means a 200-person company should have at least four people, and realistically around 10 people, focused on data. This includes analysts, engineers, scientists, and managers.\nIn April of 2018, we were at \u003C 1% (1/300) and would continue to be \u003C 1% throughout 2018.\n\nAs the company grew, I did not wholly understand how the business was planning to grow and how the Data team would scale to meet the data needs of the organization. This lack of strategic thinking led to a situation where I felt blindsided and overwhelmed by the number of requests for data and analytics.\n\nEven with the addition of the excellent people I was able to hire, I wasn't doing as good a job as I needed to help my team truly succeed.\n\nLesson: Understand the trajectory of the company, the workload you have and expect to have, pick a gearing ratio for headcount, stick to your hiring targets, and think about [team structure](https://blog.getdbt.com/data-team-structure-examples/).\n{: .alert .alert-gitlab-purple}\n\n### Individual contributor or manager? Pick one\n\nBy the end of 2018, the Data team was a three-person team: one data analyst, one data engineer, and me.\nThankfully, the three of us were, I'm not ashamed to say, excellent at our jobs and performed at a level beyond what you would expect three FTEs to handle.\n\nBut even we have limits and couldn't do it all.\n\nDue to the volume of work we were trying to accomplish, it was critical that I take on analyst and engineering work as well.\n\nThis created a situation where I was splitting my brain and my attention trying to do too many things at once.\n\nSome days would be all manager work, and I would make zero progress on issues assigned to me. Others would be IC work, and I would fall behind on managerial tasks. The worst days were when I would try to do both, and everything would suffer.\n\nAs time went on this split brain effect would become worse – the signs of burnout were starting to ramp up rapidly.\n\nI was able to hire more people, which put more demand on the manager side of me, yet the volume of work was increasing while I was still the primary contributor and maintainer of our codebase. By the end, I didn't feel like I was a good manager, and I felt like my technical skills were rapidly atrophying.\n\nLesson: If you're a manager, be a manager. Yes, you'll have to pick up some work, especially at a startup, but figure out your exit plan so you can pass that work to your team who will be much better at accomplishing it than you.\n{: .alert .alert-gitlab-purple}\n\n### Hire awesome people\n\nThis should go without saying, but hire excellent people and your life will be better. My first four hires for the Data team (two in 2018, two in early 2019) have blown me away with their skill, curiosity, tenacity, and intelligence.\n\nI learned from my previous job and past bosses the value in finding great people and the force multiplier they can have on the work you're trying to accomplish.\n\nLesson: Continue hiring great people! But think about how to scale it.\n{: .alert .alert-gitlab-purple}\n\n### Invest in process\n\nThis lesson I learned from [Emilie Schario](https://gitlab.com/emilie), the first Data Analyst I hired. She taught me to think about how and where we'll need processes as the company scaled, so we could remain [efficient](https://handbook.gitlab.com/handbook/values/#efficiency).\n\nWe, of course, used GitLab for managing our code, and we had built-in merge request workflows, but she took the time to think about the messy \"people stuff\" surrounding the technology.\n\nA short list of artifacts she created:\n\n- [Onboarding issue for new analysts](https://gitlab.com/gitlab-data/analytics/-/blob/master/.gitlab/issue_templates/Data%20Onboarding.md)\n- [Onboarding script to get new analysts up and running quickly](https://gitlab.com/gitlab-data/analytics/-/blob/master/admin/onboarding_script.sh)\n- [Merge request templates, so everyone is working off the same checklist](https://gitlab.com/gitlab-data/analytics/-/blob/master/.gitlab/merge_request_templates/dbt%20Model%20Changes.md)\n\nAnd many more I'm sure I'm forgetting.\n\nWhile she wasn't the manager, she had the experience and understood the parts of working at a company that can slow down team members, and she worked to automate as much of it as possible. I've heard from many people outside the company how much they appreciate our documentation in general and our onboarding process in particular.\n\nThat is a testament to thinking about scale and having the empathy to continually step into the shoes of a GitLab learner and to see things from an outsider's perspective.\n\nAs Data teams have grown and evolved they've also [become more technical](https://blog.getdbt.com/what-is-an-analytics-engineer/). These mean it's important to invest in the technical process as well – this means you should have [version control](/topics/version-control/), change control (merge requests), automated testing, and [documentation on everything you're doing](https://dbt.gitlabdata.com/).\n\nCertain tools make implementing technical processes better and easier, which I'll highlight in the next section.\n\nLesson: (1) Think about process deeply and document everything. (2) Maintain the mind of a learner and continually think about what day one with GitLab is like for new people. (3) Invest in process, documentation, and testing - they are gifts you give your future self.\n{: .alert .alert-gitlab-purple}\n\n### Pick excellent tools\n\nAlong with process, picking the right tools can be a force multiplier for team productivity. When the Data team started, we were using PostgreSQL as our data warehouse. Postgres is not column-oriented, and at a certain point it doesn't make sense to use it as an analytics database.\n\nWe went with Postgres anyway because we believe in using a [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions) and it aligns with our value of [iteration](https://handbook.gitlab.com/handbook/values/#iteration). For the volume of data we were throwing at it, Postgres did admirably. We used the CloudSQL-hosted version which enabled us to do cool, programmatic things with GitLab CI (I'll save that for another post).\n\nOnce we outgrew Postgres we decided to move to Snowflake.\n\nOf course, being GitLab, we use GitLab the product for anything and everything, which saved us much of the stress around picking tools. It has all the things you want from a coding perspective, and it has enough of the things you need to be productive as a manager. No need for Trello, Jira, and a dozen other tools.\n\nBy far though, the best tool for the Data team's productivity is [dbt (data build tool)](https://www.getdbt.com/). I could talk forever about how great dbt is, but suffice to say that we would not be where we are today and we would not have been able to support the organization this well with such a small crew, were it not for dbt and the great community behind it.\n\nLesson: Find the best tools you can for your team. Use dbt!\n{: .alert .alert-gitlab-purple}\n\n### Handling under-performers is a challenge\n\nUp until 2019, I'd never hired somebody who didn't perform well in their job, aside from a few interns.\nI'd like to think most of this was my ability to find good people, but it was probably luck, if I'm being honest.\n\nLast year challenged me with two under-performers on the team that I now realize I could have supported better. Having those difficult conversations with people was hard when I wasn't 100% in the manager brain space. My advice is to pay attention to those first few weeks of productivity, and if you find there are gaps, either in skills or motivation, do whatever you can to call out the gaps in a friendly and productive way, and then give your people every opportunity to become better.\n\nLesson: Be a good manger, notice things early, and help your team proactively.\n{: .alert .alert-gitlab-purple}\n\n### So many meetings\n\nGitLab has a great culture around meetings.\n\nThey [always start on time](https://handbook.gitlab.com/handbook/communication/#video-calls), there [must be an agenda for every meeting](https://handbook.gitlab.com/handbook/communication/#scheduling-meetings), and [people aren't afraid to end meetings early if everything on the agenda is done](https://handbook.gitlab.com/handbook/values/#be-respectful-of-others-time).\nEven with this rigor and discipline you will find yourself on the [\"Manager's Schedule\"](http://www.paulgraham.com/makersschedule.html) and will be in a lot of meetings. But that's okay! That's part of your job.\n\nI will always argue that you should still try to reduce the time you're in meetings, but if you're in a meeting, do your best to ensure your team *isn't* also in a meeting, if at all possible. Meetings are terrible for makers (i.e., your direct reports). Shield your team from them as much as possible.\n\nLesson: Meetings are a part of the job, reduce them as much as you can, and protect your team from unnecessary meetings.\n{: .alert .alert-gitlab-purple}\n\n### You need executive buy-in and representation\n\nPart of the reason I was excited to join GitLab was because the C-Suite clearly supported having a Data team in the organization.\nThe CEO and CFO understood the value a Data team could bring, even if the specifics and execution were blurry.\nThis is important! You will be in a tough spot if your company has nobody on the executive team that understands the value that good descriptive and predictive analytics can provide.\nData literacy is a cultural attribute, and it's [near impossible to grow literacy](https://towardsdatascience.com/is-your-company-too-dumb-to-be-data-driven-696932d597c3) in an organization if the CEO isn't driving it in some way.\n\nAt a certain scale though, you need Data leadership beyond a team manager.\nYou absolutely need someone at the Director level and up that can advocate and champion Data literacy and fluency across the functional areas of the organization.\nManagers can't be expected to spend much time on this since there is so much daily work to be done.\n\nLesson: Be wary of organizations that don't have C-Suite buy-in around the data function.\nAdvocate for a Director-level and up position that can be the cheerleader for Data across the organization.\n{: .alert .alert-gitlab-purple}\n\n### Plan to spend some money\n\nExecutive level buy-in for a Data team is important because of this fact: Starting a Data team can be expensive. To be effective, you'll need to hire several people or empower your single data lead to purchase some third-party software.\n\nOut of the gate you'll need an extract and load tool like Stitch or Fivetran, you'll need a data warehouse (e.g., Snowflake, BigQuery, Redshift), you'll need compute to run transform jobs, and you'll want a BI tool.\nThere are free tools that can sustain you for a while, but plan to invest some money up front if you're in it for the long haul.\n\nLesson: Long term success will require investment. You can start cheaply, but to scale requires resources.\n{: .alert .alert-gitlab-purple}\n\n### Don't reinvent the wheel\n\nEspecially for things like extracting data from tools such as Salesforce, Zendesk, or Zuora, please, please, PLEASE don't write your own scripts to do this. Just pay a company to do it for you. You'll waste a ton of time doing something that doesn't deliver business value and will probably come back to bite you in the end.\n\nYou should spend most of your time [delivering value for the business](https://blog.getdbt.com/the-startup-founder-s-guide-to-analytics/) in the form of automated reporting and generating insights, not writing a Salesforce to Snowflake extractor for the thousandth time.\n\nLesson: Pay for Stitch or Fivetran for common data extractions.\n{: .alert .alert-gitlab-purple}\n\n### Manager is a different career\n\nDon't think about becoming a manager as an extension of your individual contributor career. It *is* a different career path and your IC-skills will certainly help you be a better manager. However, management is its own set of skills and choosing to go into this field puts you on a different career path. It's not necessarily better depending on how you define success.\n\nGo into management with open eyes and a full understanding that you are switching tracks and not \"moving ahead\". It isn't permanent, though, and can be reversed if you choose.\n\nLesson: Don't assume the move to manager is the default for an IC. Think deeply about your [career](https://www.locallyoptimistic.com/post/career-ladders-part-1/). Read [about the Engineer/Manager Pendulum](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/).\n{: .alert .alert-gitlab-purple}\n\n### It's okay to be a little selfish\n\nOne area I've struggled with for a while is making the effort to be a little selfish. I can have a people-pleaser mentality which, when applied to the business of a startup, can be useful: Startups need people that are willing to do what it takes to make the company successful (within reason!). But once the company is in a growth stage or beyond, that mentality is a recipe for burnout.\n\nAt my previous company, we were less than 30 people. Having the attitude of trying to do and learn as much as possible was a good strategy for me. I learned a ton, was given a bunch of responsibility, and helped the business grow. That strategy worked for me at GitLab for a while too. After some time passed, it was clear I couldn't keep up with everything, and my sanity would start to suffer without a fix.\n\nBeing selfish in this case meant I had to be okay with wanting to take a \"step back\" from the manager role to the IC role (Spoiler: it's not a step back! See the previous point).\n\nI had to admit to myself that I wanted to focus on programming more and that continuing down the manager track wasn't currently right for me.\n\nIt felt selfish because it was hard in the moment to see that what the business needed was somebody who *wanted* to be the manager. It didn't need me to continue in the role just because I happened to currently be in the role.\n\nWhile there were short-term ramifications for the team because of my move to an IC role, I know that I'm healthier for it, and we now have two excellent managers who are leading the team further than I could have.\n\nLesson: (1) It's a *good* thing to prioritize and be selfish about your mental health. (2) It's okay to say \"No, I can't do this anymore\". (3) Companies need people who want to be in their jobs - performance is better and people are happier.\n{: .alert .alert-gitlab-purple}\n\n### Fin\n\nMy hope is that these lessons are valuable to you, and are applicable in your own life and career. I would love to hear from you if you disagree with any of these, or if you have your own stories and lessons to share about your career in data; please reach out on [Twitter](https://twitter.com/tayloramurphy), via email (tmurphy at gitlab.com), or in an [issue in our main project](https://gitlab.com/gitlab-data/analytics/).\n\nThank you for reading and thank you to GitLab for enabling my growth as a Data professional.\n\n*Special thanks to [Emilie Schario](https://gitlab.com/emilie) for her review on multiple drafts of this post.*\n",[982,1158,905],"design",{"slug":1160,"featured":6,"template":700},"lessons-learned-as-data-team-manager","content:en-us:blog:lessons-learned-as-data-team-manager.yml","Lessons Learned As Data Team Manager","en-us/blog/lessons-learned-as-data-team-manager.yml","en-us/blog/lessons-learned-as-data-team-manager",{"_path":1166,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1167,"content":1173,"config":1179,"_id":1181,"_type":17,"title":1182,"_source":18,"_file":1183,"_stem":1184,"_extension":21},"/en-us/blog/power-of-iteration",{"title":1168,"description":1169,"ogTitle":1168,"ogDescription":1169,"noIndex":6,"ogImage":1170,"ogUrl":1171,"ogSiteName":686,"ogType":687,"canonicalUrls":1171,"schema":1172},"How iteration helps build our product and improve our work lives","One of GitLab’s core values, iteration permeates everything we do from UX design to product development. And when it comes to our work lives, iteration is a game changer.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681060/Blog/Hero%20Images/iteration.jpg","https://about.gitlab.com/blog/power-of-iteration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How iteration helps build our product and improve our work lives\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-02-04\",\n      }",{"title":1168,"description":1169,"authors":1174,"heroImage":1170,"date":1176,"body":1177,"category":14,"tags":1178},[1175],"Valerie Silverthorne","2020-02-04","\n\n*it-er-a-tion*\n\n_/ˌidəˈrāSH(ə)n/_\n\n_noun_\n\n_the repetition of a process or utterance._\n\n_repetition of a mathematical or computational procedure applied to the result of a previous application, typically as a means of obtaining successively closer approximations to the solution of a problem._ – Oxford Dictionary via Lexico\n\nAt GitLab iteration is simply what we do – with everything. CEO [Sid Sijbrandij](/company/team/#sytses) explains that even in the very early stages of GitLab, when the company was in the [Y Combinator](https://www.ycombinator.com) \"incubator,” he knew iteration was the right choice because even though it seems contradictory, you can go faster by breaking things down into smaller pieces. \"There were people, even at the time, who suggested that we should slow down. The response from GitLab has always been, 'No, we'll get the most we can get done. The smaller we split things up, the smaller the steps we take, the faster we can go.'\"\n\nIt’s not surprising that iteration is one of GitLab’s [six core values](https://handbook.gitlab.com/handbook/values/), and you don’t have to look too closely to see how it steers our product development. When we wanted to make our [error tracking feature](/blog/iteration-on-error-tracking/) stronger, we \"scoped” the project down and made small changes more quickly.\n\nOur user experience team took the same approach when [trying to improve usability](/blog/how-ux-research-impacts-product-decisions/), and [when we migrated](/blog/gitlab-journey-from-azure-to-gcp/) from Microsoft’s Azure to the Google Cloud Platform we used iteration to guide our process.\n\nBut perhaps where iteration shines brightest at GitLab is at the individual level where the ability to take small steps frees employees to take risks and be creative. This is something that’s obvious even if you’re a [brand new employee](/blog/agile-iteration-unique-onboarding-experience/).\n\nWe asked six team members to explain the impact of iteration on their work lives.\n\n[Heather Simpson](/company/team/#hsimpson), senior external communications analyst:\n\"Honestly, the ability to throw something out there without being judged because it’s not completely formed and polished is new and refreshing for me.  I know I’ve got teammates ready to collaborate and help me strengthen my ideas and the end result.”\n\n[Ashish Kuthiala](/company/team/#kuthiala), senior director of Product Marketing:\n\"It helps us create a culture and organization that learns very fast and creates a self-learning and always improving organization.  We cannot and do not always get things right but we learn and improve really rapidly.”\n\n[Emily Kyle](/company/team/#Emily), manager, Corporate Events and Branding:\n\"It allows me to be a bit bolder and braver in coming up with out of the box solutions and in my decision making. Small steps make change so much easier to achieve.”\n\n[Tina Sturgis](/company/team/#TinaS), manager, Partner and Channel Marketing:\n\"Iteration for me is a game changer at GitLab. Gone are the days of getting everyone's buy-in prior to rolling out messaging. Put it out there and people will iterate on it making it better. If my messaging was off, no worries – iterate on what it is NOT and keep driving to results.\"\n\n[Lorie Whitaker](/company/team/#loriewhitaker), senior UX researcher: \"To a UX researcher iteration means something different to me than other people. The value of iteration should encourage people to change directions when they find answers to their questions. Iteration should be a stop-gap measure to say ‘This is not the right solution. We will stop and reassess and rethink what is the right solution to this problem.’”\n\n[Lee Matos](/company/team/#lbot), Support engineering manager:\n\"Iteration is hard because at first it feels unnatural, but once you learn how to really iterate, it's liberating. You can keep being nimble which is huge.\"\n\nCover image by Eryk on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[804,697,742],{"slug":1180,"featured":6,"template":700},"power-of-iteration","content:en-us:blog:power-of-iteration.yml","Power Of Iteration","en-us/blog/power-of-iteration.yml","en-us/blog/power-of-iteration",{"_path":1186,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1187,"content":1193,"config":1199,"_id":1201,"_type":17,"title":1202,"_source":18,"_file":1203,"_stem":1204,"_extension":21},"/en-us/blog/working-in-vastly-different-timezone",{"title":1188,"description":1189,"ogTitle":1188,"ogDescription":1189,"noIndex":6,"ogImage":1190,"ogUrl":1191,"ogSiteName":686,"ogType":687,"canonicalUrls":1191,"schema":1192},"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":1188,"description":1189,"authors":1194,"heroImage":1190,"date":1196,"body":1197,"category":14,"tags":1198},[1195],"Erich Wegscheider","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](https://handbook.gitlab.com/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",[763],{"slug":1200,"featured":6,"template":700},"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":1206,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1207,"content":1213,"config":1219,"_id":1221,"_type":17,"title":1222,"_source":18,"_file":1223,"_stem":1224,"_extension":21},"/en-us/blog/mastering-the-all-remote-environment",{"title":1208,"description":1209,"ogTitle":1208,"ogDescription":1209,"noIndex":6,"ogImage":1210,"ogUrl":1211,"ogSiteName":686,"ogType":687,"canonicalUrls":1211,"schema":1212},"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":1208,"description":1209,"authors":1214,"heroImage":1210,"date":1216,"body":1217,"category":14,"tags":1218},[1215],"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",[721,697,763],{"slug":1220,"featured":6,"template":700},"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":1226,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1227,"content":1233,"config":1239,"_id":1241,"_type":17,"title":1242,"_source":18,"_file":1243,"_stem":1244,"_extension":21},"/en-us/blog/six-key-practices-that-improve-communication",{"title":1228,"description":1229,"ogTitle":1228,"ogDescription":1229,"noIndex":6,"ogImage":1230,"ogUrl":1231,"ogSiteName":686,"ogType":687,"canonicalUrls":1231,"schema":1232},"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":1228,"description":1229,"authors":1234,"heroImage":1230,"date":1236,"body":1237,"category":14,"tags":1238},[1235],"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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[697,763,1098],{"slug":1240,"featured":6,"template":700},"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":1246,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1247,"content":1253,"config":1258,"_id":1260,"_type":17,"title":1261,"_source":18,"_file":1262,"_stem":1263,"_extension":21},"/en-us/blog/funny-gitlab-remote-meetings",{"title":1248,"description":1249,"ogTitle":1248,"ogDescription":1249,"noIndex":6,"ogImage":1250,"ogUrl":1251,"ogSiteName":686,"ogType":687,"canonicalUrls":1251,"schema":1252},"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":1248,"description":1249,"authors":1254,"heroImage":1250,"date":1255,"body":1256,"category":14,"tags":1257},[978],"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",[742,697,763],{"slug":1259,"featured":6,"template":700},"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":1265,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1266,"content":1272,"config":1276,"_id":1278,"_type":17,"title":1279,"_source":18,"_file":1280,"_stem":1281,"_extension":21},"/en-us/blog/how-to-build-a-more-productive-remote-team",{"title":1267,"description":1268,"ogTitle":1267,"ogDescription":1268,"noIndex":6,"ogImage":1269,"ogUrl":1270,"ogSiteName":686,"ogType":687,"canonicalUrls":1270,"schema":1271},"5 Ways to build a more productive remote team","Hacker Noon named GitLab the world's most productive remote team – here's how we make it work.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682933/Blog/Hero%20Images/getting-things-done.jpg","https://about.gitlab.com/blog/how-to-build-a-more-productive-remote-team","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Ways to build a more productive remote team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Murph\"}],\n        \"datePublished\": \"2019-12-10\",\n      }",{"title":1267,"description":1268,"authors":1273,"heroImage":1269,"date":1274,"body":1275,"category":14},[978],"2019-12-10","\n\nEarlier this year Hacker Noon's community voted GitLab the [world's most productive remote team](https://noonies.hackernoon.com/award/cjxvsz6576k8u0b40czyb7xhj). We were honored, and thought we'd share a few tips on how we make it work in hopes of inspiring more remote companies.\n\n### We're serious about efficiency\n\nEfficiency isn't just something we strive for. It's a [value at the heart of every decision](/company/culture/all-remote/values/#efficiency). By enabling our all-remote team to [work from wherever they're most fulfilled](/company/culture/all-remote/people/), GitLab team members enjoy the built-in efficiency of time saved from no commute.\n\nWe also realize that no single person can design the perfectly efficient day for someone else. That's why we empower people to be a [manager of one](https://handbook.gitlab.com/handbook/values/#managers-of-one). When there's no clock to punch and no one watching you work, you're incentivized to be [highly efficient](/2018/05/17/eliminating-distractions-and-getting-things-done/). This is manifested in our obsession with [documentation](https://handbook.gitlab.com/handbook/values/#write-things-down) and our [bias for asynchronous communication](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication).\n\n![Working while flying creates more time to explore](https://about.gitlab.com/images/blogimages/remote-work-airplane-laptop.jpg){: .shadow.medium.center}\nWorking while flying creates more time to explore.\n{: .note.text-center}\n\nWe're also [transparent](/company/culture/all-remote/values/#transparency), which leads to far fewer questions, less confusion, and fewer interruptions on a daily basis. When information is available to all, you're conditioned to simply look for it. This habit of self-service allows team members to enjoy longer, uninterrupted periods of work.\n\n### We look at meetings differently\n\nWhen your [team](/company/team/) is spread across a myriad of time zones, and you're given [a travel stipend](/handbook/incentives/#visiting-grant) to crisscross oceans and meet your colleagues, you're forced to [see meetings in a different light](/company/culture/all-remote/meetings/). Part of what drives our productivity as a global team is our resistance to defaulting to a meeting.\n\n![Meetings are a judgement free zone](https://about.gitlab.com/images/blogimages/gitlab-team-meeting-zoom-call.jpg){: .shadow.medium.center}\nMeetings are a judgement-free zone.\n{: .note.text-center}\n\nWe default to documentation instead, which allows each individual to contribute insights and discussion during a time that suits them. This also allows people to properly digest a situation and create a considered response, rather than vocalizing whatever is top of mind.\n\nDespite our best efforts, some meetings are unavoidable. We require each meeting to have a pre-defined [agenda](/company/culture/all-remote/meetings/#have-an-agenda) and for [notes to be taken](/company/culture/all-remote/meetings/#document-everything-live-yes-everything) for those who cannot attend live. We don't bother with prettying up the background, since [meetings should be about the work](/company/culture/all-remote/meetings/#meetings-are-about-the-work-not-the-background). We're also known to [turn weekly all-hands meetings into podcasts](/2019/06/03/how-we-turned-40-person-meeting-into-a-podcast/).\n\n![Seriously, we mean it. Meetings are a judgement free zone!](https://about.gitlab.com/images/blogimages/gitlab-marketing-team-hotdog-meeting.jpg){: .shadow.medium.center}\nSeriously, we mean it. Meetings are a judgement-free zone!\n{: .note.text-center}\n\nThe element that's most counter to conventional wisdom? We give each team member the liberty to take their focus off of the meeting if an agenda item does not pertain to them. We don't judge people for looking away and working on other tasks, and it's not rude to ask someone to repeat something if you're looped back into a conversation.\n\n### We focus on results, not vanity metrics\n\nWe're able to maintain a high level of productivity by valuing [results](/company/culture/all-remote/values/#results) over inputs. It's true that what gets measured gets done. At GitLab, we publish our [Objectives and Key Results](/company/okrs/) (OKRs), ensuring that anyone in the company – and even outside of the company – knows exactly what matters. If it's not an OKR, it's not a priority.\n\nIn colocated environments, it's easy to favor people you see more often. In turn, it becomes easy to justify vanity metrics – things like appearing in the most meetings or being seen as the last to leave the office. Metrics like these do not propel a business forward in a meaningful way, and yet they often supercede productive effort.\n\nIf these vanity metrics are rewarded via praise or promotion, it creates a [dysfunctional culture](https://handbook.gitlab.com/handbook/values/#five-dysfunctions) where appearances trump excellent work.\n\n### We iterate with short toes\n\nGitLab looks at [iteration](/company/culture/all-remote/values/#iteration) in a way that feels unnatural to most. Across the company, we encourage the smallest possible change that makes an improvement. If you feel a twinge of embarrassment about the minimal nature of your first shipped feature set, you're on the right track.\n\nOur productivity is bolstered by a shared embrace of something that is actively discouraged in most organizations. When you iterate minimally and quickly, it's easier to roll things back. It's easier to pivot, or gently change course. If you're completely off-base, you'll realize it before you've sunk a catastrophic amount of time into a project.\n\nOne of the biggest killers of productivity is the fear of stepping on someone's toes, or veering too far into a lane that's owned by someone else. At GitLab, we have [short toes](https://handbook.gitlab.com/handbook/values/#short-toes). We actively work to improve our comfort level with others contributing to varying domains. When there's no ego and no long toes to mash, it creates an inclusive culture that *invites* innovation.\n\n### We answer questions with links\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/ejlb9tPzjZs?start=420\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*In the above [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A) video, GitLab team members discuss the benefits of widespread documentation with Job Portraits' co-founder [Miki Johnson](https://twitter.com/heymikij).*\n\nDoing the same thing twice hinders productivity. Repeating the answer to a question dozens of times – a common predicament when scaling a team and [addressing new hire concerns](/company/culture/all-remote/learning-and-development/#how-do-you-onboard-new-team-members) on a continual basis – is even worse. Unnecessary repitition not only hampers productivity, but it wears down the person answering the same questions.\n\nGitLab's handbook is [over 3,000 pages](/handbook/about/#count-handbook-pages) (and counting), and while we do not expect any single team member to read everything, its searchable nature means that it can be read and leveraged precisely when it's needed. Because of this, we're conditioned to ingest every question by first wondering if the answer is already documented.\n\nIn the event that the answer to your question is not documented, we take a [handbook first approach](/handbook/handbook-usage/#why-handbook-first) to answering. In other words, we document solutions to unanswered inquiries in order to make our future selves more productive. We answer it once, with a documented link, to prevent repetition in the future. If the answer needs to be updated with time, future team members can [use a merge request to iterate](/2019/08/02/gitlab-for-the-non-technical/) – an exercise that's far more productivity than rewriting from scratch.\n\n",{"slug":1277,"featured":6,"template":700},"how-to-build-a-more-productive-remote-team","content:en-us:blog:how-to-build-a-more-productive-remote-team.yml","How To Build A More Productive Remote Team","en-us/blog/how-to-build-a-more-productive-remote-team.yml","en-us/blog/how-to-build-a-more-productive-remote-team",{"_path":1283,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1284,"content":1290,"config":1296,"_id":1298,"_type":17,"title":1299,"_source":18,"_file":1300,"_stem":1301,"_extension":21},"/en-us/blog/how-a-remote-internship-at-gitlab-shaped-my-career",{"title":1285,"description":1286,"ogTitle":1285,"ogDescription":1286,"noIndex":6,"ogImage":1287,"ogUrl":1288,"ogSiteName":686,"ogType":687,"canonicalUrls":1288,"schema":1289},"My experience as a recruiting intern at GitLab","Why interning for an asynchronous and all-remote company is the best way to go.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673044/Blog/Hero%20Images/books-internship-post.jpg","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":1285,"description":1286,"authors":1291,"heroImage":1287,"date":1293,"body":1294,"category":14,"tags":1295},[1292],"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",[804,697,763],{"slug":1297,"featured":6,"template":700},"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":1303,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1304,"content":1310,"config":1314,"_id":1316,"_type":17,"title":1317,"_source":18,"_file":1318,"_stem":1319,"_extension":21},"/en-us/blog/how-all-remote-supports-inclusion-and-bolsters-communities",{"title":1305,"description":1306,"ogTitle":1305,"ogDescription":1306,"noIndex":6,"ogImage":1307,"ogUrl":1308,"ogSiteName":686,"ogType":687,"canonicalUrls":1308,"schema":1309},"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":1305,"description":1306,"authors":1311,"heroImage":1307,"date":1293,"body":1312,"category":14,"tags":1313},[978],"\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",[721,697,763],{"slug":1315,"featured":6,"template":700},"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":1321,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1322,"content":1328,"config":1334,"_id":1336,"_type":17,"title":1337,"_source":18,"_file":1338,"_stem":1339,"_extension":21},"/en-us/blog/parallels-between-all-remote-and-cloud-computing",{"title":1323,"description":1324,"ogTitle":1323,"ogDescription":1324,"noIndex":6,"ogImage":1325,"ogUrl":1326,"ogSiteName":686,"ogType":687,"canonicalUrls":1326,"schema":1327},"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":1323,"description":1324,"authors":1329,"heroImage":1325,"date":1331,"body":1332,"category":14,"tags":1333},[1330],"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",[721,697,763],{"slug":1335,"featured":6,"template":700},"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":1341,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1342,"content":1348,"config":1353,"_id":1355,"_type":17,"title":1356,"_source":18,"_file":1357,"_stem":1358,"_extension":21},"/en-us/blog/whats-in-your-backpack",{"title":1343,"description":1344,"ogTitle":1343,"ogDescription":1344,"noIndex":6,"ogImage":1345,"ogUrl":1346,"ogSiteName":686,"ogType":687,"canonicalUrls":1346,"schema":1347},"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":1343,"description":1344,"authors":1349,"heroImage":1345,"date":1350,"body":1351,"category":14,"tags":1352},[939],"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",[763,697],{"slug":1354,"featured":6,"template":700},"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":1360,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1361,"content":1367,"config":1372,"_id":1374,"_type":17,"title":1375,"_source":18,"_file":1376,"_stem":1377,"_extension":21},"/en-us/blog/how-to-push-code-from-a-hammock",{"title":1362,"description":1363,"ogTitle":1362,"ogDescription":1363,"noIndex":6,"ogImage":1364,"ogUrl":1365,"ogSiteName":686,"ogType":687,"canonicalUrls":1365,"schema":1366},"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":1362,"description":1363,"authors":1368,"heroImage":1364,"date":1369,"body":1370,"category":14,"tags":1371},[939],"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](https://handbook.gitlab.com/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",[763,697],{"slug":1373,"featured":6,"template":700},"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":1379,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1380,"content":1386,"config":1391,"_id":1393,"_type":17,"title":1394,"_source":18,"_file":1395,"_stem":1396,"_extension":21},"/en-us/blog/not-everyone-has-a-home-office",{"title":1381,"description":1382,"ogTitle":1381,"ogDescription":1382,"noIndex":6,"ogImage":1383,"ogUrl":1384,"ogSiteName":686,"ogType":687,"canonicalUrls":1384,"schema":1385},"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":1381,"description":1382,"authors":1387,"heroImage":1383,"date":1388,"body":1389,"category":14,"tags":1390},[939],"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",[697,763],{"slug":1392,"featured":6,"template":700},"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":1398,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1399,"content":1405,"config":1410,"_id":1412,"_type":17,"title":1413,"_source":18,"_file":1414,"_stem":1415,"_extension":21},"/en-us/blog/not-all-remote-is-created-equal",{"title":1400,"description":1401,"ogTitle":1400,"ogDescription":1401,"noIndex":6,"ogImage":1402,"ogUrl":1403,"ogSiteName":686,"ogType":687,"canonicalUrls":1403,"schema":1404},"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":1400,"description":1401,"authors":1406,"heroImage":1402,"date":1407,"body":1408,"category":14,"tags":1409},[1195],"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](https://handbook.gitlab.com/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",[763],{"slug":1411,"featured":6,"template":700},"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":1417,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1418,"content":1424,"config":1429,"_id":1431,"_type":17,"title":1432,"_source":18,"_file":1433,"_stem":1434,"_extension":21},"/en-us/blog/how-we-scaled-our-summits",{"title":1419,"description":1420,"ogTitle":1419,"ogDescription":1420,"noIndex":6,"ogImage":1421,"ogUrl":1422,"ogSiteName":686,"ogType":687,"canonicalUrls":1422,"schema":1423},"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":1419,"description":1420,"authors":1425,"heroImage":1421,"date":1426,"body":1427,"category":14,"tags":1428},[939],"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",[697,763],{"slug":1430,"featured":6,"template":700},"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":1436,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1437,"content":1442,"config":1447,"_id":1449,"_type":17,"title":1450,"_source":18,"_file":1451,"_stem":1452,"_extension":21},"/en-us/blog/welcome-to-gitlab-unfiltered",{"title":1438,"description":1439,"ogTitle":1438,"ogDescription":1439,"noIndex":6,"ogImage":1031,"ogUrl":1440,"ogSiteName":686,"ogType":687,"canonicalUrls":1440,"schema":1441},"Welcome to the home of GitLab Unfiltered","The GitLab Unfiltered blog is user-generated content by the GitLab team.","https://about.gitlab.com/blog/welcome-to-gitlab-unfiltered","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Welcome to the home of GitLab Unfiltered\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2019-08-20\",\n      }",{"title":1438,"description":1439,"authors":1443,"heroImage":1031,"date":1444,"body":1445,"category":14,"tags":1446},[998],"2019-08-20","\n\nIn the spirit of [transparency](https://handbook.gitlab.com/handbook/values/#transparency) and \"[everyone can contribute](/company/mission/#mission),\" the GitLab Unfiltered blog is user-generated content by the GitLab team.\n\nAny GitLab team member is free to publish to the Unfiltered blog, provided that they have a peer review their post first.\nPlease read the [GitLab Unfiltered handbook](/handbook/marketing/blog/unfiltered/) to find out how to contribute.\n\nWatch this space!\n",[697],{"slug":1448,"featured":6,"template":700},"welcome-to-gitlab-unfiltered","content:en-us:blog:welcome-to-gitlab-unfiltered.yml","Welcome To Gitlab Unfiltered","en-us/blog/welcome-to-gitlab-unfiltered.yml","en-us/blog/welcome-to-gitlab-unfiltered",{"_path":1454,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1455,"content":1461,"config":1466,"_id":1468,"_type":17,"title":1469,"_source":18,"_file":1470,"_stem":1471,"_extension":21},"/en-us/blog/all-remote-is-for-everyone",{"title":1456,"description":1457,"ogTitle":1456,"ogDescription":1457,"noIndex":6,"ogImage":1458,"ogUrl":1459,"ogSiteName":686,"ogType":687,"canonicalUrls":1459,"schema":1460},"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":1456,"description":1457,"authors":1462,"heroImage":1458,"date":1463,"body":1464,"category":14,"tags":1465},[978],"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](https://handbook.gitlab.com/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",[721,697,763,742],{"slug":1467,"featured":6,"template":700},"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":1473,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1474,"content":1480,"config":1486,"_id":1488,"_type":17,"title":1489,"_source":18,"_file":1490,"_stem":1491,"_extension":21},"/en-us/blog/remote-kids-part-four",{"title":1475,"description":1476,"ogTitle":1475,"ogDescription":1476,"noIndex":6,"ogImage":1477,"ogUrl":1478,"ogSiteName":686,"ogType":687,"canonicalUrls":1478,"schema":1479},"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":1475,"description":1476,"authors":1481,"heroImage":1477,"date":1483,"body":1484,"category":14,"tags":1485},[1482],"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](https://handbook.gitlab.com/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",[763,742,697],{"slug":1487,"featured":6,"template":700},"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":1493,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1494,"content":1500,"config":1506,"_id":1508,"_type":17,"title":1509,"_source":18,"_file":1510,"_stem":1511,"_extension":21},"/en-us/blog/tips-for-mastering-video-calls",{"title":1495,"description":1496,"ogTitle":1495,"ogDescription":1496,"noIndex":6,"ogImage":1497,"ogUrl":1498,"ogSiteName":686,"ogType":687,"canonicalUrls":1498,"schema":1499},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749670134/Blog/Hero%20Images/remote-life-cover.png","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":1495,"description":1496,"authors":1501,"heroImage":1497,"date":1503,"body":1504,"category":14,"tags":1505},[1502],"Betsy Church","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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[763,697,804],{"slug":1507,"featured":6,"template":700},"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":1513,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1514,"content":1520,"config":1526,"_id":1528,"_type":17,"title":1529,"_source":18,"_file":1530,"_stem":1531,"_extension":21},"/en-us/blog/gitlab-for-the-non-technical",{"title":1515,"description":1516,"ogTitle":1515,"ogDescription":1516,"noIndex":6,"ogImage":1517,"ogUrl":1518,"ogSiteName":686,"ogType":687,"canonicalUrls":1518,"schema":1519},"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":1515,"description":1516,"authors":1521,"heroImage":1517,"date":1522,"body":1523,"category":14,"tags":1524},[1175],"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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/handbook/communication/#start-with-a-merge-request) is a formalized way to request something (usually in the [GitLab handbook](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[697,1525,763],"git",{"slug":1527,"featured":6,"template":700},"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":1533,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1534,"content":1539,"config":1544,"_id":1546,"_type":17,"title":1547,"_source":18,"_file":1548,"_stem":1549,"_extension":21},"/en-us/blog/working-remotely-with-children-at-home",{"title":1535,"description":1536,"ogTitle":1535,"ogDescription":1536,"noIndex":6,"ogImage":1477,"ogUrl":1537,"ogSiteName":686,"ogType":687,"canonicalUrls":1537,"schema":1538},"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":1535,"description":1536,"authors":1540,"heroImage":1477,"date":1541,"body":1542,"category":14,"tags":1543},[1482],"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",[763,742,697],{"slug":1545,"featured":6,"template":700},"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":1551,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1552,"content":1558,"config":1564,"_id":1566,"_type":17,"title":1567,"_source":18,"_file":1568,"_stem":1569,"_extension":21},"/en-us/blog/pyb-all-remote-mark-frein",{"title":1553,"description":1554,"ogTitle":1553,"ogDescription":1554,"noIndex":6,"ogImage":1555,"ogUrl":1556,"ogSiteName":686,"ogType":687,"canonicalUrls":1556,"schema":1557},"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":1553,"description":1554,"authors":1559,"heroImage":1555,"date":1560,"body":1561,"category":14,"tags":1562},[939],"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",[1563,697,763],"cloud native",{"slug":1565,"featured":6,"template":700},"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":1571,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1572,"content":1578,"config":1585,"_id":1587,"_type":17,"title":1588,"_source":18,"_file":1589,"_stem":1590,"_extension":21},"/en-us/blog/balancing-career-and-baby",{"title":1573,"description":1574,"ogTitle":1573,"ogDescription":1574,"noIndex":6,"ogImage":1575,"ogUrl":1576,"ogSiteName":686,"ogType":687,"canonicalUrls":1576,"schema":1577},"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":1579,"description":1574,"authors":1580,"heroImage":1575,"date":1582,"body":1583,"category":14,"tags":1584},"How I balance a baby, a career at GitLab, and cultural expectations of motherhood",[1581],"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",[763,742,697],{"slug":1586,"featured":6,"template":700},"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":1592,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1593,"content":1598,"config":1603,"_id":1605,"_type":17,"title":1606,"_source":18,"_file":1607,"_stem":1608,"_extension":21},"/en-us/blog/how-is-it-being-a-new-mom-working-for-gitlab",{"title":1594,"description":1595,"ogTitle":1594,"ogDescription":1595,"noIndex":6,"ogImage":1575,"ogUrl":1596,"ogSiteName":686,"ogType":687,"canonicalUrls":1596,"schema":1597},"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":1594,"description":1595,"authors":1599,"heroImage":1575,"date":1600,"body":1601,"category":14,"tags":1602},[1581],"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",[763,742,270],{"slug":1604,"featured":6,"template":700},"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":1610,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1611,"content":1616,"config":1621,"_id":1623,"_type":17,"title":1624,"_source":18,"_file":1625,"_stem":1626,"_extension":21},"/en-us/blog/tips-for-working-from-home-remote-work",{"title":1612,"description":1613,"ogTitle":1612,"ogDescription":1613,"noIndex":6,"ogImage":1497,"ogUrl":1614,"ogSiteName":686,"ogType":687,"canonicalUrls":1614,"schema":1615},"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":1612,"description":1613,"authors":1617,"heroImage":1497,"date":1618,"body":1619,"category":14,"tags":1620},[1581],"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",[721,697,763],{"slug":1622,"featured":6,"template":700},"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":1628,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1629,"content":1635,"config":1640,"_id":1642,"_type":17,"title":1643,"_source":18,"_file":1644,"_stem":1645,"_extension":21},"/en-us/blog/five-things-you-hear-from-gitlab-ceo",{"title":1630,"description":1631,"ogTitle":1630,"ogDescription":1631,"noIndex":6,"ogImage":1632,"ogUrl":1633,"ogSiteName":686,"ogType":687,"canonicalUrls":1633,"schema":1634},"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":1630,"description":1631,"authors":1636,"heroImage":1632,"date":1637,"body":1638,"category":14,"tags":1639},[691],"2019-06-28","\n\nDuring my two-week rotation in GitLab’s [CEO shadow program](https://handbook.gitlab.com/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](https://handbook.gitlab.com/handbook/), [breakout calls](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[763,804,697],{"slug":1641,"featured":6,"template":700},"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":1647,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1648,"content":1653,"config":1659,"_id":1661,"_type":17,"title":1662,"_source":18,"_file":1663,"_stem":1664,"_extension":21},"/en-us/blog/how-remote-work-at-gitlab-enables-location-independence",{"title":1649,"description":1650,"ogTitle":1649,"ogDescription":1650,"noIndex":6,"ogImage":1497,"ogUrl":1651,"ogSiteName":686,"ogType":687,"canonicalUrls":1651,"schema":1652},"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":1649,"description":1650,"authors":1654,"heroImage":1497,"date":1656,"body":1657,"category":14,"tags":1658},[1655,1502],"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",[721,697,763],{"slug":1660,"featured":6,"template":700},"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":1666,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1667,"content":1672,"config":1678,"_id":1680,"_type":17,"title":1681,"_source":18,"_file":1682,"_stem":1683,"_extension":21},"/en-us/blog/day-in-the-life-remote-worker",{"title":1668,"description":1669,"ogTitle":1668,"ogDescription":1669,"noIndex":6,"ogImage":1497,"ogUrl":1670,"ogSiteName":686,"ogType":687,"canonicalUrls":1670,"schema":1671},"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://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":1668,"description":1669,"authors":1673,"heroImage":1497,"date":1675,"body":1676,"category":14,"tags":1677},[939,1674],"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",[721,763,804,697],{"slug":1679,"featured":6,"template":700},"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":1685,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1686,"content":1692,"config":1697,"_id":1699,"_type":17,"title":1700,"_source":18,"_file":1701,"_stem":1702,"_extension":21},"/en-us/blog/contribute-wrap-up",{"title":1687,"description":1688,"ogTitle":1687,"ogDescription":1688,"noIndex":6,"ogImage":1689,"ogUrl":1690,"ogSiteName":686,"ogType":687,"canonicalUrls":1690,"schema":1691},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749670139/Blog/Hero%20Images/gitlab-contribute-team-photo.png","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":1687,"description":1688,"authors":1693,"heroImage":1689,"date":1694,"body":1695,"category":14,"tags":1696},[1175,939],"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",[270,721,697,763],{"slug":1698,"featured":6,"template":700},"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":1704,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1705,"content":1711,"config":1717,"_id":1719,"_type":17,"title":1720,"_source":18,"_file":1721,"_stem":1722,"_extension":21},"/en-us/blog/how-we-turned-40-person-meeting-into-a-podcast",{"title":1706,"description":1707,"ogTitle":1706,"ogDescription":1707,"noIndex":6,"ogImage":1708,"ogUrl":1709,"ogSiteName":686,"ogType":687,"canonicalUrls":1709,"schema":1710},"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":1706,"description":1707,"authors":1712,"heroImage":1708,"date":1714,"body":1715,"category":14,"tags":1716},[1713],"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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[804,721,697,763],{"slug":1718,"featured":6,"template":700},"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":1724,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1725,"content":1731,"config":1739,"_id":1741,"_type":17,"title":1742,"_source":18,"_file":1743,"_stem":1744,"_extension":21},"/en-us/blog/lessons-on-building-a-distributed-company",{"title":1726,"description":1727,"ogTitle":1726,"ogDescription":1727,"noIndex":6,"ogImage":1728,"ogUrl":1729,"ogSiteName":686,"ogType":687,"canonicalUrls":1729,"schema":1730},"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":1726,"description":1727,"authors":1732,"heroImage":1728,"date":1734,"body":1735,"category":14,"tags":1736},[1733],"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",[697,1737,763,1738],"open source","startups",{"slug":1740,"featured":6,"template":700},"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":1746,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1747,"content":1753,"config":1760,"_id":1762,"_type":17,"title":1763,"_source":18,"_file":1764,"_stem":1765,"_extension":21},"/en-us/blog/what-its-like-to-interview-at-gitlab",{"title":1748,"description":1749,"ogTitle":1748,"ogDescription":1749,"noIndex":6,"ogImage":1750,"ogUrl":1751,"ogSiteName":686,"ogType":687,"canonicalUrls":1751,"schema":1752},"A peek inside GitLab's recruitment process: What to expect","A new GitLab team-member shares her experience of being recruited to GitLab, as well as some advice for potential candidates.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680526/Blog/Hero%20Images/interviewing-at-gitlab.jpg","https://about.gitlab.com/blog/what-its-like-to-interview-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What it's like to interview at GitLab: A peek inside the recruitment process\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gosia Ksionek\"}],\n        \"datePublished\": \"2019-03-28\",\n      }",{"title":1754,"description":1749,"authors":1755,"heroImage":1750,"date":1757,"body":1758,"category":14,"tags":1759},"What it's like to interview at GitLab: A peek inside the recruitment process",[1756],"Gosia Ksionek","2019-03-28","\nWhen [Zsuzsanna](/company/team/#zkovacs) from GitLab approached me on LinkedIn, I was sure I had no shot at getting an engineer's job at this kind of company.\nI decided to give it a try anyway, knowing that I can only gain experience and have nothing to lose.\n\nI have to admit, the whole process made me want to work for Gitlab even more, as each step of the way I could clearly see that company values are not only something written in the handbook, but clear guidelines for every part of the process.\nYou can read all about [GitLab's hiring processes here](/handbook/hiring/interviewing/), but I'll also describe each part of the recruitment process as I experienced it, how it was conducted, and what I can advise future candidates:\n\n### Stage 1: Questionnaire\n\nThe first stage was a questionnaire, with both general questions about education and experience,\nbut also two interesting technical questions with the mysterious instruction: \"Describe in as much detail as you think is appropriate,\"\nwhich allowed me to dive into details but also be concise when I felt I have nothing more to add.\nEven this part was educational and left me with some new knowledge!\n\n**Tip**: Take your time! It's not a race, better to get it right.\nWriting is not my forte, it took me over two weeks to write the answers at my own pace.\n\n### Stage 2: Screening call\n\nThe second stage involved talking to one of the GitLab team-members and let me use tools that are adopted among the GitLab team.\nThis first screening call contained general questions about my experience and why I applied.\n\n**Tip**: Read the handbook – not all of course, it's over 2,000 pages – but the general section about the company\nto understand the values and how you see yourself in this kind of environment.\n\n### Stage 3: Technical interview\n\nI was assigned a merge request and asked for a code review.\nDuring the actual interview, we discussed the code review and ways to improve the code.\nLater came time for, in my opinion, the most stressful part of the process: LIVE CODING – every programmer's nightmare.\nSuddenly I wasn't able to hit any proper key on my keyboard ...\nBut I was allowed to check any doubts in Google if needed and we ended the conversation with some time for me to ask questions\nabout GitLab, the process and remote setup.\n\n**Tip**: Don't stress out about live coding.\nAnd plug your laptop into the power source,\nthis interview may last for over an hour and with the video call, it can drain the battery really quickly!\n\n### Stage 4: Manager interview\n\nThe fourth stage was a great opportunity to know more about the team –\nas in GitLab, you are applying to the specific team.\nTalking to the manager was a great chance to ask all the questions I had about the everyday aspects of the job\nand to know who would be my potential teammates.\n\n**Tip**: Be prepared for a variety of questions, both technical and regarding soft skills.\n\n### Final stage\n\nThe last stage was very similar to the previous one, but with the person higher up in the organization.\nI need to say at this stage stress got the better at me – I really wanted it to go well.\n\n**Tip**: Just relax and prepare the same way as for the previous step.\n\n### References\n\nAfter all those steps I was asked to provide references.\nI chose a colleague I worked with at two different companies and my former manager.\n\n**Tip**: Think carefully who can provide the most valuable feedback about you. Not the most positive, of course, it doesn't hurt,\nbut also honest. Who knows your good sides and what can you improve.\n\nAnd after all those steps and stages, all I could do is wait for the final decision ...\n\nI can't emphasize enough how transparent the whole process was.\nI was informed at every stage what was ahead of me, I could pick which time worked best for me, and I got results quite quickly every time.\nPlus everyone was so nice, not only to me but also to my references, and this was so important to me\nas I was asking for a favour. I think all of this – making a candidate understand the process,\ntreating them with respect, and making it a nice experience overall, is a great example of acting according\nto the GitLab values in every way – even through the recruitment process.\n\nTL;DR: would apply again!\n\nPhoto by [Piotr Wilk](https://unsplash.com/photos/Kc-OBw1fMJg?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",[742,697],{"slug":1761,"featured":6,"template":700},"what-its-like-to-interview-at-gitlab","content:en-us:blog:what-its-like-to-interview-at-gitlab.yml","What Its Like To Interview At Gitlab","en-us/blog/what-its-like-to-interview-at-gitlab.yml","en-us/blog/what-its-like-to-interview-at-gitlab",{"_path":1767,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1768,"content":1774,"config":1780,"_id":1782,"_type":17,"title":1783,"_source":18,"_file":1784,"_stem":1785,"_extension":21},"/en-us/blog/incident-management-design-facilitation",{"title":1769,"description":1770,"ogTitle":1769,"ogDescription":1770,"noIndex":6,"ogImage":1771,"ogUrl":1772,"ogSiteName":686,"ogType":687,"canonicalUrls":1772,"schema":1773},"How we used design facilitation to understand incident management","The group responsible for the Monitor stage at GitLab recently got together to decide on new product features with a facilitated design session.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678649/Blog/Hero%20Images/incident_management-blog-image.jpg","https://about.gitlab.com/blog/incident-management-design-facilitation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we used design facilitation to understand incident management\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amelia Bauerly\"}],\n        \"datePublished\": \"2019-03-15\",\n      }",{"title":1769,"description":1770,"authors":1775,"heroImage":1771,"date":1777,"body":1778,"category":14,"tags":1779},[1776],"Amelia Bauerly","2019-03-15","\nBefore starting to design a new product feature, it’s useful to get everyone on the same page by asking a few important questions: What is the problem we are trying to solve?\nWho are we solving this problem for?\nWhat are the steps we should take in trying to solve this problem?\n\nAs we work remotely, collaborating on these questions synchronously isn’t generally an option.\n\nRecently, the [Monitor group](/handbook/engineering/development/ops/monitor/) was given the opportunity to gather in Berlin for a Fast Boot.\nWe took advantage of everyone being in the same place and time zone to host a [facilitated design session](https://gitlab.com/gitlab-org/gitlab-ce/issues/55663) on incident management, where we could answer these questions together.\n\n## How the facilitated design session works\n\nThe session involved walking the group through three exercises, each focusing on one of the core questions we needed to solve.\n\n### We tackled problem definition through running a boundary critique exercise\n\nUsing the [1-2-4-All](http://www.liberatingstructures.com/1-1-2-4-all/) technique, we came up with a list of things incident management is and is not.\nSince we had engineers, designers, and product managers all working together, we were able to benefit from diverse perspectives and experience levels.\nWe finished the exercise by agreeing on a definition of the space we wanted to work on together.\n\n### Next, we did an exercise to build empathy with our users\n\nWe took our four [ops personas](https://handbook.gitlab.com/handbook/product/personas/), broke into groups, and compiled [empathy map canvases](https://gamestorming.com/wp-content/uploads/2017/07/Empathy-Map-Canvas-006.pdf) for each.\nWe then took our deepened understanding of our assigned users and applied it to an imagined incident.\nWe shared our users’ pain points, concerns, and goals with the group.\n\n### Finally, brainstorming product features\n\nHaving established a scope for our work and a sense of our users’ needs, our final exercise involved brainstorming product features that would fit the requirements we had established.\nWe finished the session with everyone dot-voting on features, which left us with a prioritized list of features to work on as we move forward with this project.\n\nThough working this way isn’t a part of our normal flow, the facilitation was a great chance for us all to engage with a product discovery process together.\nBy tackling these questions as a group, we could all come to alignment on what was needed going forward.\nParticipating in these early stages of planning also generates an extra level of commitment to seeing these features through the development process, since we had all agreed on the necessity for them.\n\nWe will continue to explore how to inject the energy and enthusiasm generated by this process into our normal, asynchronous workflow.\n",[804,721,697],{"slug":1781,"featured":6,"template":700},"incident-management-design-facilitation","content:en-us:blog:incident-management-design-facilitation.yml","Incident Management Design Facilitation","en-us/blog/incident-management-design-facilitation.yml","en-us/blog/incident-management-design-facilitation",{"_path":1787,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1788,"content":1794,"config":1801,"_id":1803,"_type":17,"title":1804,"_source":18,"_file":1805,"_stem":1806,"_extension":21},"/en-us/blog/international-womens-day-gitlab-initiatives",{"title":1789,"description":1790,"ogTitle":1789,"ogDescription":1790,"noIndex":6,"ogImage":1791,"ogUrl":1792,"ogSiteName":686,"ogType":687,"canonicalUrls":1792,"schema":1793},"GitLab supports women in STEM for International Women's Day","We're shining a light on some of the initiatives we're proud to support, helping us to give back and foster a global community of women in technology.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680483/Blog/Hero%20Images/international-womens-day.jpg","https://about.gitlab.com/blog/international-womens-day-gitlab-initiatives","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Happy International Women’s Day! How we’re working to inspire and educate women in STEM\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stephanie Garza\"}],\n        \"datePublished\": \"2019-03-08\",\n      }",{"title":1795,"description":1790,"authors":1796,"heroImage":1791,"date":1798,"body":1799,"category":14,"tags":1800},"Happy International Women’s Day! How we’re working to inspire and educate women in STEM",[1797],"Stephanie Garza","2019-03-08","\n\nAs one of our six [core values](https://handbook.gitlab.com/handbook/values/), diversity is more than just a single project or initiative for GitLab.\nIt’s crucial for the success of our globally distributed team, and for the future of the tech industry as a whole.\nGitLab aims to make a significant impact in efforts to foster an environment where everyone can thrive.\nWe have designed a multidimensional approach to ensure we uphold a culture which embodies transparency, opportunity, and open communication.\n\nAs we celebrate [International Women’s Day](https://www.internationalwomensday.com/) today, we’re taking a moment to reflect on the progress so far, while recognizing there’s lots of work to be done to [#BalanceforBetter](https://www.internationalwomensday.com/Theme).\n\n## We're on a mission to support organizations where women thrive\n\nWe hope to shine a light on some of the initiatives we’re passionate about to help build awareness and encourage others to get involved.\n\n### Free workshops with Django Girls, Girls Get Geeky, and Rails Girls\n\nDjango Girls and GitLab partner to provide women free code workshops across the globe.\n[Django Girls](https://djangogirls.org/) (DG) strives to empower women to pursue careers in technology.\nThe free workshops equip women with a solid coding curriculum to kick start their professional journey.\nAlong with DG, we partner with [Girls Get Geeky](https://girlsgetgeeky.com/) and [Rails Girls](http://railsgirls.com/), organizations created to inspire and educate young women in tech.\nThe free workshops provide community, networking, and coding lessons to women of various backgrounds. The women share their goals, dreams (and delicious treats), which GitLab happily supports.\n\n### GitLab Diversity Sponsorship\n\nThrough the [GitLab Diversity Sponsorship program](/community/sponsorship/), we are able to contribute financially to the initiatives.\nThe goal is to foster a community of organizations with the desire to inspire, encourage, and empower women.\nWe have had the pleasure of partnering with [Wonder Women in Tech](https://wonderwomentech.com/), [FemPower](https://www.fempowerafrica.com.ng/), [Women Who Code](https://www.womenwhocode.com/), and [Women Hack](https://womenhack.com/events/), other incredible female-focused powerhouses in the industry.\nThe collaborations allow Gitlab to connect on a greater scale with amazing women around the world. Visit our [Sponsorships page](/community/sponsorship/) to find out more and to apply.\n\nThe greater GitLab team is actively striving to impact change, raise awareness, and fully support global initiatives.\nWe came together at a recent summit to promote the [STEM Gems](https://stemgemsbook.com/), the foundation devoted to giving girls role models in Science, Technology, Engineering, and Mathematics (STEM).\n[GitLab team-members came together to share their stories](/blog/stem-gems-give-girls-role-models/) in hopes of inspiring women to pursue STEM.\nThese collaborations allow GitLab to connect on a greater scale with amazing women around the world. We hope to inspire the community to join us in our pursuit to provide opportunity. Visit the organizations' websites to learn more about contributing through volunteering, mentoring, or sponsoring. \n\n## Our goals for 2019 are even more aggressive\n\nWith the development of the [GitLab Mentorship program](https://gitlab.com/gitlab-com/people-ops/General/issues/178) we hope to inspire and motivate women from across the globe.\nThe goal is to contribute to the development of a better trained and engaged community.\nOur first round of applications is already in and, once paired, mentors will help mentees learn the ropes at the company, develop relationships across the organization, and identify skills to work on developing.\nThe next cohort of mentee applications will open in August.\n\nEducation and encouragement play a vital role in women’s pursuits.\nIn a typically male-dominated field, it’s important for women to come together and support, mentor, and encourage one another.\nThe women of GitLab embody this belief, taking on various projects, workshops, and volunteer opportunities.\nWe rally together to connect our distributed team.\n\nOf course, these initiatives are just a drop in the ocean.\nUniting our team through charity, sponsorship, and mentoring is one stride toward making global change.\nNarrowing the gender gap will remain a constant goal.\nWe aim to provide all GitLab team-members with the opportunity to thrive, contribute, and succeed.\nA balanced and inclusive team will accelerate our potential. [#BalanceforBetter](https://twitter.com/search?q=balance+for+better)\n\nPhoto by [Şahin Yeşilyaprak](https://unsplash.com/photos/SNm9Re4pL9M?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/hot-air-balloon?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText  )\n{: .note}\n",[270,697],{"slug":1802,"featured":6,"template":700},"international-womens-day-gitlab-initiatives","content:en-us:blog:international-womens-day-gitlab-initiatives.yml","International Womens Day Gitlab Initiatives","en-us/blog/international-womens-day-gitlab-initiatives.yml","en-us/blog/international-womens-day-gitlab-initiatives",{"_path":1808,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1809,"content":1815,"config":1821,"_id":1823,"_type":17,"title":1824,"_source":18,"_file":1825,"_stem":1826,"_extension":21},"/en-us/blog/why-we-pay-local-rates",{"title":1810,"description":1811,"ogTitle":1810,"ogDescription":1811,"noIndex":6,"ogImage":1812,"ogUrl":1813,"ogSiteName":686,"ogType":687,"canonicalUrls":1813,"schema":1814},"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":1810,"description":1811,"authors":1816,"heroImage":1812,"date":1818,"body":1819,"category":14,"tags":1820},[1817],"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",[742,697,763,1738],{"slug":1822,"featured":6,"template":700},"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":1828,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1829,"content":1835,"config":1841,"_id":1843,"_type":17,"title":1844,"_source":18,"_file":1845,"_stem":1846,"_extension":21},"/en-us/blog/remote-enables-innovation",{"title":1830,"description":1831,"ogTitle":1830,"ogDescription":1831,"noIndex":6,"ogImage":1832,"ogUrl":1833,"ogSiteName":686,"ogType":687,"canonicalUrls":1833,"schema":1834},"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":1830,"description":1831,"authors":1836,"heroImage":1832,"date":1838,"body":1839,"category":14,"tags":1840},[1837],"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)](https://handbook.gitlab.com/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",[804,697,763,1738,805],{"slug":1842,"featured":6,"template":700},"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":1848,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1849,"content":1855,"config":1860,"_id":1862,"_type":17,"title":1863,"_source":18,"_file":1864,"_stem":1865,"_extension":21},"/en-us/blog/git-for-business-processes",{"title":1850,"description":1851,"ogTitle":1850,"ogDescription":1851,"noIndex":6,"ogImage":1852,"ogUrl":1853,"ogSiteName":686,"ogType":687,"canonicalUrls":1853,"schema":1854},"How we use Git as the blockchain for process changes","Git can be useful for more than just coding and operations. It can help you run your entire business – here's how we do it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679971/Blog/Hero%20Images/git-blockchain.jpg","https://about.gitlab.com/blog/git-for-business-processes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we use Git as the blockchain for process changes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n        \"datePublished\": \"2019-01-15\",\n      }",{"title":1850,"description":1851,"authors":1856,"heroImage":1852,"date":1857,"body":1858,"category":14,"tags":1859},[1817],"2019-01-15","\n\nGit may have started out as a way to collaborate on code, but there’s no denying that it has crept into the operations side of things. But does it stop there? We don’t think so.\n\nJust like [blockchain technology](https://blockgeeks.com/guides/what-is-blockchain-technology/) was originally created for cryptocurrency, but is now seen as a revolutionary way to share, store and update [all kinds of data](https://www.fool.com/investing/2018/04/11/20-real-world-uses-for-blockchain-technology.aspx), we see – and use – Git in much the same way.\n\nIn addition to version controlling code and the environment in which it lives, Git can also be used at a high level to facilitate the way a company actually functions, according to our CEO [Sid Sijbrandij](/company/team/#sytses).\n\nHe says GitLab is a prime example of how it can be done.\n\n## How we use Git to run GitLab, the company\n\n\"We’re not just trying to version our code and operations, we're also trying to version all the processes we have at the company, and we do that for a whole slew of reasons,\" says Sid. \"If you write your processes down, it's easier to change and for someone to propose a change. If it's all stored in people's heads, how are you going to change it? You'll have to create a presentation and make sure everyone reads it. But if it’s written down, it's faster to make a change and you're better able to communicate the context for it.\"\n\n### How Git has helped us to scale\n\nUsing Git to implement procedural changes within the company has helped GitLab shoulder growing pains, thanks to our [handbook](https://handbook.gitlab.com/handbook/).\n\n\"Although we're not a perfect company by any means, we've been able to scale really rapidly, onboard people and get them started with the work they have to do,\" Sid says. \"And I think our handbook and how we describe things is an important part of that. It's exciting to see it grow. The handbook is now over 2,000 pages, so people can't read everything anymore, but they can read the parts that are relevant to them, and it's really helping with organizational changes that are happening between different departments.\"\n\nSid admits running a business with Git collaboration can seem like a daunting task, especially for companies that did not start out functioning that way. But he urges business leaders to give the process a chance, pointing to a number of companies that are adopting Git as a way to make procedural changes, including O’Reilly Media and several law firms.\n\n## Two tips for adopting Git to run your business\n\n### 1. Evangelize from the top down\n\n\"First of all, this is super hard. It's unnatural and it requires constant campaigning from the top of the company,\" Sid said. \"The natural state is for all the documentation to get out of date, and for people to send each other emails and PowerPoints about the change they want to make without looking at the rest of the changes.\"\n\n### 2. Make processes easier to change\n\n\"What you frequently find in companies is that there's the official process, and then the process that people really use. You can prevent that by making processes easier to change. The reality is people are changing processes in a company every single day, and they have to make those changes quickly. So the harder you make it, the more diversions there will be between reality and what's in the handbook. Instead, empower everyone in the organization to make those changes and do so quickly. That is one of the most important things you can do.\"\n\n\"Our handbook is [Creative Commons](https://creativecommons.org/licenses/by-sa/4.0/), so feel free to use that as a starting point for anything that you do.\" [Tweet us](http://twitter.com/gitlab) if you do borrow from or adapt our handbook – we'd love to hear about it.\n\n[Cover image](https://unsplash.com/photos/mf-o1E7omzk) by [chuttersnap](https://unsplash.com/@chuttersnap) on Unsplash\n{: .note}\n",[804,1525,697,1737,805],{"slug":1861,"featured":6,"template":700},"git-for-business-processes","content:en-us:blog:git-for-business-processes.yml","Git For Business Processes","en-us/blog/git-for-business-processes.yml","en-us/blog/git-for-business-processes",{"_path":1867,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1868,"content":1874,"config":1880,"_id":1882,"_type":17,"title":1883,"_source":18,"_file":1884,"_stem":1885,"_extension":21},"/en-us/blog/the-case-for-all-remote-companies",{"title":1869,"description":1870,"ogTitle":1869,"ogDescription":1870,"noIndex":6,"ogImage":1871,"ogUrl":1872,"ogSiteName":686,"ogType":687,"canonicalUrls":1872,"schema":1873},"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":1869,"description":1870,"authors":1875,"heroImage":1871,"date":1877,"body":1878,"category":14,"tags":1879},[1876],"Suri Patel","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](https://handbook.gitlab.com/handbook/communication/#introduction) becomes a\nnecessity, which helps instill good, scalable working practices. At GitLab, we\ndocument best practices in our [handbook](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[697,763],{"slug":1881,"featured":6,"template":700},"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":1887,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1888,"content":1894,"config":1899,"_id":1901,"_type":17,"title":1902,"_source":18,"_file":1903,"_stem":1904,"_extension":21},"/en-us/blog/how-we-keep-investors-in-the-loop",{"title":1889,"description":1890,"ogTitle":1889,"ogDescription":1890,"noIndex":6,"ogImage":1891,"ogUrl":1892,"ogSiteName":686,"ogType":687,"canonicalUrls":1892,"schema":1893},"How we keep investors in the loop","Monthly updates to investors and team members ensure transparency and open communication.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678944/Blog/Hero%20Images/investorupdate.jpg","https://about.gitlab.com/blog/how-we-keep-investors-in-the-loop","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we keep investors in the loop\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-10-17\",\n      }",{"title":1889,"description":1890,"authors":1895,"heroImage":1891,"date":1896,"body":1897,"category":14,"tags":1898},[1876],"2018-10-17","\nI was a bright-eyed and bushy-tailed new GitLab team-member of two months when I emailed\n[Sid](/company/team/#sytses), the CEO of GitLab, and told him that I thought the investor\nupdate format needed a makeover. During my onboarding, I had heard that\n[**everyone can contribute**](/company/strategy/#why), so I decided to take the idea\nfor a test drive.\n\n![My message to Sid.](https://about.gitlab.com/images/blogimages/suriemail.png){: .shadow}\n\nI obsessively refreshed my inbox, waiting to see whether the sentiment was highly\nregarded only in theory, when Sid’s reply arrived.\n\n![Sid’s response.](https://about.gitlab.com/images/blogimages/sidemail.png){: .shadow}\n\n_Challenge accepted, Sijbrandij._ 😎\n\n## Updating the template\n\nOur investor update has gone through several iterations over the years. In the\nearly days, we included sections on hiring, feedback, and upcoming features.\nAfter reading blog posts by\n[Elad Gil](http://blog.eladgil.com/2015/05/investor-update-emails.html) and\n[Aaron K. Harris](http://www.aaronkharris.com/investor-updates), Sid developed\nour current version with their insights in mind and narrowed the scope of our\nupdate to the following sections: thanks, asks, key metrics, lowlights,\nhighlights, and next month expectations.\n\nWhen I joined GitLab, the investor update looked cluttered, and from a reader’s\nperspective, I had difficulty absorbing the information. Below is an example of\nan old update with the former template. Please note that some names have been\nchanged to respect organizations’ privacy.\n\n![Former investor update template.](https://about.gitlab.com/images/blogimages/oldtemplatev3.png){: .shadow}\n\nKnowing that investors can only dedicate a few minutes to each email, I knew that\nI had to organize the sections and copy in a way that would increase comprehension\nand reading speed, so I employed UX copy techniques.\n\n![New investor update template.](https://about.gitlab.com/images/blogimages/originaltemplate.png){: .shadow}\n\nWith this new format, investors can quickly read the update and locate the\ninformation that is most relevant to them.\n\n### Why these categories are important\n\nEach of the seven sections provides investors with a look inside GitLab, offering\na comprehensive assessment of our monthly performance.\n\n1. **CEO foreword**: A brief introduction that will typically coincide with the close of a fiscal quarter. This narrative will provide a high level overview of company operations from the most recently ended quarter as well as key initiatives and expectations for upcoming quarters. \n1. **Thanks**: We express gratitude for investors who have assisted us with\nmaking introductions, providing feedback, or offering assistance. Investing is a\ntype of social engagement, and we like to celebrate people who set aside time to\nhelp us.\n1. **Asks**: We ask our investors to help us connect with people or\norganizations, introduce us to hiring candidates, or provide some other assistance.\nInvestors can be extremely helpful and often say they want to add\nvalue when they invest, so this area of the update gives them the opportunity to\ndrive our business forward.\n1. **Key metrics**: People want to know how their investment is performing.\nOffering figures instills trust and shows a certain discipline and rigor. We\nwant our investors to know how we’re doing - even when we don’t meet our goals -\nbecause we believe in [transparency](https://handbook.gitlab.com/handbook/values/#transparency).\n1. **Lowlights**: Our commitment to open communication extends to this\nsection in which we always list the top three worst things that occurred in the\nmonth. By committing to three items, the question is no longer, “_Should_ I tell\nmy investors?” It’s “_Which_ three things are the most severe?” That's a\nmuch easier question to answer.\n1. **Highlights**: This section gets people excited about the investment and\nillustrates what we’re doing well.\n1. **Expectations**: We discuss what we’re looking forward to, conferences we’re\nattending, and what we’re planning in the next month.\n\n### Have a fixed number of good and bad things\n\nEvery month we send three lowlights and three highlights.\nThis forces us to always tell the three things that are worst.\nWe never have to wonder if something is important enough to include it.\nBy the severity of the items people can tell if it was a good or bad month.\n\n## Every company should send monthly updates\n\nIf you’re not sending investor updates, you’re keeping your biggest proponents\nin the dark. If people invested in your organization, you should keep them up to\ndate on what's happening with their investment. If investors don’t receive regular\ncommunication, they’re forced to go fishing for information and what they might\nhear could be inaccurate.\n\nMonthly updates instill confidence and save you from having to\nfield questions from several directions. When organizations don’t communicate,\ninvestors constantly have to ping their companies to ask how things are going.\nBut, if they receive regular updates, they know they're going to hear from you\nand learn the most challenging things that happened in the previous month. You\ndon’t want to give your investors any reason to worry.\n\nMonthly updates also help you build stronger bonds with investors. Because the\nbasics of an investment are covered each month, conversations with investors\ncan focus on deeper subjects. You can brainstorm about strategy, long-term\ngoals, and emerging trends rather than recap hiring challenges and share\nrelease updates.\n\n## Investors \u003C3 information\n\nInvestors have told us how much they love our updates, specifically expressing\ntheir appreciation of the reliability of our emails. We send the updates around\nthe 10th (give or take 1-3 days) of every month, so investors have come to\nexpect a little GitLab sunshine in their inbox.\n\nInvestors love the format(!) and [Y Combinator](http://www.ycombinator.com/)\nreached out to Sid asking whether the format could be shared with other YC\nfounders in a resource of high quality updates. As Sid says, “The format seems\nto be better than average.”\n\n>“I want to thank you and also commend you for having such\nconsistent, regular, excellent shareholder communications. It’s rare\nto see, and I think it elevates your company and it’s something that\nonly grows in importance as the company scales.” — GitLab investor\n\n## Now it’s your turn\n\nIf you’d like to send your investors a monthly update, we invite you to\n[create a copy](https://docs.google.com/document/d/1TVpESZlemYWLrXQHeDvnASCFvs_tvjpJnLahEFMIxYE/copy)\nof our template. As you work on your update, please remember that it’s important\nto establish a regular cadence and keep the emails concise. Links to spreadsheets\nwith detailed figures and an offer to answer any questions prevents people from\nbecoming overwhelmed.\n\nOur updates are also sent to team members, because we all have stock options and\nSid believes that it’s the company’s duty to inform us of our investment.\nMoreover, team members should know the highlights, lowlights, and next month's\nexpectations, since we’re all working towards a [common goal](/company/strategy/#sequence).\nWe encourage you to send the updates to your team since they invest their talents,\nideas, and efforts into making your organization successful.\n\nUPDATE: To see what we currently do, see our [Investor Relations page on our Monthly Investor Updates](/handbook/finance/investor-relations/#monthly-investor-update-email).\n",[1738,697],{"slug":1900,"featured":6,"template":700},"how-we-keep-investors-in-the-loop","content:en-us:blog:how-we-keep-investors-in-the-loop.yml","How We Keep Investors In The Loop","en-us/blog/how-we-keep-investors-in-the-loop.yml","en-us/blog/how-we-keep-investors-in-the-loop",{"_path":1906,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1907,"content":1913,"config":1918,"_id":1920,"_type":17,"title":1921,"_source":18,"_file":1922,"_stem":1923,"_extension":21},"/en-us/blog/stem-gems-give-girls-role-models",{"title":1908,"description":1909,"ogTitle":1908,"ogDescription":1909,"noIndex":6,"ogImage":1910,"ogUrl":1911,"ogSiteName":686,"ogType":687,"canonicalUrls":1911,"schema":1912},"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":1908,"description":1909,"authors":1914,"heroImage":1910,"date":1915,"body":1916,"category":14,"tags":1917},[1797],"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",[742,270,804,697,763],{"slug":1919,"featured":6,"template":700},"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":1925,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1926,"content":1932,"config":1939,"_id":1941,"_type":17,"title":1942,"_source":18,"_file":1943,"_stem":1944,"_extension":21},"/en-us/blog/how-i-transitioned-from-frontend-to-ux",{"title":1927,"description":1928,"ogTitle":1927,"ogDescription":1928,"noIndex":6,"ogImage":1929,"ogUrl":1930,"ogSiteName":686,"ogType":687,"canonicalUrls":1930,"schema":1931},"How I transitioned from frontend to UX","One GitLab team-member shares how switching from a frontend engineer to a UX designer has been a rewarding experience.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679015/Blog/Hero%20Images/frontendux.jpg","https://about.gitlab.com/blog/how-i-transitioned-from-frontend-to-ux","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How I transitioned from frontend to UX\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Annabel Dunstone Gray\"}],\n        \"datePublished\": \"2018-10-05\",\n      }",{"title":1927,"description":1928,"authors":1933,"heroImage":1929,"date":1935,"body":1936,"category":14,"tags":1937},[1934],"Annabel Dunstone Gray","2018-10-05","\nWhen I joined GitLab over two and a half years ago as a frontend engineer, I brought with\nme a background in photography and an interest in art and design. In my last year\nof university, I worked at an art museum, and I’ve always gravitated towards the\nmore design-y aspects of frontend. For each release, my assigned deliverables\nwere usually focused on redesigns, and while I enjoy that type of work, what I\nreally wanted to do was to help shape the look and feel of GitLab, rather than\nimplementing the designs of others.\n\n## Making the first move\n\nAt GitLab, we're lucky to have the opportunity to [transfer](/handbook/people-group/promotions-transfers/#department-transfers)\nto a different department, if our interests or career goals change. I spoke with\nmy frontend manager about my passions and shared my desire to start learning and\nworking with the UX team. I then spoke with [Sarrah](/company/team/#SVesselov),\nthe UX Manager, about the next steps, and I started working through online\ntutorials, getting up to speed on Sketch, and attending the UX weekly calls.\nOnce I acquired the necessary technical skills, I joined the [Plan](/direction/#plan)\nteam, which is focused mostly on the prioritization of ideas, allocation of\nresources, scheduling, and tracking. It’s an area I’m really excited about, and\nwe’re working on some incredibly useful management features (like [improved issue boards](https://gitlab.com/gitlab-org/gitlab-ce/issues/48847), [sub-epics](https://gitlab.com/gitlab-org/gitlab-ee/issues/7327), and [value stream management](https://gitlab.com/groups/gitlab-org/-/epics/229)) that will help make\nGitLab an even more powerful tool.\n\nAs a frontend engineer, I was fortunate to have developed many transferable\nskills which helped me tackle this new challenge. Attention to detail is one\nskill that has been particularly useful when working on a new feature. Since\nI’m new to UX, I’ve found it really helpful to have a technical background,\nespecially considering that GitLab is such a technical product.\n\n## Advice to others\n\n![Me and my daughter attending a frontend meeting.](https://about.gitlab.com/images/blogimages/annabelandbaby.jpg){:.shadow.small.right.wrap-text}\n\nIf you’re interested in making a similar transition, I encourage you to speak\nwith your manager. I wish I’d done so sooner. I discussed my interests early\nlast year, but after having a baby, I had this idea that I\nshould stay in my current role, as I would never have time to learn a whole new\npractice. While I definitely don’t have any free time (I don’t know if you’ve\nheard – babies are quite time consuming), I’m so happy to be on the UX team, even\nthough I have a lot of catching up to do. Everyone in both frontend and UX has\nbeen incredibly supportive of my switching teams, and I’m learning a lot as I go\nalong. For now, I’ve got the best of both worlds – 50 percent of my time is focused on\nstyling-related frontend issues and reviewing the CSS in merge requests, while\nthe other 50 percent is working on UX issues.\n\nBy the way, we're hiring for loads of positions, across the company – [check out our current job openings](/jobs/).\n\n[Cover image](https://unsplash.com/photos/aLGiPJ4XRO4) by [Bharath](https://unsplash.com/@xen0m0rph), licensed under [CC X](https://unsplash.com/license).\n{: .note}\n",[1098,1938,742,697],"frontend",{"slug":1940,"featured":6,"template":700},"how-i-transitioned-from-frontend-to-ux","content:en-us:blog:how-i-transitioned-from-frontend-to-ux.yml","How I Transitioned From Frontend To Ux","en-us/blog/how-i-transitioned-from-frontend-to-ux.yml","en-us/blog/how-i-transitioned-from-frontend-to-ux",{"_path":1946,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1947,"content":1953,"config":1958,"_id":1960,"_type":17,"title":1961,"_source":18,"_file":1962,"_stem":1963,"_extension":21},"/en-us/blog/what-were-reading-in-september",{"title":1948,"description":1949,"ogTitle":1948,"ogDescription":1949,"noIndex":6,"ogImage":1950,"ogUrl":1951,"ogSiteName":686,"ogType":687,"canonicalUrls":1951,"schema":1952},"What we've been reading in September","We've been busting out our bookmarks this month – discover what we've been reading.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678773/Blog/Hero%20Images/septemberreading.jpg","https://about.gitlab.com/blog/what-were-reading-in-september","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What we've been reading in September\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-09-25\",\n      }",{"title":1948,"description":1949,"authors":1954,"heroImage":1950,"date":1955,"body":1956,"category":14,"tags":1957},[1876],"2018-09-25","\nTo get back into the swing of things after our [recent summit](/blog/gitlab-summit-cape-town-recap/),\nwe've been reading. Here's what we've been discussing on Slack:\n\n### [I just deployed a serverless app – and I can't code. Here's how I did it](https://medium.freecodecamp.org/i-just-deployed-a-serverless-app-and-i-cant-code-here-s-how-i-did-it-94983d7b43bd).\n\n[Erica Lindberg](/company/team/#EricaLindberg_), Content Marketing Manager, raves about\nthis Medium article,\nsaying \"I loved this article, and this woman might be my new hero.\"\n\n### [High Growth Handbook](https://www.amazon.com/High-Growth-Handbook-Elad-Gil/dp/1732265100)\n\n[Sid Sijbrandij](/company/team/#sytses), CEO, is currently reading and loving\nthis insightful playbook.\n\n### [The Design of Everyday Things](https://www.amazon.com/Design-Everyday-Things-Revised-Expanded/dp/0465050654/ref=sr_1_1?ie=UTF8&qid=1536093671&sr=8-1&keywords=The+Design+of+Everyday+Things%3A+Revised+and+Expanded+Edition)\n[Jeremy Watson](/company/team/#d3arWatson), Product Manager, has been rereading this\npowerful book, saying\n\"It's a constant reminder to practice mindfulness in the things we ship at GitLab, and to make\nsure we're adding features to the product that are consciously designed. The book\nalways serves as a reminder that we're all designers; it's our collective\nresponsibility to ensure that we're intentionally solving the right problems for our users.\"\n\n### Go 2 Draft Designs\n\n[Eric Johnson](/company/team/#edjdev), VP of Engineering, has been reading about the\nbig news: [Generics in Golang 2.0](https://blog.golang.org/go2draft)! Woohoo!\n\n### [Storytelling with Data: A Data Visualization Guide for Business Professionals](https://www.amazon.com/Storytelling-Data-Visualization-Business-Professionals/dp/1119002257)\n\n[Emilie Schario](https://gitlab.com/emilie), Data Analyst, has been enjoying\nthis riveting read,\nand says, \"In my role as a data analyst, I spend a lot of time helping different\nteams understand what the data they're collecting or using mean. Clear\ncontext, useful narratives, and consistent visuals help me empower stakeholders\nto make data-driven decisions.\"\n\n[Cover image](https://unsplash.com/photos/XT-o5O458as?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) by [Ugur Akdemir](https://unsplash.com/@ugur), licensed\nunder [CC X](https://unsplash.com/license)\n{: .note}\n",[697],{"slug":1959,"featured":6,"template":700},"what-were-reading-in-september","content:en-us:blog:what-were-reading-in-september.yml","What Were Reading In September","en-us/blog/what-were-reading-in-september.yml","en-us/blog/what-were-reading-in-september",{"_path":1965,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1966,"content":1972,"config":1977,"_id":1979,"_type":17,"title":1980,"_source":18,"_file":1981,"_stem":1982,"_extension":21},"/en-us/blog/what-we-re-reading",{"title":1967,"description":1968,"ogTitle":1967,"ogDescription":1968,"noIndex":6,"ogImage":1969,"ogUrl":1970,"ogSiteName":686,"ogType":687,"canonicalUrls":1970,"schema":1971},"What we're reading","GitLab team-members are a passionate group of learners who enjoy reading to strengthen their skills, develop new techniques, and enhance their knowledge.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683225/Blog/Hero%20Images/gitlabreading.jpg","https://about.gitlab.com/blog/what-we-re-reading","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What we're reading\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-08-27\",\n      }",{"title":1967,"description":1968,"authors":1973,"heroImage":1969,"date":1974,"body":1975,"category":14,"tags":1976},[1876],"2018-08-27","\nAt GitLab, we ❤️ reading. Here are a few of our recent pageturners.\n\n### How Rust’s standard library was vulnerable for years and nobody noticed\n[Nick Thomas](/company/team/#nick.thomas), Staff Developer, enjoyed\n[this article](https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6)\non Rust, a new systems programming language. Nick commented, \"It was very\ninteresting from a general-security point of view, especially the\n'everything is broken' and 'here is how security advisories actually work' bits.\"\n\n### Designing Delivery: Rethinking IT in the Digital Service Economy\n[Kristie McGoldrick](/company/team/#Krist_McG), Solutions Architect, has been devouring\n[this book](https://www.amazon.com/Designing-Delivery-Rethinking-Digital-Service/dp/1491949880/ref=mt_paperback?_encoding=UTF8&me=&qid=),\nfinding it \"very applicable to GitLab.\"\n\n### It's the Future\n[Lin Jen-Shin](/company/team/#godfat-gitlab), Developer, fondly reflects on\n[this CircleCI blog post](https://circleci.com/blog/its-the-future/), saying\n\"I think I'll remember this post forever. One person is trying to persuade\na teammate, who just wants to get things done right now, to use future technology.\nThe future tech is not mature enough to get things done easily, so it\novercomplicates a lot of things, and the teammate just wants something simple. It's\npretty technical, but it's funny! That future tech is getting closer to becoming\nmature now, and GitLab is  trying to use Kubernetes and collaborating with Google\nto make this tech better.\"\n\n### The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win\n\n[Rebecca Dodd](/company/team/#rebecca), Content Editor, recently read\n[\"The Phoenix Project\"](https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509)\nand confidently declared that, \"I think we’ve\nall read 'The Phoenix Project.'\"\n\n### The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations\n\n[Mike Miranda](/company/team/#zmikemiranda), Sales Development Representative, just\npicked up [\"The DevOps Handbook\"](https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations-ebook/dp/B01M9ASFQ3/)\nto understand the needs of IT leaders.\n\n",[697],{"slug":1978,"featured":6,"template":700},"what-we-re-reading","content:en-us:blog:what-we-re-reading.yml","What We Re Reading","en-us/blog/what-we-re-reading.yml","en-us/blog/what-we-re-reading",{"_path":1984,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1985,"content":1991,"config":1996,"_id":1998,"_type":17,"title":1999,"_source":18,"_file":2000,"_stem":2001,"_extension":21},"/en-us/blog/iterating-improving-frontend-culture",{"title":1986,"description":1987,"ogTitle":1986,"ogDescription":1987,"noIndex":6,"ogImage":1988,"ogUrl":1989,"ogSiteName":686,"ogType":687,"canonicalUrls":1989,"schema":1990},"How we iterated and improved our frontend team culture","A recent internal survey revealed that the frontend team culture needed some improvements. Here are some noteworthy steps we took.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684058/Blog/Hero%20Images/improving-frontend-team-culture.jpg","https://about.gitlab.com/blog/iterating-improving-frontend-culture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we iterated and improved our frontend team culture\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Clement Ho\"}],\n        \"datePublished\": \"2018-06-26\",\n      }",{"title":1986,"description":1987,"authors":1992,"heroImage":1988,"date":1994,"body":1995,"category":14},[1993],"Clement Ho","2018-06-26","\n\nIn February, the [results of GitLab's first anonymous engineering engagement survey were announced][survey-results-announced].\nThe purpose of this survey was to understand the culture of the teams and the organization as a whole, and to identify areas of improvement (if any).\n\nThrough this engagement survey, it was identified that out of all the engineering teams, members of the frontend team felt the least favorable about being safe to share their opinions.\n\n![frontend-survey-culture-image][frontend-survey-culture-image]{: .shadow.medium.center}\n*\u003Csmall>Only 58.3 percent of the frontend team felt safe to express their opinions\u003C/small>*\n\n## Steps taken to improve our frontend team culture\n\nSince the results were published, we've taken multiple iterative steps to improve our culture. Below are a few noteworthy steps we thought were insightful to share with the community.\n\n### Monthly themed frontend calls\n\nAs a remote company, it tends to be difficult to have casual conversations with your coworkers.\nAlthough at GitLab we have our [team calls][team-call], interactions between frontend team members seemed to always be work related.\nLast year, I had the opportunity to visit my former frontend lead, [Jacob Schatz][jacob-schatz], in person and it made an impact on our relationship because it created a space for us to chat casually about non-work topics.\nThese casual conversations created a foundation for me to feel comfortable giving constructive feedback because I understood him on a personal level.\nGitLab has regular [summits][summits] for team members to meet face to face, so perhaps we need to be more intentional about that time during our next summit, but it wouldn't be ideal for the team to wait until then to take steps to improve our culture.\n\nAs a means to bridge casual conversations within the frontend team, [monthly themed frontend calls][issue-monthly-frontend-calls] was created. Before this, the frontend team would have a weekly 30-minute call to discuss new technologies or to share new information with the team. Since discussions about frontend technologies can get highly opinionated (just ask a group of frontend engineers what framework to use), our calls tend to lean more on the serious note.\n\nTo lighten the mood and encourage some non-work-related conversation, every first call of the month, a theme is chosen by the winner of the previous month and each team member is encouraged to share something in line with the theme. After all the team members share their story about their theme, we all vote to see who wins that month.\n\n![themed-call][themed-call]{: .shadow.medium.center}\n*\u003Csmall>Our first themed frontend call – most interesting hat (check out the [handbook][theme-call-handbook] to see who won)\u003C/small>*\n\n### Frontend calendar\n\nSince our team ships code fast, one of the challenges noticed was that frontend team members can often feel left out of decisions. Sometimes frontend-related meetings take place on demand (whenever the respective parties are online) that feels excluding to other team members (who may have good insights to contribute to the discussion). As a result, we created a [shared frontend calendar][calendar-handbook] as a means of unifying and including team members on frontend-related discussions.\n\nOne of the early successes of this calendar was a meeting that discussed the \"Overview of frontend tests at GitLab.\" This was a session about testing that was created since we had a few new hires at the time who wanted to learn, but the existing frontend documentation wasn't adequate. After the session, we added improvements to the documentation. Due to the open nature of this calendar, we also fostered open collaboration with other engineering teams as [Mek Stittri][mek] (Engineering Manager of the Quality team) joined that session because he was new to GitLab and had prior experience in JavaScript testing.\n\n### #frontend_maintainers Slack channel\n\nAnother challenge our frontend team encountered was that sometimes maintainers' code review feedback would contradict one another. It seemed to be because sometimes information about a best practice wasn't communicated well within the group of maintainers. As a result, we created a #frontend_maintainers slack channel to create a space for frontend maintainers to share knowledge, ask questions and get on the same page about what code should be merged into the codebase.\n\n![frontend-maintainers-channel][frontend-maintainers-channel]{: .shadow.medium.center}\n\n## Results\n\nAlthough there won't be another engineering survey until later this year to accurately measure whether these steps made an impact, I've personally seen the frontend team culture grow positively over the last few months. One of the biggest examples of improvement was the recent Content Hack Day. Since the beginning of this year, the content team hosts these days to encourage team members to write blog posts for the company. ([One][hacker-news-post] of these hack day posts also recently hit [number 1 on hacker news][hacker-news]). There are always great prizes, but one to mention is the team prize – the team that contributes the most blog posts wins an evangelism dinner for each member of the team (company reimburses up to $100 USD for a meal).\n\nLeading up to the Content Hack Day, I learned that this iteration of the event required teams to have at least 50 percent participation (jump on the open Zoom call, write blog posts, contribute blog post ideas... etc.) to qualify for the team prize. Since our team was 16 people at the time, it seemed pretty tough to get eight team members to participate. I announced the Hack Day on the frontend team call and that led to [Lukas Eipert][lukas] creating a private Slack channel (#content-hack-fe) for the frontend team to brainstorm ideas before the day, so that we could have the best chance of winning the team prize.\n\nTo my surprise, on the actual day, the frontend team had a 68.7 percent participation rate and eight blog posts. This is especially encouraging for the frontend team culture because the event took place on a public holiday for several team members which, statistically speaking, should have decreased our participation.\n\nOverall, it's been amazing to see the culture shift since the beginning of the year. There are probably still many steps we can take to get better, but I am confident that if the team continues at its current trajectory, the frontend team culture will soon become the example for other teams to learn from about how to foster a positive culture.\n\nCover image: [Photo][unsplash-photo] by [Kimson Doan][unsplash-author] on [Unsplash][unsplash]\n{: .note}\n\n[survey-results-announced]: https://youtu.be/BNwx-QslzjI?t=3m33s\n[jacob-schatz]: /company/team/#jakecodes\n[team-call]: /handbook/communication/#team-call\n[summits]: /culture/summits/\n[issue-monthly-frontend-calls]: https://gitlab.com/gitlab-com/organization/issues/149\n[theme-call-handbook]: /handbook/engineering/frontend/#frontend-team-calls\n[calendar-handbook]: /handbook/engineering/frontend/#frontend-calendar\n[mek]: /company/team/#mekdev\n[lukas]: /company/team/#leipert_io\n[frontend-survey-culture-image]: /images/frontend_culture/engineering-survey-culture.png\n[themed-call]: /images/frontend_culture/themed-call.png\n[frontend-maintainers-channel]: /images/frontend_culture/frontend-maintainers-channel.png\n[unsplash-photo]: https://unsplash.com/photos/AZMmUy2qL6A\n[unsplash-author]: https://unsplash.com/\n[unsplash]: https://unsplash.com/\n[hacker-news-post]: /2018/06/15/introducing-gitlab-s-integrated-development-environment\n[hacker-news]: https://news.ycombinator.com/item?id=17321921\n",{"slug":1997,"featured":6,"template":700},"iterating-improving-frontend-culture","content:en-us:blog:iterating-improving-frontend-culture.yml","Iterating Improving Frontend Culture","en-us/blog/iterating-improving-frontend-culture.yml","en-us/blog/iterating-improving-frontend-culture",{"_path":2003,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2004,"content":2010,"config":2016,"_id":2018,"_type":17,"title":2019,"_source":18,"_file":2020,"_stem":2021,"_extension":21},"/en-us/blog/people-ops-using-gitlab",{"title":2005,"description":2006,"ogTitle":2005,"ogDescription":2006,"noIndex":6,"ogImage":2007,"ogUrl":2008,"ogSiteName":686,"ogType":687,"canonicalUrls":2008,"schema":2009},"GitLab People Ops: Getting drunk on our own wine","How our People Ops team uses GitLab day to day: from onboarding new GitLab team-members to keeping our handbook up to date.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678697/Blog/Hero%20Images/how-people-ops-uses-gitlab.jpg","https://about.gitlab.com/blog/people-ops-using-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab People Ops: Getting drunk on our own wine\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chloe Whitestone\"}],\n        \"datePublished\": \"2018-05-25\",\n      }",{"title":2005,"description":2006,"authors":2011,"heroImage":2007,"date":2013,"body":2014,"category":14,"tags":2015},[2012],"Chloe Whitestone","2018-05-25","\nWe’ve heard people say \"[every company is a software company](https://www.forbes.com/sites/techonomy/2011/11/30/now-every-company-is-a-software-company/#5761b57cf3b1),\" but what about the people who work there? At GitLab, we [drink our own wine](/company/culture/), and that means all of our team members, in some way or another, are technical because we use GitLab ourselves. In [People Ops and recruiting](/handbook/people-group/), I use GitLab every day; just take a look at my [activity chart](https://gitlab.com/chloe)!\n\n![Chloe's GitLab Activity Chart](https://about.gitlab.com/images/blogimages/gitlab-chloe.png){: .shadow.medium.center}\n\nThese blue squares represent contributions I’ve made across the GitLab project (and the white ones prove that work/life balance exists!).\n\n## Getting started with issues\n\nA good portion of those blue squares are dedicated towards issues, specifically pre-established template issues, such as [the onboarding issue](https://gitlab.com/gitlab-com/people-group/employment-templates/-/blob/main/.gitlab/issue_templates/onboarding.md). This is the \"first look\" our new hires have into GitLab and our workflow, and it’s a fantastic way to get them using issues, and thus GitLab the product, right away. One of the tasks in this issue is \"add yourself to the [team page](/company/team/),\" so within the first week at GitLab, all team members submit a merge request, even if they’ve never coded before. Another task is to \"make an improvement to the handbook,\" which both encourages new hires to submit another merge request and to explore our handbook and adopt our ethos of \"everyone can contribute.\"\n\n>within the first week at GitLab, all team members submit a merge request, even if they’ve never coded before\n\nOther issue templates we have and use regularly are [offboarding](https://gitlab.com/gitlab-com/people-group/employment-templates/-/blob/main/.gitlab/issue_templates/offboarding.md) and [opening new vacancies](https://gitlab.com/gitlab-com/people-ops/vacancy/blob/master/.gitlab/issue_templates/vacancy.md). People Ops uses these issue templates to maintain version control, enable everyone to contribute, and allow us to continually iterate and improve on how we onboard our new hires, all of which promote the GitLab [values](https://handbook.gitlab.com/handbook/values/).\n\nWe constantly iterate on all of our issue templates, predominantly the onboarding issue template mentioned above. You can view its [history](https://gitlab.com/gitlab-com/people-ops/employment/commits/master/.gitlab/issue_templates/onboarding.md) and see how everyone at the company iterates on our onboarding issue – not just People Ops, but also new hires and seasoned GitLab team-members. You can also view some of the ideas we’re working through in the [\"Overhaul onboarding for Ta-NEW-kis\" issue](https://gitlab.com/gitlab-com/people-ops/General/issues/105), and feel free to contribute your own ideas!\n\n## Transparent by default\n\nPeople Ops and HR departments are not typically considered transparent at most companies, but here at GitLab we try our best to be as transparent as possible. The only times we keep things confidential are when we are legally required to, or to protect someone’s privacy. Everything else is fair game! Some great examples in our handbook are our [identity data](/company/culture/inclusion/identity-data/), [internal feedback](/company/culture/internal-feedback/), and the questions we ask in our [screening calls with candidates](/handbook/hiring/interviewing/#screening-call). We make it a point to keep this data, as well as other handbook pages dedicated to People Ops and recruiting, up to date and accurate.\n\n## Everyone can contribute\n\nWe encourage our team members and the wider GitLab community to contribute and give us their ideas because they will have a fresh look and unique perspective, which can only improve our own understanding.\n\nI remember when I joined GitLab a year ago, I interviewed with [Sid Sijbrandij](/company/team/#sytses), our CEO, and he asked me what I wanted to accomplish within my first month at GitLab. I told him I wanted to become proficient in Git so that I could properly contribute, and he was surprised! But I was steadfast, and within my first two weeks, I’d already started contributing via my local machine. Sure, I’m not a developer by any means, but I use Git every day, have figured out quite a few things both on my own, and with the help of our #git-help Slack channel, was even granted merge powers last year! Here at GitLab, everyone can contribute, no matter what your background is.\n\nPhoto by [Maxime Le Conte des Floris](https://unsplash.com/) on Unsplash\n{: .note}\n",[697,804,805],{"slug":2017,"featured":6,"template":700},"people-ops-using-gitlab","content:en-us:blog:people-ops-using-gitlab.yml","People Ops Using Gitlab","en-us/blog/people-ops-using-gitlab.yml","en-us/blog/people-ops-using-gitlab",{"_path":2023,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2024,"content":2029,"config":2035,"_id":2037,"_type":17,"title":2038,"_source":18,"_file":2039,"_stem":2040,"_extension":21},"/en-us/blog/eliminating-distractions-and-getting-things-done",{"title":2025,"description":2026,"ogTitle":2025,"ogDescription":2026,"noIndex":6,"ogImage":1269,"ogUrl":2027,"ogSiteName":686,"ogType":687,"canonicalUrls":2027,"schema":2028},"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://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":2025,"description":2026,"authors":2030,"heroImage":1269,"date":2032,"body":2033,"category":14,"tags":2034},[2031],"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](https://handbook.gitlab.com/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",[763],{"slug":2036,"featured":6,"template":700},"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":2042,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2043,"content":2049,"config":2055,"_id":2057,"_type":17,"title":2058,"_source":18,"_file":2059,"_stem":2060,"_extension":21},"/en-us/blog/day-in-life-of-remote-sdr",{"title":2044,"description":2045,"ogTitle":2044,"ogDescription":2045,"noIndex":6,"ogImage":2046,"ogUrl":2047,"ogSiteName":686,"ogType":687,"canonicalUrls":2047,"schema":2048},"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":2044,"description":2045,"authors":2050,"heroImage":2046,"date":2052,"body":2053,"category":14,"tags":2054},[2051],"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](https://handbook.gitlab.com/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",[763,697],{"slug":2056,"featured":6,"template":700},"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":2062,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2063,"content":2069,"config":2076,"_id":2078,"_type":17,"title":2079,"_source":18,"_file":2080,"_stem":2081,"_extension":21},"/en-us/blog/remote-future-how-remote-companies-stay-connected",{"title":2064,"description":2065,"ogTitle":2064,"ogDescription":2065,"noIndex":6,"ogImage":2066,"ogUrl":2067,"ogSiteName":686,"ogType":687,"canonicalUrls":2067,"schema":2068},"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":2070,"description":2065,"authors":2071,"heroImage":2066,"date":2073,"body":2074,"category":14,"tags":2075},"The remote future: How tech companies are helping their remote teams connect",[2072],"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",[763],{"slug":2077,"featured":6,"template":700},"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":2083,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2084,"content":2090,"config":2097,"_id":2099,"_type":17,"title":2100,"_source":18,"_file":2101,"_stem":2102,"_extension":21},"/en-us/blog/high-efficiency-innovation",{"title":2085,"description":2086,"ogTitle":2085,"ogDescription":2086,"noIndex":6,"ogImage":2087,"ogUrl":2088,"ogSiteName":686,"ogType":687,"canonicalUrls":2088,"schema":2089},"3 lessons for innovation and rapid execution from GitLab","Guest author Jay Newman recently shadowed our CEO to discover how we move so quickly.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680169/Blog/Hero%20Images/high-efficiency-innovation.jpg","https://about.gitlab.com/blog/high-efficiency-innovation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"High-efficiency innovation: 3 lessons to learn from GitLab's culture of rapid execution\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jay Newman\"}],\n        \"datePublished\": \"2018-03-27\",\n      }",{"title":2091,"description":2086,"authors":2092,"heroImage":2087,"date":2094,"body":2095,"category":14,"tags":2096},"High-efficiency innovation: 3 lessons to learn from GitLab's culture of rapid execution",[2093],"Jay Newman","2018-03-27","\n\nAll companies have different ways of creating new products and services. Despite that, there are a few patterns that show up consistently. At [Jump](http://www.jumpassociates.com), we like to call those patterns the different \"cultures\" of innovation. One such pattern has to do with execution. Great executors (like GE and FedEx) are masters of sharp focus and efficient machine-making.\n\nMany of the Fortune 500 companies that we work with do their best innovation this way. They've built infrastructure that excels at launching products globally, coordinating thousands of employees and operating at massive scale. These companies often ask us what they can learn from what's going on in Silicon Valley. There's much to learn, of course, from the startups and entrepreneurial ecosystem here.\n\nThe important question is not \"How do they do things in Silicon Valley?\" Instead, it's \"What can I learn that would work well in my organization?\" It's always exciting to come across a startup that's doing what these big companies do best – execute at scale – and doing it in a completely different way.\n\nGitLab is one such company. They're an open source software company powering many of the world's largest corporations. They've developed a surprising – and strong – culture of innovation. They're a remote-only company. There's no physical headquarters or office space for their 200+ employees located worldwide. They proudly admit that they value \"boring solutions.\" Their [entire business strategy is available](/company/strategy/) for the public and their competitors to see. They're respected for their [product](/blog/gitlab-leader-continuous-integration-forrester-wave/), their [culture](/company/culture/), and their [results](http://www.businessinsider.com/gitlab-raises-20-million-from-gv-2017-10).\n\nMany companies pride themselves on their ability to iterate quickly and answer yes/no decisions rapidly. Even they might be surprised at the scope and scale of GitLab's efficiency. GitLab drives high-efficiency innovation through a culture of rapid execution. They weave speed directly into the fabric of who they are and what they do. Do you want to learn how they do it? I recently shadowed GitLab's CEO, [Sid Sijbrandij](/company/team/#sytses), and his team for a day.\n\nHere's how they make it happen.\n\n## When the answer is clear, build for speed. Speed wins.\n\n*Why build a culture of rapid execution?*\n\nWith such a unique team culture and set of business practices, the first thing I wanted to learn from Sid was why GitLab operates the way it does. What became clear was that it's all very intentional.\n\nA few key beliefs are central to the decisions they've made:\n\n### Belief 1: The solution required to win is already super clear to everyone.\n\nThey're operating in a market called DevOps, which is about creating platforms and tools for software developers to use in their work. It's a market where both the unmet customer need and the ideal solution are clear to everyone.\n\nThey were newer to the game than some brand name and legacy competitors, so they chose to prioritize speed over invention to get to the finish line first.\n\n### Belief 2: If you don't do anything new, you can do things faster, bigger and better.\n\nThe folks at GitLab believe that it's better to be boring. They value \"boring solutions.\" It's not because boring is better in and of itself. It's because boring is efficient. It's faster. And faster can become bigger. And when you add in collaboration with a global open source community, bigger can become better.\n\nIf there's a market standard, they don't try to create something different. They get on board. As Sid says, \"It's about convention over conviction. We make sure everyone [in the open source community] is enticed to participate. If the rest of the world is doing it in some way, we should be doing it in that way.\"\n\n### Belief 3: It's OK not to make everyone happy.\n\nIt's hard for most companies – and most people – to change to what made them successful in the first place. For GitLab, making those kinds of changes is critical to achieving the growth they seek. So on a daily basis, they choose to act quickly, make mistakes quickly, and learn from those mistakes quickly.\n\nThat can lead to decisions – big and small – that might not make everyone happy.\n\nWhen they launch a completely new version of GitLab (they're on version [10.6](/releases/2018/03/22/gitlab-10-6-released/) right now), they always add some things that will frustrate some existing customers, and they often take away things that other customers love.\n\n\"There's way more people not using GitLab than that are. So we should always optimize for those future customers, not your current ones. That's why companies slow down. They start listening. Engineers want to fix the current bugs. Sales wants to keep the old deck that works for them. You start listening to your customers and what they need you to maintain or fix. The natural motion of any company is to slow down. So as CEO you need to get the company beyond that.\"\n\nSo what does high-efficiency innovation and rapid execution look like at GitLab?\n\nHere are a few examples of the pace at which they operate:\n\n1. They release a new version of GitLab every single month.\n1. Everything is in draft and subject to change. It's always under construction.\n1. They don't repeat themselves. GitLab documents how it does things in a [handbook](https://handbook.gitlab.com/handbook/). It's 1,000 pages long. If it's in the handbook, don't repeat it.\n1. Every conference call starts on time. No wasted minutes. Sid checks 15-30 action items off the list in each of his 25-minute 1-on-1 meetings.\n1. They trust their team to multi-task appropriately. If you want to check email during a meeting, it's probably more important than the meeting is to you.\n\nThere's a final, often-overlooked value of speed: it's exciting. Workplaces that manage to pair speed with evident progress allow their teams to feel accomplished, motivated, and on the edge of their seats. It's an easy hack for maintaining employee engagement.\n\n## Don't sacrifice long-term vision for short-term speed. Be accountable for both.\n\n*What is GitLab is rapidly executing on?*\n\nMany companies who prize execution do a great job at sustaining and growing their existing products. They're often quite efficient – though they could learn something from the speed at which GitLab operates. But they're more likely to struggle with thinking far out into the future.\n\nTo paraphrase Stephen Covey, there's a big difference between efficiency and effectiveness. A jet flying 1,000 miles per hour is efficient; a jet flying 1,000 miles per hour in the right direction is effective.\n\n#### So if GitLab as an organization is a jet built for speed – where is it going?\n\nSid wants GitLab to help multiply the potential for progress that humanity can drive into the world. \"Our mission is 'Everyone can contribute.' That's a long-term vision. That's 10 years. It means changing all of our culture to read-write. Think Wikipedia. They allow everyone to contribute. Imagine if we can do that. You release a lot of progress. You 10x the progress. [Multipliers like that are] thrown around so easily in Silicon Valley that you have to be cautious. But if you look at 100,000 companies using GitLab, and really being able to get their out software faster. I'm willing to stand behind that.\"\n\nThat means that not only is GitLab thinking about efficiency and effectiveness, but it's also thinking about impact. Impact on the scale of human progress and global culture.\n\nThat's pretty big and pretty far out. So how do they make sure the pilots keep looking way out there on the horizon while flying at supersonic speeds and maneuvring around today's obstacles?\n\nFirst, you set the mission and vision. Everything starts with that mission in mind. Everyone knows it, and Sid talks about it [every chance he gets](https://blog.ycombinator.com/gitlab-distributed-startup/).\n\nNext, you draw that vision back into today's actions with cascading plans. Create a three-to-five-year strategy about how to get there. Craft a yearly plan and [product vision](/blog/gitlabs-2018-product-vision/) – one that's concrete enough that you could show screenshots of what it will look like a year from now. Define quarterly goals (GitLab's [OKRs](/company/okrs/) are public), monthly targets, and smaller sprints to get you there.\n\nThird, you make each of these regular goals highly ambitious, close-in, unambiguous, and concrete. \"Setting high goals pushes people beyond their comfort zone,\" Sid told me. At Y Combinator, he says they taught GitLab that \"20 percent is the new 10 percent.\" That's 20 percent growth, every single week. It's a high number, and it forces them to make completely different types of decisions.\n\nFinally, because the short-term goals are incredibly high, you focus on iteration. [Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is one of GitLab's core values. They define it clearly: \"We do the smallest possible thing and get it out as quickly as possible.\" And they don't just ask developers and designers to work this way. \"We put the whole company on that diet. It made sense for the product. But for marketing, sales, etc., we've gotten them there. If you say 'Grow XYZ in the next two weeks,' you do completely different things. I don't know why that is, but you do.\"\n\n### Encode culture and values to keep the company moving faster.\n\n*How does GitLab do what they do?*\n\nIt was GitLab's strong culture and values orientation that first drew me to them as an organization. I'm often on the lookout for how leaders drive values through their organizations – from Jon Stewart on \"The Daily Show\" to the frontline teams at Starbucks and Zappos.\n\nThe best values-oriented organizations draw explicit links between their values, their competitive advantages, and their daily activities.\n\nHere's where GitLab stands out.\n\nIn just one day of shadowing GitLab's staff, the team talked about values during a product meeting, two interviews with prospective employees, an analyst call and a 1-on-1 with a teammate. The whole team is drawing causal links between what it does (its business activities) and how it does them (the values they live by).\n\n>The whole team is drawing causal links between what it does (its business activities) and how it does them (the values they live by).\n\nSo how does that work? It requires leaders choosing to identify not just the values that matter, but also how to organize around them. Sid told us \"I didn't do a very good job coding GitLab [when he and his co-founders all started back in 2011]. But I think I'm doing a good job coding GitLab the company.\"\n\nAs a remote-only company, \"coding the company\" means (1) writing things down, (2) referencing back to what's been written and (3) reinforcing it through rewards.\n\nAll of this \"GitLab the company\" code is captured in its handbook. The handbook is referenced in almost every conversation. The handbook consists of over 1,000 pages of text. It's a tool that GitLab uses to capture and detail out decisions that have already been made about all of its core business practices – marketing, sales, product, team operations, finance, and more. It's a constant practice for Sid and the team to reference the handbook in meetings, and to send people to look there first before continuing the conversation.\n\nThe values take a prime place in the handbook. There, values are defined, not just described. Words can mean different things in different contexts – and these values indicate a particular thing at GitLab. The definitions are brought to life with 5-15 concrete actions that employees often take for each of the six values. As Sid says, \"The culture got stronger because it is written down. And because it improves and is edited over time.\" And then they're reinforced every day through hiring, coaching, performance reviews and casual conversations.\n\nIt's rare that companies think about linking their values with their competitive advantage. It's rarer still that a company brings its values to life through the day-to-day work. What GitLab has unlocked with its values orientation is not just good and meaningful work. It has also opened the most important competitive advantage in its business model – speed.\n\n>It's rare that companies think about linking their values with their competitive advantage. It's rarer still that a company brings its values to life through the day-to-day work.\n\nIt says it right there in the 'Why have values' section of the handbook: \"Values are a framework for distributed decision-making; they allow you to determine what to do without asking your manager.\" By encoding values deep into everyday activities of the company, everyone on GitLab's team can make decisions faster.\n\nIn DevOps, winning is about getting there first. GitLab coded values right into its organizational design to make sure it could always be the fastest to market.\n\n## Parting thoughts: Will high-efficiency innovation work for you?\n\nAlthough they weren't thinking about large corporations, the oracles of Delphi were right. The most important maxim is to \"know thyself.\" The GitLab prescription isn't right for every company. What's most important is to build a culture of innovation that reflects your strengths and your values.\n\nGitLab is a company of executors, of coders and of people who aren't afraid to work out in the open and make mistakes. They see clear problems. Then they attack. GitLab built a method of innovation that works well for them, but it's not a one-size-fits-all approach. It won't work for everyone, but it might work for you.\n\n#### Here are the questions you should ask:\n\n1. Is the problem you're facing clear to you and your competitors?\n1. Would the people on your team prioritize efficiency over novelty if it'll get you there first?\n1. Do you know how to make trade-offs between what works for your existing customers and what might work better for future customers?\n\nIf you answered yes, pay close attention to what GitLab is doing. Their unrelentingly quick iterative process might be just what the doctor ordered to scale your innovation.\n\nIf not, the GitLab system isn't the right fit for you. You'll want to organize your innovation in a different way.\n\nAs one example, we built Jump to handle an entirely different type of [highly ambiguous problems](https://www.forbes.com/sites/brucerogers/2018/01/25/innovation-leaders-dev-patnaik-co-founder-and-ceo-jump-associates/3/#42518f211238). So it makes sense that some of Jump's values (Passion, Curiosity, Enthusiasm, Intention, Acuity, Initiative and Play) look very much the opposite of GitLab's values (Collaboration, Results, Efficiency, Diversity, Iteration and Transparency).\n\nJump and GitLab are both deeply values-oriented companies with rich and collaborative cultures focused on innovation. And yet we value different things, have different org structures, hire different types of people and work on very different types of problems.\n\nSo what if you're like me and your company's approach or market situation is quite different than GitLab's? Take this as an opportunity to learn from seeing your mirror image.\n\nFirst, test parts of their approach. See what works for you and your team. Then, consider the polar opposites. Find the points where you value distinctly different things, and ask why. Learn why their method works for them, and why it wouldn't work for you. Then flip the script – what's an approach to innovation that GitLab would never do that would be a difference maker for you if you did it?\n\nEither way, take note of what GitLab is doing and how they're doing it. It's amazing, effective, growing like crazy and a great place to work. And ask yourself – should my team be innovating like that?\n\n## About the guest author\n\nJay Newman is Director of Strategy at Jump Associates, a leading strategy and innovation firm. Learn more at [jumpassociates.com](http://www.jumpassociates.com) and connect directly with Jay on [LinkedIn](https://www.linkedin.com/in/jaynewman1).\n\nPhoto by [Karsten Würth](https://unsplash.com/photos/ZKWgoRUYuMk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[697,804,805],{"slug":2098,"featured":6,"template":700},"high-efficiency-innovation","content:en-us:blog:high-efficiency-innovation.yml","High Efficiency Innovation","en-us/blog/high-efficiency-innovation.yml","en-us/blog/high-efficiency-innovation",{"_path":2104,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2105,"content":2111,"config":2117,"_id":2119,"_type":17,"title":2120,"_source":18,"_file":2121,"_stem":2122,"_extension":21},"/en-us/blog/remote-work-done-right",{"title":2106,"description":2107,"ogTitle":2106,"ogDescription":2107,"noIndex":6,"ogImage":2108,"ogUrl":2109,"ogSiteName":686,"ogType":687,"canonicalUrls":2109,"schema":2110},"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":2106,"description":2107,"authors":2112,"heroImage":2108,"date":2114,"body":2115,"category":14,"tags":2116},[2113],"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",[763,697,805,804,1737],{"slug":2118,"featured":6,"template":700},"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":2124,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2125,"content":2131,"config":2137,"_id":2139,"_type":17,"title":2140,"_source":18,"_file":2141,"_stem":2142,"_extension":21},"/en-us/blog/working-at-gitlab-affects-my-life",{"title":2126,"description":2127,"ogTitle":2126,"ogDescription":2127,"noIndex":6,"ogImage":2128,"ogUrl":2129,"ogSiteName":686,"ogType":687,"canonicalUrls":2129,"schema":2130},"How working at GitLab has changed my view on work and life","A glimpse of the things I've learned at GitLab since I joined.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678678/Blog/Hero%20Images/gitlab-effects.jpg","https://about.gitlab.com/blog/working-at-gitlab-affects-my-life","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How working at GitLab has changed my view on work and life\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hazel Yang\"}],\n        \"datePublished\": \"2018-03-15\",\n      }",{"title":2126,"description":2127,"authors":2132,"heroImage":2128,"date":2134,"body":2135,"category":14,"tags":2136},[2133],"Hazel Yang","2018-03-15","\nI will have been at GitLab for two years in June of this year. Working at GitLab is a fresh experience for me. Joining a company outside of Asia and working 100 percent remotely was not something that I had previously done. It not only affects my work but my entire life. I am so grateful to have the opportunity to work with talented and friendly people around the world. I think it would be good to share my reflections about what I’ve learned during this 19-month journey.\n\n\u003C!-- more -->\n\nWe have an open source [handbook](https://handbook.gitlab.com/handbook/) that everyone can access, and it includes our six [values](https://handbook.gitlab.com/handbook/values/), (CREDIT) which support our everyday work. Keeping these values in mind benefits me a lot both in my work and in my life, and I would love to share them with you here:\n\n### Expressing oneself completely, clearly and without reservation\n\nCollaboration is essential in our everyday work. At GitLab, we prefer asynchronous communication instead of synchronous communication since we are spread around the world, from America, Europe, Africa, to Asia. We rely on text-based communication heavily. However, words are cold without the body language support, and they could easily lead to misunderstanding and conflict. So how we express our thoughts clearly and kindly in text becomes crucial.\n\nAfter joining GitLab, I always think twice before sending out messages or comments, even in my personal life. I started to choose my words more carefully both in English and Chinese. I also have tried to explain as much as possible. I found that if I did these two things, I can avoid the misunderstanding and increase the efficiency of communication. The most important thing is that people feel comfortable while discussing with you in the text. So don't be afraid to completely express your thoughts, in a careful and sensitive manner.\n\n### Don't be shy to show your gratitude\n\nWe have [\"Say thanks\"](https://handbook.gitlab.com/handbook/communication/#say-thanks) in our [values](https://handbook.gitlab.com/handbook/values/), and we often say \"Thank you\" to each other, especially in our \"Thanks\" channel on Slack.\n\n{: .text-center}\n![graphic-gratitude](https://about.gitlab.com/images/blogimages/working-at-gitlab/gratitude.png){:height=\"480px\" width=\"680px\"}\n\nDue to my personality and culture, at first I was shy to express my appreciation to my friends, family, and colleagues. At GitLab, we have a unique culture that encourages people to say “thanks,” so I try not to be too shy to show my gratitude. As I practiced this more and more, it became a habit and a natural thing to me. Now I say “thanks” very often, even for little things, and it feels positive and makes me happy every day.\n\nExpressing gratitude not only makes me feel satisfied, it also makes the person that I expressed my appreciation for have a beautiful mood.\n\n### Learning from failure\n\n\"Iteration\" is critical to our product improvement and development. We see what each of us produce initially as a draft. This helps us reduce the cycle time and have a prototyping mindset towards the features we are working on. We are not afraid of failure since we are always flexible in adjusting our products based on the feedback from both our external and internal communities.\n\n{: .text-center}\n![graphic-iterations](https://about.gitlab.com/images/blogimages/working-at-gitlab/iterations.png){:height=\"480px\" width=\"680px\"}\n\nI have applied this mindset to my personal life as well. In my culture, we value the smart person who never makes mistakes. So we try as hard as possible to avoid errors and losing face. However, the prototyping mindset changed my thoughts and reactions towards the things that previously may have made me feel embarrassed or uncomfortable. I became more open-minded in accepting positive and negative feedback from others. I no longer get upset or offended if someone corrects something that I did. I realized that my life is also a kind of product and it will be better and better in every iteration.\n\n### Trust your team and grow with them\n\nWhen you trust your team members, you will be brave enough to leave your comfort zone because you believe they will give you the support whenever you need it.\n\nA good example of trust concerns my English. English is my second language and therefore it is a weakness of mine. When you lack confidence in something, you often refuse to do the things outside of your comfort zone as you fear it would make you look stupid. This was exactly my situation when I joined GitLab. However, when I realized that the people around me weren’t as concerned about my shortcomings in English as much as they valued me for my contributions to the company. It gives me the courage to face my linguistic challenges.\n\nI am still not 100 percent as confident in English as I am in Mandarin, yet my confidence has increased from 30 percent to almost 70 percent if one puts a number to it. As you can see, I am writing this blog post in English to share my experience at GitLab now. This is only my second blog post.\n\nGitLab provides a very positive environment where I can improve and grow professionally as well as personally. I appreciate that my colleagues are always supportive and patient. I feel safe and comfortable while doing challenging things, not just concerning my English but in all of the tasks that I face at GitLab.\n\n### Befriend your manager and colleagues\n\nI felt that it was harder to befriend managers and colleagues at a company in Asia. I am not the sure what the reason is, but I think perhaps it is because of Confucianism which impacts our culture a lot.\n\nAt GitLab, I speak freely about numerous things to my manager, [Sarrah Vesselov](/company/team/#SVesselov), since I know she cares about our team and wants our team to grow. I also feel that GitLab is like a big family even though we are a large and distributed team. We try as hard as we can to get people together in both virtual and practical ways.\n\n{: .text-center}\n![image-summit](https://about.gitlab.com/images/blogimages/working-at-gitlab/summit.png){:height=\"480px\" width=\"680px\"}\n\nFor example, we have the [team call](https://handbook.gitlab.com/handbook/communication/#team-call), and people can share a bit about their lives. We also encourage our team members to join the [\"virtual coffee breaks\"](https://work.qz.com/1147877/remote-work-why-we-put-virtual-coffee-breaks-in-our-company-handbook/) to get to know each other. Moreover, we host a [summit](/events/gitlab-contribute/) to get together in person every nine months. This year we will meet in [Cape Town, South Africa](https://gitlab.com/summits/2018-Summit).\n\n### Embrace diversity\n\nGitLab promotes [diversity](/company/culture/inclusion/) and hires globally. We believe \"Culture add\" much more than \"Culture fit.\" We include different race, color, religion, gender, national origin, age, disability, or genetics. We also support inclusive benefits, for instance, [Transgender Medical Services](/handbook/total-rewards/benefits/general-and-entity-benefits/inc-benefits-us/) and [Pregnancy and Maternity Care](/handbook/total-rewards/benefits/general-and-entity-benefits/#parental-leave). We have a LGBTQ+ channel on Slack as well. Embracing differences powers our creativity.\n\n{: .text-center}\n![graphic-diversity](https://about.gitlab.com/images/blogimages/working-at-gitlab/diversity.png){:height=\"480px\" width=\"680px\"}\n\nWorking with people from diverse backgrounds is fantastic. I have learned from others’ communicative styles and different ways of thinking. I have broadened my views and now see the world from different perspectives. I am much more open-minded. The most important thing is that I completely understand that we are equal regardless of who we are.\n\n## Conclusion\n\nWorking at GitLab is a unique experience for me. I feel excited to start my work every day and enjoy the job I am doing.\n\nFor those that may be interested in working at Gitlab, we are currently hiring people from everywhere. If you want to join the journey, you can check out our [jobs](/jobs/) page and feel free to apply for the position if you feel that you are qualified. We are looking forward to hearing from you!\n",[697,804,742],{"slug":2138,"featured":6,"template":700},"working-at-gitlab-affects-my-life","content:en-us:blog:working-at-gitlab-affects-my-life.yml","Working At Gitlab Affects My Life","en-us/blog/working-at-gitlab-affects-my-life.yml","en-us/blog/working-at-gitlab-affects-my-life",{"_path":2144,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2145,"content":2151,"config":2156,"_id":2158,"_type":17,"title":2159,"_source":18,"_file":2160,"_stem":2161,"_extension":21},"/en-us/blog/preventing-burnout",{"title":2146,"description":2147,"ogTitle":2146,"ogDescription":2147,"noIndex":6,"ogImage":2148,"ogUrl":2149,"ogSiteName":686,"ogType":687,"canonicalUrls":2149,"schema":2150},"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":2146,"description":2147,"authors":2152,"heroImage":2148,"date":2153,"body":2154,"category":14,"tags":2155},[1993],"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",[763,742,697],{"slug":2157,"featured":6,"template":700},"preventing-burnout","content:en-us:blog:preventing-burnout.yml","Preventing Burnout","en-us/blog/preventing-burnout.yml","en-us/blog/preventing-burnout",{"_path":2163,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2164,"content":2170,"config":2177,"_id":2179,"_type":17,"title":2180,"_source":18,"_file":2181,"_stem":2182,"_extension":21},"/en-us/blog/pick-your-brain-interview-vincent-jong",{"title":2165,"description":2166,"ogTitle":2165,"ogDescription":2166,"noIndex":6,"ogImage":2167,"ogUrl":2168,"ogSiteName":686,"ogType":687,"canonicalUrls":2168,"schema":2169},"Key decisions for building successful startups","Vincent Jong of SaaS.CEO sits down for a 'pick your brain' meeting with GitLab CEO Sid Sijbrandij.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680253/Blog/Hero%20Images/pick-your-brain-interview-thrive.jpg","https://about.gitlab.com/blog/pick-your-brain-interview-vincent-jong","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Saas.CEO and Sid Sijbrandij talk key decisions, influential connections, and strategic vision when building a startup\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vincent Jong\"}],\n        \"datePublished\": \"2018-01-26\",\n      }",{"title":2171,"description":2166,"authors":2172,"heroImage":2167,"date":2174,"body":2175,"category":14,"tags":2176},"Saas.CEO and Sid Sijbrandij talk key decisions, influential connections, and strategic vision when building a startup",[2173],"Vincent Jong","2018-01-26","\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\n\u003C!-- more -->\n\n**GitLab has become a leading provider in software development solutions, but it didn’t start out like that. Looking back, what were the one or two decisions that really made the company to the success it is today?**\n\nThe first one is the decision to build a company around it, because GitLab started as an open source project without a company. As such a project gets bigger, you will have to pay people to keep the quality high.\n\nAnother thing was my co-founder Dmitriy tweeting \"I want to work on GitLab full time,\" which led me to contact him and hire him, which was a great change.\n\nThis may be atypical advice on a SaaS CEO interview series, but one thing we did right was not to focus on SaaS. The demand for GitLab was coming from the self-managed side much more than from the SaaS side, so we decided to focus on that first.\n\nThe final one was the decision to apply to Y Combinator. This changed our ambition level from just running the project to being a market leader.\n\n**Would you say that your focus on the self-managed product also allowed you to focus on a different market segment than where players like GitHub were already capturing market share?**\n\nWhen we started, GitHub and Atlassian were already there in that market and it should have been locked up. But they left an opening in the self-managed market and at the bottom of the market.\n\nIn the beginning our software wasn’t very good, but we were able to rapidly make it better and grow upmarket. This is a great thing because I think today most of the revenue is coming from those large accounts.\n\nThe way I see it, source code management is one of the last things to leave self hosted for SaaS. Where this happened much earlier for CRM for example, I think source code for various reasons is transitioning later. We still see that for companies with more than 5,000 employees, 95 percent is still self hosted.\n\n**Alright. Looking at a more general perspective, what would you say you understand about building a (SaaS) company that is often overlooked or underestimated by other founders?**\n\nWhat we do differently is that we write things down. We’re a remote-only company of 200 people working from 200 locations. We try to work as asynchronously as we can and we write down what we do. The output of that is a [company handbook](https://handbook.gitlab.com/handbook/) with over 500 pages of our processes.\n\nFor a fast growing company, it is important that new people know the customs and values of the organization. Spending a lot of time to verbally communicate this is time consuming and dilutive, because you are never going to be able to tell person 100 as well as you’ve told the first. However, when you write it down, which is very painful in itself, person 100 will have an even more detailed version than person 1. So it gets better over time.\n\n**Then let’s talk about the people you’ve worked with. For startups, connecting with the right people can be a game-changer. One person can provide a connection that changes everything. If you look at people who are not employed at GitLab – which person provided essential additional value and how did you get in touch with this person?**\n\nJoining Y Combinator has been essential for us. It opened up lots of doors that would otherwise have been closed. For example, the seed round of investors we have with people like Ashton Kutcher and Michael Arrington. I don’t think they would have even looked at us if it wasn’t for Y Combinator.\n\nThen your board members are just very important. We got lucky with our first board member, Bruce Armstrong, operating partner at Khosla Ventures, who was very thoughtful with us and very hardworking in helping us every step along the way. That felt very empowering and it’s not always the case with venture capitalists, so that was awesome.\n\nSometimes it’s just reaching out. Like Matt Mullenweg who joined our board. He is the CEO of Automattic, the makers of WordPress. I just sent him an email saying “Hey, can we talk?” If you show you’ve done your homework, like mentioning why you want to talk and reference a blog post or something they tweeted, people are more likely to respond.\n\n**One of the things we do at [SaaS.CEO](https://www.saas.ceo/) is ask our audience beforehand if they have any questions for the CEO who is being interviewed. This time two questions came up. The first is coming from Michael Kamleiter, CEO of Swat.io and Walls.io. He asks \"How do you go about positioning towards other players like GitHub, especially when you were still a smaller company?\"**\n\nI don’t think we’ve figured it out yet. Where our competition was sometimes more focused on the needs of open source projects, we focused on those large customers and their requirements. For example, our competition has two levels of authorization and we have five, because our customers need more granularity.\n\nPositioning to me is mostly marketing and I think we have lagged in that regard. Actually, the last two days I have been in a workshop to figure out our positioning. What we’re going to do is articulate that GitLab is an end-to-end tool. Where all the other applications are about assembling a toolchain and orchestrating that toolchain, we want to be \"toolless.\"\n\nIf you have a toolchain, you end up having all these handoffs that create delays from working in serial. We want people with GitLab to be able to work in parallel. I think that will be a big enabler of our future growth. But it’s a really hard thing to determine, to get everybody aligned on, and then to roll it out on all your channels, from product to sales to marketing.\n\n**The second question we received is from Florian Dorfbauer, CEO of Usersnap. His question is: \"With the latest investment round, you've also revealed the bigger vision of GitLab: providing a complete DevOps experience. How much time do you spend on strategic vision building and what does the process look like to work on such strategies?\"**\n\nI consider myself a Product CEO and spend most of my time on our product. The way I spend time on this is first of all by talking with customers. My call before this was with a potential customer, to answer their questions. It’s great to be able to talk directly with customers.\n\nI also keep an eye on our issue tracker and [Hacker News](https://news.ycombinator.com/), which are important channels for me. Apart from that I work a lot with our product managers where we try to get the best out of each other.\n\nIt’s all driven by what you know about where the market is – what are the trends, what are the analysts saying, what are customers saying, what are users saying. All these things come together and you reflect on it with each other and choose a direction.\n\n**By sharing your experiences, you have given valuable input other to SaaS CEOs out there. Therefore, I want to give you the opportunity to ask something in return. Is there something our listeners can do for you?**\n\nI think it would be great that those who read this reach out to you to be interviewed so you will have more content and we can make this a bigger thing. Then when this becomes a famous podcast I can claim to be the first one ever to be interviewed.\n\nSecondly, I would like to take the opportunity to say that GitLab.com is becoming a great product now, so I hope that in 2018 people will give it a shot and try it out.\n\n**Sid, thank so much for sharing your insights. I’m very happy to have had you as our first interviewed CEO and we do hope many of the readers and listeners will follow your request.**\n\n### About the guest author\n\nVincent is a Dutch serial entrepreneur excited about advanced technology and Software as a Service solutions. While building his company, he noticed how many founders are trying to get in touch with the same people: CEOs who have already walked the path they are going. Facing the same challenge, he founded [SaaS.CEO](https://www.saas.ceo/), a platform to make successful SaaS founders more accessible. His own company [Thrive for Email](http://www.thrive.email/) is an AI-driven sales automation solution that helps sales reps increase their capacity by automatically entering all data into the CRM.\n\n[Cover image](https://unsplash.com/photos/kRnkqSKZODQ) by [Federico Beccari](https://unsplash.com/@federize) on Unsplash\n{: .note}\n",[1563,1738],{"slug":2178,"featured":6,"template":700},"pick-your-brain-interview-vincent-jong","content:en-us:blog:pick-your-brain-interview-vincent-jong.yml","Pick Your Brain Interview Vincent Jong","en-us/blog/pick-your-brain-interview-vincent-jong.yml","en-us/blog/pick-your-brain-interview-vincent-jong",{"_path":2184,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2185,"content":2191,"config":2197,"_id":2199,"_type":17,"title":2200,"_source":18,"_file":2201,"_stem":2202,"_extension":21},"/en-us/blog/zapier-pick-your-brain-interview",{"title":2186,"description":2187,"ogTitle":2186,"ogDescription":2187,"noIndex":6,"ogImage":2188,"ogUrl":2189,"ogSiteName":686,"ogType":687,"canonicalUrls":2189,"schema":2190},"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":2186,"description":2187,"authors":2192,"heroImage":2188,"date":2194,"body":2195,"category":14,"tags":2196},[2193],"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](https://handbook.gitlab.com/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",[1563,763,804],{"slug":2198,"featured":6,"template":700},"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":2204,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2205,"content":2211,"config":2217,"_id":2219,"_type":17,"title":2220,"_source":18,"_file":2221,"_stem":2222,"_extension":21},"/en-us/blog/tasktop-webcast-recap",{"title":2206,"description":2207,"ogTitle":2206,"ogDescription":2207,"noIndex":6,"ogImage":2208,"ogUrl":2209,"ogSiteName":686,"ogType":687,"canonicalUrls":2209,"schema":2210},"Cross-functional ≠ dysfunctional","Don't let process hold you back – here are our best practices for working cross-functionally.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671305/Blog/Hero%20Images/tasktop-integration-cover.png","https://about.gitlab.com/blog/tasktop-webcast-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Cross-functional ≠ dysfunctional\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-11-08\",\n      }",{"title":2206,"description":2207,"authors":2212,"heroImage":2208,"date":2213,"body":2214,"category":14,"tags":2215},[998],"2017-11-08","\n\nWe recently teamed up with [Tasktop](https://www.tasktop.com/integrations/gitlab-issues) to talk about processes and how to make sure\nthey work for you instead of against you. Check out the highlights below.\n\n\u003C!-- more -->\n\nCreating great software involves a number of different disciplines, each of\nwhich may use their own tool for managing work. Chaos might seem inevitable, but\nwe've learned that a few guiding principles can help to connect people and keep\nchannels of communication open.\n\n## 1. Goals first, process second\n\nProcess exists to serve goals. Before you put processes in place or continue with existing ones, take a step back to establish what you're trying to achieve. Getting input from all stakeholders to determine goals will help to set clear expectations up front and allow everyone to voice their concerns about the scope of the project. Armed with this information, you can then decide on the best process (including timelines, review cycles and communication vehicles) to achieve the desired outcome.\n\n## 2. Establish a single source of truth\n\nWith so many stages and so much activity involved in creating a product or feature, it can be hard to keep track of what's going on. This potential for chaos is quelled by establishing a single source of truth. So when you've outlined your goals and settled on a process for achieving them, write it all down so that everyone has something to refer to and there's no confusion about what was decided or what stage something is at. This is especially helpful for distributed teams, as it means people in other locations and time zones can get up to speed quickly and collaborators can work asynchronously.  \n\n## 3. Clear, visible outcomes\n\nWhat exactly does success mean for your project? What metrics will you use? You want clear, measurable outcomes for what you're working on, so that everyone can see what's expected of them and others. At GitLab, we use [issue trackers](https://docs.gitlab.com/ee/user/project/issues/) to follow the progress of a new feature or project. Individual issues can be customized to reflect the problem you're trying to solve, how you're going to go about it, and what the outcome should be. Issues can be connected to related [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/) so that all involved stakeholders can view new developments or changes right away, in a production-like environment. This way concerns or problems can be flagged at any stage along the way.\n\n## 4. Work cross-functionally from start to finish\n\nThe above guidelines only work if all your different functions are in communication. Instead of locking communication per-stage, per team, or per-specialty principle, leave the doors as open as possible. This minimizes risk, as GitLab Product Manager [Victor Wu](/company/team/#victorwu416) explains:\n\n> When you're creating software, and you're creating a feature, you probably want a security stakeholder involved. Security is often something that's tacked on at the end, but if it's baked directly into the design of the software it will be accounted for, and you can estimate the cost or effort required to design and implement something that accounts for security instead of backtracking later.\n\nCross-functional working also encourages a diversity of ideas from different teams contributing to a feature, which can result in a better outcome. You can foster open communication by working more transparently: make your goals, processes and metrics for success visible to your whole organization, if possible, and invite feedback. Use real-time editing tools (such as Google docs) for meetings and allow everyone to add to the agenda, take notes or suggest follow-up items.\n\n## 5. Improve the process in iterations\n\nFeeling inspired? Before you throw out all your existing processes, think about whether you can [iterate](https://handbook.gitlab.com/handbook/values/#iteration) on them instead. Radical change can be difficult for people to embrace, so you may have more success with gradual adjustments. Identify something that's not working well, and a small change you can make to improve on it.\n\n> Try to win those small battles, solve those small problems, week by week and month to month, and over time your process will improve.\n\n## Recording\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/8X6x54gaYRo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Slides\n\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://docs.google.com/presentation/d/e/2PACX-1vRcQw1XTuEk12ALqnrjMSTPLQ9OAm6Mmzn-eIoUOCJgUdX8dVDejdmN_HaK2AW1lVq1iDG7VxmzaXcD/embed?start=false&loop=false&delayms=3000\" frameborder=\"0\" width=\"960\" height=\"569\" allowfullscreen=\"true\" mozallowfullscreen=\"true\" webkitallowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\nYou can read more about [Tasktop's GitLab integration here](/blog/tasktop-gitlab-integration/).\n",[2216,234,804,805],"webcast",{"slug":2218,"featured":6,"template":700},"tasktop-webcast-recap","content:en-us:blog:tasktop-webcast-recap.yml","Tasktop Webcast Recap","en-us/blog/tasktop-webcast-recap.yml","en-us/blog/tasktop-webcast-recap",{"_path":2224,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2225,"content":2231,"config":2238,"_id":2240,"_type":17,"title":2241,"_source":18,"_file":2242,"_stem":2243,"_extension":21},"/en-us/blog/triage-issues-gitmate",{"title":2226,"description":2227,"ogTitle":2226,"ogDescription":2227,"noIndex":6,"ogImage":2228,"ogUrl":2229,"ogSiteName":686,"ogType":687,"canonicalUrls":2229,"schema":2230},"Triage issues in 7 simple steps","Guest authors Lasse Shuirmann and Sebastian Latacz walk us through how to work through your issue backlog and triage effectively.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670529/Blog/Hero%20Images/automate-retrospectives.jpg","https://about.gitlab.com/blog/triage-issues-gitmate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Triage issues in 7 simple steps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sebastian Latacz\"},{\"@type\":\"Person\",\"name\":\"Lasse Schuirmann\"}],\n        \"datePublished\": \"2017-10-26\",\n      }",{"title":2226,"description":2227,"authors":2232,"heroImage":2228,"date":2235,"body":2236,"category":14,"tags":2237},[2233,2234],"Sebastian Latacz","Lasse Schuirmann","2017-10-26","\n\nActively triaging issues is crucial for keeping an overview on your repository, yet it’s tedious and takes up valuable developer hours. That’s why we summarized seven simple steps to help you triage efficiently.\n\n\u003C!-- more -->\n\n## Preparation\n\nThere are three types of issues: questions, bug reports, and feature requests. Define which you want to tackle in your tracker and which you handle elsewhere (you can use different [GitLab Issue Boards](/stages-devops-lifecycle/issueboard/) to help keep different types of issues together). Once this has been done, check each issue with the following scheme:\n\n## 1. Filter noise\n\nCheck whether the issue is the type you want in your tracker (as defined in the preparation phase). If not, point the user to the right place or move it to the relevant [issue board](/stages-devops-lifecycle/issueboard/) yourself. For example, indicate that questions will be answered on Stack Overflow or feature requests are best being posted for discussion in the Slack channel. Be friendly; remember the user just provided valuable feedback. Close the issue once you’ve pointed the user to the right place.\n\n## 2. Look for similars\n\nOftentimes work related to existing issues already exists. Searching your issue tracker for related keywords can bring up a lot of similar issues that can be helpful. Reference the existing issues in the new one.\n\n## 3. Look for duplicates\n\nWhile you are researching similar topics you might find or remember duplicate issues as well – in that case simply close those (or the new issue) and streamline your efforts in one place.\n\n## 4. Retrieve missing information\n\nIssues are often reported incomplete; critical information like a version number is not given and it turns out that a bug occurred in an unsupported version – ask people for missing information and close issues if that is not provided.\n\n## 5. Label\n\nLabel issues so you can find those which are relevant for a particular topic with a filter. Also set labels for states of an issue. For example, putting a `needs-info` label on an issue prevents other people from wasting their time on it.\n\n## 6. Ping related devs\n\nEspecially for bigger changes or if it's not obvious how to tackle an issue, you will want to cc developers who are knowledgeable in the area. This can prevent you from running against three walls after each other and make sure all related efforts are coordinated properly.\n\n## 7. Handle stale issues\n\nEvery issue has to die. If you're thinking about closing an issue you should probably close it. Also close issues where you have been waiting for an answer for more than 30 days. Be friendly while doing so. The user can always reopen it if needed. This will prevent your tracker from cluttering.\n\nUpdate 2020-06-29: This post originally included information about automating issue triage using GitMate.io. Please note that GitMate.io was deprecated in January 2019 and references to the project have therefore been removed.\n{: .alert .alert-info}\n\nPhoto by [Daniele Levis Pelusi](https://unsplash.com/photos/Pp9qkEV_xPk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/automation?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[805,234],{"slug":2239,"featured":6,"template":700},"triage-issues-gitmate","content:en-us:blog:triage-issues-gitmate.yml","Triage Issues Gitmate","en-us/blog/triage-issues-gitmate.yml","en-us/blog/triage-issues-gitmate",{"_path":2245,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2246,"content":2252,"config":2258,"_id":2260,"_type":17,"title":2261,"_source":18,"_file":2262,"_stem":2263,"_extension":21},"/en-us/blog/how-to-spot-development-issues",{"title":2247,"description":2248,"ogTitle":2247,"ogDescription":2248,"noIndex":6,"ogImage":2249,"ogUrl":2250,"ogSiteName":686,"ogType":687,"canonicalUrls":2250,"schema":2251},"How to spot development issues and fix them fast","Guest author Patrick Foster shares how to get things back on track when a development project starts to go awry.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680343/Blog/Hero%20Images/spot-dev-issues.jpg","https://about.gitlab.com/blog/how-to-spot-development-issues","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to spot development issues and fix them fast\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Foster\"}],\n        \"datePublished\": \"2017-10-16\",\n      }",{"title":2247,"description":2248,"authors":2253,"heroImage":2249,"date":2255,"body":2256,"category":14,"tags":2257},[2254],"Patrick Foster","2017-10-16","\n\nDevelopment issues can be expensive to fix — and the later you uncover them,\nthe worse it is. If you’re running (or dependent on) a development project it’s\nreally important that you stay on the ball at all times. Communication,\ntransparency, and accountability are all essential. Here are some development\nproject red flags that you need to be aware of – as well as how you\ncan address things if it looks like they are starting to go wrong...\n\n\u003C!-- more -->\n\n## Track developer stress and coping strategies\n\n**Start with getting to know the team behind the work – learn how to track their\nstress levels accurately.**\n\nIf you are working with developers or managing a team of them, you will start to\nget a feel for their stress levels via your day-to-day interactions. If you know\nthem reasonably well, you will probably be able to recognize stress in the\nthings that they say, or in way that they act. ([Everyone handles stress differently](http://serendip.brynmawr.edu/biology/b103/f03/web1/skim.html),\ndepending on their personality and past experience).\n\nThe easiest way to diagnose developer stress? Over-complication of simple tasks.\nIf you find it’s taking you about 16 emails to discuss some simple edits to a\nsite menu, it’s probably a sign that something is wrong, and that undue pressure\nis being applied somewhere along the line. Once we enter stressful realms,\ncommunication tends to get very fraught and people will start to feel on edge\nall the time.\n\nIt’s important to address any workflow or workload issues that might be causing\nstress, but don’t forget that one of the biggest stressors is probably other\npeople. It could be that development personalities and job responsibilities are\nclashing in unproductive ways. Development teams need the right mix of people\nand skillsets in order to function harmoniously (just like any other team).\n[Does your team have all of these crucial attributes?](/blog/attributes-of-successful-development-teams/)\nIt could be that the team is out of balance somewhere, so spend some time with\npeople in order to improve team dynamics and implement coping strategies.\n\n## Stop little things from snowballing\n\nIf little tasks and small instructions are constantly getting ‘lost in briefing’\nit could signal that there is a missing chain in the communication workflow.\nSmall oversights can quickly build and create mountains of frustrations for the\nteam. Missing even the most minute detail can completely derail an otherwise\nsuccessful development project, so react immediately if you spot any oversights,\nno matter how small.\n\nFeatures like Issues and [Issue Boards](/stages-devops-lifecycle/issueboard/) can help everyone break down\ncomplex tasks into smaller individual ones and track their progress across the\ndevelopment lifecycle. Singular tasks are often be the best way for developers\nto tackle a subject – this is especially true for junior developers and\ntrainees. Overloading people with too many tasks at once will crash their\nbandwidth, so approach briefs in a very ordered manner.\n\n## Adopt ‘slow’ solutions (where needed)\n\nSometimes it’s not possible to whack a plaster on an issue and call it a day.\nSome solutions to development problems are just as complex as the problems\nthemselves, and you need to focus on proper, rather than fast, implementation.\nYou might need to factor in extra time or budget (gulp) in order to get a\ndevelopment project or team back on track. The effort you put into the (right)\nsolution will pay off in the long run.\n\nA good example of a ‘slow solution’ is the [steep learning curve developers face when adopting new tools and ways of working like Git](/blog/learning-curve-is-the-biggest-challenge-developers-face-with-git/)\n– but that shouldn’t put you off. It may be that right now your development team\nneed to spend some time getting to grips with a process, framework, or tool that\nwill save hundreds of development hours further down the line.\n\nYou may also want to take advantage of the [Minimum Viable Change Principle](/blog/how-to-shorten-conversation-cycle/) that\ntakes into account the full scale of development complexity, but focuses on\nmoving the project forwards with a minimum viable fix, allowing for further\niterations when the time is right. This is a great strategy that should be\nimplemented on a regular basis, especially when time is of the essence and a\nfull raft of features is not immediately feasible.\n\n## Focus on logic\n\nDevelopment is an extremely logical task, and you need to approach development\ntroubleshooting in the same logical and methodical way. Development problems\nneed to be fully mapped out in a logical sequence, not treated reactively with\n‘creative’ solutions.\n\nSpecificity is a really important thing when discussing potential development\nissues.  Unclear and vague pronouns aren’t helpful – be ready to be super\nanalytical and direct.\n\nDevelopment projects are notorious for running over-budget and taking up loads\nof business time, which can cause logic to fly out of the window in a state of\npanic. Think carefully about any knee-jerk reactions, and don’t be so ready to\nburn a whole project because of a few final teething problems.\n\n## Review your team model\n\n**It all works better when you embrace the idea that “product,” “design,” and\n“engineering” are just different perspectives on the same thing.** – [Greg Veen](http://jrsinclair.com/articles/2017/faster-better-cheaper-art-of-making-software/#fn:3)\n\nSlow progress or projects stalling could come down to your software team model.\nWhen was the last time you reviewed yours? There are a few different software\nproject management methodologies that can really help structure and improve\npreviously ‘messy’ development teams. Have a look around you, and see whether\nit’s time your team went in for an upgrade?\n\nFrom [Scrum to Kanban](https://devops.com/kanban-vs-scrum/), there is an\nincreasing focus on [DevOps](/topics/devops/)\nas a way to have more joined-up development and software teams. A product\nengineering model can be a great way to improve company and project efficiency –\nit’s certainly [helped big software companies like Shopify refine their development strategy](https://engineering.shopify.com/blogs/engineering/why-shopify-moved-to-the-production-engineering-model).\n\n## Measure constantly for project agility\n\nIf you want to find problems, you need to be tracking them first! From\ncollecting the right data, to testing and tracking, make sure that you\nconstantly keeping tabs on the project as it progresses. Adopting tools like\n[Cycle Analytics](/solutions/value-stream-management/) will\nensure that you always stay on track with how your projects are progressing,\nand the data you’ll harness will become an invaluable source of business intelligence.\n\nOne great way to incentivize teams and fix any looming issues on the horizon is\nto make performance and progress visible, then discuss them openly.\nWhen a problem does surface, treat it as a single entity and don’t wait for any\nmore to pile up – this is a much more [agile approach](http://agilemethodology.org/)\nthat will help keep projects streamlined.\n\n## Build communication into the project\n\nShow, don’t tell. Development progress needs to be communicated in clear and\nvisual terms – language is often an insufficient medium for development (and\ndevelopers). Consistent bug reporting and watertight specifications are\nimportant. Specification quality needs to be at 100 percent, otherwise you can’t\nexpect the code you get back to be 100 percent either.\n\nIf development is rubbing up against teams with little development experience,\ncommunication becomes even more essential. Reducing the amount of jargon can\nhelp non-developers stay in the loop, but at the same time, it’s important that\na business learns how to adopt development and software language (especially if\nit relies on it for its income).\n\nIt’s disheartening to see how little some software company employees actually\nknow about software development – better communication can help rectify this issue.\n\n## The halfway point check-in\n\nThe halfway point is a critical yardstick for any development project. It’s a\ngreat time to check in with your team and see how they are getting on. By then,\nyou should have a pretty robust feel for how people are coping, and whether the\nproject is going to be delivered in time.\n\nHaving a formal process and meeting for the halfway point isn’t always feasible\n(it largely depends on project size), but it’s a good idea to do nevertheless.\n[Getting the team together and getting visibility on progress is also a morale booster](https://www.themuse.com/advice/7-great-ways-to-boost-your-teams-morale).\n\nIf things aren’t looking good halfway? Don’t just cross your fingers, and hope\nfor the best for the rest of the time – you need to tackle the issue there and\nthen. Go away and review all the data that’s available to you before you make\nany rash killswitch decisions.\n\n*In order to keep your development projects on track, you need to become good at\ncommunicating with your development team, embracing agile solutions wherever\npossible. What’s your number one project management tip?*\n\n### About the guest author\n\nPatrick Foster is an ecommerce consultant and coach, and has been helping\nfounders and ecommerce startups for longer than he cares to admit. A passionate\nadvocate of ecommerce journeys and stories, he is always looking to find\nlikeminded thinkers and entrepreneurs. Come say hello on [Twitter](https://twitter.com/myecommercetips).\n\n[Cover image](https://unsplash.com/photos/SITaCHf7jjg) by [Alexander Shustov](https://unsplash.com/@alexandershustov) on Unsplash\n{: .note}\n",[805],{"slug":2259,"featured":6,"template":700},"how-to-spot-development-issues","content:en-us:blog:how-to-spot-development-issues.yml","How To Spot Development Issues","en-us/blog/how-to-spot-development-issues.yml","en-us/blog/how-to-spot-development-issues",{"_path":2265,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2266,"content":2272,"config":2279,"_id":2281,"_type":17,"title":2282,"_source":18,"_file":2283,"_stem":2284,"_extension":21},"/en-us/blog/pick-your-brain-interview-kwan-lee",{"title":2267,"description":2268,"ogTitle":2267,"ogDescription":2268,"noIndex":6,"ogImage":2269,"ogUrl":2270,"ogSiteName":686,"ogType":687,"canonicalUrls":2270,"schema":2271},"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":2273,"description":2268,"authors":2274,"heroImage":2269,"date":2276,"body":2277,"category":14,"tags":2278},"How to become the best distributed software development team? My interview with GitLab's CEO",[2275],"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",[1563,763,804],{"slug":2280,"featured":6,"template":700},"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":2286,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2287,"content":2293,"config":2299,"_id":2301,"_type":17,"title":2302,"_source":18,"_file":2303,"_stem":2304,"_extension":21},"/en-us/blog/pick-your-brain-interview-cedric-savarese",{"title":2288,"description":2289,"ogTitle":2288,"ogDescription":2289,"noIndex":6,"ogImage":2290,"ogUrl":2291,"ogSiteName":686,"ogType":687,"canonicalUrls":2291,"schema":2292},"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":2288,"description":2289,"authors":2294,"heroImage":2290,"date":2296,"body":2297,"category":14,"tags":2298},[2295],"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",[1563,763],{"slug":2300,"featured":6,"template":700},"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":2306,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2307,"content":2313,"config":2319,"_id":2321,"_type":17,"title":2322,"_source":18,"_file":2323,"_stem":2324,"_extension":21},"/en-us/blog/why-your-code-review-process-is-broken-and-how-to-fix-it",{"title":2308,"description":2309,"ogTitle":2308,"ogDescription":2309,"noIndex":6,"ogImage":2310,"ogUrl":2311,"ogSiteName":686,"ogType":687,"canonicalUrls":2311,"schema":2312},"Why your code review process is broken, and how to fix it","What do you do when you follow your code review process, and you’re still rudely greeted by code full of bugs, or a flood of user complaints?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679775/Blog/Hero%20Images/why-your-code-review-process-is-broken-and-how-to-fix-it.jpg","https://about.gitlab.com/blog/why-your-code-review-process-is-broken-and-how-to-fix-it","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why your code review process is broken, and how to fix it\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2017-07-25\",\n      }",{"title":2308,"description":2309,"authors":2314,"heroImage":2310,"date":2316,"body":2317,"category":14,"tags":2318},[2315],"Emily von Hoffmann","2017-07-25","\nPeople in every field can relate to the feeling of carefully moving down your checklist, triple-checking your work, and confidently *sending that email*, or *posting that tweet*, or *merging those changes*, only to at some later interval experience unmistakable stomach-sinking at some surprise snafu. That’s why we identify areas with potential for human error and build in review cycles with hopefully explicit steps and goals — like code reviews! So what about when you follow all of those steps and you’re still rudely greeted by code full of bugs, or a flood of user complaints?\n\n\u003C!-- more -->\n\nIn other words, why exactly did your code review process “fail” to deliver what you designed it for? It’s not just overt technical errors we’re looking to avoid; our Discussion Product Manager [Victor Wu](/company/team/#victorwu416) told me that we can think of code review as being ineffective if it results in code being shipped that doesn’t meet business or product goals. In this case, poor code review contributes to the ultimate failure, and may lead the product to snowball over time, becoming harder to fix and add new features. Here are a few scenarios with some thoughts on what might have contributed to the code review breakdown.\n\n### Feature shipped with a lot of defects\n\nThis one is easy to identify, but maybe not always as easy to remediate. What broke in the process that allowed this to happen? It might have something to do with rushed or unrealistic deadlines handed to developers, which we heard in our [Global Developer Survey](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) is a major reason code gets shipped before it’s ready. One option here might be to try a cross-functional team, or review the channels available for communication with teammates in a different function than your own — the key to [better deadline-setting](/blog/why-code-is-released-too-early/) is finding ways to develop empathy for other teams’ needs, and that won’t happen if you’re siloed.\n\nIt can be even trickier if the problem arises from within the culture of the dev team itself. There can be a power dynamic and intimidation factor inherent in the review process that could make a more junior reviewer, for example, not stick to their guns when their suggestions are insufficiently addressed. At GitLab, we follow best practices, largely based on the [thoughtbot code review guide](https://github.com/thoughtbot/guides/tree/master/code-review), that are designed to create an effective environment for code reviews.\n\n>There can be a power dynamic and intimidation factor inherent in the review process that could make a more junior reviewer, for example, not stick to their guns when their suggestions are insufficiently addressed\n\nThe guide contains truisms that could apply to any setting where one’s creation might be critiqued by a teammate, like `avoid using terms that could be seen as referring to personal traits`, and `if you don't understand a piece of code, say so. There's a good chance someone else would be confused by it as well` for the reviewer, and `don't take it personally. The review is of the code, not of you` and `be grateful for the reviewer's suggestions` for the reviewee. It’s important to have the right person reviewing, and for everyone to internalize the respect and balance between the reviewee and reviewer roles.\n\n### Feature shipped with poor usability or did not solve the underlying business problem\n\nWhat happened here is likely to do with the [dynamic between the business and engineering teams](/blog/your-engineers-need-to-understand-your-business-heres-why/). Engineers may feel disheartened by business managers who seem solely concerned with functionality. This disregard can be reciprocal, with engineers focusing on delivering quality work but unconcerned with the business and the end users.\n\nIt’s not uncommon for engineers to be excluded from business discussions, until requirements are [thrown over the wall](/blog/your-engineers-need-to-understand-your-business-heres-why/) at them — this lack of alignment creates inefficiencies that can have long-term consequences. Engineers may feel uneasy about the timeline or the product direction, or they may simply feel whatever’s being asked of them is a bad idea. If their organization doesn’t have a channel open for them to discuss their concerns, they might feel they have no choice but to go along with it. Ideally, dev teams today will be heavily involved in business discussions, and they’ll have the responsibilities to match.\n\n>Ideally, dev teams today will be heavily involved in business discussions, and they’ll have the responsibilities to match\n\n### Feature shipped BUT...\n\nIt might be the case that all seems well when a feature ships, but going forward it takes much more time to develop new features, and there are many brittle edge cases. Victor told me that in this case, it’s more likely that the architecture is simply inadequate, and not enough effort was made to clean up tech debt. This is not the opportunistic tradeoff of tech debt and time to market that many startups weigh; it’s when tech debt feels like it’s spiraled out of control. This might be the confluence of the poor dynamics we’ve discussed above, with engineers pressed for time, [burned out and working long hours](https://codewithoutrules.com/2017/06/21/why-company-want-long-hours/), and perhaps feeling unable to push back against business demands.\n\nOn his blog *Code Without Rules*, Itamar Turner-Trauring [explains several possible reasons](https://codewithoutrules.com/2017/06/21/why-company-want-long-hours/) why organizations might have unhappy developers unable to do their best work, and he offers some tips for how individual developers might be able to regain some control over their work lives.\n\nWhat are other scenarios you’ve experienced? Leave a comment and let us know.\n",[804,805],{"slug":2320,"featured":6,"template":700},"why-your-code-review-process-is-broken-and-how-to-fix-it","content:en-us:blog:why-your-code-review-process-is-broken-and-how-to-fix-it.yml","Why Your Code Review Process Is Broken And How To Fix It","en-us/blog/why-your-code-review-process-is-broken-and-how-to-fix-it.yml","en-us/blog/why-your-code-review-process-is-broken-and-how-to-fix-it",{"_path":2326,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2327,"content":2333,"config":2338,"_id":2340,"_type":17,"title":2341,"_source":18,"_file":2342,"_stem":2343,"_extension":21},"/en-us/blog/how-to-shorten-conversation-cycle",{"title":2328,"description":2329,"ogTitle":2328,"ogDescription":2329,"noIndex":6,"ogImage":2330,"ogUrl":2331,"ogSiteName":686,"ogType":687,"canonicalUrls":2331,"schema":2332},"How to shorten the conversation cycle","Four simple steps to move faster from idea to production.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671350/Blog/Hero%20Images/shorten-conversation-cycle.jpg","https://about.gitlab.com/blog/how-to-shorten-conversation-cycle","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to shorten the conversation cycle\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-06-19\",\n      }",{"title":2328,"description":2329,"authors":2334,"heroImage":2330,"date":2335,"body":2336,"category":14,"tags":2337},[998],"2017-06-19","\n\nIf your new features often get stalled in the initial discussion phase, read our four tips for shortening the conversation cycle and shipping faster.\n\n\u003C!-- more -->\n\n## 1. Measure your cycle time\n\nThe first step towards making a change is having the numbers to motivate it. If you measure the duration of time from the moment an idea is first discussed in chat, all the way through to its release in production, you can make a good case for changing your approach if others can see that something is causing delays. Try a feature like [cycle analytics](/solutions/value-stream-management/) to monitor each stage in your workflow.\n\n## 2. Start with minimum viable changes\n\nYou've identified the problem, now how do you fix it? Where ideas for new features and improvements often get stuck is on how to implement them. The idea may be too ambitious or too time consuming to ship easily, so it gets pushed back in favor of more manageable changes. Try breaking up new products or features into smaller pieces of functionality. [Iteration is one of our company values](https://handbook.gitlab.com/handbook/values/) and while it's often one of the more uncomfortable ones, it is effective. Do the smallest thing possible and release it quickly – you can keep iterating from there.\n\n## 3. Include gatekeepers early on\n\nWho needs to approve something before you ship? Don't leave them out until the last minute. Including stakeholders, security experts, product managers and UX team members in the conversation in the early phases prevents bottlenecks ahead of release, and ensures that most errors have been caught and addressed before you move into production. Read more about [shipping faster without sacrificing security or quality](/blog/speed-security-quality-with-hackerone/).\n\n## 4. Get everyone on board\n\nAcknowledging that a feature or product is not polished and needs more work, yet releasing it anyway, feels unnatural to most of us, so you may meet some resistance to the idea. Working in this way does offer benefits to both business owners and developers, which you can communicate to help persuade hesitant team members.\n\nFor example, you can respond more quickly to market needs and user feedback by shipping minimum viable changes often, which is good news for your business. For developers, it's easier to troubleshoot a small release and having faster, more frequent feedback on work gives more of a sense of progress and boosts motivation.\n\nMoving towards smaller releases to shorten the time between idea and production may feel strange at first, but you'll start seeing results quickly.\nShortening the conversation cycle is just one principle of Conversational Development. Visit [conversationaldevelopment.com](http://conversationaldevelopment.com/) to learn more.\n{: .alert .alert-gitlab-orange}\n\n[Cover image](https://unsplash.com/@djmalecki?photo=fw7lR3ibfpU) by [Dawid Malecki](https://unsplash.com/@djmalecki) is licensed under [CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/)\n{: .note}\n",[804,805],{"slug":2339,"featured":6,"template":700},"how-to-shorten-conversation-cycle","content:en-us:blog:how-to-shorten-conversation-cycle.yml","How To Shorten Conversation Cycle","en-us/blog/how-to-shorten-conversation-cycle.yml","en-us/blog/how-to-shorten-conversation-cycle",{"_path":2345,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2346,"content":2352,"config":2358,"_id":2360,"_type":17,"title":2361,"_source":18,"_file":2362,"_stem":2363,"_extension":21},"/en-us/blog/on-calliday-unsucking-your-on-call-experience",{"title":2347,"description":2348,"ogTitle":2347,"ogDescription":2348,"noIndex":6,"ogImage":2349,"ogUrl":2350,"ogSiteName":686,"ogType":687,"canonicalUrls":2350,"schema":2351},"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":2347,"description":2348,"authors":2353,"heroImage":2349,"date":2355,"body":2356,"category":14,"tags":2357},[2354],"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",[805,763,742],{"slug":2359,"featured":6,"template":700},"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":2365,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2366,"content":2372,"config":2377,"_id":2379,"_type":17,"title":2380,"_source":18,"_file":2381,"_stem":2382,"_extension":21},"/en-us/blog/ways-to-encourage-collaboration",{"title":2367,"description":2368,"ogTitle":2367,"ogDescription":2368,"noIndex":6,"ogImage":2369,"ogUrl":2370,"ogSiteName":686,"ogType":687,"canonicalUrls":2370,"schema":2371},"3 Ways to foster collaboration","Want to know how we encourage everyone to contribute?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669991/Blog/Hero%20Images/ways-to-encourage-collaboration.jpg","https://about.gitlab.com/blog/ways-to-encourage-collaboration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 Ways to foster collaboration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-06-12\",\n      }",{"title":2367,"description":2368,"authors":2373,"heroImage":2369,"date":2374,"body":2375,"category":14,"tags":2376},[998],"2017-06-12","\n\nWe know that [collaboration is critical](/blog/why-collaboration-tools-matter/) for organizations moving towards a DevOps culture. Here's how we encourage collaboration in our workflow at GitLab.\n\n\u003C!-- more -->\n\n## 1. We make suggesting changes less scary\n\nUsing version control for more than just your source code means that everyone feels free to contribute to documentation, configurations, tests and whatever else you're working on. With the benefit of [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), it's possible to suggest a change or an improvement, or even just query something that isn't entirely clear or could be described better, without just going ahead and making the change immediately. This invites discussion and prevents less experienced team members from feeling nervous to voice their opinions.\n\n>\"It really makes the documentation, similar to the source code, an open source and living document that everyone can contribute to.\" – GitLab Platform Backend Lead, [Douwe Maan](/company/team/#DouweM)\n\n## 2. We open our development platform\n\nBy giving everyone in your organization access to view what other teams are working on, you allow everyone to discover and contribute beyond their own projects. This [inner sourcing](https://en.wikipedia.org/wiki/Inner_source) approach makes it more likely that team members can learn from others or offer suggestions from their own experience that could be applied to a different project, avoiding duplication of work. Douwe explains: \"It's working together to make all of our code better, because if we use a shared library – even if it’s just an internal one – if one person improves it or fixes a bug or increases the functionality of that application, that’s work by one person that will immediately affect all the different teams.\"\n\n## 3. We make code review impersonal\n\nEveryone is encouraged to [review each other's code](https://www.youtube.com/watch?v=XluG9mAQdSo&feature=youtu.be) or ask for input, and the focus of that review is firmly on improving the code. The approach is not to say, \"This is wrong, change it to this,\" which can be really demotivating. We use language like, \"Have you considered this?\" or \"What do you think about this?\"\n\nThis not only makes code review less scary for the person whose merge request is being reviewed, it also makes it less intimidating for other team members to weigh in on more senior team members' work.\n\n>\"Review is really something we all do together. Even the most junior person or just someone who doesn’t really know this part of the application yet, if they see something that doesn’t quite look right to them or something they might have a question about, it’s really useful if you make them feel free to comment on that.\" - Douwe\n\nBy removing the barriers to contribution and making it easy and encouraged to offer input, even where team members have less experience, we've built a culture around collaboration and learning from others' expertise. Fostering collaboration across different teams and functions is just one element of a DevOps culture – to learn more, watch our webcast, \"[Managing the DevOps Culture Shift](https://www.youtube.com/watch?v=py8c6-3zyKM&feature=youtu.be)\" on demand now.\n\n*How does your team encourage everyone to contribute? Tell us in the comments!*\n\n\u003C!-- cover image: https://unsplash.com/search/street-art?photo=PVw_vtpCGaM-->\n",[2216,804,805,695],{"slug":2378,"featured":6,"template":700},"ways-to-encourage-collaboration","content:en-us:blog:ways-to-encourage-collaboration.yml","Ways To Encourage Collaboration","en-us/blog/ways-to-encourage-collaboration.yml","en-us/blog/ways-to-encourage-collaboration",{"_path":2384,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2385,"content":2391,"config":2398,"_id":2400,"_type":17,"title":2401,"_source":18,"_file":2402,"_stem":2403,"_extension":21},"/en-us/blog/speed-security-quality-with-hackerone",{"title":2386,"description":2387,"ogTitle":2386,"ogDescription":2387,"noIndex":6,"ogImage":2388,"ogUrl":2389,"ogSiteName":686,"ogType":687,"canonicalUrls":2389,"schema":2390},"Workflow tips to ship faster without sacrificing security or quality","We partnered up with HackerOne to explain how to ship faster with a security-first development mindset. Watch the recording and check out the slides here.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671606/Blog/Hero%20Images/workflow-tips-security-quality-cover.jpg","https://about.gitlab.com/blog/speed-security-quality-with-hackerone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Workflow tips to ship faster without sacrificing security or quality\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2017-06-05\",\n      }",{"title":2386,"description":2387,"authors":2392,"heroImage":2388,"date":2394,"body":2395,"category":14,"tags":2396},[2393],"Erica Lindberg","2017-06-05","\n\n[Release early and often](/blog/release-early-release-often/),\nrespond quickly to customer feedback, iterate. Rinse, repeat.\nThe value of getting new features and products in front of customers faster has made\nits mark on the business world. As a result, development teams are under pressure\nto shorten release cycles and meet tighter deadlines all while maintaining high\nquality and security standards. How do experienced teams do it?\n\n\u003C!-- more -->\n\nAccelerating the development lifecycle without cutting corners is no easy feat but\nit can be done. While there's no \"silver bullet\" solution, adopting a security-first\nmindset and a few workflow best practices can help.\n\nWatch the our webcast with HackerOne below to get all the details on how you can build in quality and\nsecurity checks throughout your development lifecycle from GitLab's Product Manager, [Victor Wu](/company/team/#victorwu416),\nand GitLab Security Lead, [Brian Neel](/company/team/#b0bby_tables).\n\nYou can watch the recording, check out the slides, and read a few of the highlights\nbelow.\n\n## Security as a first-class citizen\n\nEnsuring every line of code is secure is a shared responsibility, meaning security\nshould be top of mind from the very beginning of the development process. Don't wait\nuntil the very end to start the conversation around security and check for vulnerabilities.\n\n> \"We want to take security and make it a first-class citizen. You want security controls\nbaked into each stage of your development process. When we develop software and we\ndevelop in small chunks, we always say we want cross-functional collaboration.\nWe want people at the table earlier on.\" - Victor Wu, Product Manager, GitLab\n\nWhether you have dedicated security experts, or perhaps a lead engineer who's wearing\nmultiple hats, talk about security from the get go so that security issues\ncan be identified earlier, and vulnerabilities can be avoided altogether.\n\n## Workflow best practices\n\nIn the webcast, Victor details how DevOps teams can bake quality and security controls\ninto their workflows so that these checks don't become cumbersome bottlenecks at the\nvery end of the process.\n\nHere are a couple of his highlights:\n\n### Make smaller changes and commit often.\n\nPerhaps the most critical adjustments to make to your workflow is how you actually write\nand collaborate on code. When we talk about development speed, a big part of this is transitioning\naway from developing huge portions of code over long periods of time to making smaller changes more often\nand making that work visible sooner.\n\n> \"We want to ship smaller pieces, often. Whether it's in an agile context, scrum,\nor moving away from the more traditional waterfall requirements, we want to ship\nin small pieces so we can react more quickly and minimize risk.\" - Victor\n\nBy adopting this practice, it's quicker to perform code reviews and\nsecurity checks because reviewers are only dealing with a couple of changes. Then,\nif there is an issue, it becomes much easier to identify the cause because there\nare fewer new variables to consider.\n\n### Involve experts and reviewers early in the development process.\n\nInvolving collaborators and reviewers earlier in the development process does two things.\nFirst, it can speed up the development process by giving stakeholders an opportunity\nto anticipate problems *before* developers begin to write code, and nip them in the bud.\nIt's common to involve your UX team, product managers, and software architects during the\nplanning phase and throughout the code review process, but often security is left out.\n\nGet your security experts involved in the earlier phases of your development process\nso it doesn't become a bottleneck right before you're trying to release.\n\n> \"Let's get our UX folks early on, let's get our business managers involved early on.\nLet's not wait until very late in the game before we bring our product managers,\nsenior engineers, our architect, and security experts.\" - Victor\n\nSecondly, by keeping all stakeholders involved in the conversation throughout the\ndevelopment process, you can ensure that by the time the code is ready to move\ninto production, most errors have been spotted and corrected.\n\n### Get code into staging or test environments earlier.\n\nThis goes back to the high-level concept that we want to work on small pieces of code and get\nthem integrated into the mainline branch right away to minimize the risk of something not working,\nor not accounting for certain things.\n\n\"The point of pushing code into production-like environments is to get your feature into a place that looks\nand functions more like the real world,\" says Victor. Getting your code into staging or test environments sooner\ncan also help to minimize security risks.\n\n> \"You might have certain tools to scan dynamically and inject attacks into\nyour systems, whether that might be directly into your data or your code base.\nIn the same way that you have human testers doing manual testing, in addition to the automated testing,\nyou might have human users doing the security testing as well.\" - Victor\n\nAgain, if you're developing in small chunks, involving stakeholders earlier on into those environments,\nthat they can jump into those environments and start testing the feature.\n\n### Leverage your community to spot and prioritize security issues and bugs faster.\n\nEven with all the right quality and security checks threaded throughout the development process,\nproblems can slip through. In the webcast, Security Lead, Brian Neel, details the\nevolution of the security development process (starts at 28:20) and why GitLab's security\nteam uses a bug bounty program to round out our security practices.\n\n> \"Right around the time you push a beta out to customers, you can open up a bug bounty program, and it provides\nsort of an endless coverage from prior to version 1 all the way through version 2 and into the future for any new\nvulnerabilities. You're constantly going to have professional hackers out there testing this code, testing it against new types of\nvulnerabilities.\"\n\n## Recording\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/9_yicOrtbqM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\n## Slides\n\n\u003Ciframe src=\"//www.slideshare.net/slideshow/embed_code/key/fWsLY4ft2VvAMA\" width=\"595\" height=\"485\" frameborder=\"0\" marginwidth=\"0\" marginheight=\"0\" scrolling=\"no\" style=\"border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;\" allowfullscreen> \u003C/iframe>\n\n",[2397,805],"security",{"slug":2399,"featured":6,"template":700},"speed-security-quality-with-hackerone","content:en-us:blog:speed-security-quality-with-hackerone.yml","Speed Security Quality With Hackerone","en-us/blog/speed-security-quality-with-hackerone.yml","en-us/blog/speed-security-quality-with-hackerone",{"_path":2405,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2406,"content":2412,"config":2416,"_id":2418,"_type":17,"title":2419,"_source":18,"_file":2420,"_stem":2421,"_extension":21},"/en-us/blog/attributes-of-successful-development-teams",{"title":2407,"description":2408,"ogTitle":2407,"ogDescription":2408,"noIndex":6,"ogImage":2409,"ogUrl":2410,"ogSiteName":686,"ogType":687,"canonicalUrls":2410,"schema":2411},"9 Attributes of successful development teams","What makes a good development team? Here's what we think.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671496/Blog/Hero%20Images/attributes-successful-dev-teams.jpg","https://about.gitlab.com/blog/attributes-of-successful-development-teams","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"9 Attributes of successful development teams\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-05-23\",\n      }",{"title":2407,"description":2408,"authors":2413,"heroImage":2409,"date":2414,"body":2415,"category":14},[998],"2017-05-23","\n\nNot all development teams work the same way, but there are some values, processes and attitudes that all successful teams share.\n\n\u003C!-- more -->\n\n## 1. They automate everything\n\nThere’s no substitute for the work of the human brain, but by automating some of the more time-consuming (and sometimes tedious) aspects of a developer’s job, you not only free up time that could be spent on other, more creative tasks, but you ensure that your software development process is easily repeatable, and consistent every release cycle. “We have a big release every month,” says GitLab Platform Backend Lead, [Douwe Maan](/company/team/#DouweM), “but we have numerous patch releases. We have tons of scripts in our release tools repository that automate that so that we don’t miss little bits and so that it’s identical and reproducible every time.” Automation also means doing things like leveraging [continuous integration](/solutions/continuous-integration/) to run scripts, so a portion of your code review is taken over, offloading work that would otherwise be done manually.\n\n## 2. They’re meticulous about documentation\n\n“Documentation of processes and guidelines is a way of kind of scripting or automating your team’s behavior,” explains Douwe. Because we’re a distributed team, it’s important that if a question comes up often, that there’s somewhere people can find what they need without having to wait for team members in other time zones to come online and answer a question – this saves time not just for the person with the question, but for others who are spared answering the same questions over and over. “If people on my team have a certain question or things that are blocking them repeatedly, that probably means it’s something we should either document better or invent a process around,” says Douwe.\n\n“As a consequence of that, for example, we have the process around getting merge requests and issues into a patch release when it’s a regression or security issue and so on. At one point we had so few people that we could just say, ‘Hey that needs to go into the patch release,’ but of course as the team grows, that doesn’t scale anymore, because you’d have 20 people asking one person. To address that we invented the process around labels, where we use labels and milestones very heavily in GitLab to signal to people what has to happen with an issue.”\n\n## 3. They use collaboration tools\n\nHaving space for comments, questions or suggestions at each stage of the cycle is critical for fostering collaboration and making sure that everyone can follow the latest progress of a project. “For us, the single source of truth is always the [issue](/stages-devops-lifecycle/issueboard/). Tools like labels, milestones, assigning to people, these all make sure that the right person knows when it’s their turn to do something, and the handoff happens through issue comments,” explains Douwe. This is another area in which we’ve had to become disciplined about documenting the latest update on an issue, because as a distributed team we can’t just walk over to a colleague’s desk to check something. “We don’t have the problem where after two days people will be like, ‘Hmm, what did we decide again?’” says Douwe. Discussion takes place right in the same environment where we’re working – whether it’s a comment on an issue or a merge request or an inline question on the code itself – so it’s easy for everyone to see the context for it and to refer back to it later.\n\n## 4. They use integrated platforms\n\nHaving all your software development tools in one environment reduces context-switching, tiresome maintenance when APIs change, and administrative complexity. It also makes the development process smoother, as an integrated tool often offers shortcuts within the UI that would not exist if you were using two separate products.\n\nDouwe explains: “For a long time GitLab CI used to be a separately deployed web application: the UIs were not integrated in any way and they felt like separate products, as if they were not even made by the same company. At one point we decided to integrate it, and literally within one or two weeks we started seeing new possibilities of interlinking these applications. We’d think, ‘Hey, wouldn’t it be neat if we added a button to the latest status of this page?’ which previously is something we never would have thought about, because we really thought of the two as separate products that need to talk over an established channel, instead of just putting a link in everywhere where it would useful to have a link to CI. So with a built-in solution, the integration you get is not just tighter, it’s integrated in ways which other, separate products being developed by siloed development teams would never think of. We’re not just approaching it as an issue tracker, a code review tool or a CI tool, we’re seeing it as a development environment.”\n\n## 5. They version control everything\n\nUsing [version control](/topics/version-control/) for source code is widely accepted as a good idea, but it’s useful for a number of other purposes too. Take documentation, for example: if you use a wiki, there is no concept of a merge request. “There’s no way of suggesting an improvement without immediately making it,” says Douwe, “so what that means is that in a lot of places that use a wiki, changing it is kind of scary.” This creates a feeling that suggesting updates or improvements is for senior team members only, and discourages participation and collaboration on the documentation. \"Using source control here means that even the most junior person who’s like, ‘Hmm, I spotted a typo here,’ or ‘Hey, this wasn’t super clear, let’s do it like this,’ won’t be hesitant to bring up that suggestion.\" Having time to write a merge request that clearly outlines the advantages of what they're proposing makes it less intimidating to suggest a change. \"It really makes the documentation, similar to the source code, an open source and living document that everyone can contribute to.\" The same principle applies to things like your CI/CD configuration, tests, and infrastructure code.\n\nImproved collaboration and learning opportunities aren’t the only benefits of using version control for things beyond your source code: the ability to roll back in the event of something breaking, and to pinpoint where a bug was introduced are advantages both in that it’s easier to fix something, but also in that team members feel freer to experiment without the fear of causing irreparable damage if something breaks.\n\n## 6. They make it easy for everyone to contribute\n\nBy opening up your development platform, other team members can discover, contribute to and learn from other team members’ work. “If you hide your CI configuration in an area that can only be accessed by the masters of the project, that means that very few developers on the team and especially very few developers on other teams will ever see that config,” says Douwe. “You really shouldn’t see your code as just a product of your team, you should also see it as a resource for everyone else in the company. If you ask a developer how they learned to code, most of them will not mention university or this book that they read, most of them will mention ‘code I read that was written by people who have more experience than me.’ So by giving them access to as much code as you can, that will actually make them better coders than if you have them work in a silo.”\n\n> If you ask a developer how they learned to code, most of them will not mention university or this book that they read, most of them will mention \"code I read that was written by people who have more experience than me.\"\n\nThis isn’t just about less experienced developers learning from more experienced developers. Sometimes a fresh perspective from someone who isn’t as close to a project can spark solutions that aren’t apparent when you’ve been deep inside the code for a week. “Like if someone reads code and they ask a question like ‘Hey, what’s the reasoning behind this? I just found your code and I was wondering…’ it enables a conversation.” Douwe explains. “It helps us avoid [Not Invented Here syndrome](https://en.wikipedia.org/wiki/Not_invented_here).” Someone from another team might have already done work you require on a previous project of theirs – why not use it on your team? “It’s working together to make all of our code better, because if we use a shared library – even if it’s just a company internal one, like innersourcing – if one person improves it or fixes a bug or increases the functionality of that application, that’s work by one person that will immediately affect all the different teams.”\n\n## 7. They spend time on side projects\n\n“We don’t have explicit [20 percent time](https://googleblog.blogspot.co.uk/2006/05/googles-20-percent-time-in-action.html),” says Douwe, “but at GitLab, as we are working on improving the same platform we use to do all our work, our job is to make our own job easier. Which means that even if something is not scheduled for this release, if it’s something that you think you can get done in couple hours, and it would save you more than a couple hours in the future, just do it.”\n\nSometimes going through the formal process for approving time to work on a new feature just isn’t necessary. “Unless you have something urgent you should be working on, it really helps to ask developers to feel responsible for the product, and also own the product in the sense that they can also suggest new features, and even spearhead the development of them without going through product management for example,” says Douwe.\n\n## 8. They make code review collaborative\n\nHaving your work reviewed can feel like a personal judgement on whether you’re good enough or not. When code review is about “This is wrong, change it to this,” it can be really demotivating. Douwe explains: “A much better way, even if it seems like something is obviously wrong, would be to ask, ‘What do you think about changing to this/Did you consider X, Y, Z/I suggest changing it to this, if you think that makes sense.’ The communication there really helps and it also means that people don’t feel review is the time where they as person are being told if their work is good enough, if they are good enough, it’s really just talking about the actual code, the implementation, the best way to solve a problem.” Everyone on a team is free to review each other’s code or to ask for a review, so it becomes about just improving the merge request instead of passing a judgement about that person’s work. “If review feels like something that’s just done by the higher-up people and it’s a time when your code is deemed perfect or not, it might feel kind of scary to review someone’s code, especially if that someone is more experienced than you or has more experience in this area of the application. What really helps with collaboration is having everyone feel free to question each other’s code or question, ‘Is this the best way to go about this?’ without saying ‘This is wrong.’”\n\n## 9. They’re allowed to be creative\n\nProblem solving is what developers do. So if a customer has a request for some feature that they would find useful, it can be helpful to ask the team to solve the problem the customer is experiencing, rather than presenting them with a spec which might not be the optimal solution. “In a lot of cases developers are aware of solutions either that already exist within the codebase or that exist in other people’s codebases because of innersourcing, or they might even have just read about this cool, open source tool, which a product manager might not be aware of,” says Douwe. “So allowing developers to be really critical of the proposal and having product managers not be too rigid in their specs also gives you better code and makes for happier developers.” This can also help you to build features that don’t just address one particular customer’s problem and fix it the way they would like, but rather work on solutions that can be useful to everyone.\n\nTo learn more about what makes development teams successful today, watch our webcast, \"[Managing the DevOps Culture Shift](http://get.gitlab.com/managing-devops-culture-shift/)\" on demand.\n{: .alert .alert-gitlab-orange}\n",{"slug":2417,"featured":6,"template":700},"attributes-of-successful-development-teams","content:en-us:blog:attributes-of-successful-development-teams.yml","Attributes Of Successful Development Teams","en-us/blog/attributes-of-successful-development-teams.yml","en-us/blog/attributes-of-successful-development-teams",{"_path":2423,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2424,"content":2430,"config":2434,"_id":2436,"_type":17,"title":2437,"_source":18,"_file":2438,"_stem":2439,"_extension":21},"/en-us/blog/inside-gitlabs-code-review-flow",{"title":2425,"description":2426,"ogTitle":2425,"ogDescription":2426,"noIndex":6,"ogImage":2427,"ogUrl":2428,"ogSiteName":686,"ogType":687,"canonicalUrls":2428,"schema":2429},"Inside GitLab’s code review flow","We keep a quality-conscious mindset throughout the development process, sharing the responsibility among everyone instead of seeing review as an obstacle at the end.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667591/Blog/Hero%20Images/code-review-blog.jpg","https://about.gitlab.com/blog/inside-gitlabs-code-review-flow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Inside GitLab’s code review flow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2017-05-02\",\n      }",{"title":2425,"description":2426,"authors":2431,"heroImage":2427,"date":2432,"body":2433,"category":14},[2315],"2017-05-02","\n\nCode review, or engineers manually reviewing code as it is being developed, is one of several tools that organizations have to maintain code quality. Having a clean codebase allows developers to quickly build new features, which comes in handy if you find yourself needing to react promptly to the market.  \n\n\u003C!-- more -->\n\nSince teams can feel pressed to skimp on code reviews due to deadline pressure, it’s important to create a clear, repeatable process that becomes a habitual part of the workflow. In addition to the business benefits of keeping code quality high, a robust code review process also carries benefits for productivity, like helping share technical knowledge across teams, and looping in the right people during the process instead of at the end. With a tool like GitLab, where the intuitive UI and discussion features make it easy for non-technical people to contribute, code review can also become a mechanism for uniting stakeholders in your organization.\n\nWhile using GitLab to build GitLab, we apply a quality-conscious mindset throughout the development process, sharing the responsibility among everyone instead of seeing review as an obstacle at the end.\n\n### How we think about code reviews\n\nWe review every single change, so nothing is ever committed directly to master, but we think “code review” is too narrow a term for what we do. Software engineers manually reviewing code is just one part of the entire product development process, and is interrelated with many other processes, so it doesn’t make sense to think about them separately. They all move us closer to our desired outcome: awesome features, shipped on a monthly basis, that meet our customer needs and grow our business.\n\n### Who is involved\n\nOur three core teams involved in the process are product managers, designers, and software engineers. All three teams are constantly collaborating and sharing resources; our roles are not strictly defined by our job titles. PMs and designers may write code, engineers may mock up a design, and everyone discusses the features and the product overall.\n\n### Our process\n\nWe have the benefit of constant dogfooding, or using our own product so as to discover new use cases, test our assumptions, and generally improve GitLab for our users. Loosely, we have a product-design phase, and a code implementation phase. We use [GitLab issues](/stages-devops-lifecycle/issueboard/) to mediate product-design discussions, and GitLab merge requests to mediate code discussions. We encourage “[WIP](/blog/feature-highlight-wip/)”, or work in progress, merge requests for code collaboration, especially when people with different skills are working together: non-engineers often actively engage in WIP merge request discussions to hash out edge cases and design decisions. Since we ship monthly, we schedule work monthly, and putting up WIP merge requests early helps us plan ahead and adjust the scope when we need to.\n\nWe generally assign one backend engineer and one frontend engineer to each feature, which is scoped as small as possible to reduce risk and help us move fast. The backend engineer and frontend engineer collaborate in the WIP merge request, and there is at least one reviewer who reviews the code and makes comments. When all comments, bugs, and design questions are addressed, we merge the feature branch into master. All designers, product team members, and engineers typically check out branches themselves and run code in a local or virtual environment to verify features throughout the development process. (This is also the case for our marketing and people operations teams — GitLab's UI makes it simple for non-technical users to get up to speed and start contributing without needing to work from the command line.) Engineers do their own manual and sanity testing, but we use [Test Driven Development](http://agiledata.org/essays/tdd.html) to catch most errors. We don’t follow a strict Agile flow, instead, we call it [Conversational Development](http://conversationaldevelopment.com/).\n\n### The benefits\n\nWe believe that this approach, which doesn’t segregate code review to the end of the process and entirely burden the reviewer, places responsibility on all of us. If something is broken, it is because we all failed collectively, so we do a retrospective and think about how to fix it. In a very concrete way, code reviews help enforce conventions, consistency, and technical standards among your team. Newer team members can accelerate their education about the product by creating code and then reviewing it critically. A collaborative code review process helps engineering and product teams work closely together to make the best decisions.\n\n\nWatch our webcast, [Code Review: A Business Imperative](https://www.youtube.com/watch?v=XluG9mAQdSo&feature=youtu.be) to learn how code review can help you keep up with the market by shipping better features, faster.\n{: .alert .alert-gitlab-orange}\n",{"slug":2435,"featured":6,"template":700},"inside-gitlabs-code-review-flow","content:en-us:blog:inside-gitlabs-code-review-flow.yml","Inside Gitlabs Code Review Flow","en-us/blog/inside-gitlabs-code-review-flow.yml","en-us/blog/inside-gitlabs-code-review-flow",{"_path":2441,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2442,"content":2448,"config":2453,"_id":2455,"_type":17,"title":2456,"_source":18,"_file":2457,"_stem":2458,"_extension":21},"/en-us/blog/our-secret-to-tackling-thousands-of-open-issues",{"title":2443,"description":2444,"ogTitle":2443,"ogDescription":2444,"noIndex":6,"ogImage":2445,"ogUrl":2446,"ogSiteName":686,"ogType":687,"canonicalUrls":2446,"schema":2447},"3 Rules for tackling thousands of open issues","Keep your DevOps teams focused and productive with these three simple rules.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684021/Blog/Hero%20Images/how-our-engineers-tackle-thousands-of-open-issues.jpg","https://about.gitlab.com/blog/our-secret-to-tackling-thousands-of-open-issues","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 Rules for tackling thousands of open issues\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jacob Schatz\"}],\n        \"datePublished\": \"2017-04-10\",\n      }",{"title":2443,"description":2444,"authors":2449,"heroImage":2445,"date":2451,"body":2452,"category":14},[2450],"Jacob Schatz","2017-04-10","\n\n Every engineering team likely has a process for triaging issues and allocating them to different team members. Otherwise, it can be difficult to mobilize to put out small fires without losing sight of bigger goals for building new things over the course of your release cycle.\n\n\u003C!-- more -->\n\nAt GitLab, the pile of work to be done is perhaps even more visible than most. Right now, on the GitLab Community Edition [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce) alone, there are 6,826 open issues, a number that could be numbing at best, and overwhelming at worst if viewed without a strong system for prioritization. Although I'm now the Frontend Lead, I started at GitLab as an engineer, and quickly became more productive than in any other previous job. I attribute this largely to the simple process that every new technical hire learns when they join, including a clear roadmap to follow when they start work every day. The key difference for me is that people at GitLab spend most of their time writing code, rather than talking about and planning it.\n\nThe secret hinges largely on our [issue board and labels](/stages-devops-lifecycle/issueboard/), with which we meticulously track progress and conversation. This also helps us meet other goals that are necessary for successful asynchronous work — we always opt for fewer meetings, and more communication through the issue tracker. All of these methods were passed down (and remixed) by our CTO, [Dmitriy Zaporozhets](/company/team/#dzaporozhets).\n\nIt boils down to three rules that help engineers sort issues and know exactly what to work on next, largely without consulting anyone:\n\n### 1. Regressions have the highest priority.\nWhy do we fix regressions before anything else? A regression is some functionality that used to work but no longer does, so we want to make sure that all the stuff we've built continues to serve our users. We believe we need to have a commitment to the code that's already in the codebase before continuing to write new things. When a regression is fixed, it goes into the next stable release. By marking a merge request as `pick into stable`, we signal release managers to collect it the next time they come around looking for fixes to include. It works like garbage collection — we place it all by the side of the road, and the truck comes to pick it all up.  \n\n### 2. Deliverables are always second.\nDeliverables are the things that we are promising to deliver in the next release, and ideally, they are the highest priority (as long as nothing else that used to work is broken). A deliverable takes precedence over other work because we want to have a way to show our customers what will be coming out in the next release. These are planned based on bandwidth and time, after Product talks with leads and we figure out how we are going to make it happen.\n\nWhen a developer gets to a new release, the only work that I actively assign involves the deliverables. Unless someone has an emergency, I don't assign any other work to any one developer; they are free to decide what they want to work on outside of their key deliverables. These are important to assign specifically, because each team member has their strengths, and with limited time before deadlines we have to delegate issues properly. If a deliverable doesn't make it into the current release, it is automatically pushed to the following release — we won't drop it until it is finished.  \n\n### 3. With free time, grab bugs unless told otherwise.\nThere are always bugs to fix. We always aim to fix bugs quickly to create the most stable software, which is why not every Frontend Developer gets a deliverable. We also want to move fast and break things, so we want some developers available to work only on bugs. Often I tell new hires on the Frontend team to work on bugs and regressions for the first few months, unless there is an emergency. That helps them wrap their head around the codebase, and get comfortable.\n\nIn addition to making expectations very clear to developers, these rules also simplify my role as a manager. I can filter issues according to whether they're labeled \"regression,\" \"deliverable,\" or \"bug\" to quickly see where progress is being made. All communication happens in the issues, so the right people can jump in and speak to the question. There's no reason to have me be a mediator, instead, Frontend can talk to UX directly, and so on for the other teams.\n\nIdeally, managers try to remove all formal meetings about projects and instead rely on flowing, open, recorded communication. This is the best system we've developed for managing remote engineers: they all know what to do, they’re very self-sufficient, and because of our development cycle it’s really easy to see whether we're on pace to meet our goals. By having issues [in the open](https://gitlab.com/gitlab-org/gitlab-ce/issues), everyone can stay focused on solving the problem.\n\n\n\u003Cp class=\"alert alert-orange\" style=\"background-color: rgba(252,163,38,.3); border-color: rgba(252,163,38,.3); color: rgb(226,67,41) !important; text-align: center;\">Watch our webcast   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Cstrong>Managing the DevOps Culture Shift\u003C/strong>   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   on demand. \u003Ca style=\"color: rgb(107,79,187);\" href=\"https://www.youtube.com/watch?v=py8c6-3zyKM&feature=youtu.be\">Register here\u003C/a>!\u003C/p>\n\n",{"slug":2454,"featured":6,"template":700},"our-secret-to-tackling-thousands-of-open-issues","content:en-us:blog:our-secret-to-tackling-thousands-of-open-issues.yml","Our Secret To Tackling Thousands Of Open Issues","en-us/blog/our-secret-to-tackling-thousands-of-open-issues.yml","en-us/blog/our-secret-to-tackling-thousands-of-open-issues",{"_path":2460,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2461,"content":2467,"config":2471,"_id":2473,"_type":17,"title":2474,"_source":18,"_file":2475,"_stem":2476,"_extension":21},"/en-us/blog/demo-mastering-code-review-with-gitlab",{"title":2462,"description":2463,"ogTitle":2462,"ogDescription":2463,"noIndex":6,"ogImage":2464,"ogUrl":2465,"ogSiteName":686,"ogType":687,"canonicalUrls":2465,"schema":2466},"Demo: Mastering code review with GitLab","Code review shouldn't be a burden, it should make your team better and faster so you can keep delivering new features on time.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670664/Blog/Hero%20Images/code.png","https://about.gitlab.com/blog/demo-mastering-code-review-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Demo: Mastering code review with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2017-03-17\",\n      }",{"title":2462,"description":2463,"authors":2468,"heroImage":2464,"date":2469,"body":2470,"category":14},[2315],"2017-03-17","\nWatch Discussion Lead Sean McGivern demonstrate our typical code review process.\n\n\u003C!-- more -->\n\nWhatever your team’s workflow, we expect you face immense pressure to quickly ship new features. In our [2016 Developer Survey](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html), 81 percent of developers admit to releasing code before it’s ready, citing the pressure of tight or unrealistic deadlines as the reason they release prematurely. To combat this pressure, engineering teams need a process they can repeat every time, so there are no steps skipped during a time crunch. Our code review tools were built with the aim of enhancing your review process, taking you from idea to production while setting new personal records for code delivery speed and quality.\n\n## Demo\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/HagT3a33BA8\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n## Typical flow\n\nExcellent code depends on rigorous review. At GitLab, every change is reviewed using this flow:\n\n* A developer makes a change in their feature branch and tests it. When they’re happy they push, and make a merge request.\n* The developer assigns the merge request to a reviewer, who looks at it and makes line and design level comments as appropriate. When the reviewer is finished, they assign it back to the author.\n* The author addresses the comments. This stage can go around for a while, but once both are happy, one assigns to a final reviewer who can merge.\n* The final reviewer follows the same process again. The author again addresses any comments, either by changing the code or by responding with their own comments.\n* Once the final reviewer is happy and the build is green, they will merge.\n\nTo find out more about the importance of code quality, considerations for teams of different sizes and stages, and details on how we develop at GitLab while using GitLab, [watch our webcast, \"Code Review: A Business Imperative\"](https://www.youtube.com/watch?v=XluG9mAQdSo&feature=youtu.be) on demand.\n\nInterested in GitLab Enterprise Edition? Check out the [features exclusive to\nEE](/pricing/).\n",{"slug":2472,"featured":6,"template":700},"demo-mastering-code-review-with-gitlab","content:en-us:blog:demo-mastering-code-review-with-gitlab.yml","Demo Mastering Code Review With Gitlab","en-us/blog/demo-mastering-code-review-with-gitlab.yml","en-us/blog/demo-mastering-code-review-with-gitlab",{"_path":2478,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2479,"content":2485,"config":2489,"_id":2491,"_type":17,"title":2492,"_source":18,"_file":2493,"_stem":2494,"_extension":21},"/en-us/blog/buffer-and-gitlab-ceos-talk-transparency",{"title":2480,"description":2481,"ogTitle":2480,"ogDescription":2481,"noIndex":6,"ogImage":2482,"ogUrl":2483,"ogSiteName":686,"ogType":687,"canonicalUrls":2483,"schema":2484},"GitLab & Buffer CEOs talk transparency at scale","The two transparency advocates recently met to talk about openness in business, what they keep confidential, and some things they've learned as their companies grow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683999/Blog/Hero%20Images/ee-products-hero-image.jpg","https://about.gitlab.com/blog/buffer-and-gitlab-ceos-talk-transparency","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab & Buffer CEOs talk transparency at scale\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2017-03-14\",\n      }",{"title":2480,"description":2481,"authors":2486,"heroImage":2482,"date":2487,"body":2488,"category":14},[2315],"2017-03-14","\n\nJoel Gascoigne, CEO of [Buffer](https://buffer.com/), a social media management tool, recently met GitLab CEO Sytse (Sid) Sijbrandij on a call to chat about one of their favorite topics: transparency in their respective companies.\n\n\u003C!-- more -->\n\n“I feel like I know you already,” seemed like a sentiment shared by both men, since each has a vast public footprint online. This isn’t an accident, but a result of their shared philosophy that the traditional business’ tendency towards secrecy is not only unnecessary, but at times wrongheaded and even harmful.\n\nBeing open by default has led to unconventional choices. Both companies are remote only, making the impulse to document everything a necessary one for organizational knowledge. After all that effort, it’s a short jump to hit ‘publish,' and teams in both companies have developed a habit of doing so. Buffer has made their financial model predicting the company’s health available to all employees. Their [transparency dashboard](https://buffer.com/transparency) also includes details on equity breakdown by individual, demographics of applicants and employees, pricing, fundraising, and [every email](https://open.buffer.com/buffer-transparent-email/) sent by teammates.\n\nGitLab recently rolled out a [salary calculator](/handbook/total-rewards/compensation/) on our jobs page, and our company [handbook](https://handbook.gitlab.com/handbook/) is entirely public, including details on the [hiring process](/handbook/hiring/) and how we should [respond](https://gitlab.com/gitlab-com/runbooks/merge_requests/194#note_24603440) in the event of a crisis. We recently [live-streamed](https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub) the recovery of deleted production data. Finally, Sid’s monthly email to our board is also sent to all team members, including all the good and the bad from the previous 30 days.\n\nHere are some highlights from their conversation, which, naturally, they wanted to share.\n\n## How do you share salary and career progression info?\n\n**Sid:** We’re early to the salary calculator; we created bands so that engineers can make progress while not becoming a manager. GitLab does not make actual salaries public because raises are based on performance, which is one of the rare things that we tightly guard. This is becoming a challenge because there seems to be uneven progression available on the business and engineering sides; we’re still working on how to create a clear growth path on the business side.\n\n**Joel:** We use a salary formula to calculate each team member's salary. Within the formula we have four levels: Entry Level, Intermediate, Advanced, and Master. In practice, we realized that these various levels left room for bias, and it wasn’t clear how one person might go from “Intermediate” to “Advanced,” for example, so we started thinking about putting together a clear career progression framework throughout Buffer. We're including more explicit definitions and suggesting timeframes to move from one level to another. Our goal is to apply this framework across all teams at Buffer. We have evolved the framework to include levels on the engineering side by designating people as “engineer one, two, three,” etc., and we’re also aiming to provide the same clarity amongst other teams. Our happiness (customer support) and marketing teams are currently working on their career paths as well.\n\n## Which things do you keep categorically confidential?\n\n**Sid:** We never talk about conditions under which people leave the company, and performance feedback is never public. We’re worried about information being damaging to the person when they apply for new jobs and give reference calls. We think it’s unfair because the person cannot share their perspective. It’s hard when a colleague leaves the company and the team is accustomed to total openness, but we think that this is a case where transparency could harm the person who left. They shouldn’t be punished in seeking new opportunities simply because we’re likely more transparent than their new employer. We used to say that the person was on a performance improvement plan (PIP) and it didn’t work, but stopped because PIPs gained a negative connotation. We’re working to replace it with a [proactive, positive way](/handbook/leadership/underperformance/) to help people grow in their roles.\n\n**Joel:** At Buffer, we do share information when people leave the company, but we keep the details of the feedback and performance improvement plan private leading up to that. We experimented with fully transparent feedback for a few months, but it didn’t work out very well. People weren’t keen to give transparent feedback very often. Sharing something potentially sensitive about an area someone can improve in can be difficult to do 1:1, so doing it publicly made things even harder. On the few occasions when someone managed to provide constructive feedback to another teammate, it quickly became a much bigger thing, due to its public nature. Frequently, we had other people jump into the discussion to provide their opinion of the situation, which is only natural if you have full context and feel you have a valuable perspective to offer. Ultimately we decided that fully transparent feedback didn’t quite work for us, though we still publicly celebrate achievements and provide positive feedback in Slack and Discourse.\n\n## How do you talk about company culture?\n\n**Sid:** I recently decided to [stop using the phrase culture fit](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/5182/diffs), because we have to be mindful when building a diverse, accepting company. Often “culture fit” is a shorthand that excuses hiring only people who look like ourselves, or who want a “brogrammer” culture. It’s better to tie to [values](https://handbook.gitlab.com/handbook/values/).\n\n**Joel:** Buffer uses the phrase “cultural contribution,” for similar reasons; we want to focus more on what people bring to their jobs. Do you have a scorecard for assessing different factors?\n\n**Sid:** Not yet. That could be beneficial going forward to see how top performers scored in different areas. During the interview I use 12 questions [on the website](https://docs.google.com/forms/d/e/1FAIpQLScXUW07w36Ob2Y2XQuESBaYqU5_c1SoweGS1BzGHnbesISGXw/viewform) that applicants answer ahead of time. It’s not all qualitative, though. Our technical standards are very high and developers have to actually develop something on GitLab.\n\n## How has your approach been challenged as you grow?\n\n**Sid:** Some pain points for us have been our beloved team calls — it’s a great way to get to know everyone on the team, but our number is so large now it takes a long time. Structuring the team has also been a challenge. We aim to have a maximum of ten people reporting to any one person, but it means we’re getting more segmented. At Y Combinator, everyone was either selling or building, with myself doing everything else. Now I have offloaded finance and business operations on other people, and now I have to stop focusing so much on the product. Now I work with reports to get changes into the handbook, so I have to keep in mind: “You’re building the company that’s building the product.” Having people in so many time zones also means everyone has to stay disciplined about when they ping people: it’s preferred to use issues first, then email, then Slack. For product management we prefer to use GitLab for everything.\n\n**Joel:** At Buffer we’re having some remote work issues. Things are starting to feel more synchronous because we use chat a lot. Something about chat makes it feel urgent, so people are responding right away to things that they might not need to. Buffer uses Dropbox Paper; hierarchy doesn’t really exist so we need more of a wiki system, and we need to be able to distinguish between source of truth docs and docs used for short-term progress.\n\n## Who are some of your biggest inspirations?\n\n**Sid:** Buffer has been an inspiration for transparency. For getting results and going after what your customers need: Amazon. Tesla and SpaceX are great examples of doing the impossible by focusing on the basics. Also, our team members think of new ways to get the most out of remote work: someone recently proposed a GitLab house swap, and two team members used our travel policy [to visit 22 locations over six months](/blog/around-the-world-in-6-releases/).\n\n**Joel:** Amazon is one of mine as well, [\"The Best Service is No Service\"](https://www.amazon.com/dp/B008L047UK/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1) by their head of customer success is great. Zappos, and recently Patagonia as well. I like their attitude towards avoiding the “deferred life plan,” which is a huge benefit of remote work. I recently read [\"Joy at Work\"](https://www.amazon.com/dp/B0027VSQL0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1), by Dennis Bakke, founder of AES. Interestingly, “fun” was a company value, not ping pong tables but really making sure everyone has responsibility and satisfaction at work.\n\n_Have more questions? Tweet [@joelgascoigne](https://twitter.com/joelgascoigne) and [@sytses](https://twitter.com/sytses) using #transparencytalk_\n",{"slug":2490,"featured":6,"template":700},"buffer-and-gitlab-ceos-talk-transparency","content:en-us:blog:buffer-and-gitlab-ceos-talk-transparency.yml","Buffer And Gitlab Ceos Talk Transparency","en-us/blog/buffer-and-gitlab-ceos-talk-transparency.yml","en-us/blog/buffer-and-gitlab-ceos-talk-transparency",{"_path":2496,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2497,"content":2503,"config":2507,"_id":2509,"_type":17,"title":2510,"_source":18,"_file":2511,"_stem":2512,"_extension":21},"/en-us/blog/introduce-continuous-workflows",{"title":2498,"description":2499,"ogTitle":2498,"ogDescription":2499,"noIndex":6,"ogImage":2500,"ogUrl":2501,"ogSiteName":686,"ogType":687,"canonicalUrls":2501,"schema":2502},"3 Tips for introducing continuous workflows to your development process","Continuous doesn’t stop at integration – here's how to use it to your advantage throughout your development process.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671434/Blog/Hero%20Images/introducing-continuous-workflows.jpg","https://about.gitlab.com/blog/introduce-continuous-workflows","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 Tips for introducing continuous workflows to your development process\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2017-03-06\",\n      }",{"title":2498,"description":2499,"authors":2504,"heroImage":2500,"date":2505,"body":2506,"category":14},[998],"2017-03-06","\n\nWe know that developers see [Continuous Integration as an integral part of their workflow](/blog/ci-integral-to-everyday-work/), but working in a continuous manner goes beyond just the technical. Here are some ways your teams can be more continuous throughout the development lifecycle.\n\n\u003C!-- more -->\n\n##  Adopt DevOps\n\nReleases get delayed and broken code gets shipped when communication between teams breaks down and expectations aren’t managed. If this sounds all too familiar, [DevOps might help](/topics/devops/): it’s a set of practices for developing software that emphasises integration and collaboration between teams and sharing responsibility for the outcome. This combats the “silo” mentality that often results in one team completing their portion of a project and passing it on without giving any thought to how the next team will be able to perform their role.\n\nDevOps means working together and keeping each other in the loop throughout the entire software development lifecycle. By updating each other early and often, you can collect feedback regularly and integrate suggestions throughout the process. Below are three ways you can adopt DevOps for your own needs:\n\n### 1. Decentralize your structure\n\nContinuous Integration gives developers immediate feedback that code for a bug fix or new feature has broken the build, and using Git they can discuss and collaborate on solutions. These benefits are negated if they have to wait around for permission to make changes addressing any issues they run into.\n\nReleases are delayed by teams waiting for approval from up top to implement solutions. If they hit a roadblock, teams that are empowered to make their own decisions about how to address it can implement fixes more quickly, reducing the impact on your delivery rates. This is not just true for your developers: teams in other areas of the business can work more efficiently if they’re entrusted with their own troubleshooting.\n\n### 2. Monitor continuously\n\nOf course you want your product to be aligned to your customers’ needs. If you want to improve continuously, you need a consistent stream of feedback to work from. Encourage explicit feedback by inviting your customers to give it, but you can also gather implicit feedback by monitoring behavior with your product and exploring analytics.\n\n### 3. Do it your way\n\nThis isn’t a race, and becoming more continuous can be a gradual process. Find a way of adopting these ways of working that works for you: choose which DevOps elements are suitable for your product and your company, introduce them and monitor how they are working. Treat it much the same way that you would integrate feedback about your product continuously and release incremental changes.\n\n\n\n\n\u003Cp class=\"alert alert-orange\" style=\"background-color: rgba(252,163,38,.3); border-color: rgba(252,163,38,.3); color: rgb(226,67,41) !important; text-align: center;\">Watch our   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>   \u003Cstrong>From Continuous Integration to Continuous Everything\u003C/strong>   \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n  webcast. \u003Ca style=\"color: rgb(107,79,187);\" href=\"https://page.gitlab.com/20170301_continuouseverything.html\">Register here\u003C/a>!\u003C/p>\n\nImage: “[Blue Loops](https://www.flickr.com/photos/drainrat/14017306767)” by [darkday](https://www.flickr.com/photos/drainrat/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/)\n{: .note}\n",{"slug":2508,"featured":6,"template":700},"introduce-continuous-workflows","content:en-us:blog:introduce-continuous-workflows.yml","Introduce Continuous Workflows","en-us/blog/introduce-continuous-workflows.yml","en-us/blog/introduce-continuous-workflows",{"_path":2514,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2515,"content":2521,"config":2526,"_id":2528,"_type":17,"title":2529,"_source":18,"_file":2530,"_stem":2531,"_extension":21},"/en-us/blog/set-expectations",{"title":2516,"description":2517,"ogTitle":2516,"ogDescription":2517,"noIndex":6,"ogImage":2518,"ogUrl":2519,"ogSiteName":686,"ogType":687,"canonicalUrls":2519,"schema":2520},"Set expectations, manage better","Creating overhead with meetings and reviews is a risk to the efficiency and remote culture of organisations and should be actively avoided for an organisation to succeed remote at scale.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683955/Blog/Hero%20Images/set-expectations-manage-better.jpg","https://about.gitlab.com/blog/set-expectations","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Set expectations, manage better\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2017-01-03\",\n      }",{"title":2516,"description":2517,"authors":2522,"heroImage":2518,"date":2524,"body":2525,"category":14},[2523],"Job van der Voort","2017-01-03","\n\nWith GitLab Inc growing to [more than 150 people](/company/team/) working remotely and\nsteadily increasing, inevitably new challenges come up while building great\nsoftware.\n\n\u003C!--more-->\n\nWe never shied away from [hierarchy](/company/team/structure), but recently I’ve been\nnoticing a trend towards more traditional people management in an effort to\nmaintain focus on shipping at scale.\n\nI believe that creating overhead with meetings and reviews is a risk to the\nefficiency and remote culture of organisations. It should be _actively_ avoided\nfor an organisation to succeed remote at scale.\n\n## More people, less productivity\n\nWhen a team grows from five to 30 to 100 people, some parts of the\nteam will fail at some point: be that in the form of missing a deadline or not\ndelivering quality work.\nOf course, larger organisations want to solve this permanently. If there\nalready is an established hierarchy, it’s likely that the managers of the\nfailing team will ask themselves:\n\n> How could we have seen this earlier?\n\nA senior manager will think back to the old days when everyone was\nperforming well as a small team.\n\nNow, reader, how would you solve this? Obviously this was an oversight by\nmanagement: they should’ve seen this earlier. The suggested solution might be to improve or\ncreate a reporting structure where management reviews the status of projects\nand teams more frequently.\nIn addition, management should have more frequent meetings in order to review\nthe status of the teams and handle these if necessary.\n\nThis is where productivity goes down significantly and remote culture is in\ndanger.\n\n## Solution: Set clear expectations\n\nReviewing work in progress both directly, and indirectly through meetings is a\nwaste of time.\n\n> Q: But what happens if things go off the rails? How will I know? Who will handle it?\n>\n> A: Trust your people.\n\nYou must set clear expectations for any and all work. These expectations should\ninclude a clear scope, time of delivery, but more importantly: communication\nexpectations.\nCommunication expectations are easily outlined:\n\n- I expect that you will let me know immediately if you think that this deliverable will not make the deadline.\n- I expect that if you have doubts about the feasibility, functionality, scope, or outline of this deliverable, you will let me know.\n- I expect that if you need help from colleagues, you will contact them and ensure their collaboration. If you get stuck with this, I expect you to communicate this to me.\n\nNow this seems a little verbose – maybe it is, but it makes it very clear\nwhat is expected of those responsible. It even seems very obvious, but now that\nwe wrote this down, do the additional reviews and reports still make sense?\n\n## Doing this remotely\n\nDoing all of this remotely adds a layer of complexity. We’re fighting with two\nparadoxical goals: we want to maintain a single source of truth, and we want to be able to give a sense of urgency when working with deadlines, to be able to maintain a certain pace.\n\nIn practice this means that everyone is expected to over-communicate. For\nexample, I might say in a GitLab issue to Sytse that our rocket engine won’t\nmake it in time for the planned launch date, but because I know he’s way behind\non email and Todos, I’ll also send him a message in chat.\n\nFor remote teams, such as our own, I’d add another expectation:\n\n- I expect _you_ to make sure that other parties you communicate with are actually reached.\n\nThis means sometimes you’ll have to ask someone else if Jane is absent or\nsend her another message on chat if she doesn’t reply within a reasonable\ntime.\nFrom personal experience, being a little more pushy and impatient than you’d be\nin everyday life is enormously beneficial to this end.\n\nOver-communicating is a small cost to pay for the freedom of working remotely.\n\n## At GitLab\n\nI wrote this as a response to observations I made at GitLab. That said,\nit already was a company policy to look specifically for people who\nmanage themselves. This is [what we write in our handbook on this topic](/handbook/leadership/):\n\n> We don't have project managers. Individual contributors need to manage themselves. Not everyone will be able to do this effectively and be fit for our organization. Making someone responsible for managing others will make the job of the people who can manage themselves worse. If you manage yourself you have a much greater freedom to make decisions, and those decisions are based on deep knowledge of the situation. We want to retain the people who can handle that responsibility and therefore we can't retain the ones that struggle. Assigning a project manager/coordinator/case manager/etc. to something is an indicator that something is wrong and we are picking the wrong solution.\n\nWe write these and other lessons in our single source of truth,\n[our handbook](https://handbook.gitlab.com/handbook/). Like (almost) everything at GitLab, our handbook is\nopen source and you're welcome to read it and contribute to it.\n",{"slug":2527,"featured":6,"template":700},"set-expectations","content:en-us:blog:set-expectations.yml","Set Expectations","en-us/blog/set-expectations.yml","en-us/blog/set-expectations",{"_path":2533,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2534,"content":2540,"config":2544,"_id":2546,"_type":17,"title":2547,"_source":18,"_file":2548,"_stem":2549,"_extension":21},"/en-us/blog/how-to-keep-remote-teams-engaged",{"title":2535,"description":2536,"ogTitle":2535,"ogDescription":2536,"noIndex":6,"ogImage":2537,"ogUrl":2538,"ogSiteName":686,"ogType":687,"canonicalUrls":2538,"schema":2539},"How to keep remote (volunteer) teams engaged","Our Director of Strategic Partnerships chats about remote engagement challenges at a charity that encourages kids to get interested in space, finding interesting parallels with open source projects.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670694/Blog/Hero%20Images/how-to-keep-remote-teams-engaged-cover.jpg","https://about.gitlab.com/blog/how-to-keep-remote-teams-engaged","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to keep remote (volunteer) teams engaged\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2016-12-21\",\n      }",{"title":2535,"description":2536,"authors":2541,"heroImage":2537,"date":2542,"body":2543,"category":14},[2315],"2016-12-21","\n\nWe love hearing when people outside of GitLab read our [Handbook](https://handbook.gitlab.com/handbook/) – it's totally public, after all, and it's pretty comprehensive (or a behemoth, depending on your frame of mind). It was even more exciting to hear from James Telfer, of [UK Students for the Exploration and Development of Space](http://ukseds.org/) (UKSEDS) that he read the handbook and had further questions that we'd left unanswered. In particular – what to do when you have neither carrot nor stick when managing remote volunteers?\n\n\u003C!--more-->\n\nUKSEDS, a student-run charity that operates around the UK, offering career advice and skills support to students interested in the space industry, borrowed a lot from our handbook when making their constitution.\n\nThe internal engagement problem grew after UKSEDS experienced a growth surge and a structural change earlier this year. Specifically, James said:\n\n> _Project teams are interacting okay with their direct managers but interaction with the wider organization is little to none. While this doesn't directly impact work, we're concerned about the longer-term impact on volunteer enjoyment and retention, both of which are really important to us._\n\nEliran Mesika, our Director of Strategic Partnerships, agreed to jump on the phone with James to learn more about UKSEDS' particular case and the challenges they faced.\n\nHere are some highlights:\n\n- Having individual responsibilities somewhere public (even internally) is a useful accountability tool, and helps direct team members to the correct person when they have a question.\n- Functional group updates presented to the whole company make teams talk more, which results in more organic collaboration.\n- Keeping communication on a specific topic within the right issue is essential for keeping everyone on the same page – especially when working asynchronously.\n\nRead on for Eliran's tips.\n\n**James:** Our work involves hosting skills workshops and conducting outreach, which means traveling to schools and science fairs to tell kids that space is great and they should get involved. We recently restructured by creating a small executive group that meets every week, and allowing volunteer teams to grow larger and meet less frequently. We found that destroyed our ability to connect with the teams and we've started losing people; we've got quite a high attrition rate, which is normal for a charity. But I wondered how you approached this problem? Some of those things like the random Hangouts and the 1:1 chats work great as long as you can pay people for their work time. But with volunteers it's a different problem entirely.\n{: .alert .alert-info}\n\n**Eliran:** I'm actually working with Drupal, and I think your problem is more similar to an open source project, or an open source community behind a project. There is a major difference between volunteers and people who are being paid. Once you're paying someone, you have their attention. Perhaps learning what open source projects do to engage their contributors may be helpful in your case. For now, I can share a bit about what we're doing to keep people engaged and connected to the mission.\n\nWe're an open core product, and since its inception the whole behavior and culture of the company has also been open. This extends to everything the company does: from the very technical details of a new feature that is being repaired or created, all the way to our high priorities and strategy, and the actual procedures the company follows, is documented and publicly shared. It is shared within the whole company, and is available all the time.\n\n**James:** How does that culture extend to individual responsibilities?\n{: .alert .alert-info}\n\n**Eliran:**\nExpectations and responsibilities are also public. I handle strategic partnerships, and it's pretty much just me doing this, but I can look at what anyone on our whole team is working on, without even having to ask them directly. On our team page, we have everyone's job description linked, along with any specific responsibilities. So if you have frontend developers, maybe one is responsible for the website, and others are responsible for a particular set of features of the community edition, for example. You can understand at a glance who the right person is for what you're interested in, and you can go into any repo and see what they're working on. For the most part when we're talking about procedures, we have the Handbook which describes everything about the administration and culture of the company. It goes into detail even about how to write a shared document that you work on. It also talks about what we do on a regular basis.\n\n**James:** Can you elaborate a bit on those routine things, like the daily calls?\n{: .alert .alert-info}\n\n**Eliran:** Our daily calls have worked really well for us. They're optional, but we usually get maybe two-thirds of the company joining each day. We have functional updates, where we've divided teams into the various days of the week, and they give an update on what they've completed over the past few weeks, which gives the whole company insight into what the marketing team is doing, what the CI team is doing, and what they're working on next. It really connects you with the whole scope, rather than just seeing your team's goals and your individual goals in a vacuum.\n\n**James:** So that's using what other people are doing to remind an individual person or team that the greater company exists – it's not so much that they'd be interested in the technical details, but it reminds them they're part of something bigger? Is that the key there?\n{: .alert .alert-info}\n\n**Eliran:** Yeah I think it's very important to give people insight into what other teams are doing, because it's remote. That's really key. Otherwise, it seems like when people are working remotely it's very easy to feel isolated. Having those functional updates forces you out of isolation and connects you with the bigger goal. And on a personal level, it connects you with other people's work. As you said, even if you're not a technical person, you'll still get a high-level understanding of the product or what the objective was. That's great for creating a more cohesive environment, and it's remained the same since I joined.\n\n>It's very important to give people insight into what other teams are doing – having functional updates forces you out of isolation and connects you with the bigger goal\n\nWe also have a second part of the call where people share what they did last weekend. So once a week you have an opportunity to talk about your personal life, we rotate so everyone shares their experiences. I think that's a very powerful tool to connect on a social level, even if you're not talking with people on a regular basis. Typically you're working with a team of 5-10 people, and you'll be part of a group that's maybe 30 people. So at best you'll know 30 people, and you won't talk to them on a regular basis. You know the regular few people that you talk to, and I think that's very narrow if you're part of a bigger group. But the way that we do these individual stories helps make everyone feel closer.\n\n**James**: I can see one definite scope for improvement for us, because we haven't been very good at pulling the teams together. They're sort of sandboxed at the moment.\n{: .alert .alert-info}\n\n**Eliran;** I think you'll notice that once teams start talking about what they're doing, obviously all teams have touch points that they've been speaking with others about, but you'll have more organic collaboration. Just by talking about what they're thinking about doing, or trying to do. That's the best case scenario. At the most basic level, you'll get people to be aware of what's going on.\n\nWe also have a second type of meeting, which is an open meeting focused on a certain department or area. We have a kick-off meeting for a product, or for example we have a monthly release cycle, and anyone can come to those meetings to learn more about what's going on. Our marketing team also has those meetings for example, to talk about new efforts and past performance.\n\n**James:** How else do people reach out to work together?\n{: .alert .alert-info}\n\n**Eliran:** We use Slack for communication, and I'm not sure how that would work in an environment like yours, without volunteers dedicating a certain amount of time every day. But we have channels for everything, and the whole team is distributed across channels. We have #whats-happening-at-gitlab, which is the channel Emily used to ask \"Hey is there anyone relevant who'd like to help James and talk about remote work at his organization?\" We also have a #questions channel, where anyone can ask anything from the most sophisticated to the stupidest. They just throw their question to the channel and people try to help them or steer them in the right direction for who to talk to. Another channel that's really important is the #thanks channel, and I feel that's an important part to offer gratitude to someone for helping you, and also receive that when you've helped someone. Because of the remote environment it's very powerful. Because GitLab's culture is built on asynchronous work – people in different time zones – you're not on Slack all the time because others will pick up your question whenever they become available.\n\nOne other thing that's working well is centralizing a process for working asynchronously. So, we try to make all the work and communication and discussion on GitLab by using issues. Someone will create an issue with a particular task or mission, and then the whole communication is available there. So people have access to information or decisions or a process on a specific area. Even if you're not involved, you can comment and say, \"Hey I'd like to suggest a, b, c.\" So by virtue of being in different time zones, we were forced to use asynchronous methods of work, and issues work very well for that. Having the discussion tools integrated into that, and using it to keep everything in one work space dedicated to a specific topic, is great for remote teams. If you can't always set a time for everyone to sit down together, using issues is crucial to making work happen.\n\n**James:** We do use Slack, because, as you may recall as a student you may as well be in different time zones, waking up at 9 am one day and 1 pm the next. Are there decisions made on Slack, or do you tell people, \"No this is a discussion, take it to x issue\"?\n{: .alert .alert-info}\n\n**Eliran:** We may have those specific discussions on Slack, but for the most part, maybe 95% of the decisions are happening within the issue. But we don't discourage people from talking, so there could be times when you have to talk to someone or a group of people, because there's only so much you can do over text. So you may make a decision over Hangout, but that is communicated back through the issue. Someone will go back and say \"I had a discussion with Mark, and we decided the best way to move forward is x.\" That way everyone has the opportunity to get the takeaways from that meeting and give input. So some decisions happen away from the issues. But it's important to reinforce that we try to keep communication on a specific topic within an issue. We really push that, and it's part of the culture at GitLab. As you keep growing, the sooner you adopt changes in a working culture, the better it is for people to learn them later on.\n\n\nRead more about [how we stay connected as a remote company](/blog/how-we-stay-connected-as-a-remote-company/).\n\n_Tweet us [@GitLab](https://twitter.com/gitlab) and check out our [job openings](/jobs/)._\n\n\u003C!-- cover image: https://www.pexels.com/photo/people-coffee-meeting-team-7096/ -->\n\n\u003C!-- cover image license: CC0: https://www.pexels.com/photo-license/ -->\n",{"slug":2545,"featured":6,"template":700},"how-to-keep-remote-teams-engaged","content:en-us:blog:how-to-keep-remote-teams-engaged.yml","How To Keep Remote Teams Engaged","en-us/blog/how-to-keep-remote-teams-engaged.yml","en-us/blog/how-to-keep-remote-teams-engaged",{"_path":2551,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2552,"content":2558,"config":2562,"_id":2564,"_type":17,"title":2565,"_source":18,"_file":2566,"_stem":2567,"_extension":21},"/en-us/blog/how-we-stay-connected-as-a-remote-company",{"title":2553,"description":2554,"ogTitle":2553,"ogDescription":2554,"noIndex":6,"ogImage":2555,"ogUrl":2556,"ogSiteName":686,"ogType":687,"canonicalUrls":2556,"schema":2557},"How we stay connected as a remote company","Open communication and strong relationships are key to our company culture – here's how we achieve these remotely","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684130/Blog/Hero%20Images/how-we-stay-connected-as-a-remote-company-globe.jpg","https://about.gitlab.com/blog/how-we-stay-connected-as-a-remote-company","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we stay connected as a remote company\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2016-12-05\",\n      }",{"title":2553,"description":2554,"authors":2559,"heroImage":2555,"date":2560,"body":2561,"category":14},[998],"2016-12-05","\n\nGitLab is a remote-only company, which means we have the freedom to live where we choose and work from anywhere. This flexibility is one of the reasons why it’s great to work at GitLab, but working remotely can be isolating. So how do we build a company culture when we’re all so scattered?\n\n\u003C!-- more -->\n\n## Team calls\n\nAlmost every day we have a [team call](https://handbook.gitlab.com/handbook/communication/#team-call), not just for company updates but to take it in turns filling in the rest of the team about what we’ve been up to that weekend. I’ve been given a tour of team members’ new houses, admired their Christmas decorations, squealed when their pets and kids make an appearance and watched them preparing dinner – glimpses into the personal lives of my colleagues that I’ve never had in any office job. I’ve worked at companies where I didn’t know the names of anyone who worked on a different floor. \"There are no floors at GitLab,\" Douwe said to me on a call, and it's true both literally and metaphorically. Because you’ve chatted with everyone on team calls, everyone feels approachable.\n\n## Coffee break calls\n\nWe also have regular one-on-one chats that can be about anything (as long as it’s not work!). Acknowledging that we don’t have a water cooler around which to gather, we make time for shooting the breeze online instead. And it’s kind of cool to have my [coffee break](/company/culture/all-remote/informal-communication/#coffee-chats) with someone on the other side of the world, in an entirely different time zone or season.\n\n## Summits\n\nOf course, nothing beats getting to know your team in person, which is why we get together every nine months for the [GitLab summit](/company/culture/). So far we’ve met up in Amsterdam and Austin, and in January we’ll be heading to sunny Cancun for a week to work and play together.\n\n![GitLab Austin summit](https://about.gitlab.com/images/blogimages/Gitlab-summit-Austin.jpeg)*The GitLab summit in Austin, May 2016*\n\n## Meet-ups\n\nWorking remotely means you can take your office anywhere – and that’s exactly what some of the team has done. Douwe and Robert are currently on an epic 6-month World Tour, working from 13 different countries and meeting up with other team members in Mexico City, Edinburgh, Warsaw, Tel Aviv and more. Working together even for just short bursts builds our relationships so that even when we’re working independently, we feel more connected and in tune with each other. Douwe and Robert’s adventure has even inspired others to travel while working, joining team members along the way.\n\n![GitLab Edinburgh](https://about.gitlab.com/images/blogimages/gitlab-edinburgh.jpg)*The unofficial GitLab Edinburgh office*\n\n\nLike the sound of how we work together at GitLab? Come work with us! Check out our [job openings](/jobs/).\n",{"slug":2563,"featured":6,"template":700},"how-we-stay-connected-as-a-remote-company","content:en-us:blog:how-we-stay-connected-as-a-remote-company.yml","How We Stay Connected As A Remote Company","en-us/blog/how-we-stay-connected-as-a-remote-company.yml","en-us/blog/how-we-stay-connected-as-a-remote-company",{"_path":2569,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2570,"content":2574,"config":2578,"_id":2580,"_type":17,"title":2581,"_source":18,"_file":2582,"_stem":2583,"_extension":21},"/en-us/blog/working-at-gitlab-30-days-later",{"title":2571,"description":2571,"ogTitle":2571,"ogDescription":2571,"noIndex":6,"ogImage":896,"ogUrl":2572,"ogSiteName":686,"ogType":687,"canonicalUrls":2572,"schema":2573},"Working at GitLab - 30 days later","https://about.gitlab.com/blog/working-at-gitlab-30-days-later","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Working at GitLab - 30 days later\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Clement Ho\"}],\n        \"datePublished\": \"2016-11-03\",\n      }",{"title":2571,"description":2571,"authors":2575,"heroImage":896,"date":2576,"body":2577,"category":14},[1993],"2016-11-03","\n\nMuch like [Emily von Hoffmann](https://twitter.com/emvonhoffmann), I too recently finished my first month at GitLab. I started contributing regularly to GitLab in July, so although I've only been employed for a month, I feel like I've been here for several months. Most of my takeaways after this first month is primarily based on the company culture since I already had prior exposure to the product.\n\n\u003C!-- more -->\n\n## The Wow Factor\n\nOne of the most impressive part of the GitLab culture is it's efficiency. Although it is listed as a value, I did not expect it to be so pronounced. Monthly releases for GitLab CE and EE is just the tip of the iceberg of how much this team can accomplish in a short amount of time. I was amazed at how everything was ready for me before my first day of work. My GitLab email, my slack account, my swag codes and many onboarding items were all set up a few days after I signed my offer letter. I even had my business cards before I started my first day and got to hand them out to my coworkers before I left my previous company!\n\nThe efficiency of the team paired with the fact that everyone is so talented at what they do, truly creates an incredibly productive environment. I cannot agree more with [general guideline #1](https://handbook.gitlab.com/handbook/):\n\n> Working at GitLab Inc. is cooperating with the most talented people you've ever worked with, being the most productive you'll ever be, and creating software that is helping the most people you've ever reached.\n\nIn less than a week of me working at GitLab, I collaborated with other team members and shipped the first iteration of a new feature, the [compensation calculator](https://handbook.gitlab.com/job-families/engineering/backend-engineer/#compensation) ([!3418](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/3418)). That's the fastest progress I've ever encountered in all the companies and internships I've experienced.\n\n## Work-Life Balance\n\nUnfortunately this wow factor also cultivates a dark side. In a startup culture that is so focused, moving so fast and rewards results (all of which are good), it can be easy for me to continue working through lunch or after work. I enjoy working at and on GitLab which makes this all the more difficult (also a good thing). From time to time, it gets very tempting for me to put in extra work during my spare time. Although I know that working continually is only appealing in the short run and unsustainable in the long run, I've had to take extra steps to be more disciplined in this area.\n\nAs of a few weeks ago, I've started to block off my lunch time on my calendar. I tend not to prioritize what I need to do until it is on my schedule, so this helps me discipline my time. This may not work for everyone, it definitely keeps me in check.\n\nIn light of all this, it is reliving that the team at GitLab is very supportive of a [healthy work life balance](/company/culture/all-remote/) and will do all they can to make sure everyone is well taken care of. After all, why else would they ask you to take a [minimum of 2 weeks off](/handbook/paid-time-off/) a year for vacation.\n\nOverall, this first month working at GitLab has been a blast. Working on something that impacts many organizations and has a clear [strategic vision](/company/strategy/) is an absolute thrill. If you think you have what it takes to be a GitLab team-member, check out our [job openings](/jobs/).\n",{"slug":2579,"featured":6,"template":700},"working-at-gitlab-30-days-later","content:en-us:blog:working-at-gitlab-30-days-later.yml","Working At Gitlab 30 Days Later","en-us/blog/working-at-gitlab-30-days-later.yml","en-us/blog/working-at-gitlab-30-days-later",{"_path":2585,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2586,"content":2592,"config":2596,"_id":2598,"_type":17,"title":2599,"_source":18,"_file":2600,"_stem":2601,"_extension":21},"/en-us/blog/three-things-i-learned-in-my-first-month-at-gitlab",{"title":2587,"description":2588,"ogTitle":2587,"ogDescription":2588,"noIndex":6,"ogImage":2589,"ogUrl":2590,"ogSiteName":686,"ogType":687,"canonicalUrls":2590,"schema":2591},"3 things I learned in my first month at GitLab","Adapting to life at GitLab--marketing edition!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663743/Blog/Hero%20Images/three-things-i-learned-in-my-first-month-at-gitlab.jpg","https://about.gitlab.com/blog/three-things-i-learned-in-my-first-month-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 things I learned in my first month at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2016-11-02\",\n      }",{"title":2587,"description":2588,"authors":2593,"heroImage":2589,"date":2594,"body":2595,"category":14},[2315],"2016-11-02","\n\nI rang in my first month at GitLab in spectacular fashion, by meeting up with team members for our NYC [World Tour](/blog/world-tour-amplify-your-code/) stop. The only real surprise in meeting team members in person — after weeks of daily Hangouts — is height (hopefully by force of my personality, several people remarked they thought I’d be taller.) Here are some other big takeaways from my time here so far.\n\n\u003C!-- more -->\n\n## MVC applies even to marketers\n\nThe product team at GitLab lives and breathes the principle of [“Minimum Viable Change”](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) (MVC). This meant nothing to me in my day-to-day as a writer and marketer, until I joined GitLab and got an engineer as my team lead. We don’t apply the exact same language and principles to our content projects, but I believe that the spirit of MVC still informs our work. For example, our team lead Sean [explained](/blog/how-we-ship-so-quickly/) his simple test for reviewing our merge requests — he asks himself, “is this better than what was here before?” If the answer is ‘yes’, it gets approved. We now operate with the attitude that it’s better to jump in and do the work, than ask for approval, which not only makes us faster but increases our sense of agency over projects. We don’t need to establish consensus among innumerable team members before making a documentation or handbook update live on the site; if someone thinks of an improvement, they create a subsequent merge request, and the same rule applies. This feels like a radical way for a team of writers to work, but so far it’s all upside.\n\n## Feedback flows thick and fast\n\nBecause we work remotely and with relentless transparency, it occasionally happens that an issue thought to be uncontroversial develops an accordion-like comment section. We have team members in [34 countries](/company/team/), with a vast range of first languages, professional backgrounds, and experience levels, but the same intense drive to make GitLab better every day. I quickly learned to never read into perceived “tone” online, because nearly 100 percent of the time, questions are asked in earnest by team members and users who want to be sure they understand. By the time I experienced this, Sytse our CEO had armed me with a mantra for just such an occasion, and I repeat it to myself with abandon: *“If you’re getting feedback you’re doing it right...if you’re getting feedback you’re doing it right...if you’re getting feedback you’re doing it right.”* As a new employee, this also empowers me to chime in with my own questions, and I trust that my team members will always let me know how I’m doing.\n\n## Intimidation is your only enemy\n\nThe first (open) secret I learned during my time here is that learning Git basics is pretty easy. Checking out a new branch, tracking a file, committing changes, pulling from and pushing to the origin – these are the only functions I needed to master to do routine marketing tasks, and they became no problem after a day or two. Every non-technical person at GitLab could likely write a similar story about trepidation and triumph, because we have to successfully apply these commands to complete our [onboarding](/handbook/people-group/general-onboarding/) process. I haven’t since experienced the level of apprehension I felt when I opened up the terminal on my first day; the same applies to when I created my first issue and puzzled through the norms of our [workflow](https://docs.gitlab.com/ee/topics/gitlab_flow.html). It’s also really true that gamifying anything is an awesome way to learn (my favorite right now is [ShortcutFoo](https://www.shortcutfoo.com/app/dojos/git).) This is not to disrespect the amazing work the developers on our team do; myself and another team member are starting to learn Ruby, and I’m sure I’ll have complicated feelings to report on that later.\n\nUntil then, git at us on [Twitter](https://twitter.com/gitlab?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor), check out our [job openings](/jobs/), or add to our [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues).\n",{"slug":2597,"featured":6,"template":700},"three-things-i-learned-in-my-first-month-at-gitlab","content:en-us:blog:three-things-i-learned-in-my-first-month-at-gitlab.yml","Three Things I Learned In My First Month At Gitlab","en-us/blog/three-things-i-learned-in-my-first-month-at-gitlab.yml","en-us/blog/three-things-i-learned-in-my-first-month-at-gitlab",{"_path":2603,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2604,"content":2609,"config":2614,"_id":2616,"_type":17,"title":2617,"_source":18,"_file":2618,"_stem":2619,"_extension":21},"/en-us/blog/how-we-ship-so-quickly",{"title":2605,"description":2606,"ogTitle":2605,"ogDescription":2606,"noIndex":6,"ogImage":896,"ogUrl":2607,"ogSiteName":686,"ogType":687,"canonicalUrls":2607,"schema":2608},"My first weeks at GitLab: How we ship so quickly","How we move so quickly and create so much at GitLab","https://about.gitlab.com/blog/how-we-ship-so-quickly","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"My first weeks at GitLab: How we ship so quickly\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sean Packham\"}],\n        \"datePublished\": \"2016-10-24\",\n      }",{"title":2605,"description":2606,"authors":2610,"heroImage":896,"date":2612,"body":2613,"category":14},[2611],"Sean Packham","2016-10-24","\n\nAbout two months ago I joined GitLab and in that time I have seen two new releases,\nhad the quickest and smoothest team onboarding I have ever had,\npushed dozens of changes and\nhave gotten to know almost everyone in GitLab.\nSo how do we move and ship so quickly at GitLab?\n\n\u003C!-- more -->\n\n## 1. Communication\n\nAt GitLab we are a [remote-only](http://remoteonly.org/) company which means communication is essential.\n\n### The GitLab Handbook\n\nWe have to diligently record and document knowledge to be efficient.\nThe result is if you ask any GitLab team-member an organizational question\nthe answer is always \"It's in the handbook.\"\nOur [handbook](https://handbook.gitlab.com/handbook/) is public, copy it, adapt it and make it your own.\n\n> \"It's in the handbook\" - Everyone who's been at GitLab for more than two weeks\n\n### Reporting\n\nSid, our CEO, believes everyone deserves only one manager to report to\nso that they easily know what needs to be done.\nWant to know how GitLab is structured?\nTake a look at our [team page](/company/team/) and\n[organizational chart](/company/team/structure/org-chart/).\n\n> \"Everyone deserves only one manager\" - Sid Sijbrandij (CEO)\n\n### Meetings\n\nAt GitLab we have a number of essential meetings mostly for keeping up-to-date\nwith teams and getting to know everyone:\n\n- Weekly or biweekly one-on-one meetings with your manager\n  to align priorities and get guidance.\n- Weekly standups with your immediate team to review what was done and what is next.\n- Monday to Thursday team call with everyone at GitLab to receive important updates\n  and get to know the team by sharing stories of what we did the past weekend.\n- One-on-one coffee break calls to get to just have a chat.\n\nHearing what other team members did on their weekends and sharing my stories\nhas been an extremely valuable experience. In a matter of weeks I have gotten\nto know most of the team quicker than anywhere else I've worked.\nI hear personal stories from people in all departments where normally\npeople tend to socialize within their department.\n\n## 2. Focus\n\nMy team and I were fortunate to get a lot of time\nwith Sid during my first few weeks at GitLab and\nSid gave us the following simple productivity steps:\n\n1. Pick the next smallest thing you need to do.\n1. Don't over engineer for a future that might not exist.\n1. Don't do massive restructures (do step 1.)\n1. If it is better than what is there, merge it!\n\nOver my years in software development I have notice that people\nover discuss ideas instead of acting.\nAt GitLab each person knows what their objectives are because they have only one manager,\nthis means individuals can own their work, make the change and then discuss it.\nThe smaller the change, the less discussion there will be and then move to step 4 - merge it!\n\n## 3. Iteration\n\nThe final thing that ties together our communication and focus is iteration.\nGitLab has always shipped a new version on the\n22nd of every month no matter the day of the week.\n\n> I think that Gitlab already took a part of the market from Github and\n  that this progression is going to continue thanks to the\n  incredible rate at which the product is developed.\n  The existing features and the ones that are coming are\n  going to make Gitlab an even more central tool than it is today.\n  It is probable that, in a few months, we will not need\n  anything more than Gitlab to manage the whole lifecycle of a project. - Théo Chamley\n  [MrTrustor's Shiny Blog: Gitlab's Master Plan](http://blog.mrtrustor.net/post/gitlab-grand-master-plan/)\n\nIterations is so important to us that we built\n[Cycle Analytics](/solutions/value-stream-management/) to\nallow anyone to measure how long it takes them to get from [Idea to Production](https://www.youtube.com/watch?v=t_rB1oQdG98),\nwith GitLab its a matter of minutes!\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/t_rB1oQdG98\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003Cbr>\n\nIf you would like to be part of the GitLab team and\ncontribute to our culture and tools take a look our\n[jobs page](/jobs/).\n",{"slug":2615,"featured":6,"template":700},"how-we-ship-so-quickly","content:en-us:blog:how-we-ship-so-quickly.yml","How We Ship So Quickly","en-us/blog/how-we-ship-so-quickly.yml","en-us/blog/how-we-ship-so-quickly",{"_path":2621,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2622,"content":2628,"config":2633,"_id":2635,"_type":17,"title":2636,"_source":18,"_file":2637,"_stem":2638,"_extension":21},"/en-us/blog/gitlab-in-action",{"title":2623,"description":2624,"ogTitle":2623,"ogDescription":2624,"noIndex":6,"ogImage":2625,"ogUrl":2626,"ogSiteName":686,"ogType":687,"canonicalUrls":2626,"schema":2627},"GitLab in Action","GitLab team-members on the road!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684165/Blog/Hero%20Images/map.jpg","https://about.gitlab.com/blog/gitlab-in-action","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab in Action\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily Kyle\"}],\n        \"datePublished\": \"2016-08-24\",\n      }",{"title":2623,"description":2624,"authors":2629,"heroImage":2625,"date":2631,"body":2632,"category":14},[2630],"Emily Kyle","2016-08-24","\n\nA huge part of the company [culture] at GitLab is the fact that we are fully remote.\nWe have no hub; Google Hangouts are at our core and we are thriving on this model.\n\nWorking remotely affords so many opportunities that being tied to an office never could.\nFor one, you get back the time you used to spend commuting. Some use this extra time to\nsleep, be with their families, work out, practice their craft, or just relax.\nWe still have a daily team call, but it can just happen with pajama pants on! 😃\n\n\u003C!-- more -->\n\nTwo of my coworkers, whom I think are really excelling at this remote work thing,\nare [Robert] and [Douwe]. They won’t promote their awesomeness so I have to.\nThey have set out to meet other GitLab team-members in 12 different countries for the next\n6 months. They are calling it, “Around the World in 6 Releases”.\n\n![Nashville Bowling](https://about.gitlab.com/images/blogimages/gitlab-in-action/nashville_work.jpg)\n\nEvery week or two they head to a new city, spend the weekdays working, the evenings with\nthe local team members, and the weekends sightseeing. I had the pleasure of meeting up\nwith them on a leg of their North America tour.\n\n## Nashville\n\nSomething to note about them - they would rather work than go to the country music hall\nof fame with me. They would also rather make me eat all the fried bologna sandwiches\nand moon pies than participate.\n\nNashville is such a welcoming, lively city. We honkey tonked, Douwe had his first tater tot,\nand we worked from a bowling alley that also had a swimming pool and served some damn good coffee.\n[John] made sure we celebrated National Mac and Cheese Day right with some Hot Hattie B’s Mac\ntopped with their famous hot chicken. When they couldn’t take any more of me leaving Dolly Parton\non repeat, they put on Kimmy Schmidt and pretended to go to sleep.\n\n![Nashville Bowling](https://about.gitlab.com/images/blogimages/gitlab-in-action/nashville.jpg)\n\n## Denver\n\n[Drew] braved a turbulent flight from Nebraska to join us in Denver, where locals [Josh] and [Phil] were determined to show us the best the city had to offer.\nThey tried to take us to a Rockies game, which unfortunately was rained out. We made the best of it\nby going to a local developer meetup. Phil and Josh welcomed us to their local WeWork and once\nwe needed a change of scenery we moved to the bar downstairs, where we were shockingly productive,\nconsidering we were working from a brewery.\n\n![Denver Meetup](https://about.gitlab.com/images/blogimages/gitlab-in-action/denver.jpg)\n\n## Salt Lake City\n\nI had to go home to get clean clothes, but they reported Utah was filled with natural beauty.\nTheir highlight was getting to meet and go to dinner with a local GitLab user [Gabe Gunderson].\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Honored to host these \u003Ca href=\"https://twitter.com/gitlab\">@gitlab\u003C/a> ers. Cool guys making a difference in the corporate and open-source worlds. \u003Ca href=\"https://twitter.com/hashtag/gitlab?src=hash\">#gitlab\u003C/a> \u003Ca href=\"https://t.co/nBJ5plVJMa\">pic.twitter.com/nBJ5plVJMa\u003C/a>\u003C/p>— Gabriel Gunderson (@gabegundy) \u003Ca href=\"https://twitter.com/gabegundy/status/759214257594662912\">July 30, 2016\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## Las Vegas\n\nKirsten joined us in Vegas with her husband Jobert, co-founder of HackerOne, for the\nDefCon and Black Hat conferences. I can confidently say the highlight for everyone was\nthe annual [Queercon] pool party co-sponsored by HackerOne.\nWe were so overcome with excitement at being there we jumped in the pool fully clothed and swam\nlistening to the DJ for hours. John, in an effort to make us all look like slobs, rented a tux\nfor the event. It took a bit of coaxing, but he eventually caved and did the most epic cannonball\ninto the pool in a full out monkey suit. John claims his #tuxedoswim trending on Twitter\nwas worth the extra dry cleaning bill.\n\n![Hard at work in Vegas](https://about.gitlab.com/images/blogimages/gitlab-in-action/vegas.jpg)\n\n## Upcoming\n\nFrom Vegas they headed to South America where their remote work adventure continues.\nLook out for their future blog series on the coffee shops with the best wifi\nin the world and other insights from these road warriors.\n\nThis post is one in a series about this particular trip. Check out\n[part 2](/blog/gitlab-in-action-part-2/) and the\n[summary](/blog/around-the-world-in-6-releases/)!\n\n## Join us!\n\nIf you are as amazed as we are, why don't you consider [joining our team][jobs]? I bet you'd love it! \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(252,109,38); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n\n\n\u003C!-- identifiers -->\n\n[culture]: /company/culture/\n[Douwe]: https://twitter.com/DouweM\n[Drew]: https://twitter.com/drewblessing\n[jobs]: /jobs/\n[John]: https://twitter.com/northrup\n[Josh]: https://twitter.com/wredej\n[Phil]: https://twitter.com/pmanjr311\n[Robert]: https://twitter.com/rspeicher\n[queercon]: https://www.queercon.org/\n[Gabe Gunderson]: https://twitter.com/gabegundy\n\n\u003Cstyle>\n  .center twitterwidget {\n    margin-left: auto;\n    margin-right: auto;\n    display: block;\n    box-shadow: 0 4px 18px 0 rgba(0, 0, 0, 0.1), 0 6px 20px 0 rgba(0, 0, 0, 0.09);\n    margin-bottom: 20px;\n    margin-top: 20px;\n}\n\u003C/style>\n",{"slug":2634,"featured":6,"template":700},"gitlab-in-action","content:en-us:blog:gitlab-in-action.yml","Gitlab In Action","en-us/blog/gitlab-in-action.yml","en-us/blog/gitlab-in-action",{"_path":2640,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2641,"content":2646,"config":2651,"_id":2653,"_type":17,"title":2654,"_source":18,"_file":2655,"_stem":2656,"_extension":21},"/en-us/blog/five-principles-that-make-it-easier-for-people-to-love-your-company-culture",{"title":2642,"description":2642,"ogTitle":2642,"ogDescription":2642,"noIndex":6,"ogImage":2643,"ogUrl":2644,"ogSiteName":686,"ogType":687,"canonicalUrls":2644,"schema":2645},"Five principles that make it easier for people to love your company culture","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683656/Blog/Hero%20Images/million_downloads.jpg","https://about.gitlab.com/blog/five-principles-that-make-it-easier-for-people-to-love-your-company-culture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Five principles that make it easier for people to love your company culture\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-08-12\",\n      }",{"title":2642,"description":2642,"authors":2647,"heroImage":2643,"date":2649,"body":2650,"category":14},[2648],"Sid Sijbrandij","2016-08-12","\n\nWe were very pleased and surprised to see [this article](https://www.b.agilob.net/choose-gitlab-for-your-next-project/) pop up\n(thanks, agilob!) as well as [this one](https://news.ycombinator.com/item?id=11091980),\n[this one](https://news.ycombinator.com/item?id=11095652), and\n[this one](https://news.ycombinator.com/item?id=11091577) that all arrived on\nthe Hacker News front page in the space of about a weekend. There were also many\nkind comments left by users, which is always great to see. We’re excited to have\na lot of loyal fans (many of whom are also contributors).\n\nWhile there’s no magic formula for getting people to like you, we think that\nsome of it has to do with the values embedded in your company culture. Your company culture not only defines how your organization works together\nbut it also defines how your team interacts with the outside world. It dictates the underlying philosophies for how you treat employees, customers, partners, suppliers, etc.\nA great company culture can help you attract great talent and earn respect from your\ncustomers and partners. At GitLab, we take our culture very seriously\nand we are constantly working to maintain it as we grow.\n\nThis post outlines the principles that we think make it\neasier for people to become fans. Naturally, every company culture is unique so these are our thoughts on what works for us. We think there may be some learnings\nhere for your company as well. We could also learn from your culture so please comment on this post with what works for your company or team.\n\n\u003C!-- more -->\n\n## Be consistent\n\nWe try to do things consistently as much as possible, like releasing a new\nversion of GitLab [every month on the 22nd][releasedate].\nIt’s not that different from knowing your favorite show is going to come out on\nthe Thursday of every week; when you can rely on something, it’s easier to get\ncommitted to it.\n\nWe also try to make it very easy for our users and team to understand our\nprocesses, for example by having our [Handbook]\nand [strategy] out in the open.\nIf people have access to clear information about who we are and how we work,\nthey can become better ambassadors for GitLab.\nThat means, basically, knowing our values in a way that can be communicated forward.\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Possibly one of the best startup resources that I've ever come across: \u003Ca href=\"https://twitter.com/gitlab\">@GitLab\u003C/a>'s Handbook, \u003Ca href=\"https://t.co/IU5Ee8voI3\">https://t.co/IU5Ee8voI3\u003C/a>. Absolutely incredible.\u003C/p>— Omar Kassim (@okassim) \u003Ca href=\"https://twitter.com/okassim/status/753650731001999360\">July 14, 2016\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## Be productive\n\nNothing is worse than a company that creates a need rather than addressing a\nreal problem.\nWe develop new features on a regular basis and to be prolific (yet efficient)\nin our work, because we value productivity.\nIn short: don’t try to create a problem where there isn’t one; solve a real\nproblem. And then do it again, and again, and again. People will appreciate it.\n\n![Be productive - thanks channel](https://about.gitlab.com/images/blogimages/building-a-culture-people-love-be-productive.png){: .shadow}\n\n## Be collaborative\n\nOne of our core values at GitLab is to contribute to the bigger project rather\nthan guarding one corner of it. In one sense this is just a more efficient way\nto solve problems, by group-sourcing solutions. We developed our public issue\ntracker to help make [collaboration][1000] as easy as possible.\nBut not surprisingly, collaboration also builds solidarity, goodwill, and\nloyal fans. Just one more reason to do it.\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Thanks \u003Ca href=\"https://twitter.com/gitlab\">@gitlab\u003C/a> you make me feels special today :) Loved the handwritten message behind the card ! \u003Ca href=\"https://t.co/Enc1FejpTx\">pic.twitter.com/Enc1FejpTx\u003C/a>\u003C/p>— Stéphane HULARD (@s_hulard) \u003Ca href=\"https://twitter.com/s_hulard/status/760834353660366848\">August 3, 2016\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## Be opinionated\n\nMany companies try to tread a careful line, never taking much of an opinion so\nas not to alienate potential customers. We don’t believe in that. We’re vocal\nabout things we believe in, like the fact that we think [remote only] is the way\nforward.\n\nIt’s hard for people to become fans if you never take a position on things.\nIt can cause some polarization, ie. people will dislike you OR they’ll really\nlike you – and we think that’s okay. It’s preferable to be disliked on occasion\nthan to have a lukewarm company personality that’s completely uninteresting.\nDon’t be afraid to be a little different.\n\n## Be transparent\n\nTransparency is one of those buzzwords that gets used a lot, and can mean very\nlittle. For some companies it means they’ve done their job if they put a few\ncompany documents online. We think real transparency is about trying to do as\nmuch as possible out in the open, so that anyone can see it. Being remote-only\nmakes this easier, because we can ensure that most of our comms are logged publicly.\n\nWe still run into conflicts, because we’re also a commercial entity that has customers and\npartners, which means some things have to be kept private. We’ve outlined our\ncommitment by looking at other communities and projects which have struggled\nwith the open-source issue. We try to achieve:\n\n- Transparent decision making about the direction of the project.\n- Company involvement in open communication channels.\n- A balance of tending to the needs of the project and to the needs of the company.\n\n## Have Ideas?\n\nWe’re working hard, but there’s always a lot to potentially improve upon.\nWhat do you think is important and what could we be doing better in your\nopinion?\n\n[1000]: /2016/05/24/1k-contributors/\n[contribution]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md\n[handbook]: /handbook/\n[releasedate]: /blog/why-we-shift-objectives-and-not-release-dates-at-gitlab/\n[remote only]: http://www.remoteonly.org/\n[strategy]: /company/strategy/\n\n\u003Cstyle>\n  .center twitterwidget {\n    margin-left: auto;\n    margin-right: auto;\n    display: block;\n    box-shadow: 0 4px 18px 0 rgba(0, 0, 0, 0.1), 0 6px 20px 0 rgba(0, 0, 0, 0.09);\n    margin-bottom: 20px;\n    margin-top: 20px;\n  }\n\u003C/style>\n",{"slug":2652,"featured":6,"template":700},"five-principles-that-make-it-easier-for-people-to-love-your-company-culture","content:en-us:blog:five-principles-that-make-it-easier-for-people-to-love-your-company-culture.yml","Five Principles That Make It Easier For People To Love Your Company Culture","en-us/blog/five-principles-that-make-it-easier-for-people-to-love-your-company-culture.yml","en-us/blog/five-principles-that-make-it-easier-for-people-to-love-your-company-culture",{"_path":2658,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2659,"content":2665,"config":2669,"_id":2671,"_type":17,"title":2672,"_source":18,"_file":2673,"_stem":2674,"_extension":21},"/en-us/blog/moving-from-ops-to-infrastructure",{"title":2660,"description":2661,"ogTitle":2660,"ogDescription":2661,"noIndex":6,"ogImage":2662,"ogUrl":2663,"ogSiteName":686,"ogType":687,"canonicalUrls":2663,"schema":2664},"Why we switched our philosophy from Ops to Infrastructure","Why and how GitLab moved from an Ops mindset to an Infrastructure mindset","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683873/Blog/Hero%20Images/infrastructure-cover-image.jpg","https://about.gitlab.com/blog/moving-from-ops-to-infrastructure","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we switched our philosophy from Ops to Infrastructure\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pablo Carranza\"}],\n        \"datePublished\": \"2016-08-12\",\n      }",{"title":2660,"description":2661,"authors":2666,"heroImage":2662,"date":2649,"body":2668,"category":14},[2667],"Pablo Carranza","\n\nThere is Ops, Infrastructure, Performance, DevOps etc. The terms and titles go on and they vary based on a\nvariety of industries, companies, and cultures. At GitLab, we focus on the philosophy not the title. In this\npost, I’ll explain why and how our team shifted our philosophy on how we approach GitLab's performance\nfrom an Operations mindset to an Infrastructure mindset.\n\n\u003C!-- more -->\n\n## Operations mindset\n\nWith more and more people using GitLab to host their public and private repos, run CI tests, and deploy to a\nnumber of different environments, we started experiencing noticeable performance and scaling challenges. We’d spot a problem and then race to get it fixed.\nThe team was incredibly reactionary, working to fix this and change that. The reality is that computers will\nbreak and as you scale more things will fail. With this in mind, we could’ve\ntaken the “Mongolian hoard approach” and thrown more people at the problem. However, that would have been\nanother knee-jerk reaction and we could already see that the reactive way of doing things would never scale.\nSo, we had to change. Our goal was to stop running behind the issues and start anticipating challenges in\norder to stay steps ahead of them.\n\n## The transition\n\nLike most things, change is a process. Here are the steps we took:\n\n* **Focus on infrastructure**: We shifted the team to drop the operations view that segregates systems engineering and instead focus on building infrastructure from a development perspective. Our goal was to get away from a world where developers code features and then system engineers deploy it and provision machines. We achieve better results when everyone has to be included in this process, either by building the product adding features, or by building the infrastructure and driving how the product uses the infrastructure to grow.\n* **Spot patterns**: We built graphs to spot patterns. Fortunately, human brains are very good at pattern matching. It's just the way our brain works. Of course, just seeing the pattern isn’t enough. We’d spot the pattern and then work to match it to what we already knew were signs of good performance levels. The only way to be able to spot patterns is to commit to time based metrics that you will collect and then correlate.\n* **Mind the gap**: When we spotted an unexpected or strange behavior we moved closer to the problem to understand where it was coming from, build a hypothesis, and then challenge our assumptions. We don't take feelings as data, if someone on the team feels that something is slow, we still need to get a number showing how slow, in a way that we can measure and reproduce the experiment.\n* **Align resources effectively**: With data on what’s not working and how is this affecting your system, you can focus on the right problem and allocate the right level of people and resources to find a solution.\n* **Seek to automate**: If you find yourself performing a manual task, you should do it once, twice, then many. By that, I mean you do the manual work once, a second time, and then you if you need to perform it a third time you need to automate it somehow. This is the laziness Larry Wall talks about in [the three virtues of a great programmer](http://threevirtues.com/). The goal is to stop doing the boring work a machine is so good at.\n* **Rinse and repeat**: Take your graphs, make your assumptions, challenge them with an experiment, get your results, and start again following an iterative process, forever.\n\n## Cultural shift\n\nMaking this transition really forced the company to tear down the wall between development and production and\ncollectively focus on building a better product. It’s been very important\nfor our infrastructure team to have a \"developer mindset\". We need to find simple solutions to complex problems\nand constantly be working to code ourselves out of a job.\nOur team works to scale our software and our infrastructure by automating solutions.\nThere will always be new challenges for the team work on next.\nFor example, one of the problems that we faced recently was that we were going to run out\nof storage in a single appliance and we needed to fix this before we ran out, a show stopper kind of problem.\nOur process to get ahead of this was:\n\n1. Identify the problem: we are running out of storage space and performance. This opens the questions: how much time left we have?\n1. Add monitoring to understand what the context and environment is: monitor iostat, monitor filesystem growth, plan how much time we have left.\n1. Build a hypothesis and an experiment to challenge our assumptions: by using [multiple shards](https://gitlab.com/gitlab-com/infrastructure/issues/139) we can buy time increasing complexity to move to a better solution.\n1. Run the experiment by building a small piece of infrastructure: [attach a new filesystem shard to the nodes](https://gitlab.com/gitlab-com/infrastructure/issues/192), and set up new projects to be created there.\n1. Learn, and move to the next iteration of solving this long running issue, leaving better tooling behind to make a better decision next time.\n\nIn this iteration we realized that our [git ssh access timings where not to blame to NFS at all](https://gitlab.com/gitlab-com/infrastructure/issues/59#note_13488035), it was all within ssh.\nWe also learned that most of our traffic comes from new projects that are being imported into GitLab.com so most of the write load moved to the new shard. This is good information that we can use to plan our infrastructure using our resources better.\n\n## The story of a recent win: improve our ssh git access time\n\n1. Assumption: ssh is slow because we are doing a linear search in the `authorized_keys` file. Data to back up this assumption is the current graphs for io metrics in the main NFS server.\n1. Experiment: adding an [authorized keys](https://gitlab.com/gitlab-com/operations/issues/99) api command and using it for openssh authorization will give better performance.\n1. Result: stabilized API access because of less filesystem access, but API is still slow: ![Stabilized API Access](https://about.gitlab.com/images/blogimages/moving-from-ops-to-infrastructure/grape-internal-allowed-timings.png){: .shadow}\n1. Assumption: web in general (API included) is slow because the worker nodes are [being restarted too often](https://gitlab.com/gitlab-com/operations/issues/276)\n1. Experiment: [adding queueing times for http requests](https://gitlab.com/gitlab-com/operations/issues/264) will give us understanding of how much time is a request waiting to be served.\n1. Result: we had way better information and realized that our http requests where queueing for 1 second in the p99 case.\n1. Assumption: by preventing unicorn processes from being killed too often we will avoid enqueuing requests for too long.\n1. Experiment: increasing _out of memory_ killer will keep workers running for longer.\n1. Result: http queueing time dropped to virtually zero and transaction timings were also [massively impacted](https://gitlab.com/gitlab-com/operations/issues/276#note_12353835): ![HTTP Queueing time](https://about.gitlab.com/images/blogimages/moving-from-ops-to-infrastructure/http-queue-timings.png){: .shadow}\n1. New data: from the wider picture perspective, our ssh access is still irregular and quite slow intermittently: ![intermittent slow ssh access](https://about.gitlab.com/images/blogimages/moving-from-ops-to-infrastructure/slow-ssh-access.png){: .shadow}\n1. Assumption: after deeper investigation, [dbus is queueing connections](https://gitlab.com/gitlab-com/infrastructure/issues/290#note_13536786) because of an arbitrary max sockets limit and bad file descriptor handling.\n1. Experiment: patching dbus in a PPA package and [bouncing all the workers](https://gitlab.com/gitlab-com/infrastructure/issues/290#note_13607928) will remove the dbus queuing time.\n1. Result: git ssh access [stabilized at ~2 seconds for push, ~5 seconds for pull](https://gitlab.com/gitlab-com/infrastructure/issues/290#note_13613187): ![stable ssh access times](https://about.gitlab.com/images/blogimages/moving-from-ops-to-infrastructure/stable-ssh-access.png){: .shadow}\n1. Ongoing further actions: investigate how we can reduce those ssh access timings, and [contribute back to the community](https://gitlab.com/gitlab-com/infrastructure/issues/290#note_13613213) so everyone can benefit from this.\n\nOther things happened in the mean time, we added a [public black box monitoring system](http://dashboards.gitlab.com/) to make our performance improvement efforts public. We used this monitoring to start with simple things, and over time we added more and more metrics to get better insight.\nFor example, monitoring our ssh access times was as easy as writing a [simple script](https://gitlab.com/gitlab-org/gitlab-monitor) and adding a cronjob to probe the access every minute. Only with this _boring solution_ we managed to understand how was GitLab.com behaving, and we managed to see how it was evolving in our efforts to build a better system.\n\nThere were also some assumptions that proved wrong, but led to better understanding, for example: we assumed that our ssh access was being slow because of the TCP load balancing we do before reaching a worker node, this turned not to be the case when we started monitoring each node individually for better understanding.\nThis kind of experiments are extremely useful because they will invalidate the assumption and make you look somewhere else - failing is an extremely important part of the process.\n\n## Our toolbox\n\nHere is a list of the tools we use right now:\n\n- [Chef](https://www.chef.io/chef/) → [infrastructure as code](https://www.thoughtworks.com/es/insights/blog/infrastructure-code-reason-smile)\n- [Prometheus](https://github.com/prometheus) → It will allow you to gather metrics in a time series providing good exploration tools. Then graph those metrics in grafana building dashboards.\n- [Blackbox exporter](https://github.com/prometheus/blackbox_exporter) → It will allow you to see what your customers are seeing from the outside, if it's slow, you will [see how slow](http://dashboards.gitlab.com/dashboard/db/gitlab-status)\n- [Influxdb](https://influxdata.com/) → Time series database, supported by GitLab for pushing white box performance metrics.\n- [Grafana](http://grafana.org/) → Graphing tool, we use it with both Influxdb and Prometheus to build graph dashobards that allow you to see how the application is behaving through time.\n- [ELK stack](https://www.elastic.co/webinars/introduction-elk-stack) (Elasticsearch, Logstash, Kibana) → Log processing and analyzing system. Logs are usually the first source of information that can and should be used. There's no lower hanging fruit than writing logs that add value, then parsing these logs to see how is the system behaving. Something as simple as requests per minute will tell you how much the system is being used, add errors per minute to the same graph and you will know if your last deploy is broken and should be reverted.\n- [Sentry](https://getsentry.com/welcome/) → Real time error tracking system.\n",{"slug":2670,"featured":6,"template":700},"moving-from-ops-to-infrastructure","content:en-us:blog:moving-from-ops-to-infrastructure.yml","Moving From Ops To Infrastructure","en-us/blog/moving-from-ops-to-infrastructure.yml","en-us/blog/moving-from-ops-to-infrastructure",{"_path":2676,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2677,"content":2683,"config":2687,"_id":2689,"_type":17,"title":2690,"_source":18,"_file":2691,"_stem":2692,"_extension":21},"/en-us/blog/our-handbook-is-open-source-heres-why",{"title":2678,"description":2679,"ogTitle":2678,"ogDescription":2679,"noIndex":6,"ogImage":2680,"ogUrl":2681,"ogSiteName":686,"ogType":687,"canonicalUrls":2681,"schema":2682},"Our Handbook is open source: here's why","In this post we’re explaining the reasons why having an open source Handbook works for us and how it can help you.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665885/Blog/Hero%20Images/love-the-sun-gitlab.jpg","https://about.gitlab.com/blog/our-handbook-is-open-source-heres-why","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our Handbook is open source: here's why\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-07-12\",\n      }",{"title":2678,"description":2679,"authors":2684,"heroImage":2680,"date":2685,"body":2686,"category":14},[2648],"2016-07-12","\nIn the past two years we’ve gone from a team of 10 people to a team of 90+, spread across \n26 countries. As a remote-only company, there is a stronger need to document and broadly share \nour policies and procedures.\n\nIn this post we’re explaining the reasons why having an open source Handbook\nworks for us, and how it can help you, whether you’re working at or running a company of\nyour own.\n\n\u003C!-- more -->\n\n## Remote-only communications \n\nEffective communication is the lifeblood of any company or team. At GitLab, \nwe needed to ensure our communications methods were scalable for a growing company, and that \nthey could simplify onboarding for new hires in various countries. Since at a remote-only\ncompany you can’t turn to the person next to you and ask where a file is kept. We needed\nsomething that everyone could access, no matter where they are.\n\nPlus, we value results, transparency, sharing, efficiency, and collaboration.\nWith all that in mind, it just made sense that we would create an open source\ncompany [Handbook]. Our Handbook is actually under a [Creative Commons][cc-by] license,\nmeaning that as long you attribute GitLab you’re free to copy and use it at will. \nWe welcome you to do that if you wish!\nThis way nobody has to reinvent the wheel.\n\nRunning a company out in the open isn’t the usual way,\nand we want more people to be doing it. By putting our\nHandbook out in the open, we’re making it easy for people to pick up on what\nwe’ve already learned, without having to start from square one. You can also\nsee how we achieved the current thinking, since you can see historical states and edits.\n\n## Hiring\n\nPeople considering a job will know what they’re getting into. Having an openly\navailable Handbook makes it pretty easy for people to learn about our company\nculture and processes before they decide to work here. As part of the hiring\nprocess, it makes things more efficient. \n\n> _Being able to get a look inside the company and not having to fully rely on the\nrepresentatives of the company makes you feel more confident — you don’t feel like\nyou’re being sold. By looking at the handbook, I was able to answer key questions like, \"do I see myself \nworking here\" and \"is everything I’m hearing from my interviewers aligned with what I’m reading in the Handbook?\"\nFor me, I could see myself working in an organization that had thoughtfully crafted how teams could best work together.\nAnd three months in to my role at GitLab, the Handbook is aligned with what I heard and it is constantly being\nupdated to reflect the latest needs of our team.”_ - [Amara Nwaigwe], Senior Product Marketing Manager at GitLab.\n\n## Transparency\n\nTransparency keeps us honest. If we don’t want to publicize a company policy or practice,\nthat probably means it shouldn’t be part of our company culture. Putting it all out\nthere ensures we keep our practices up to a high standard.\n\n## WIP\n\nWhen Handbooks are not open and not easily accessible, they often grow stale. The reality is that companies are fluid. \nCompanies scale up and down, people come and go, processes changes, and priorities shift. Amidst all of that change, \nwe believe that it is important to have a central place where the full team can make changes to update the \nworking guidelines to reflect the organization at its current state. Our Handbook is \nalways a Work in Progress (WIP). We use the same procedures to change our Handbook as we do for\neverything else, so changing a process = changing the Handbook. It’s totally simultaneous.\nIt’s also very easy to see how a process has changed by looking at the history of\nmerge requests associated with it.\n\n## Efficiency\n\nAn open Handbook that is always updated to reflect the latest policies and procedures means that \neveryone is up to speed. Onboarding new hires — and onboarding everyone regarding new\npolicies — is time consuming, and someone is always left out. If time is tight, training\nsuffers. Having a living, open-source Handbook means that when changes are made, we all know.\nEveryone is always up to speed on what has changed and why.\n\n## Advice on getting started\n\nIf you've ventured off this page to take a look at our Handbook you're probably thinking, \nthat thing is massive and it's unrealistic that your team will find the time to create something like that. \nHere's some advice to help you get started. \n\n* Think about the processes that are universal to your team or company (e.g. values, onboarding, communication, etc.). Focus on these first because they are the ones that most people will have opinions on and they will have the largest effect on your organization because they impact nearly everyone at the company.\n* Create a shared document and ask others to contribute to it. We believe everyone can contribute and that collaborating yields better results, faster. \n* Don't reinvent the wheel. Borrow content from other companies and Handbooks you admire. \n* Just start. Starting is always the hardest part. However, if you accept that your Handbook will (and should) evolve over time, then you'll feel more comfortable getting something out there. \n\nHave an idea for our Handbook? Want to use it to create your own? Feel free to drop us a line [@GitLab]!\n\n\u003C!-- Identifiers, in alphabetical order -->\n\n[Amara Nwaigwe]: https://twitter.com/its_amaracle\n[@GitLab]: https://twitter.com/gitlab\n[cc-by]: https://creativecommons.org/licenses/by-sa/4.0/\n[Handbook]: /handbook/\n",{"slug":2688,"featured":6,"template":700},"our-handbook-is-open-source-heres-why","content:en-us:blog:our-handbook-is-open-source-heres-why.yml","Our Handbook Is Open Source Heres Why","en-us/blog/our-handbook-is-open-source-heres-why.yml","en-us/blog/our-handbook-is-open-source-heres-why",{"_path":2694,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2695,"content":2701,"config":2706,"_id":2708,"_type":17,"title":2709,"_source":18,"_file":2710,"_stem":2711,"_extension":21},"/en-us/blog/gitlab-employees-on-working-at-gitlab",{"title":2696,"description":2697,"ogTitle":2696,"ogDescription":2697,"noIndex":6,"ogImage":2698,"ogUrl":2699,"ogSiteName":686,"ogType":687,"canonicalUrls":2699,"schema":2700},"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":2696,"description":2697,"authors":2702,"heroImage":2698,"date":2703,"body":2704,"category":14,"tags":2705},[780],"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](https://handbook.gitlab.com/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",[763,697],{"slug":2707,"featured":6,"template":700},"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":2713,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2714,"content":2720,"config":2724,"_id":2726,"_type":17,"title":2727,"_source":18,"_file":2728,"_stem":2729,"_extension":21},"/en-us/blog/remote-working-parents",{"title":2715,"description":2716,"ogTitle":2715,"ogDescription":2716,"noIndex":6,"ogImage":2717,"ogUrl":2718,"ogSiteName":686,"ogType":687,"canonicalUrls":2718,"schema":2719},"What’s It Like to Be a Working Parent at GitLab?","In this post, we’re giving you a view into our experiences of remote working as parents.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684745/Blog/Hero%20Images/crayons-kids.jpg","https://about.gitlab.com/blog/remote-working-parents","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What’s It Like to Be a Working Parent at GitLab?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2016-04-08\",\n      }",{"title":2715,"description":2716,"authors":2721,"heroImage":2717,"date":2722,"body":2723,"category":14},[780],"2016-04-08","\n\nYou might be aware that a fair percentage of the GitLab team are parents, and\nwe all work remotely.\nNot only are we a [remote-first] company we recently affirmed our dedication\nby changing this declaring we are a \"remote only\" company.\nWe believe that remote working is the way forward, when it’s done right.\n\nIn this post, we’re giving you a view into our experiences of remote working\nas parents—we even asked members of team to chime in with their thoughts.\nWhile there’s no “typical” day in the life of the GitLab employee, there were a\nlot of similarities in what people find great and challenging about remote working.\n\n\u003C!-- more -->\n\n## The Biggest Benefit: Family Time!\n\nWe’re very family-oriented here at GitLab (of course I say here meaning all\nover the world) When we asked our team why they like working remotely, the\nthing that came up first and foremost was that people get to spend more time\nwith their kids and partners. It’s simple, really: when you don’t need to\nspend two or more hours a day commuting, that’s two hours you can spend being\nwith your family, or recharging so that you’re in better form for your family.\n\n“I eat together with my son every day,” says Pablo, an Operations lead who works\nfrom his home in Dublin, something not a lot of dads get to do during the day.\n\nLuke, GitLab designer and new dad in Colorado Springs, can share flexible\nparenting hours with his wife, a nurse who works long shifts. “We don’t have to\nsend our daughter to daycare,” says Luke, which has financial benefits as well,\n“and I have the flexibility to take breaks throughout the day with my family.\nIt’s awesome.”\n\n## That’s another big benefit: Flexibility.\n\n“The flexibility makes family life exponentially easier,” says Haydn, from our\nSales team, “which reduces stress and makes you more productive and motivated.\nYou can’t put a dollar value on it – it’s priceless.”\n\nBalancing everything in one space, while challenging, is something you can get\ngood at pretty quickly. Zeger-Jan, a student CS in Utrecht, finds that being a\nstudent, parent, and remote employee work well together—thanks in part to\nasynchronous communication, ie. using Issues and email whenever possible, so\npeople can get to things when it makes sense.\n\n## Oh, yeah, and don’t forget: Productivity.\n\nContrary to what it might seem like,\n[productivity is shown to increase][productivity] when you take people out of\nthe office setting. Our team agrees. “Working at GitLab has increased my\nproductivity at work,” says Chad (GitLab CRO based in Sacramento, California),\n“as I’m not spending time commuting, and the hours I focus on work increases—but\nso does the time I’m able to spend with my family. Win-win for all.”\n\n## But, there are some challenges.\n\nA lot of the challenges, we found from talking with our team, come from a lack\nof boundaries, something you don’t really have to think about when you work\noutside the home; for most people who do, work stays at work.\nIt can be a little too easy, says Richard (in Bath, England), “to spend time\nworking when I should be blocking off quality time with my children.\nMy son often says ‘Daddy is always on call when I come home from school.’”\n\nIn other words, it can be distracting to have work near your family life\nand family near your work life.\nAlso, if the other partner works outside the home, they might unconsciously\nexpect the home-working parent to do things in the house during the day, which\ncan lead to, ehm—tension.\n\nAnd it works the other way, too: for those who intentionally combine working\nand being a parent, things can get logistically complicated. New dad Luke says\nit can be difficult at times to schedule meetings around feeding times, for\nexample, and “of course poopy diapers, upset tummies, and spit up often\ninterrupt my day,” but “it sure beats commuting to an office every day, and\nbeing away from my family.” Well said.\n\nHow do our working parents deal with the challenges?\n\n## It’s all about creating boundaries.\n\nFirst of all, mark off some space. If you can’t create a home office, sometimes\nyou might just have to go somewhere. “I often head out of the home to a nearby\ncafé or co-working space,” says Heather. Co-locate with colleagues if you have\nany nearby, or if you have friends who also work remotely, share a space.\n\nBoundaries help with distractions, too. Set your mobile phone aside for certain\nhours of the day, [eliminate social media-type distractions][focus], shut the\noffice door, put in earphones, and make sure your family knows that between the\nhours of this and that, you’re only reachable in case of emergencies.\nIf your spouse consciously or unconsciously expects you to get things done,\nhave that conversation and ask them to not think of you as being “home.”\n\n## Basically though, parenting as a remote employee is awesome.\n\nWe think it’s important to trust our team to get their jobs done on their own\nsteam, and we’re fine if that incorporates a good bit of home-life in the mix.\nIt’s even [in our handbook][handbook] that GitLab employees should feel free to\ninclude pets, kids, partners, and family around during video calls if they want\nto pop in and say hello!\n\nWe also try to do things to make our team’s remote work experience comfortable\nand seamless where we can, like paying for height-adjustable desks, ergonomic\nchairs, Internet (of course), mobile phone, video calling credit, and even\noffice space if they need it. This is well worth our while, because it means\nour team members are happy and productive.\n\n## Are you a remote-working parent?\n\nWhat benefits do you find? What do you do to manage the challenges?\n\nWant to leave a comment or ask us something? Feel free! Catch us here or\n[tweet to us][twitter].\n\n[remote-first]: https://zachholman.com/posts/remote-first/\n[productivity]: http://www.inc.com/christina-desmarais/want-productive-employees-let-some-of-them-work-from-home.html\n[handbook]: /handbook/communication\n[focus]: http://thewritelife.com/10-concentration-apps-that-will-help-you-get-down-to-business/\n[twitter]: http://twitter.com/GitLab\n",{"slug":2725,"featured":6,"template":700},"remote-working-parents","content:en-us:blog:remote-working-parents.yml","Remote Working Parents","en-us/blog/remote-working-parents.yml","en-us/blog/remote-working-parents",{"_path":2731,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2732,"content":2737,"config":2741,"_id":2743,"_type":17,"title":2744,"_source":18,"_file":2745,"_stem":2746,"_extension":21},"/en-us/blog/sponsorship-update",{"title":2733,"description":2734,"ogTitle":2733,"ogDescription":2734,"noIndex":6,"ogImage":2680,"ogUrl":2735,"ogSiteName":686,"ogType":687,"canonicalUrls":2735,"schema":2736},"GitLab Sponsorship Update","In this post, I'll give you an update of what we've sponsored recently as well as some insight into our priorities as we welcome more requests for sponsorship.","https://about.gitlab.com/blog/sponsorship-update","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Sponsorship Update\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily Kyle\"}],\n        \"datePublished\": \"2016-03-24\",\n      }",{"title":2733,"description":2734,"authors":2738,"heroImage":2680,"date":2739,"body":2740,"category":14},[2630],"2016-03-24","\n\nIn this post, I'll give you an update of what we've sponsored recently as well\nas some insight into our priorities as we welcome more requests for sponsorship.\n\nWe’re so delighted with the interest in our [tech diversity sponsorship program][diversity]. Since we announced the program in early February, we've sponsored a number of great events.\n\n\u003C!-- more -->\n\n- [Rails Girls Brussels](http://railsgirls.com/brussels) February 19-20, 2016\n- [Django Girls Łódź](https://djangogirls.org/lodz/) Feb 27, 2016\n- [Rails Girls Tricity](http://railsgirls.com/tricity) March 5-6, 2016\n- [Rails Girls Atlanta](http://www.meetup.com/Rails-Girls-Atlanta/) March 30, 2016\n- [AlterConf](http://www.alterconf.com/) April 9, 2016\n- [ClojureWest](http://clojurewest.org/) Opportunity Scholarship April 15-16, 2016\n- [Django Girls Florence](https://djangogirls.org/florence/) April 17, 2016\n- [SciPyLA](http://conf.scipyla.org/) Opportunity Scholarship May 16-20, 2016\n- [Rails Girls Bialystok](http://railsgirls.com/bialystok) May 21-22, 2016\n\n## Rails Girls\n\nRails Girls is an important program for the Rails community.\nRails Girls aims to open up technology and make it more approachable for girls and women.\n\nOur colleagues Tomasz Maczukin and Grzegorz Bizon mentored at the recent\nTricity Rails Girls event, and there were even a few men attending to learn too!\n\nOur GitLab CE project was accepted as a Rails Girls Summer of Code project.\nWe’re really excited to get involved. My colleague, Yorick wrote about\n[Rails Girls Summer of Code](/blog/rails-girls-summer-of-code-2016/).\n\nWe've also invested as a Gold Sponsor, and the Rails Girls Summer of Code is still\nseeking support through their [crowd funding campaign](http://railsgirlssummerofcode.org/campaign/).\n\nPhotos used with permission from [Rails Girls Tricity](https://www.facebook.com/RailsGirlsTricity/?fref=photo).\n\n![Rails Girls Tricity](https://about.gitlab.com/images/blogimages/railsgirls-tomazs.jpg)\n\n![Rails Girls Tricity](https://about.gitlab.com/images/blogimages/railsgirls-grzegorz.jpg)\n\n## Sponsorship in areas of low opportunity\n\nIn other news, we are also sponsoring events which have a great impact at a local level.\nIt's part of our [strategy][strategy] to sponsor initiatives in countries that have low\nopportunity, and less access to funding.\nSince we're a distributed company, it also means we can send colleagues to\nparticipate in these events.\n\n- [TechParty - 2016](http://techparty.faccat.br/)  April 25 - 28, 2016.\n- [Cuba Startup Meetup](http://www.meetup.com/merchise/) Dates TBD\n\nIt's certainly an area we can improve, so we're looking forward to hearing your\nproposals!\n\n## Reach out to us about sponsorship\n\nIf you would like us to sponsor your next event, please check out\nour [community sponsorship program][sponsorship]. You can also see\n[where our team][team] is if you want to connect to someone in your local region\nfor attending or speaking.\n\n[team]: /company/team/\n[sponsorship]: /community/sponsorship/\n[diversity]: /2016/02/02/gitlab-diversity-sponsorship/\n[strategy]: /company/strategy/\n",{"slug":2742,"featured":6,"template":700},"sponsorship-update","content:en-us:blog:sponsorship-update.yml","Sponsorship Update","en-us/blog/sponsorship-update.yml","en-us/blog/sponsorship-update",{"_path":2748,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2749,"content":2755,"config":2759,"_id":2761,"_type":17,"title":2762,"_source":18,"_file":2763,"_stem":2764,"_extension":21},"/en-us/blog/remote-communication",{"title":2750,"description":2751,"ogTitle":2750,"ogDescription":2751,"noIndex":6,"ogImage":2752,"ogUrl":2753,"ogSiteName":686,"ogType":687,"canonicalUrls":2753,"schema":2754},"To Work Remotely You Need: Wifi & Good Communication Habits","In this post, we’re looking at how solid communication can be implemented as in a set of rules, like we have here at Gitlab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684641/Blog/Hero%20Images/phones.jpg","https://about.gitlab.com/blog/remote-communication","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"To Work Remotely You Need: Wifi & Good Communication Habits\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2016-03-23\",\n      }",{"title":2750,"description":2751,"authors":2756,"heroImage":2752,"date":2757,"body":2758,"category":14},[780],"2016-03-23","\n\nCommunicating clearly is important in almost every profession, but if you work\nremotely (or if you hope to integrate remote working into your company culture),\nit’s indispensable. In this post, we’re looking at how solid communication can be\nimplemented—as in a set of rules, [like we have here at Gitlab][handbook]—and\nwhy you should think about doing just that.\n\n\u003C!-- more -->\n\n## Asynchronous Communication, So Everyone Can Focus\n\n[“Asynchronous communication”](/company/culture/all-remote/asynchronous/) means we’re all getting information from each other\nat a time when we can handle it—usually not “live.” This is important for the\nvery simple reason that most programmers need head space to focus on what we do.\nYou can minimize interruption by setting up a “preference list” for how to contact\nyour remote team. At GitLab, issues are most preferred, then email, then chat.\n\nAsynchronous also refers to the fact that you’re not expected to immediately\nrespond if, for example, a colleague or even your boss emails you on the weekend.\nJust reply on Monday. Likewise, if something is urgent, we encourage team members\nto go ahead and ping someone on chat whenever—that’s how we know it’s urgent.\n\n## Go Public, Not Private\n\nWe find that our team functions most smoothly when people ask a lot of questions,\nand open those questions out to everyone. This means going via issues or public\nchat channels versus person-to-person emails or private messages. Why? Because\nthen you get answers faster, and also this way everyone sees the answer – which\nsaves time for the team in the long run, because that question was bound to come\nup again.\n\nIf you urgently need an answer from one person (and you know that person is the\n  one with the answer you need) mention them by name. This still gives others\n  the opportunity to learn and chime in.\n\n## One Thing at a Time\n\nOne thing that happens a lot is that someone will pack several questions into a\nsingle email, and then something in that email (or post, or whatever) gets\nforgotten about and isn’t ever resolved, or there’s a big delay on one item\nthat affects everything else. This is one way things fall through the cracks.\n\nTo keep that to a minimum, we ask our team to stick to one question or problem\nper email/issue. This also makes it easier to search for issues in your comms\narchives.\n\n## Links! Links!\n\nIf you mention something like a website or document in your message to the team,\nif possible include a link. This shortens the time it will take for people to\nfind that item, and it decreases opportunities for confusion.\n\n## Reply UNTIL IT’S DONE.\n\nWe always reply to emails, even when no action is needed, just to let the other\nperson know the email was received. A thread is considered finished for us when\nthere’s a single word reply, like “ok” or “thanks” or “done.”\n\n## Be a Human\n\nObviously all these rules can seem, eh, a little robotic at first. It’s also\nimportant to actually be a human being, not just disembodied text. If you’re on\nvideo chat—which you can and should do, especially if you find you’re going back\nand forth over chat—have your kid/wife/husband/etc. pop their head in and say\nhello, because this is one of the great perks of remote working! Also this way\neveryone knows you’re not AI.\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">I really want to thank \u003Ca href=\"https://twitter.com/gitlab\">@gitlab\u003C/a> for this document, the communications section is changing how I lead.\u003Ca href=\"https://t.co/Bsvzpon0pE\">https://t.co/Bsvzpon0pE\u003C/a>\u003C/p>— Jesse Noller (@jessenoller) \u003Ca href=\"https://twitter.com/jessenoller/status/710220595963645952\">March 16, 2016\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"//platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\nAlso, say thanks to your coworkers to let them know that you know THEY’RE human,\ntoo! We have a “Thanks” chat channel just for this purpose, where we ask GitLab\nemployees to mention each other by name and say thanks for specific things.\nIt just makes things nicer.\n\nHave an idea for something we missed? Mention it in comments. Also feel free to\nsteal our entire [communications handbook][handbook]. That’s why we put it online!\n\n[handbook]: /handbook/communication\n",{"slug":2760,"featured":6,"template":700},"remote-communication","content:en-us:blog:remote-communication.yml","Remote Communication","en-us/blog/remote-communication.yml","en-us/blog/remote-communication",{"_path":2766,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2767,"content":2772,"config":2777,"_id":2779,"_type":17,"title":2780,"_source":18,"_file":2781,"_stem":2782,"_extension":21},"/en-us/blog/remote-working-gitlab",{"title":2768,"description":2769,"ogTitle":2768,"ogDescription":2769,"noIndex":6,"ogImage":2698,"ogUrl":2770,"ogSiteName":686,"ogType":687,"canonicalUrls":2770,"schema":2771},"Working Remotely at GitLab: An update","You might be curious what it's like to work remotely at GitLab. Watch this video to hear from our team!","https://about.gitlab.com/blog/remote-working-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Working Remotely at GitLab: An update\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather McNamee\"}],\n        \"datePublished\": \"2016-03-04\",\n      }",{"title":2768,"description":2769,"authors":2773,"heroImage":2698,"date":2775,"body":2776,"category":14},[2774],"Heather McNamee","2016-03-04","\n\nIn April 2015, we published [the Remote Manifesto][manifesto] on our blog.\nThere were 9 people in the company at that time, which means we've grown\nover 600% during that time, with 54 people [on our team][team] as I write this.\n\n\u003C!-- more -->\n\n### Working remotely at GitLab\n\nYou might be curious what it's like to work remotely at GitLab.\nWatch this video to hear from our team!\n\n\u003Cdiv style=\"text-align: center; margin-bottom: 12px\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/NoFLJLJ7abE\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\u003C/div>\n\n### Our handbook\n\nThe Remote manifesto outlines the over-arching principles.\nYet it's the [handbook][handbook] that details the specifics.\n\n[The communication guidelines][communication handbook] in the handbook are thorough.\nMy friend asked me how I could possibly remember it all.\nIn fact you don't have to.\nWhen you start out at GitLab, you read the handbook, but you still act and react\nwith your old habits.\nLuckily your colleagues will remind you, and help you learn how to *be more GitLab.*\n\nA typical thing is to see someone say \"I'm going out for lunch.\"\nBut you don't need to tell people at GitLab you're going AFK (away from keyboard).\nSo invariably, someone else will remind them: Hey no one is checking up on you.\n\nAs the handbook says:\n\n> Everyone at the company cares about your output.\nBeing away from the keyboard during the workday, doing private browsing\nor making personal phone calls is fine and encouraged.\n\nYou're expected to get your work done, and organize your own time.\nWe do keep a group availability calendar, so if someone is away everyone can see easily.\n\nAnother typical thing is to be chatting 1:1 with someone, and someone else will\nsay: Hey we should bring this to a group channel so others can see.\n\nAs the handbook advises:\n\n> If you use chat please use a public channel whenever possible,\nmention the person you want to reach if it is urgent.\nThis ensures it is easy for other people to chime in, and easy to\ninvolve other people, if needed.\n\nMany rules of communication in face to face offices are implicit.\nHaving the Handbook helps making those rules explicit and clear.\n\n### So what has changed? The team call got bigger.\n\nIn July 2014, Job wrote about [how GitLab works remotely][remotely].\nWe still do have a daily [team call][team call].\nThe technology may have changed, but that isn't as relevant as how we do it.\n\nThe rules, according to the [the Remote Manifesto][manifesto] are the same,\nbut we had to make some changes to accommodate a larger group.\n\nWe still keep a running agenda, which acts like an internal \"GitLab News\" update.\nIt's expected that even if you can't make the meeting, you still read it.\nWe start with agenda items which anyone can add.\n\nThen we get an update from members of a functional team.\nSo you can find out what other teams are working on easily and ask questions.\nOur Marketing team gives an update on Mondays!\n\nWe still use the time for bonding too.\nThis is one of my favorite guidelines in the handbook:\n\n> Having pets, children, significant others, friends and family visible\nduring video chats is encouraged.\nIf they are humans, ask them to wave at your remote team member to say ‘Hi’.\n\nAs a remote employee since 2009, I can't even tell you how much this means to me.\nIt reflects the human and compassionate side of GitLab. It's lovely.\nIt's not unusual to have some small kids on laps, or dogs, or cats.\nThe daily team meeting is meant to be a relaxing time, and it always cheers me up!\n\nThe main difference is that now we can't hear from everyone each day,\nso we have people grouped to speak on a specific day.\nThen each person talks about something they did recently, or they are planning to do.\nNo one expects you to be \"interesting\" though.\nWhether you baked a cake or watched a movie, it's been an easy way to get to know\npeople across the company.\nI was worried my nights of knitting might be boring news, but I flash a WIP\n(work in progress in Knitting terminology, and [on GitLab][wip])\nonce in a while, and it's nice to share.\n\n### How remote bonding works even better\n\nMy favorite quote from the video above is what [Ashley](https://twitter.com/theunquietone) said:\n\"You really get to know people and you don’t realise that you do.\"\nThat's exactly how the team meeting works.\n\nI have a feeling that I know my colleagues in this company even better\nthan I did in previous companies.\nThough I haven't met any of them in person (yet!)\n\nIn an office, you might bond more easily with those in close physical proximity.\nWith the team meeting, I feel somehow *close* to the people who joined around\nthe same time as me.\n[Jose](https://twitter.com/random_primate) joined right before me, and speaks\nbefore me in the team meeting, and [Grzegorz](https://twitter.com/GrzegorzBizon)\njoined after me, and I hand over the call to him right after me.\nWhile we don't work on the same teams, I've become more familiar with them somehow.\n\nThe notion of *proximity* is different in a remote organization.\n\nOne day, one of our colleagues said he was really bummed out and didn't even\nfeel like working.\nEveryone rallied around him.\nThey encouraged him with positive feedback.\nThey encouraged him to take time off too.\n\nI kept on thinking that if this had happened in an office,\nhe might be on the other side of the building, struggling and I wouldn't know.\nThe lack of physical proximity has the potential to bring us closer,\nas long as we are sharing what we're experiencing.\nWhile it took some bravery for him to share that, I love that he did.\n\nI know that in a way, being remote is a challenge.\nI can't go make him a cup of tea and chat with him.\nBut it gives an advantage in that we all share these experiences together.\n\nOf course, when we do get together, we can pick up where we left off.\nAnd I'm very much looking forward to that.\n\nWe have a [visiting grant][visiting-grant] at GitLab, to bring people together.\n\n> If you want to visit a colleague in another part of the world, or promote\nGitLab at events in another country, then present your travel plan to your\nmanager or the CEO, and you can receive up to $2,000 in support for your plan!\n\nWhile we don't have an office, we can get financial support to visit colleagues.\nI'm super excited about this! I can't wait to make a trip on this grant :)\n\n### Join us!\n\nHaving the handbook out there in the open makes it easier for people to\nidentify if they'd be a fit for our team.\n\nIf you'd like to work with us at GitLab, please check out the [Jobs][jobs] available.\n\n[visiting-grant]: /handbook/incentives/#visiting-grant\n[wip]: http://doc.gitlab.com/ce/workflow/wip_merge_requests.html\n[jobs]: /jobs/\n[handbook]: /handbook/\n[communication handbook]: /handbook/communication/\n[team call]: /handbook/communication/#team-call\n[manifesto]: /blog/the-remote-manifesto/\n[team]: /company/team/\n[remotely]: /blog/how-gitlab-works-remotely/\n",{"slug":2778,"featured":6,"template":700},"remote-working-gitlab","content:en-us:blog:remote-working-gitlab.yml","Remote Working Gitlab","en-us/blog/remote-working-gitlab.yml","en-us/blog/remote-working-gitlab",{"_path":2784,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2785,"content":2791,"config":2795,"_id":2797,"_type":17,"title":2798,"_source":18,"_file":2799,"_stem":2800,"_extension":21},"/en-us/blog/gitlab-open-strategy",{"title":2786,"description":2787,"ogTitle":2786,"ogDescription":2787,"noIndex":6,"ogImage":2788,"ogUrl":2789,"ogSiteName":686,"ogType":687,"canonicalUrls":2789,"schema":2790},"GitLab's Open Strategy","We've just created and published our Strategy document to make our choices clear as they relate to our strategic objectives.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683642/Blog/Hero%20Images/moving-parts2.jpg","https://about.gitlab.com/blog/gitlab-open-strategy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's Open Strategy\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-02-09\",\n      }",{"title":2786,"description":2787,"authors":2792,"heroImage":2788,"date":2793,"body":2794,"category":14},[2648],"2016-02-09","\n\nWe've just created and published our [Strategy document][strategy]\nto make our choices clear as they relate to our strategic objectives.\n\n\u003C!-- more -->\n\nPreviously, we opened up our [roadmap][direction] and our entire [employee handbook][handbook].\nWe also outlined our dedication to being [a good open source steward][stewardship].\n\nHaving our Strategy document in the open will help users understand why\nwe make certain choices at GitLab, Inc.\nWe can be held accountable to these choices as well.\n\nThe Strategy document is comprehensive.\nOur prime objective is to *ensure that everyone can contribute*.\nWe outline our set of assumptions and the constraints under which we operate.\nWe include our tactical plans for 2016 for all aspects of our business.\nWe want to share this with the entire GitLab community so you know how\nand why important decisions are being made.\n\nWe think having our Strategy in the open will make it better for users and it will make\nthe product better.\nWe will get more feedback and potential team members can self-select\nby learning about the driving forces behind our choices.\n\nOften users are left wondering and speculating why companies do certain things.\nWe feel you have every right to know.\nFrom what we prioritize and the investment burden we take on,\nto the initiatives we support and the incentives we give our team:\nAll of these choices affect how GitLab operates and that, in turn, affects\nyour experience as a user.\n\nPlease do read our [Strategy document][strategy], and as always,\neveryone can contribute.\nMerge requests to suggest improvements to the Strategy document are welcome.\n\n[stewardship]: /blog/being-a-good-open-source-steward/\n[direction]: /direction/\n[handbook]: /handbook/\n[strategy]: /company/strategy/\n",{"slug":2796,"featured":6,"template":700},"gitlab-open-strategy","content:en-us:blog:gitlab-open-strategy.yml","Gitlab Open Strategy","en-us/blog/gitlab-open-strategy.yml","en-us/blog/gitlab-open-strategy",{"_path":2802,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2803,"content":2809,"config":2813,"_id":2815,"_type":17,"title":2816,"_source":18,"_file":2817,"_stem":2818,"_extension":21},"/en-us/blog/future-front-end-development",{"title":2804,"description":2805,"ogTitle":2804,"ogDescription":2805,"noIndex":6,"ogImage":2806,"ogUrl":2807,"ogSiteName":686,"ogType":687,"canonicalUrls":2807,"schema":2808},"Help shape the future of the front end at GitLab","Help shape the future of the front end at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684579/Blog/Hero%20Images/kitchen.jpg","https://about.gitlab.com/blog/future-front-end-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Help shape the future of the front end at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jacob Schatz\"}],\n        \"datePublished\": \"2016-01-25\",\n      }",{"title":2804,"description":2805,"authors":2810,"heroImage":2806,"date":2811,"body":2812,"category":14},[2450],"2016-01-25","\n\nHi! I'm Jacob Schatz, Principal Front End Engineer at [GitLab]().\nWhen I started here at GitLab in December 2015, I felt like I’d joined the cool-kids club.\nI’d heard about the job on HackerNews, and thought, “I’ll apply for it and it would be awesome if I got it.” \nAnd I got the job! \n\nIt’s been a fantastic experience, and I’m glad to say we’re hiring more front end developers.\nWe have a unique challenge here at GitLab, working in an “open kitchen” together.\nWe must serve both a great front end user experience and a great developer experience. \n\nIf you’re curious about working at GitLab, read on. \n\n\u003C!-- more -->\n\n## What’s so different here\n\nThe big shocker for me coming to GitLab was that everybody is involved in the plan to move things forward. \nThat’s unusual. \nEven in small companies there’s usually an “upper management divide.” They’re making decisions you’re not aware of. \nThings will change in just one day, and you don’t know why. \n\nThe team here at GitLab is very transparent and everyone is working for the betterment of the product. \nBecause it’s a small team, this means we pitch in on all kinds of tasks. \nIt also means your skills improve. \n\nIn the beginning I had a lot of questions, and people were really good about answering them. \nI'm a JavaScript developer, so working with this amazing team of Ruby developer has made my Ruby knowledge skyrocket.\nWhen you submit a merge request, you are submitting it to the public; it must be top-notch.\n\n## The Open Kitchen of Open Source\n\nIt’s great to work in a company where it looks good on the inside of the product as well as the outside.\n\nIt’s like a kitchen. \nThere are some restaurants where, the [front of house](https://en.wikipedia.org/wiki/Restaurant_management#Front-of-the-House_management) might be nice, but you don’t want to see that kitchen. \nAll too often the quality of the code will lose out to the need for speed, to get it done quickly. \nClients traditionally can’t see the elegance of the code. Some don’t care. Make it work!\n\nWhereas at GitLab, where we are developing open source software, we’re working in an open kitchen. \nIt has to look as nice as the front of house. \n\nOpen source front end developers must serve two user experiences. \n\n- UX - the front end user experience for the users who interact with the UI of the application.\n- DX - the developer experience for the contributor who needs comprehensible code.\n\nYou’re dealing with stuff that is on the bleeding edge, and you’re doing it in a way that people can contribute. \nI want to make a way of coding and working with GitLab that will allow ease for end users, and more accessibility for contributors. \nWe have quite a challenge ahead, and we need your help. \n\n## Want to join us?\n\nI’m the first front end developer here at GitLab. \nI was most recently working for a digital agency developing applications and sites for large retail clients like Panera Bread. \nThese sites have tons of visitors and they have to work really well. \nThey have to be fast and extremely reliable. \nThat is what I want to bring to GitLab. \n\nWe’re hiring two more front end developers. \nOur Ruby architecture is rock-solid, and now we need to bring out front end architecture up to that level.\nIf you’re curious, you can see open issues and activity related to front end development at GitLab, right on the [job description](https://handbook.gitlab.com/job-families/engineering/development/frontend/). \nIn my interview with Job Van der Voort, VP of Product, we worked through a current frontend issue. \nOur current frontend is written in jQuery and CoffeeScript. \nOur code should be timeless in a way. \nWe need people who are really good at pure JavaScript, and don’t really care what framework we use.\n\nWe need people who are JavaScript veterans. \nI’m still a bit traumatized by the browser wars. \nI used to write CSS and JavaScript hacks for IE6. \nIf you were there, you’ll know what I mean. \nEven now when I see [`opacity`](http://caniuse.com/#feat=css-opacity) I think “Oh no, it's only partially supported in IE8!”\nHaving that depth of experience is important at GitLab. \nYou know why code should be well-written and [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) as much it should be a great interactive experience.\n\nSome people are really dead-set on particular frameworks. \nWe can’t come in and rewrite everything. \nGitLab is released monthly. \nWe move at pace. \nWe need to work on the many small issues and at the same time think on a bigger scale: what we can do to reduce the code complexity.\n\nWe need to take it one step at a time. \n\nIf you’re curious about working in an open kitchen with us, please check out the job description: [Front End Engineer](https://handbook.gitlab.com/job-families/engineering/development/frontend/).\n",{"slug":2814,"featured":6,"template":700},"future-front-end-development","content:en-us:blog:future-front-end-development.yml","Future Front End Development","en-us/blog/future-front-end-development.yml","en-us/blog/future-front-end-development",{"_path":2820,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2821,"content":2827,"config":2831,"_id":2833,"_type":17,"title":2834,"_source":18,"_file":2835,"_stem":2836,"_extension":21},"/en-us/blog/making-gitlab-better-for-large-open-source-projects",{"title":2822,"description":2823,"ogTitle":2822,"ogDescription":2823,"noIndex":6,"ogImage":2824,"ogUrl":2825,"ogSiteName":686,"ogType":687,"canonicalUrls":2825,"schema":2826},"Making GitLab Better for Large Open Source Projects","Here we would like to share our thoughts about these issues and what we’re planning to do to make things better with GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/making-gitlab-better-for-large-open-source-projects","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Making GitLab Better for Large Open Source Projects\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2016-01-15\",\n      }",{"title":2822,"description":2823,"authors":2828,"heroImage":2824,"date":2829,"body":2830,"category":14},[2523],"2016-01-15","\n\nDear open source maintainers,\n\nWe want GitLab to be the best place for any software project,\nwhether open source or not, whether big or small.\n\n[The letter of GitHub's open source community](https://github.com/dear-github/dear-github/tree/2f45c3255a55c3ac111817840537151d96e1649e)\nis clearly not addressed to us,\nbut we're thinking a lot about the issues that were mentioned in it.\nWe see many of these things happening and have been working on them for a long time,\nnot in the least because we develop on a [busy public issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues) ourselves.\n\nHere we would like to share our thoughts about these issues and\nwhat we’re planning to do to make things better with GitLab.\n\n\u003C!-- more -->\n\n## Major issues\n\n> Issues are often filed missing crucial information like reproduction steps or version tested.\n> We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template,\n> perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.\n\nIn GitLab you can [set a template for an issue and for a merge request](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/customization/issue_and_merge_request_template.md).\n\nWe're also planning to add [multiple templates](https://gitlab.com/gitlab-org/gitlab-ee/issues/101),\nthat you can use depending on the reason for making an issue.\n\nWe're also [interested in exploring](https://gitlab.com/gitlab-org/gitlab-ce/issues/8988)\ncustom (required) fields.\n\nUsing a `new_issue.md` file for templates is a nice idea, that we're happy\nto discuss [in this issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/9088).\n\n> Issues often accumulate content-less “+1” comments which serve only to spam the\n> maintainers and any others subscribed to the issue.\n> These +1s serve a valuable function in letting maintainers know how widespread an issue is,\n> but their drawbacks are too great. We’d like issues to gain a first-class voting system,\n> and for content-less comments like “+1” or “:+1:” or “me too” to trigger a warning\n> and instructions on how to use the voting mechanism.\n\nGitLab currently has a voting system that automatically transforms `+1` into\na vote. As we use GitLab ourselves for issue tracking _and_ feature voting,\nthis is something that has a high priority for us.\n\nWe've also planned [several improvements to votes](https://gitlab.com/gitlab-org/gitlab-ce/issues/3763)\nand welcome more ideas and merge requests.\n\n> Issues and pull requests are often created without any adherence to the\n> CONTRIBUTING.md contribution guidelines, due to the inconspicuous nature of\n> the “guidelines for contributing” link when creating an issue and the fact that\n> it often contains a lot of information that isn’t relevant to opening issues\n> (such as information about hacking on the project). Maintainers should be able\n> to configure a file in the repo (interpreted as GFM) to be displayed at the top\n> of the new issue / PR page instead of that link. Maintainers can choose to inline\n> content there and / or link to other pages as appropriate.\n\nCurrently, we provide links to `CONTRIBUTING.md` whenever you create an\nissue or merge request. At the moment you can also leverage the issue\ntemplate to point people to specific rules.\n\nWe're [interested in adding a custom contributing file on top of issues](https://gitlab.com/gitlab-org/gitlab-ce/issues/9083) in GitLab.\n\n## Responses to specific suggestions\n\nThe original letter also included a long list of suggestions.\nTo see our response to every single point, please view\n[this issue on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues/8938).\n\nOne issue that was raised several times was the ability to not create\nmerge commits. In GitLab.com and EE you can, as an alternative to the merge commits,\n[use fast-forward merges](http://doc.gitlab.com/ee/workflow/ff_merge.html)\nor have [merge requests be automatically rebased](http://doc.gitlab.com/ee/workflow/rebase_before_merge.html).\n\n## How we all build GitLab\n\nGitLab is built in the open. Our decisions, doubts, and arguments about\nchanges to GitLab, new features, and everything else can all be found in our\nrepositories (mainly [GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce/issues)\nand [GitLab EE](https://gitlab.com/gitlab-org/gitlab-ee/issues)).\n\nEveryone is free to comment, create new issues, vote on, and\n[contribute to the development](http://contributors.gitlab.com/)\nof GitLab. We have short- and long-term goals, all of which are visible on the\nissues of the repositories and on the [direction page on the website](/direction/).\n\nIf you want to change something, create an issue or submit a merge request.\nYou can choose to implement something yourself, or ask someone else to do it.\nGreat ideas will always get the attention they need.\n",{"slug":2832,"featured":6,"template":700},"making-gitlab-better-for-large-open-source-projects","content:en-us:blog:making-gitlab-better-for-large-open-source-projects.yml","Making Gitlab Better For Large Open Source Projects","en-us/blog/making-gitlab-better-for-large-open-source-projects.yml","en-us/blog/making-gitlab-better-for-large-open-source-projects",{"_path":2838,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2839,"content":2845,"config":2849,"_id":2851,"_type":17,"title":2852,"_source":18,"_file":2853,"_stem":2854,"_extension":21},"/en-us/blog/being-a-good-open-source-steward",{"title":2840,"description":2841,"ogTitle":2840,"ogDescription":2841,"noIndex":6,"ogImage":2842,"ogUrl":2843,"ogSiteName":686,"ogType":687,"canonicalUrls":2843,"schema":2844},"Open Source Stewardship","We've recently detailed our policy and commitment to open source. We need to think in the interests of the project, while tending to the realities of running a business to support it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683647/Blog/Hero%20Images/sailing-5.jpg","https://about.gitlab.com/blog/being-a-good-open-source-steward","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Open Source Stewardship\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2016-01-11\",\n      }",{"title":2840,"description":2841,"authors":2846,"heroImage":2842,"date":2847,"body":2848,"category":14},[2648],"2016-01-11","\n\nWe've recently [detailed our policy and commitment to open source](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1106). We need to think in the interests of the project, while tending to the realities of running a business to support it. I wanted to share some of our thoughts around the decisions behind the policy.\n\n\u003C!-- more -->\n\n## The challenge of being an open source steward\n\nOn Opensource.com, Matthias Stürmer identified [four types of open source communities](http://opensource.com/business/13/6/four-types-organizational-structures-within-open-source-communities):\n\n- single-vendor open source projects\n- development communities\n- user communities\n- open source competence centers\n\nWe could think of the last three types as marked by distributed development. Sometimes they are managed by community-organized foundations or associations but they have no singular point of commercial support. Examples include Apache, Rails and Linux.\n\nThe first type, “single vendor open source projects” is marked by support from a distinct commercial entity which mainly controls the direction and development of the project and financially supports a majority of core developers. Examples of this type of project include Wordpress and Automattic; Hadoop and Cloudera; or Elasticsearch and Elastic.\n\nEvery time you have a company in control of an open source project, people will have questions about how the company will behave. The supporting company must balance the practical needs of running the business, supporting the development, and keeping the lights on. The company has to generate revenue, and the community and software project are reliant on the company to sustain. However, compared to closed-source or proprietary software, being open source ensures that the project can be forked and live even beyond the company.\n\n## For us, open source is an ethos not just a license\n\nOpen Source arose from the Free Software movement. In the late 90s [when the term ‘open source’ was devised](https://en.wikipedia.org/wiki/Open_source#The_emergence_of_the_.22open_source.22_term), it helped to emphasize the fact that the code was viewable or modifiable. The term open source also downplayed the idea that the software was “free as in beer” which denoted poor-quality. At the same time the term laid the groundwork for commercial ventures to support these kinds of projects. Since 1998 open source has become a de-facto standard, a mark of quality, and an assurance against vendor lock-in.\n\nHowever, the term open source has somewhat muted the activist origins of the Free Software movement: “free as in freedom.” At the heart of open source is collaboration, which requires trust and safety. When commercial companies supporting open source projects disregard these ethical issues it will serve to erode trust, which is essential for open source to work.\n\nAny companies who \"open source\" code to gain competitive advantage must address the ethical issues involved. Open Source is more than just a license, it’s also an ethos and commitment. Now, we have encoded our commitment by detailing our policy on being a good steward for the open source project.\n\n## What does it mean to be a good open source steward?\n\nI was hesitant to create a policy until we were sure about the circumstances and context for our project and company. Now that we have a few years of experience, we know better what is required.\n\nFirst, we need to think in the interests of the project, while tending to the realities of running a business to support it. We’ve outlined our commitment by looking at other communities and projects which have struggled with these issues. Typical criticisms of open source companies include:\n\n- Transparent decision making about the direction of the project.\n- Company involvement in or support of open communication channels.\n- Putting the company’s interests before the project.\n\nEach of those aspects must be addressed to ensure the project, code, and community of users are supported.\n\nWe can’t just tend to the needs of the open source project without tending to the commercial requirements. After all, we know that to sustain the project, we need to make it commercially viable.\n\nOur experienced sales team have helped us understand their struggles. Why should the software be completely free no matter who is using it? They ask “Why do I have users who are running with over 10,000 developers and not paying us a dime?” When selling proprietary services salespeople can set artificial limits which give them leverage. They've asked “Can’t we have some limit, such as if you have over 1000 developers that you need the enterprise edition?” This does make sense from a sales point of view, but it doesn’t make sense in the open source context.\n\nOpen source is not a freemium model we can just turn off after 30 days. We can’t say “The first one is free!” It’s all free. Forever.\n\nWe’re not the only ones dealing with these issues. “We’ve played with various mixes of what features go in to which offering, with how to balance our need to thrive as a commercial business with our core belief that Open Source is the future of infrastructure,” [wrote Adam Jacob of Chef](https://www.chef.io/blog/there-is-one-chef-server-and-it-is-open-source/). That was one year ago, and now Chef has come a long way in the stewardship of that project.\n\nNathen Harvey, now VP of Community Development at Chef said \"The intersection of open source and commercial interests raises questions about authority, authenticity, and culture\" in [an article on open governance](http://www.informationweek.com/strategic-cio/it-strategy/three-pillars-of-open-source-governance/a/d-id/1318585). Will commercial interests trump what is best for the project? This is a very important question which each single-vendor open source project needs to consider. Nathen's first principle that \"Transparency is key\" is one we take very seriously.\n\n## What is our policy?\n\nOur beliefs about open source are not only enshrined in our policy, but also in every aspect of how we work. We don't feel any competitive advantage is gained by working in a closed manner. Instead we aim to keep the levels of communication and collaboration with the community of users very high.\n\n- *[Development in the open.](/blog/improving-open-development-for-everyone/)* You can submit issues in a public issue tracker. This is not a read-only interface.\n- *[Business in the open.](/blog/almost-everything-we-do-is-now-open/)* Our company handbook and policies are in the open.\n- *[Clear Direction.](/direction/)* Our Direction document clarifies the current project priorities and what is possible in the upcoming releases.\n\nThis level of transparency is unheard of in proprietary software, rare even in single-vendor open source software, and unusual even among other repository management platforms (open source or not.) In fact, the history of source code management and communities is rife with obfuscation and abuses of trust. For this reason, we feel that having GitLab as a home for safe, open, collaborative development requires being an open source platform itself.\n\nIn our policy, we focused on all of the things we have promised we won’t do. We've addressed the relationship of our CE (Community Edition) and EE (Enterprise Edition), and we've accounted for the requirements of the community by detailing our responsibilities.\n\nWe invite members of the community to read the policy. With this policy published, they will be able to hold us accountable.\n\nPlease read [“Our stewardship of GitLab CE”](/company/stewardship/).\n",{"slug":2850,"featured":6,"template":700},"being-a-good-open-source-steward","content:en-us:blog:being-a-good-open-source-steward.yml","Being A Good Open Source Steward","en-us/blog/being-a-good-open-source-steward.yml","en-us/blog/being-a-good-open-source-steward",{"_path":2856,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2857,"content":2863,"config":2867,"_id":2869,"_type":17,"title":2870,"_source":18,"_file":2871,"_stem":2872,"_extension":21},"/en-us/blog/our-y-combinator-experience",{"title":2858,"description":2859,"ogTitle":2858,"ogDescription":2859,"noIndex":6,"ogImage":2860,"ogUrl":2861,"ogSiteName":686,"ogType":687,"canonicalUrls":2861,"schema":2862},"Our Y Combinator experience","This time last year, from January until March 2015, GitLab participated in the winter 2015 batch of Y Combinator.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683732/Blog/Hero%20Images/stars.png","https://about.gitlab.com/blog/our-y-combinator-experience","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our Y Combinator experience\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2016-01-06\",\n      }",{"title":2858,"description":2859,"authors":2864,"heroImage":2860,"date":2865,"body":2866,"category":14},[780],"2016-01-06","\n\nThis time last year, from January until March 2015, GitLab participated in the winter 2015 batch of [Y Combinator](/blog/gitlab-is-part-of-the-y-combinator-family/). We had an awesome time and want to thank the people at Y Combinator, our mentors Qasar and Kevin,\nthe YC alumni and our fellow batch-mates.\n\n\u003C!-- more -->\n\n## A clear focus\n\nWhen you join Y Combinator, you’re put into a batch with a few other startups. This batch includes other founding teams and one or two mentors who are experienced in starting and running new companies. Every week you meet with the same people, discussing the same topics:\n\n- Where are you,\n\n- Where are you getting stuck,\n\n- How can we help you.\n\nThese discussions are very concrete and not theoretical or philosophical. It’s all about what you are doing to get you towards your goal.\nThey have clear targets throughout the program, which will vary from startup to startup,\nsince they are all at different stages when they begin the program.\nCommon metrics are the number of customers, revenue or downloads.\nEach founder or team has a clear aim to focus on one metric.\n\nEverything for the next couple of months is building towards a pitch at the final [Demo Day](https://www.ycombinator.com/demoday/).\nDemo Day is an invite-only event where each of the founding companies pitch to a group of investors.\n\nThis gave our team a clear focus, and with our product getting released every month,\nwe had clear metrics to track against our actions.\nIn our case, we focused on the number of downloads of GitLab.\nThe goal set by our YC mentors was 20% week over week growth. We were\nonly able to increase the downloads by 10%, but the high goal helped us\npush ourselves.\nWe’ve kept that focus on growth and having clear communication\nand messaging since we completed Y Combinator.\n\nA quote from Y Combinator co-founder Paul Graham which is\n[often repeated](http://blog.ycombinator.com/yc-hacks-august-2-3-2014),\nencapsulates the Y Combinator experience: “Our goal is to give smart hackers\nan excuse to get together and spend time building something they find\ninteresting.” For us it was just that: an excuse to work really hard on\nONE thing together for three months with a strong focus.\n\n## An excuse to work really hard - together\n\nWe started in the program at the beginning of 2015 with 9 founding members of GitLab. This group was mostly engineers with two sales people.\n\nY Combinator require that the entire founding team [must live in the Bay Area during the program](https://www.ycombinator.com/faq/#p3).\nY Combinator doesn’t assist with accommodation, so each company finds its own solution.\nThis gives each company a way to forge their own approach and identity.\nIn our case, we brought over our entire team.\nWe all moved over to live in the same house for three months.\nWe found one small apartment with a very small living room.\nWe pushed all of our desks together and worked in that room for three months.\n\n![Our YC livingroom](https://about.gitlab.com/images/yc-livingroom.png)\n\nIt’s clear that the experience wouldn’t be the same without being there in person.\nIt was as much about the access to the local network as it was about building\nrelationships among our team. It was in that house that we started to develop\nour culture. We worked hard and built a strong camaraderie.\nTo get around, we used \"The Boat\", a huge car that would fit the whole team\nand we decorated with the original GitLab logo (the angry raccoon dog!)\n\n![The boat](https://about.gitlab.com/images/blogimages/boat.jpg)\n\nTowards the end of the program, Job had to return to the Netherlands for his\nwedding. A big customer in LA requested us a week before he left to come for\na visit. We jumped in the car started our road trip in the direction of LA.\nAfter many hours of driving, Job started to realize we weren't driving in\nthe correct direction after all...\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4TnKmrpiSgQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003Cbr>\n\u003Cbr>\n\n![All piled into The Boat](https://about.gitlab.com/images/yc-the-boat.png)\n\nSince Y Combinator we have kept up the same level of drive and focus.\nAs we’ve built our team, we’re working on extending our culture with a concrete focus on next actions; and a focus on clear goals.\nWe also established the [GitLab Summit](/blog/gitlab-summit-2015/)\nso we can have everyone under the same roof working together in person.\n\n## The network effect\n\nThere’s no question that this environment offers the participants huge\nadvantages. You have a sense that everyone in the program is personally\ninvested in your success. Beyond the direct mentorship, biggest benefit of\nhaving participated in Y Combinator is access to the network.\n\nThere’s a lot of experience available to you as a member of Y Combinator. They are very selective, choosing only what they feel are the most high-potential startups. Other founding teams in your batch are working on things that seem hard or impossible, it’s amazing to see what they are developing. They are also a diverse group with different backgrounds and skills. Other founders offer their direct help, without you having to ask for it. For example, they might make referrals and recommendations for key contacts.\nNote that to get into YC you don't need to network. We had zero recommendations\nfrom others when we applied.\n\nThere’s a collegial atmosphere between the participating founders, and among the [YC alumni](https://www.ycombinator.com/atyc/#alumni). They often act as beta\ntesters for one another’s software, or they offer technical help. We asked all\nY Combinator companies in our batch to move to GitLab and we gave them an\nincentive. If some of the founders from other teams wanted to learn about our\nproduct, we invited them in and helped them set up in person.\nIn addition, the peer pressure from the success and enthusiasm from fellow\nfounders made us work harder and try to be better ourselves.\nWe took every opportunity to connect with other founders. The Y Combinator\nalumni from our batch still meet in person in California.\n\nSince Y Combinator we’ve given our investors monthly updates. The update follows a similar structure to those weekly conversations we used to have. We’re clear about our success and status; and we’re also transparent about where we’re blocked and where we need help. This makes it possible for those who are invested in our success to help us.\n\nGetting launched from Y Combinator pushes you ahead with huge momentum. It’s nice to look back at 2015 and consider how far we’ve come. We’re about to hire the 37th person on our team and our sales organization has come a long way. We went from 100k downloads at the end of Y Combinator to 250k downloads in November alone.\n\nWe constantly feel a great sense of gratitude for having been given the opportunity to participate in the program. Thank you to our colleagues and investors from Y Combinator and best wishes to everyone taking part in the next round.\n",{"slug":2868,"featured":6,"template":700},"our-y-combinator-experience","content:en-us:blog:our-y-combinator-experience.yml","Our Y Combinator Experience","en-us/blog/our-y-combinator-experience.yml","en-us/blog/our-y-combinator-experience",{"_path":2874,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2875,"content":2881,"config":2885,"_id":2887,"_type":17,"title":2888,"_source":18,"_file":2889,"_stem":2890,"_extension":21},"/en-us/blog/why-we-shift-objectives-and-not-release-dates-at-gitlab",{"title":2876,"description":2877,"ogTitle":2876,"ogDescription":2877,"noIndex":6,"ogImage":2878,"ogUrl":2879,"ogSiteName":686,"ogType":687,"canonicalUrls":2879,"schema":2880},"Why we shift objectives and not release dates at GitLab","At GitLab we believe you shouldn’t wait for something to be perfect: Release what you have and do it on a schedule.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684519/Blog/Hero%20Images/goal.jpg","https://about.gitlab.com/blog/why-we-shift-objectives-and-not-release-dates-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we shift objectives and not release dates at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather McNamee\"}],\n        \"datePublished\": \"2015-12-07\",\n      }",{"title":2876,"description":2877,"authors":2882,"heroImage":2878,"date":2883,"body":2884,"category":14},[2774],"2015-12-07","\n\nI’ve just started working at GitLab, and I’m bowled over completely by the kindness and talent of the people I’m meeting. On my second day, I met with Dmitriy Zaporozhets, founder of the software project GitLab and co-founder of my company, GitLab, Inc. We spoke about the release date: it’s same day, each month, always. What is this madness? I wasn’t used to things being released ON TIME and deadlines not shifting. I discovered this monthly release date is at the heart of working at GitLab.\n\n“At GitLab we believe you shouldn’t wait for something to be perfect: Release what you have and do it on a schedule,” said Dmitriy.\n\n\u003C!-- more -->\n\nGitLab comes out the 22nd of every month, no matter what, no delays, no exceptions. This schedule creates a pace of active development, crucial for open source projects. The predictability builds trust for users and helps them plan better. Most importantly, this approach reduces stress and increases individual and team satisfaction-- because you actually shipped something.\n\n## Shifting deadlines? Stop.\n\nDmitriy explained the philosophy behind the monthly release schedule.\n\n“People expect things to be finished and perfect to meet a deadline,” Dmitriy said. Yet, no matter how you improve the estimation and planning process it seems there are always unfinished tasks as a deadline approaches. To resolve this, the most typical response is to move the deadline instead of changing the objectives.\n\n“Constant delays in release dates creates disappointment, because you don’t see the result of your work being used,” Dmitriy said this negatively affects motivation, creates confusion and erodes trust.\n\nThere is an alternative. Instead: move remaining tasks to later releases, and don’t move the deadline. This approach is unusual, but not unique; for example it is used in Ubuntu. They release every 6 months. It’s a [time-based release](https://wiki.ubuntu.com/TimeBasedReleases), not a feature-driven release.\n\nThere are many advantages.\n\n * There are advantages for users. They know there is a fixed release date which for which they can prepare and plan.\n* It gives open source projects a leading edge which increases adoption and participation. Predictable, frequent releases are crucial for open source projects: People don’t want to help and contribute on a project which is dead or stalled.\n* There are also advantages for the core developers. It promotes working with passion in periods of intense activity then celebration and relaxation.\n\nRecently, Michael Walsh of Enovate Design posted [a review of GitLab](https://www.enovate.co.uk/web-design-blog/2015/11/25/gitlab-review/). He mentioned the release date as a benefit, and I asked him how it affects his own work. He said it wasn't so much that it affected his own work.\n\n> \"I like the regularity of monthly releases (the 22nd is a date I look forward to!) and it's a routine now to check the release blog post. The monthly releases certainly focuses my attention on GitLab more compared with other services that have no/little consistency to the timing of their releases.\" [see comment in context](https://www.enovate.co.uk/web-design-blog/2015/11/25/gitlab-review/#comment-2379718375)\n\nHe knows when it's coming out, and it's nice to think that it's a day he looks forward to.\n\n## How does a time-based release promote quality?\n\nA feature drive release process works well for SaaS services. When a feature is ready you don't need to wait for a specific date to release a certain feature. On the other hand, if you're working on distributed software, users need to be prepared for a release. Having personally experienced long and delayed open source releases as both a user and community member, I'm convinced of this. Time based releases, with strict deadlines, could work best for open source projects especially.\n\nTime-based release cycles promote discipline, emphasize quality, and increase motivation.\n\nDmitriy had a good metaphor, he compared it to going to the gym. It’s better to get to the gym for part of your training plan, instead of skipping it because you don’t have time to do the entire thing. It promotes discipline.\n\nKnowing that each month you will release ‘no matter what’ forces you to focus on high-priority tasks. If you come to a stage where it’s clear certain features are not making it into this release, these tasks get deferred. Sometimes you may find that these tasks were not as important as you thought, or new insights come from the release and you change the features.\n\nYou can’t separate the software from the process and people developing it. Managing energy and motivation is very important. A predictable release schedule has huge effects on motivation.\n\nHe described a friend of his, a designer, who was feeling demotivated in her job. She would constantly experience deadlines pushed out further and further, and the products of her work remained unused or unseen. This is discouraging. It’s this kind of experience that pushes people to leave their jobs. Shifting deadlines results in a complete lack of satisfaction, and no chance to celebrate or rest.\n\nDmitriy explained that yes, sometimes people working on GitLab will work longer hours in the rush to release. “We build something we use ourselves, and this means developers are working to get features in before the release date so they can enjoy the features sooner. This can be an intense period,” he said. But it’s followed by a rest period and celebration. “I believe this approach emphasizes relaxing more and working less,” Dmitriy said. People can work with passion and play with passion.\n\n## A personal desire for quality\n\nDmitriy Zaprozhets started GitLab in 2011. Like the start of many open source projects, he was scratching his own itch; but he was also motivated by quality. I think many developers who participate in open source projects can relate to his experience.\n\n“Previously, I worked as a developer on a small team for a consulting agency. I jumped from project to project. It seems like you get the list of the tasks completed, but then you’re just assigned another list of tasks. There is a flat line of work with spikes in activity in reaction to unplanned crises,” Dmitriy said.\n\n“I was motivated by quality. I think quality matters everywhere, but that quality isn’t always appreciated. There’s a difference between software quality and code quality. The application functionality depends on the software quality: features, reliability and speed, which clients can experience. The code quality itself is something they can’t see or appreciate. Because of that it gets deprioritized,” he said. I think many developers can relate to that experience. You can be put in a situation of doing low-quality work that you’re not necessarily happy with.\n\n“In those teams, it’s typically the leaders who set the pace and level of motivation and quality,” he said, and hinted that you might not always be motivated by those leaders. In response to this, “Many people who work in consulting companies have side personal projects or collaborate on open source projects to get that experience of quality.”\n\nI laughed when he said this. “Is this how GitLab started?” I asked.\n\n“Yes,” Dmitriy said and smiled.\n\nHe wanted GitLab to be a place where he could focus on quality. Like many others who are inspired to build open source, he wanted to attract others to participate. He wanted his software to get released, he wanted it to be used. For him, the choice was obvious. A time-based release cycle and a monthly cadence of releases was the only way to fulfill this. It would be the way he could ensure that the people he attracted to the project were inspired, motivated, and delighted.\n\n\n## The debate is on.\n\nIs a time-based release cycle the best option for all open source projects?\n\nI imagined if a feature-driven release cycle held a debate about Quality with a time-based release cycle, that the feature-driven cycle could lead the argument by saying “We’re holding out for perfection!” In rebuttal, the time-based cycle could argue that their approach leads to a more vibrant, active, development community and ultimately a higher quality product. And besides that, it SHIPS.\n\nWhile a feature-drive release cycle can allow SaaS services to get to market with new features really fast, it can stall and stymie distributed software and especially open source projects. From the release of the long-awaited Drupal 8.0 the open source CMS is moving to a [predictable release schedule](https://www.drupal.org/core/release-cycle-overview), with predictable dates. Scheduled minor releases (8.1.0, 8.2.0) will be released every six months. The challenge for that project will be to resist shifting deadlines and instead, shift objectives.\n\nI’m curious what the GitLab users think about time-based or feature-driven releases, specifically for open source projects. I’d love to hear if you have experience of both, how it affects your motivation and the quality of work.\n\n## Next: How we manage releases for GitLab\n\nNext week, in a follow-up to this post, Dmitriy will share specifics about how the GitLab team manage our releases, along with some tools and examples to coordinate work among a team. Subscribe to our newsletter which includes links to our latest blog posts.\n\n\u003Cscript src=\"//page.gitlab.com/js/forms2/js/forms2.min.js\">\u003C/script>\n\u003Cform id=\"mktoForm_1073\">\u003C/form>\n\u003Cscript>MktoForms2.loadForm(\"//page.gitlab.com\", \"194-VVC-221\", 1073);\u003C/script>\n\n\u003Cp class=\"newsletter-afterword\">\n  If you subscribe, you will receive our twice monthly newsletter.\n\u003C/p>\n",{"slug":2886,"featured":6,"template":700},"why-we-shift-objectives-and-not-release-dates-at-gitlab","content:en-us:blog:why-we-shift-objectives-and-not-release-dates-at-gitlab.yml","Why We Shift Objectives And Not Release Dates At Gitlab","en-us/blog/why-we-shift-objectives-and-not-release-dates-at-gitlab.yml","en-us/blog/why-we-shift-objectives-and-not-release-dates-at-gitlab",{"_path":2892,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2893,"content":2898,"config":2902,"_id":2904,"_type":17,"title":2905,"_source":18,"_file":2906,"_stem":2907,"_extension":21},"/en-us/blog/gitlab-summit-2015",{"title":2894,"description":2895,"ogTitle":2894,"ogDescription":2895,"noIndex":6,"ogImage":2698,"ogUrl":2896,"ogSiteName":686,"ogType":687,"canonicalUrls":2896,"schema":2897},"SumIt All Up","Welcome to the GitLab 2015 Summit in Amsterdam.","https://about.gitlab.com/blog/gitlab-summit-2015","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SumIt All Up\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily Kyle\"}],\n        \"datePublished\": \"2015-11-30\",\n      }",{"title":2894,"description":2895,"authors":2899,"heroImage":2698,"date":2900,"body":2901,"category":14},[2630],"2015-11-30","\n\nWhat began as an estimated 20 person trip for bonding between our remote\nemployees turned into two weeks, four hotels, five last-minute passports, a 15\nperson Airbnb, 42 people, all the beer in the Netherlands and an infinite\namount of mayonnaise-covered fries… and a partridge in a pear tree.  Welcome to\nthe GitLab 2015 Summit in Amsterdam.\n\n![GitLab team](https://about.gitlab.com/images/blogimages/amsteampic.jpg){: .shadow.medium.center}\n\n\u003C!--more-->\n\nWith our goal of bonding, day one of 14 began with introductions, swag, hugs, and\nan amazing scavenger hunt around Amsterdam. With most people having only met over\nGoogle Hangouts, our rapidly-growing company quickly got over an initial\nawkwardness and by the end of the day teams were doing head butts in Dam Square,\nplaying tricks on the local chocolatier and scheming ways to bribe the judges to\nwin first place (bragging rights only) in the team competition.\n\nOver the next two weeks we covered a lot of ground in the Netherlands. In no\nparticular order here are a few of the highlights: canal tour of Giethoorn\n(beautiful town with canals instead of streets), Rijksmuseum, fries, a dinner\nat the home of our CEO’s parents (including a mean game of the Perfect Number on\nour bus ride there – Sid skillfully slayed with his ability to deceive), fries,\ncelebrated our monthly release over Dutch pancakes, fries, had dinner with the\nfamily of another Netherlands-based employee at a great restaurant, fries, beer\nmaking, fries, a visit to Apenheul (primate park), fries, walking tour of\nAmsterdam, fries, a tongue-in-cheek awards dinner, fries, two days as sponsors\nat OSCON (Open Source Conference), and did we mention fries?!\n\n![Happiest chocolate lover ever!](https://about.gitlab.com/images/summits/2015_amsterdam/dmitriyhugshaydnwithchocolate.jpg)\n\nOf course, there was ample time to work – we have to keep the company going. Our\nhome base, referred to as \"The Lab\", was an amazing home on the Singel where our\nAirbnb host became a GitLab groupie and supported us in our remote style of\ngetting things done and enjoying our lives.\n\n![GitLab Groupie aka David our Airbnb host](https://about.gitlab.com/images/summits/2015_amsterdam/davidatlab.jpeg)\n\nBiggest “ahas” of the trip? Dmitriy might love chocolate more than coding,\nAmsterdam is a truly spectacular city where simply walking around is amazing and\nmost importantly, as the wise Marin Jankovski said, “2 week @GitLab summit\nended today. Main thing I learned: my colleagues are not only 100% professionals\nbut also 500% great people.”\n\nSo, what’s next? We have already begun brainstorming our next summit – location\nand dates TBD. You can be sure that we will rise to the bar that has been set\nand provide yet another memorable experience that supports the idea that those\nwho work remotely are able to have their stroopwafel and eat it too!\n\n## From the folks at GitLab\n \n\nHear our team talking about what they love about working at GitLab, Inc.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/GJP-3BNyCXw\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\n\nWould you like to join our next GitLab Summit? Well then, you'll have to join the team. Please check out our current [job openings](/jobs/). Maybe there is a role for you. :)\n",{"slug":2903,"featured":6,"template":700},"gitlab-summit-2015","content:en-us:blog:gitlab-summit-2015.yml","Gitlab Summit 2015","en-us/blog/gitlab-summit-2015.yml","en-us/blog/gitlab-summit-2015",{"_path":2909,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2910,"content":2916,"config":2920,"_id":2922,"_type":17,"title":2923,"_source":18,"_file":2924,"_stem":2925,"_extension":21},"/en-us/blog/remote-agile-at-gitlab",{"title":2911,"description":2912,"ogTitle":2911,"ogDescription":2912,"noIndex":6,"ogImage":2913,"ogUrl":2914,"ogSiteName":686,"ogType":687,"canonicalUrls":2914,"schema":2915},"Remote Agile at GitLab","This is a start in describing the workflow that we've established over the past year at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684484/Blog/Hero%20Images/agile.jpg","https://about.gitlab.com/blog/remote-agile-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Remote Agile at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2015-09-14\",\n      }",{"title":2911,"description":2912,"authors":2917,"heroImage":2913,"date":2918,"body":2919,"category":14},[2523],"2015-09-14","\n\nEvery month on the 22nd a new version of GitLab is released. It always\nincludes major changes, with features, bug fixes and performance improvements.\nWe haven't missed a single month since our inception.\n\nWe are completely remote, save for the Experience Center in San Francisco that not a single\ndeveloper frequents (a 10,000km commute is a bit much for most). We do not have\npredefined teams and almost everyone works independently (i.e. without someone telling\nthem what to do).\n\nWe do not practice any specific agile methodology, but meet the principles\nof the [agile manifesto](http://www.agilemanifesto.org/iso/en/principles.html) quite well.\n\nThis is a start in describing the workflow that we've established over\nthe past year at GitLab, as it seems to work for us and might for you. It's\nlightweight and self organizing. It might or might not scale.\n\n\u003C!-- more -->\n\n## Incoming issues\n\nA large part of everything we build in terms of features is based on feedback from the\ncommunity and customers.\n\nWhen a request comes in from a customer (through support or sales usually),\nthe person receiving this request creates an issue to discuss it.\nThey are responsible for mentioning relevant parties. For most features that\nis the product manager, CTO, and any developers or other people that might be\ninterested in this feature.\n\nNext, anyone with an opinion responds to the issue. This is often done in direct\nresponse to others, including more people in the discussion if necessary. The\npoint is to reach some form of consensus. Once this has been reached, the issue\nis scheduled for an upcoming release (e.g. 8.1 or 8.2). Anyone can do this based\non the information in the issue and on how full the upcoming releases are versus\nhow important this is.\n\nEveryone that has participated in the conversation will be updated with any status\nchange. Therefore anyone can freely schedule things. If someone disagrees, they'll\nspeak up.\n\n### Known issues\n\nIt's very hard to schedule things. We simply do not have a good way to estimate\nwhether something will be doable, besides estimating based on previous releases.\nHowever, we prefer the scheduling to be hard over adding overhead with estimating\nweights and velocity for the team. We might change our minds on this.\n\n## Working and Prioritizing\n\nA developer can pick up any issue at any time they're working.\nThey simply assign themselves, marking it as \"Ongoing\" in [GitLab's Milestone\nView](https://gitlab.com/gitlab-org/gitlab-ce/milestones/13).\n\nSome issues have a clear owner in terms of knowledge and ownership of that part\nof the code. Usually this developer has already been active in the issue. The\ndeveloper likely picks these issues. This is a self-organizing process.\n\nA small part of the issues is promised to a customer. This means that we told the\ncustomer: \"Feature X will be done in release Y\". We always intend to keep our\npromise, so these issues get prioritized by everyone.\n\nThere is also a general guideline to prioritization of work. This does not\nwork as a hard rule and also depends on your skills and responsibilities:\n\n1. Emergency issues\n1. Security issues\n1. Data integrity (not losing data)\n1. Availability of GitLab.com\n1. Subscriber questions\n1. Regression issues\n1. Consultancy work\n1. Promised features\n1. Growth efforts\n1. Other work\n\nFind this [in our handbook](https://handbook.gitlab.com/handbook/communication/#gitlab-workflow).\n\n### Known issues\n\nPeople can choose their own issues, which can result in a situation where\nissues that are not 'fun' are not being picked up. This can be solved with\nproper handling of overflow issues, as described below.\n\n## Overflow\n\nOverflow of issues is something that happens every month. Meaning, not all issues\nassigned to a release get completed or worked on.\n\nIn the past, we would simply move everything to the next milestone. This 'waterfall'\nworkflow didn't work, as unpopular things would get dragged on for many releases.\nNowadays, we (I) go through all leftover issues and investigate why they didn't get\ndone and what we can do with them.\nThis often results in dropping the issue as it's no longer relevant or moving it\nup to a future release and pinging a developer to take ownership of it.\n\nManaging overflow issues is a very hard balance between capacity and process.\nMostly we blame a lack of developer capacity with overflow issues\n([we're hiring!](/jobs/)).\nWith every release, we try to reflect on what could have been done better.\n\nFor example, most recently Douwe and I proposed a different model to schedule\nissues to prevent too many promised issues. Most developers had strong opinions\non this, which spawned this article. We ended up not making changes, choosing\nspeed and flexibility over process, but gained insight into how people feel about\nthe status quo.\n\n## Openness, Independence and Responsibility\n\nAs a developer you're required to operate independently and make decisions.\nBy making your own decisions, it reduces process overhead and unnecessary\ncommunication.\n\nIt's your responsibility to report those decisions in the issue that you're working\nfrom. This is the core of our workflow. People that were previously active in the\nsame issue, will receive your updates and thoughts without disturbing one another.\nIf there is an issue, they will respond in the issue. The whole process is asynchronous\nand self-organizing.\n\nLastly, [we're open](/blog/almost-everything-we-do-is-now-open/).\nThis is something that runs deep within GitLab. To be able to work with the community,\nwith our customers, we have to work in a way that everyone can contribute equally.\n\nWe think this works well for everyone, but are always looking to improve things.\nAs we're growing very fast, we're not sure whether this will scale.\n\nHow does your workflow look and why does it work for you?\n\n## Related Reads\n\n- [How we use GitLab to build GitLab](/blog/how-we-use-gitlab-to-build-gitlab/)\n- [The Release Manager](/blog/release-manager-the-invisible-hero/)\n- [The Remote Manifesto](/blog/the-remote-manifesto/)\n",{"slug":2921,"featured":6,"template":700},"remote-agile-at-gitlab","content:en-us:blog:remote-agile-at-gitlab.yml","Remote Agile At Gitlab","en-us/blog/remote-agile-at-gitlab.yml","en-us/blog/remote-agile-at-gitlab",{"_path":2927,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2928,"content":2934,"config":2938,"_id":2940,"_type":17,"title":2941,"_source":18,"_file":2942,"_stem":2943,"_extension":21},"/en-us/blog/almost-everything-we-do-is-now-open",{"title":2929,"description":2930,"ogTitle":2929,"ogDescription":2930,"noIndex":6,"ogImage":2931,"ogUrl":2932,"ogSiteName":686,"ogType":687,"canonicalUrls":2932,"schema":2933},"Almost Everything We Do Will Be Open","We're announcing a move from doing the majority of our development work internally, to almost exclusively working in public issue trackers on GitLab.com.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684463/Blog/Hero%20Images/open.jpg","https://about.gitlab.com/blog/almost-everything-we-do-is-now-open","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Almost Everything We Do Will Be Open\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2015-08-03\",\n      }",{"title":2929,"description":2930,"authors":2935,"heroImage":2931,"date":2936,"body":2937,"category":14},[2523],"2015-08-03","\n\nAt GitLab, we do our best to work together with [the rest of our amazing community] at\nevery possible occasion. The rest of the community contributes many features, fixes bugs\nand improves performance. To work together effectively, we try to be open about\nas many things as possible.\n\nToday we're announcing a move from doing the majority of our development work\ninternally, to almost exclusively working in public issue trackers on GitLab.com.\nThis means that anyone can view and comment on all of our discussion and work.\nThis includes bugs, new features, performance issues and everything else that\nrelates to our products.\n\n\u003C!-- more -->\n\n## The Problem\n\n[GitLab Community Edition], [GitLab Continuous Integration] and the [code that we use\nto build and ship these], are all open source.\nIn fact, even our proprietary version of GitLab, GitLab Enterprise Edition,\nhas a [publicly viewable source code]. We do this because we believe it helps\neveryone building a better GitLab and makes the threshold for community contributions\nvery low.\n\nHowever, the development of the monthly releases of GitLab is done on our private\nGitLab instance. We do this because we receive many feature requests and support\nissues (bugs) from customers and we figured this was best kept private.\nThis lead to a number of problems:\n\n- Bug reports and feature requests were duplicated\n- The latest state of issues was not available to the whole community\n- It was impossible for contributors to review merge requests from GitLab Inc\n- The community had no insight into planned features for upcoming releases\n- We were not able to give customers insight into our thinking about issues\n\nWe were not working in the open as a true open source project should.\n\n## The Solution\n\nTo make the entire development of GitLab a product of the community again,\nwe decided to move all our internal issues, discussions, feature requests\nand bugs to [public repositories] on GitLab.com.\nThis will allow us to build better features and to solve bugs faster\nwith more community feedback and contributions.\n\nIssues and features from our customers will also be visible here.\nCustomers will not be named, instead we will link to internal tools so that\nGitLab Inc employees can still handle customer interactions as normal.\nWe do not intend to release any private information, so logs and other sensitive\ninformation will be sanitized or kept out of the public issue. Rather,\nwe will include the content relevant for the issue, feature request or symptoms\nof the reported bug. Having this content out in the open will lead to less duplication,\nbetter features and faster bug fixes.\n\nSensitive issues, such as security issues with GitLab, will still be handled\ninternally. We'll create tracking issues for these on the public issue trackers\nthat don't contain exploitable information.\n\nDoing this, we bridge our customers and GitLab's community. At the same time,\ncustomers are able to view our work on their issues and feature requests.\nOur work, comments and also our mistakes will be open for everyone to see.\n\n## The Next Steps\n\nOver the coming time, we'll gradually move our internal issues over to GitLab.com.\n\nIn time, we will also start to move away from using [feedback.gitlab.com] to\nusing issues in GitLab for feature requests as well.\n\nIf you have concerns about any of this, please contact us at Contact at GitLab dot com.\nAs always, we will also be present in the comments below.\n\n[the rest of our amazing community]: https://gitlab.com/gitlab-com/www-gitlab-com/commit/cf4569ad6834321f89bb6e34b719bcdcd0ba7799\n[publicly viewable source code]: https://gitlab.com/gitlab-org/gitlab-ee\n[GitLab Community Edition]: https://gitlab.com/gitlab-org/gitlab-ce\n[GitLab Continuous Integration]: https://gitlab.com/gitlab-org/gitlab-ci\n[code that we use to build and ship these]: https://gitlab.com/gitlab-org/omnibus-gitlab\n[public repositories]: https://gitlab.com/groups/gitlab-org\n[feedback.gitlab.com]: http://feedback.gitlab.com/forums/176466-general\n",{"slug":2939,"featured":6,"template":700},"almost-everything-we-do-is-now-open","content:en-us:blog:almost-everything-we-do-is-now-open.yml","Almost Everything We Do Is Now Open","en-us/blog/almost-everything-we-do-is-now-open.yml","en-us/blog/almost-everything-we-do-is-now-open",{"_path":2945,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2946,"content":2952,"config":2957,"_id":2959,"_type":17,"title":2960,"_source":18,"_file":2961,"_stem":2962,"_extension":21},"/en-us/blog/release-manager-the-invisible-hero",{"title":2947,"description":2948,"ogTitle":2947,"ogDescription":2948,"noIndex":6,"ogImage":2949,"ogUrl":2950,"ogSiteName":686,"ogType":687,"canonicalUrls":2950,"schema":2951},"Release Manager - The invisible hero","In GitLab we have one invisible hero every month, when we have our release on the 22nd of every month which we have never missed!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684444/Blog/Hero%20Images/rm.jpg","https://about.gitlab.com/blog/release-manager-the-invisible-hero","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Release Manager - The invisible hero\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Marin Jankovski\"}],\n        \"datePublished\": \"2015-06-25\",\n      }",{"title":2947,"description":2948,"authors":2953,"heroImage":2949,"date":2955,"body":2956,"category":14},[2954],"Marin Jankovski","2015-06-25","\n\nReal heroes are sometimes unknown and we can only see their accomplishments. In GitLab we have one invisible hero every month, when we have our monthly release. As you may know, we've never failed to release a new GitLab version on the 22nd of every month.\n\nAs GitLab grows, the release process becomes more complex and becoming a release manager is a more difficult, but a necessary job.\n\nEight working days before the next release, and we start the countdown. A new volunteer \"hero\" is elected by the team.\n\n\u003C!--more-->\n\n## But, why is it such a challenging job?\n\nA release manager is the person who makes sure that everything is ready for the monthly release. They follow up on every single detail and make sure that the new version is working perfectly, including all the improvements and features. They also need to delegate some tasks and make sure that the procedure is being followed.\n\nConsider that right now, GitLab is huge. Our community dishes out around 900 commits a month on GitLab alone. Add Enterprise Edition, GitLab CI and runners, Omnibus-GitLab packages and you get several thousand changes done by hundreds of developers across projects which need to come together (and work) in one day. This is a lot of responsibility for one person.\n\n## So, how do we manage to make it all into a single release every month?\n\nIn GitLab we have a [release directory](https://gitlab.com/gitlab-org/release-tools/tree/master/doc) for the release documents. The most powerful document for the release is called [monthly.md](https://gitlab.com/gitlab-org/release-tools/blob/master/doc/monthly.md).\n\nRelease manager tasks can be broken down into:\n\n1. Make sure that GitLab CE, EE and GitLab CI repositories have an updated installation and upgraded guides\n1. Make sure that the Omnibus-GitLab package will be ready for the release\n1. Release the RC version, do QA, deploy on GitLab.com and ci.GitLab.com\n1. Follow reported regressions and make sure that developers are aware/working on a fix\n1. Decide which fixes can go into the release\n1. Coordinate the package building\n1. Make sure that the blog post contains all the necessary information\n1. Do the final release\n1. Decide if there needs to be a patch release\n1. Coordinate patch release\n\nA release manager volunteers to work late (or early) to get the packages out or deploy the new version to one of our services. No one is forcing you to do so, but if you don't, it will complicate the following day. This is a weakness in our process, so we need to work on improving this situation.\n\n## History\n\nI don't know the exact date when the release manager duty was thought off but it was [around version 6.4](https://gitlab.com/gitlab-org/gitlab-ce/commit/223070b3fe9cb302d3d47ba5a616d90bab8910fd).\n\nAt that time, we had a couple of other things that were the release manager tasks: Notify everyone of the code-freeze (nothing was merged to master during this time), enforce it and build the packages *manually*. Yes, manually. This meant connecting to all machines separately and doing few commands to initiate package building. GitLab.com had a separate repository with some custom code, so the deploy needed to be done manually too. I still have nightmares as a result of these 2 things.\n\nAs you can imagine, this made the release manager tasks very undesirable and limited to a few people. Even with all the improvements that followed, this job is still not popular.\n\n## Improvements\n\nSince the painful beginnings of the release manager tasks, we've done number of improvements. We did a massive change to the process and made it even more continuous integration oriented than it was before. There are risks to it, but also massive gains:\n\n1. Code freeze was removed so there is no need to watch over anyone's shoulders\n\n1. Keeping X git repos in sync. Syncing repositories is now a one-line script where the argument is the version that is being released\n\n1. Automatizing our release process. Omnibus-gitlab packages infrastructure got built, so only supplying the shas of the release version is enough to kick off the automatic builds on all platforms and machines\n\n1. Infrastructure for deploying GitLab.com and ci.gitlab.com got created and they are being updated by using a few lines of commands and packages\n\n1. The release documentation has been updated so many times that room for error is minimal (if you follow the steps closely)\n\nYou would expect that all these improvements would make the Release manager job more appealing since you get to:\n\n* Boss around over *all* of your colleagues. This includes the project lead and the CEO. It is especially sweet when you can say NO to an unreasonable request. After all, all requests are unreasonable but your own and now you get to push that through\n* You decide at your leasure when something will be included and pushed\n* You are *the* boss of everything (for a period of time) because everyone says: \"Hey, you are the release manager, your call\"\n\n## With all the hard work, how do we choose a volunteer release manager?\n\nChoosing the release manager is probably one of the hardest tasks.\n\nDuring our team call, the release manager for the previous release mentions the subject of selecting a new release manager.\n\nAt that exact moment, there's silence, cameras and mics start breaking down, people forget the whole English language, there is always someone at the door so you need to open it and lots of faces are just looking around the room.\n\nAfter a few minutes of silence, decision is made, but mostly because we are all friends and we don't want to see a colleague suffer for another month.\n\nWe've tried improving the desirablity of this task by making procedures easier, but that is still a challenge.\n\nAt some point I've asked what kind of reward we could put forward to make people happy to volunteer, but there are no good ideas yet.\n\nMy ideas where limited to:\n\n* Material reward: a gift might be OK for some people, but others have no need for things. In this case we could publicly thank them and acknowledge their work.\n\n* \"Spiritual\" reward: We do say \"thank you\" to the RM a lot, but this gets spent. Tweeting the name of the release manager might work as a recognition for some, but I am afraid that it won't work for introverts in our team. Being more public might also yield more work for them.\n\n* Buying a beer or cocktail: This feels like something that would be appreciated, but it would only work for a few employees, since we are a *very* remote company. Maybe a beer voucher could be sent.\n\nWith that I was out of ideas. This blog post is an attempt to say a thank you to all the release managers. You know who you are and you are a true invisible hero for accomplishing the tasks to make everything go out on schedule.\n\nDo you have any ideas?\n\n### Release manager - my hero.\n",{"slug":2958,"featured":6,"template":700},"release-manager-the-invisible-hero","content:en-us:blog:release-manager-the-invisible-hero.yml","Release Manager The Invisible Hero","en-us/blog/release-manager-the-invisible-hero.yml","en-us/blog/release-manager-the-invisible-hero",{"_path":2964,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2965,"content":2971,"config":2976,"_id":2978,"_type":17,"title":2979,"_source":18,"_file":2980,"_stem":2981,"_extension":21},"/en-us/blog/highlights-to-my-first-remote-job",{"title":2966,"description":2967,"ogTitle":2966,"ogDescription":2967,"noIndex":6,"ogImage":2968,"ogUrl":2969,"ogSiteName":686,"ogType":687,"canonicalUrls":2969,"schema":2970},"Highlights to my first remote job","I started working with GitLab 2 months ago and it has been quite an interesting experience to work remotely with a team that's spread out in the world.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684436/Blog/Hero%20Images/highlights.jpg","https://about.gitlab.com/blog/highlights-to-my-first-remote-job","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Highlights to my first remote job\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Karen Carías\"}],\n        \"datePublished\": \"2015-06-17\",\n      }",{"title":2966,"description":2967,"authors":2972,"heroImage":2968,"date":2974,"body":2975,"category":14},[2973],"Karen Carías","2015-06-17","\n\nSome time ago, GitLab's CEO Sytse wrote [The Remote Manifesto](/blog/the-remote-manifesto/). It inspired me to write about it from an employee's perspective.\n\nI started working with GitLab 2 months ago and it has been quite an interesting experience to work remotely with a team that's spread out in the world.\n\n\u003C!-- more -->\n\nI have been working from home for a while, with freelance jobs, but it was very different to today, that I am part of a remote team. Here are the highlights of my experience with [getting started in an all-remote role](/company/culture/all-remote/getting-started/) so far:\n\n## Learning how to communicate\nIt was hard at the beginning to communicate with my team. I hadn't met them in person and if I had a doubt about something, I had to go to Slack to find the person who seemed the nicest and ask him. I was shy to write people to ask for their help all the time, but I learned that it is \"the way\" to learn and to stay communicated in a remote job. I learned not to be afraid to ask and to provide as much context as I could, trying not to include so many links without information.\n\n## Avoiding interruptions\nSo it is great to have coworkers and being with people, but they usually talk with each other, they are friendly and they get you distracted. I love working from home. I got myself nice headphones and I wear them when I don't want anybody at home to distract me. I think I can focus more and get into my \"zone\" easier.\n\n## Morning calls in my PJs\nThe first few days I would wake up really early to look fresh and dressed up for my morning call with the team. Then, I realized that Hangouts won't show the difference, so I learned to wake up, fix some coffee, sit down and work in my PJs all morning and then have a late shower during a break. It is absolutely comfortable and fun, but it's important to learn to be disciplined. No matter how you look or if you are in bed, you need to get into the mindset of working and have a disciplined productive day.\n\n## It's all about trust before they can see results\nTrust is a strong word and for me, it is what I feel about having a remote job. They trust that I work and that I use my time wisely. I have been learning to be more efficient, but since GitLab is very technical and I've had to learn so much, my speed has been very slowly increasing. I believe they trust that I am putting all my efforts into my job and that even though nobody is next to me looking at me working, I am doing my job. That makes me work more because when somebody trusts you, you don't want to disappoint them\n\n## Find a comfortable place where you can be productive\nI have been traveling for a couple of years and when I started, I would just try to find a comfortable  and cheap place to stay at, close to a yoga studio. Now, I find myself looking for an Airbnb with a good wifi connection and a comfortable desk or table. The rest is second. This is very important for my mental and physical health and I believe it's one of the most important things to make sure you have. If I can't find this, I will look for a co-working space or a working cafe. It is important to be able to sit comfortably and stay connected with no distractions.\n\n## I am able to travel\nThis is my favorite highlight. I used to work in the traditional corporate world, which helped me save some money and start traveling with it. When I was running out of savings, I thought that my travels had to end soon. The fact that I could work remotely was one for the best things that could happen to me, since it allows me to work from anywhere and to see the world. I can also spend quality time with my dog and it lets me take care of her.\n\nSo, are you thinking about applying for a remote job? Do it! It's awesome!\n\nBy the way, in Gitlab we're always [hiring](/jobs/)!\n",{"slug":2977,"featured":6,"template":700},"highlights-to-my-first-remote-job","content:en-us:blog:highlights-to-my-first-remote-job.yml","Highlights To My First Remote Job","en-us/blog/highlights-to-my-first-remote-job.yml","en-us/blog/highlights-to-my-first-remote-job",{"_path":2983,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":2984,"content":2990,"config":2994,"_id":2996,"_type":17,"title":2985,"_source":18,"_file":2997,"_stem":2998,"_extension":21},"/en-us/blog/the-remote-manifesto",{"title":2985,"description":2986,"ogTitle":2985,"ogDescription":2986,"noIndex":6,"ogImage":2987,"ogUrl":2988,"ogSiteName":686,"ogType":687,"canonicalUrls":2988,"schema":2989},"The Remote Manifesto","View the GitLab remote working manifesto and the multitude of life-balance benefits it allows our employees to enjoy. Learn more here!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683688/Blog/Hero%20Images/remote.jpg","https://about.gitlab.com/blog/the-remote-manifesto","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The Remote Manifesto\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2015-04-08\",\n      }",{"title":2985,"description":2986,"authors":2991,"heroImage":2987,"date":2992,"body":2993,"category":14},[2648],"2015-04-08","\n\nWe all have been greatly helped by Scrum and the [Agile manifesto](http://agilemanifesto.org/).\nIt freed us from waterfall planning and excessive process.\nBut working remotely and [continuous delivery](/topics/continuous-delivery/) need something more.\n\n\u003C!-- more -->\n\nAt GitLab we love to work remotely, but that means we need to [utilize asynchronous communication](/company/culture/all-remote/asynchronous/) as\neffectively as possible.\n\nThe following are GitLab's seven principles for modern teams working remotely:\n\n## 1. Work from anywhere you want\n\nWorking remotely allows you to be there for the ones you love, and be more\navailable for them. It allows you to see more places, without ever having\nto commute. On top of that, working remotely removes almost every distraction.\n\n## 2. Communicate Asynchronously\n\nDon't try to mimic an office. Communicate using issue mentions and chat tools.\nReduce task switching and put an end to email overload. Choose the right channel\nof communication according to the necessity of the task you're working on. Can\nit wait a few minutes, a few hours, even a few days? Don't take someone from\ntheir work if you don't have to.\n\nIf people _are_ working from the same location, it is important that they do\nnot skimp on writing things down.\n\nEveryone should use the same tools to communicate.\n\n## 3. Recognize that the future is unknown\n\nShip stuff when it's done, not when the sprint (planning) is complete.\n\n## 4. Have face-to-face meetings online\n\nThere is no need to cut back on face-to-face meetings. The technology is readily\navailable and it's easier to use than ever. We're human, we like to converse.\nSome times it can be critical to talk, even if only for a minute, when all\nother communication is written.\n\n## 5. Daily stand-up meetings are for bonding, blockers and the future\n\nDon't talk about what you did yesterday,\nthis is not a reporting moment where everyone tries to look busy.\nRather, kickstart the day with some bonding,\nsolve anything blocking and share future plans so people can plan and act\nand ultimately save time.\n\n## 6. Bond in real life\n\nHanging out together in real life is awesome and totally worth it. These are the\nbest days of our lives. Spend time together and make sure to do more than just\nwork. Do a martial arts workshop together, visit the parents of an employee,\ngo to a festival together: have fun.\n\n## 7. Give credit where it's due and remember to say thank you\n\nAt GitLab we have a Slack channel `#thanks` for this purpose.\nIt always feels good to give and receive a thanks.\n\n![Thanks Slack channel](https://about.gitlab.com/images/thanks.png)\n\nInspired by [this post on pandastrike.com.](https://www.pandastrike.com/posts/20150304-agile)\n",{"slug":2995,"featured":6,"template":700},"the-remote-manifesto","content:en-us:blog:the-remote-manifesto.yml","en-us/blog/the-remote-manifesto.yml","en-us/blog/the-remote-manifesto",{"_path":3000,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":3001,"content":3007,"config":3012,"_id":3014,"_type":17,"title":3015,"_source":18,"_file":3016,"_stem":3017,"_extension":21},"/en-us/blog/how-to-turn-screw-ups-to-your-advantage",{"title":3002,"description":3003,"ogTitle":3002,"ogDescription":3003,"noIndex":6,"ogImage":3004,"ogUrl":3005,"ogSiteName":686,"ogType":687,"canonicalUrls":3005,"schema":3006},"How to turn screw-ups to your advantage","In this post, we look at two instances where we at GitLab dropped the ball, and how we used these errors to learn and improve. Learn more here!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684352/Blog/Hero%20Images/screwup.jpg","https://about.gitlab.com/blog/how-to-turn-screw-ups-to-your-advantage","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to turn screw-ups to your advantage\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Marc Radulescu\"}],\n        \"datePublished\": \"2015-01-23\",\n      }",{"title":3002,"description":3003,"authors":3008,"heroImage":3004,"date":3010,"body":3011,"category":14},[3009],"Marc Radulescu","2015-01-23","\n\nWe at GitLab believe in providing a good service to all our users, be they customers, or non-paying users.\nIn our attempt to support our users, we sometimes make mistakes.\n\nIn this post, I'll be discussing two instances where we at GitLab dropped the ball.\nI'll go through what went wrong and what we did to address our relationship with the affected party.\nThen I'll indicate how that affected our standing with that party.\nIn the end, I'll mention the process we've followed to address our mistakes.\n\n\u003C!-- more -->\n\n## The brownout\n\nGitLab.com is our free SaaS service.\nAt close to 20k monthly active users, GitLab.com is used by many of our users for production.\nWe always notify the community of downtimes on its [twitter account](https://twitter.com/gitlabstatus) and offer [paid email support](/pricing/) for it.\n\nFor years now, we'd been happy to report minimal unplanned downtime on GitLab.com, with planned downtime seldom exceeding one hour.\nOn the 31st of July 2014 though, GitLab.com went offline for a full 8 hours, affecting the workflow of a serious number of users.\n\nThe failure happened in the night between Sunday and Monday in Dutch time, so we only caught wind of the issue in the morning.\nNeither the cause nor the solution were evident though.\nSo despite fervent investigative work, we found ourselves 30 minutes into the call (and 6 hours into the downtime) none the wiser about what had happened.\n\nWe decided to openly admit that we did not know why GitLab.com was down, but to be transparent about our actions to figure out what went wrong.\nGitLab's CEO, Sytse Sijbrandij, decided to make a [public postmortem](https://docs.google.com/a/gitlab.com/document/d/1ScqXAdb6BjhsDzCo3qdPYbt1uULzgZqPO8zHeHHarS0/edit#heading=h.p95p4f6o0twk) which we've posted on [Hacker News](https://news.ycombinator.com/item?id=8003601).\nQuite the number of anonymous users joined our public google doc to get a live feed of our exploration of GitLab, with some even giving feedback on possible actions.\n\nUltimately, we brought GitLab.com back up, apologized to the community, and updated the postmortem file with all the process improvements we've done to make sure a brownout of this magnitude never happens again.\n\nThe Hacker News thread reached the top and kept GitLab in the spotlight for quite the time.\nAnd feedback from the community was [overly positive](https://twitter.com/search?q=gitlab%20postmortem&src=typd) regarding our transparent approach.\nWe believe GitLab has garnered a lot of trust in being both open about the mistake, and quick to take action.\n\n## Waking up at 5 AM for nothing\n\nOne of our lines of business is installing or upgrading GitLab for non-subscribers and basic subscribers.\nWe do this via scheduled consultancy calls.\nOne such scheduled consultancy call ended up not being honored on our side (i.e. halfway through the designated timeframe, one of our service engineers candidly asking on Slack if there's anyone handling it.)\n\nMissing a scheduled call is a big deal in itself.\nMissing one where the system administrator had woken up at 5 AM just so they make sure the servers are running when devops start work, that's really bad.\n\nAs soon as we realized that the customer wasn't being handled we went in, however they had already left the line.\nWe apologized via email and offered to have the call as soon as possible.\nAfterwards, Sytse addressed an official email to them apologizing and offering to have the call for free.\nMoreover, he started an internal postmortem to find out what had happened.\n\nThe postmortem turned out that some steps in the support process had confused our service engineers and needed improvement.\nWe wrote a follow-up to our customer detailing not only where the issue was in our process, but also the detailed steps we took to improve it.\n\nBetween the CEO apologizing and the detailed description of how we were going to improve our process, the customer - whose basic subscription renewal was due within the month - decided to offer their vote of confidence and upgrade to the standard subscription.\n\n## Why the good vibes?\n\nIn both cases we followed the same course of action:\n - be open about the mistake;\n - take swift action to solve the issue;\n - identify what caused the problem;\n - improve internal processes in light of our findings;\n - inform the customer / user about the process improvements.\n\nWhat the above does not highlight though, is one other point we're abiding to: being disciplined about our process.\nAfter failure, make sure to review the faulty process and revise it. Iterate.\n",{"slug":3013,"featured":6,"template":700},"how-to-turn-screw-ups-to-your-advantage","content:en-us:blog:how-to-turn-screw-ups-to-your-advantage.yml","How To Turn Screw Ups To Your Advantage","en-us/blog/how-to-turn-screw-ups-to-your-advantage.yml","en-us/blog/how-to-turn-screw-ups-to-your-advantage",{"_path":3019,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":3020,"content":3026,"config":3031,"_id":3033,"_type":17,"title":3034,"_source":18,"_file":3035,"_stem":3036,"_extension":21},"/en-us/blog/pragmatic-redesign-for-gitlab",{"title":3021,"description":3022,"ogTitle":3021,"ogDescription":3022,"noIndex":6,"ogImage":3023,"ogUrl":3024,"ogSiteName":686,"ogType":687,"canonicalUrls":3024,"schema":3025},"Pragmatic Redesign for GitLab","In this post, we'll show you why we're changingthe the GitLab 7.7 user interface, how we did it and what the end result is.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684299/Blog/Hero%20Images/big.png","https://about.gitlab.com/blog/pragmatic-redesign-for-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pragmatic Redesign for GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dmitriy, Job\"}],\n        \"datePublished\": \"2015-01-16\",\n      }",{"title":3021,"description":3022,"authors":3027,"heroImage":3023,"date":3029,"body":3030,"category":14},[3028],"Dmitriy, Job","2015-01-16","\n\nWe have some big UI changes coming with the release of GitLab 7.7, on January 22nd.\nIn this post, we'll show you _why_ we're changing the user interface, _how_ we did it and _what_ we ended up with.\n\n\u003C!-- more -->\n\n## Redesign to Solve Problems\n\nChanges to the interface are always stressful. So you shouldn't even start to redesign without a list of issues you intent to solve. This way, your users get compensated for the changes with improved usability.\n\nThere are several problems with the current UI of GitLab and it was hard to fix them without making big changes.\nThis is the list of issues we started with:\n\n- Limited space in project navigation. We can't fit all items with counters\n- Two stacked levels of navigation is expensive in screen real estate\n- All navigation is on top. It's annoying to have to scroll up to navigate\n- No space for icons. We love icons!\n- Settings pages add a third level of navigation, which is too complex.\n\n__What it looked like:__\n\n![old screenshot](https://about.gitlab.com/images/redesign/old.png)\n\n\n## Prototype\n\nWe set a simple goal: Maximize improvements with minimal changes. To do this, we started with the existing UI, rather than a blank page.\n\nInstead of Photoshop, we turned to the web inspector in the browser to prototype. Make some changes, screenshot, repeat. Dmitriy noted: \"This reminds of playing old-school video games, where you have to start over with every death.\"\n\nAfter a day of prototyping, we piled up quite some screenshots. We immediately threw away a large part and let the rest sink in.\n\nA few days later, the winner was obvious.\n\n__The winning prototype__\n\n![concept screenshot](https://about.gitlab.com/images/redesign/winner.png)\n\n\n## Get Feedback\n\nChanging the UI is uncomfortable for the end-users.\nYou need time to adapt to the changes.\n\nFor this reason, people often get upset about a redesign.\nEven if your redesign is much better.\n\nWe wanted to brace our community and ourselves for this,\nso we started with a tweet\n\n![tweet with screenshot](https://about.gitlab.com/images/redesign/tweet.png)\n\nWe got lots of great advice and most people seemed to like our idea.\nThe next steps were clear.\n\nWe implemented, improved and polished the design.\nAs we build with and on our community, we couldn't wait to share it.\nWe set up a staging server with the new changes.\nThis way, everyone could try the redesign even before it landed in master.\n\nWorking with an open source product allows us to work with our (awesome) community.\nContributors started submitting merge requests with improvements to our redesign.\nThis was a great sign.\n\n## Evaluate\n\nAt start of this post we described problems we want to solve with redesign.\nAnd during work its important to remember the goal.\nSo we just listed each problem was solved by new layout:\n\nWe started with a list of issues we wanted to solve with the redesign. Focus is important, so we went back and made sure we checked all boxes:\n\n- Limited space in project navigation: fixed by moving it to the side.\n- This also gives us more vertical screen real estate\n-We fixed the navigation, so no more scrolling!\n- Better use of icons! We even introduced a responsive state, where on only the icons are shown.\n- We got rid of the third level of navigation\n\n![desktop screenshot](https://about.gitlab.com/images/redesign/final3.png)\n\n## Finish up\n\nWith the support of the community, we started to build on top of the redesign.  \nWe changed the layout of several pages to make use of the extra space\nand applied another layer of polish.\nWith everything aligned and fixed, we were done.\n\nWe're really excited about the process of redesigning the navigation.\nThe cooperation with the community and implementation of their feedback was invaluable.\nWe hope you'll love it too.\n\nThe new navigation will be released with GitLab 7.7 on January 22nd.\nIf you want to give it a try now, head over to [GitLab.com](https://gitlab.com/users/sign_up),\nas the changes are already live there!\n\n![desktop screenshot](https://about.gitlab.com/images/redesign/final1.png)\n\n![desktop screenshot](https://about.gitlab.com/images/redesign/final2.png)\n\n![mobile screenshot](https://about.gitlab.com/images/redesign/final_mobile.png)\n",{"slug":3032,"featured":6,"template":700},"pragmatic-redesign-for-gitlab","content:en-us:blog:pragmatic-redesign-for-gitlab.yml","Pragmatic Redesign For Gitlab","en-us/blog/pragmatic-redesign-for-gitlab.yml","en-us/blog/pragmatic-redesign-for-gitlab",{"_path":3038,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":3039,"content":3045,"config":3050,"_id":3052,"_type":17,"title":3053,"_source":18,"_file":3054,"_stem":3055,"_extension":21},"/en-us/blog/writing-the-gitlab-book-part-1",{"title":3040,"description":3041,"ogTitle":3040,"ogDescription":3041,"noIndex":6,"ogImage":3042,"ogUrl":3043,"ogSiteName":686,"ogType":687,"canonicalUrls":3043,"schema":3044},"Writing the GitLab book: part 1","Join me in this series of blog articles which explore the process of me writing a book about GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684280/Blog/Hero%20Images/writing.jpg","https://about.gitlab.com/blog/writing-the-gitlab-book-part-1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Writing the GitLab book: part 1\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeroen van Baarsen\"}],\n        \"datePublished\": \"2015-01-05\",\n      }",{"title":3040,"description":3041,"authors":3046,"heroImage":3042,"date":3048,"body":3049,"category":14},[3047],"Jeroen van Baarsen","2015-01-05","\nThis is a series of blog articles about the process of me writing a book about\nGitLab. It will contain information about the process with the publisher, about\nthe different state of minds I went through, and how it feels to actually finish\nthis thing!\n\n\u003C!-- more -->\n\n## Part 1: The preparation\nWhen I received an email from Vinay - an editor for\n[PacktPub.com](http://www.packtpub.com) - with the question if I wanted to write\na book about GitLab, I really thought he was crazy. I'm a developer, not a writer!\nEven though I believed the idea was nuts,\nI presented it to my girlfriend, at first she thought I was kidding, but after\nshe realized I was serious she started to support me right away, and began to\npush to actually do this.\n\nAfter a week or so I decided to actually go ahead and start writing this book!\nIn this blog post I want to explain the process I went through, and what help I got\nfrom the publisher. From starting the chapter outline, to the day the book was\nreleased.\n\nThe book I was going to write was one of the Cookbook series of packtpub.com,\nit's a book with all kind of small things you can do with the subject of the\nbook, in this case GitLab. I had to write it in a way that the reader can\nfollow along, so with steps how to achieve the goal, and with an explanation\nof what the reader has done and how it works.\n\nThe first step was to come up with a Chapter Outline. In this outline I had to\nwrite what chapters I was going to submit, and with what \"recipes\". I came up\nwith the following outline:\n\n1. Introduction and Installation\n2. Explaining Git\n3. Managing users, groups and permissions\n4. Issue tracker and Wiki\n5. Maintaining your GitLab instance\n6. Webhooks, external services and the API\n7. Using LDAP and omniauth providers\n8. GitLab CI\n9. Appendix\n\nThis was accepted by the editor, but with a footnote that I had the freedom to\nchange things around if I felt the need to do so. The next step was to estimate\nthe page count, that's a hard thing to do! Since I did not really know what I\nwanted to write about, how was I suppose to know how many pages it would cover!\nAfter discussing this with my editor he really helped me to figure out this\nthings.\n\nAfter all the above was accepted we had to sign the contract since the book was\naccepted for writing, this was all done true a service called\n[Signable](http://www.signable.co.uk/), if you\never have legal documents to sign remotely, this is a great service to do so! I\nrecommend it!\n\nIn the next part I'll cover the preparations for the actual writing, and the\nwriting itself.\n\n[Go ahead and buy the\nbook!](https://www.packtpub.com/application-development/gitlab-cookbook)\n",{"slug":3051,"featured":6,"template":700},"writing-the-gitlab-book-part-1","content:en-us:blog:writing-the-gitlab-book-part-1.yml","Writing The Gitlab Book Part 1","en-us/blog/writing-the-gitlab-book-part-1.yml","en-us/blog/writing-the-gitlab-book-part-1",{"_path":3057,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":3058,"content":3063,"config":3068,"_id":3070,"_type":17,"title":3071,"_source":18,"_file":3072,"_stem":3073,"_extension":21},"/en-us/blog/my-first-months-at-gitlab-bv",{"title":3059,"description":3060,"ogTitle":3059,"ogDescription":3060,"noIndex":6,"ogImage":2824,"ogUrl":3061,"ogSiteName":686,"ogType":687,"canonicalUrls":3061,"schema":3062},"My first months at GitLab B.V.","I would like to share with you how I got here and how this time has affected my view on a lot of different subjects.","https://about.gitlab.com/blog/my-first-months-at-gitlab-bv","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"My first months at GitLab B.V.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patricio Cano\"}],\n        \"datePublished\": \"2014-12-18\",\n      }",{"title":3059,"description":3060,"authors":3064,"heroImage":2824,"date":3066,"body":3067,"category":14},[3065],"Patricio Cano","2014-12-18","\n\nI started working at GitLab B.V. in October of this year, making this my third month with the company. Working here has\nbeen the best professional experience I've had so far, and I would like to share with you how I got here and how this time\nhas affected my view on a lot of different subjects.\n\n\u003C!-- more -->\n\nThe journey to today started back in late September. I had just finished working on project that a Mexican company hired\nme to do remotely and I was looking for my next challenge. A couple of days passed and I decided to update the GitLab\ninstallation that I use for personal projects. When I visited GitLab's home page, I saw a completely new design. The\nsimplicity and usability caught my eye, so I started exploring the website. A few clicks later I landed on the jobs page.\n\nLooking through their openings I saw one that spoke to me. _Service Engineer_. It really caught my attention that\nthey were looking for someone to work remotely from North or South America. At this point I said to myself: _Self, you\nare in South America! You should apply to this job._\n\nWithout thinking twice, I gathered my resume and sent it to [Sytse](https://twitter.com/sytses) (Our CEO).\n\nThis is where the most exciting part started. I wasn't hoping for such a quick response, but Sytse answered my email within\n2 days and, within 3, I was already talking to him. I never knew a job interview could be such a pleasant experience. We\nstarted talking about the regular stuff, _What working experience do you have?_, _Where did you study?_, _What did you\nstudy?_, etc. After we got these formalities done, we started talking about what goals I have and how they would line up\nwith the company's goals. This is where I think fate intervened, our goals and core values lined up.\n\n> Quick recap of GitLab B.V.'s core values:\n\n>\n- Open Source is always important (Try to work out in the open and radiate your knowledge to the rest of the community)\n- People and their happiness are a top priority\n- Responsibility and Accountability are paramount (There is no boss breathing down your neck every few hours)\n- Freedom of schedule\n\nI was in a place where I wanted to learn as much as I could; to work for a young and fast moving company and I also wanted to\ncontribute to an open source project. GitLab B.V. could offer me these and much more, so it was a no-brainer to accept\nthe offer. So, within two weeks I started working for one of the greatest open source companies out there.\n\n\n## Meeting the team\n\nBefore I started to officially work with GitLab B.V., Sytse invited me to join one of the daily team calls. It was on a\nThursday. I remember it clearly, because I was very nervous. My fears were quickly allayed, though. The team was very welcoming\nand everyone spoke with such a laid back tone that I quickly felt comfortable.\n\nAfter meeting with them via Google Hangouts every day and talking about our days, sometimes also joking around, you actually\nget to know a lot about them, even though you only see them via a webcam. We have had a lot of funny experiences through\nthis medium, like dogs showing up on camera (Job's and recently the little dog I adopted), Haydn joining from the front\nporch of a house right before dawn while in Hawaii (we could even see the sunrise), or Sytse joining from a youth hostel\nwhile in California.\n\n\u003Cimg src=\"/images/team_on_webcam.png\" style=\"float: right; margin-left: 5px;\">\n\nDespite the limitations of only meeting them through a webcam, every single member of the team has made me feel appreciated\nand welcomed and they have always helped me whenever I needed it.\n\nThat is why I'm really looking forward to meeting them soon. We are going to spend a couple of months together working to\nimprove the company and the GitLab project. This meeting is happening at the beginning of next year in San Francisco, where\nHaydn is located.\n\n\n## The actual work\n\nDuring the first days as a Service Engineer, [Job](https://twitter.com/Jobvo) helped me a lot. He guided me through the\nsteps required to solve a ticket posted by a client and showed me the ins and outs of the work. Since we are separated\nby 6 time zones, meaning we have a small time frame when we could actually work together, we decided to set a time\neveryday to discuss all the important issues and to give each other feedback on the work I was delivering.\n\nAfter some guidance and pointers I started working by myself. It seemed like a daunting task at first, specially because\nGitLab B.V. has Fortune 500 companies as clients, but after talking with the people behind these companies I learned\nthey are just regular people. It became evident that I was just helping people to solve problems. It didn't matter if I didn't\nhave the answer right away. I can always ask the incredible team I work with, and no one is going to bite my head off for\nnot knowing something.\n\nBefore Haydn and I joined the team, a normal day of work would start with the Team Call, but since both of us are on the\nother side of the Atlantic, this meeting was moved towards the end of the day for those in Europe, so the guys in the Americas\ncould start the day with the Team Call. Here we discuss the most important topics of the day, like any outstanding issues,\nnew features or comments from the community and our clients. This call is intended to inform everyone of what the\nothers are doing and to ask questions to the whole team.\n\nEach department also has its own daily call to deal with specific topics that might only concern Sales, Development or\nSupport.\n\nGitLab B.V. is a great place to work. I know Sytse has gone to great lengths to give us the best work atmosphere possible\nand to always keep us happy. Each of us has an extra meeting with him each week, where he asks us how happy we are with\nthe job we are doing and if there is anything he and the company can do to improve it.\n\n\n## What I've learned\n\n- It is OK to make mistakes, as long as you always learn from them and do your best to improve.\n- It is OK if you don't know something. You can always learn it later.\n- It is important to not just to ask questions, but to ask the right questions.\n- A distributed team can be just as or sometimes even more productive than a local team.\n- A small problem will turn into a big one if it's not handled in a timely manner.\n\n\nIn conclusion, I'd like to say that I'm really thankful to be where I am right now. These 2 months have been incredible.\nI really like what I do and that has made the time go by so fast. I enjoy working with GitLab B.V. and with a team so\ntalented and focused as this one. I hope to stay here longer and one day tell you about my first 2 years here.\n",{"slug":3069,"featured":6,"template":700},"my-first-months-at-gitlab-bv","content:en-us:blog:my-first-months-at-gitlab-bv.yml","My First Months At Gitlab Bv","en-us/blog/my-first-months-at-gitlab-bv.yml","en-us/blog/my-first-months-at-gitlab-bv",{"_path":3075,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":3076,"content":3081,"config":3085,"_id":3087,"_type":17,"title":3088,"_source":18,"_file":3089,"_stem":3090,"_extension":21},"/en-us/blog/happiness-at-gitlab",{"title":3077,"description":3078,"ogTitle":3077,"ogDescription":3078,"noIndex":6,"ogImage":2824,"ogUrl":3079,"ogSiteName":686,"ogType":687,"canonicalUrls":3079,"schema":3080},"Happiness at GitLab","People are happy at GitLab. Happy people are more productive.","https://about.gitlab.com/blog/happiness-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Happiness at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2014-10-09\",\n      }",{"title":3077,"description":3078,"authors":3082,"heroImage":2824,"date":3083,"body":3084,"category":14},[2523],"2014-10-09","\n\nPeople are happy at GitLab. Happy people are more productive [1].\nThat’s not an easy feat to achieve and something we want to preserve as we grow.\nThis is how we try to make people happy, it may serve as inspiration for your startup (and no more).\n\n\u003C!--more-->\n\n## Measure\n\nEvery month, Sytse (CEO) asks everyone:\n\n> On a scale from 1 to 10 how would you rate your work happiness over the past month?\n>\n> Is there anything you would like to discuss to improve your work happiness?\n\nHe set a high standard: everything below 8 is cause for troubleshooting.\n\n## Prioritise\n\nWe think that a lot of things in life are more important than work.\nIf you have health, family or any personal issues to sort out, you do not have to ask for permission to leave.\nTake care of yourself first.\n\n## Assume independence\n\nNo one likes to be told what to do.\nEveryone at GitLab is expected to take care of their responsibilities.\nLikely, they know more of them than anyone else.\nAs people are happy, they’re also extremely likely to help.\nIf you need any, just ask.\n\nBy assuming independence, people take the liberty to pursue additional goals.\nAn engineer might write a blog post, an account manager might start a new marketing initiative.\n\n## Work whenever, wherever\n\nWorking many hours at end is tiring and commuting is a waste of energy if you prefer to do your work from home.\nMost people [2]  [work from home at GitLab](/blog/how-gitlab-works-remotely/) and take the liberty to visit the gym, supermarket or hairdresser in the middle of the day.\n\nIf you want to meet a friend for lunch, that’s fine too.\nYou’re expected to handle your responsibilities and no one will question you while you do.\n\n## Take care\n\nGitLab is a close group of people.\nWe start our daily meeting with talking about our lives after work.\nBecause we now consist of eight, that takes about 50% of the time of the average meeting.\nWe know that one of us is an avid fire slinger, one just moved house and another spend the night skating.\nIn good or bad times, it’s great to know that your colleagues care.\n\n[1] follow links for papers: [Warwick article](http://www2.warwick.ac.uk/newsandevents/pressreleases/new_study_shows/) & [Quartz article](http://qz.com/190659/happy-people-are-more-productive-especially-if-you-give-them-chocolate)\n\n\n[2] We now have an office in Ukraine! Dmitriy and Valery code there happily together.\n",{"slug":3086,"featured":6,"template":700},"happiness-at-gitlab","content:en-us:blog:happiness-at-gitlab.yml","Happiness At Gitlab","en-us/blog/happiness-at-gitlab.yml","en-us/blog/happiness-at-gitlab",{"_path":3092,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":3093,"content":3098,"config":3102,"_id":3104,"_type":17,"title":3105,"_source":18,"_file":3106,"_stem":3107,"_extension":21},"/en-us/blog/how-gitlab-works-remotely",{"title":3094,"description":3095,"ogTitle":3094,"ogDescription":3095,"noIndex":6,"ogImage":2824,"ogUrl":3096,"ogSiteName":686,"ogType":687,"canonicalUrls":3096,"schema":3097},"How GitLab works remotely","GitLab is a fully remote company, meaning that all of us work 100% of our time from home or any other place in the world.","https://about.gitlab.com/blog/how-gitlab-works-remotely","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab works remotely\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Job van der Voort\"}],\n        \"datePublished\": \"2014-07-03\",\n      }",{"title":3094,"description":3095,"authors":3099,"heroImage":2824,"date":3100,"body":3101,"category":14},[2523],"2014-07-03","\n\nGitLab is a fully remote company, meaning that all of us (currently six) work 100% of our time from home or any other place in the world. We're not the first to do this, [Wordpress](http://blogs.hbr.org/2013/03/how-wordpress-thrives-with-a-1/) does it on a much larger scale, but it might be nice for high-growth startups to see how we handle it. It doesn't require as much tools or effort as you might think.\n\nCurrently we're based in Ukraine (1), Serbia (1) and The Netherlands (4).\n\n\n## Morning Meeting\n\nEvery morning at 8:00 CET (note: you have to know your timezones working remotely) we have a morning meeting with the whole team. Nowadays we use [vLine](https://vline.com/) for this, as Google Hangouts was unreliable with more than four people.\n\n![our morning meeting](https://about.gitlab.com/images/remotely/meeting.png)\n\n\u003C!--more-->\n\nWe keep an agenda in Google Docs, and limit it to 45 minutes. Anyone can add anything on the agenda. Every call starts with a round of 'What did you do yesterday?', where everyone tells what they did *after* work; almost always worth some laughs. Next we go over the points and note in the agenda what the follow-up is for each item.\nIn depth discussions are moved to later or after the call with only the relevant participants, rather than having three people doze off while the rest talks about webserver worker optimization.\n\n\n## Worktimes\n\nPeople are free to choose when to work, but most of us work during regular office hours. The flexibility that remote working brings makes that we don't have to worry about living life at the end of the day. This is a daily sight in our Slack:\n\n![During the day we not only work.](https://about.gitlab.com/images/remotely/slack.png)\n\nEveryone in GitLab actually goes to a gym, does some kind of dancing or sports in another way. As it is with a startup, there is always a lot of work to do today and more tomorrow. We find that it works best to work when you work best.\n\n\n## Communication\n\nWe prefer asynchronous communication and specifically GitLab issues. By mentioning someone, that person can reply whenever they have time to reply. It's usually not a good idea to [interrupt someone](http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer).\n\nFor all other communication we use [Slack](https://www.slack.com) and one of the video call platforms, such as [Google Hangouts](http://www.google.com/hangouts/), [Skype](http://www.skype.com/nl/) and [vLine](https://vline.com/). For communication with our customers, we do the exact same thing.\n\n\n## Social and Happiness\n\nEvery single week, everyone talks individually with Sytse (GitLab CEO) about their happiness. He makes sure everyone is happy and not lacking anything. That works really well.\n\nBesides the morning meetings and weekly calls with Sytse, we also meet up in the physical world to work or -more frequently- eat and drink together. If we can't meet in person, we have a hangout online. With every release of GitLab (22nd of each month!) we have a call together where everyone gets their favorite drink and we just have some -remote- fun together.\n\nWorking remotely, at least for GitLab, is quite a lot of fun.\n\n\n",{"slug":3103,"featured":6,"template":700},"how-gitlab-works-remotely","content:en-us:blog:how-gitlab-works-remotely.yml","How Gitlab Works Remotely","en-us/blog/how-gitlab-works-remotely.yml","en-us/blog/how-gitlab-works-remotely",14,[706,728,749,770,790,812,832,850,871],1758326246323]