remote_work_and_the_gitlab_handbook

Remote Work and The GitLab Handbook

Return to The GitLab Handbook, GitLab, Effective Remote Work, Remote Work Bibliography, Jobs Bibliography, Jobs, Remote DevOps - Remote SRE - Remote CI/CD, Remote Cloud Native - Remote Microservices - Remote Serverless, Remote Security - Remote DevSecOps, Remote Functional, Remote Concurrency, Remote Data Science - Remote and Databases, Remote Machine Learning, Remote Courses, Remote Glossary, Awesome Remote, Remote GitHub, Remote Topics

Fair Use Source: B09Z5F678G (EfctRmWrk 2022)

“ (EfctRmWrk 2022)

The GitLab Handbook

“Before we begin thinking about how to put together a handbook for ourselves, let’s get some inspiration from a company that has made its own handbook the central pillar of how it operates. Not only is it written and updated extensively by everyone who works there—including the founder and executive team—at the time of writing, it’s a staggering 13,804 pages of text, increasing every year. And it’s all available on the Internet. Yep, pretty much all of the company’s workings are completely transparent. How’s that for a radical idea?” (EfctRmWrk 2022)

“Let’s get some background on the company first. GitLab provides a DevOps platform that enables product, development, security, and operations teams to work together concurrently.[67] It’s delivered via a software-as-a-service model. You subscribe and access the product via your web browser. Aside from the quality of the product itself, one of the reasons that the company became widely known is that it was an early mover in its approach to supporting a distributed workforce. The company is fully remote.[68] It has no headquarters or offices and no predetermined work hours. Employees work predominantly asynchronously and only meet once per year at an informal event that enables them to get to know each other better face to face.” (EfctRmWrk 2022)

The strategy that forms the core of how this fully remote company keeps its workers informed and connected with each other is the use of its handbook.[69] It exhaustively documents everything from the formal organization structure and the current company vision, mission, goals, and culture to the minute details of how to raise a ticket to the finance department. It’s all there, and everyone, regardless of where they work in the company, is expected to keep it up to date as a core responsibility of their job.

Changes to the handbook are suggested and merged via the software that the company produces. In fact, one of the first onboarding exercises for new members of the staff is to add themselves to the staff page, which involves forking it, editing it, and raising a merge request for the maintainer of that page to approve. It’s a great example of eating your own dog food.

The handbook was initially created during the early stages of the company. The first ten employees wanted to make information sharing easier so that important information could be immediately discoverable for new employees when they joined the company. This exercise in efficiency soon became core to their culture.

GitLab lists the advantages of its public-facing handbook as follows:

Reading is much faster than listening.

Reading is asynchronous, so you don’t have to interrupt someone or wait for them to become available.

Talent acquisition is easier if people can see what the company stands for and how it operates.

Retention is better if people know what they’re getting into before they join.

Onboarding is easier if you can find all relevant information spelled out.

Teamwork is easier if you can read how other parts of the company work.

Discussing changes is easier if you can read what the current process is.

Communicating change is easier if you can just point to the diff.

Everyone can contribute to it by proposing a change via a merge request.

While it’s possible that some might think that a handbook could be overly rigid or prescriptive in how people get their work done, GitLab argues that writing down its processes and information has the effect of empowering everyone to propose changes and to continually improve how the company works. At the time of writing, the handbook receives tens of modifications every single day.

Your Turn: Browse the GitLab Handbook Before we begin working out how to define your own handbook, go and visit the GitLab handbook and spend some time browsing around:

What do you notice about the way that the handbook is structured? What does this layout mirror in terms of how the company is organized?

See if you can find out what the top priorities are for the company this quarter.

See if you can find out the technology stack that the company is using to develop its software.

Who is the maintainer of the handbook? Who contributes to it the most? How many of the staff members contribute in total?

“What are your thoughts on it being public? Would you feel more or less likely to apply for a job at a company that operates in this way?” (EfctRmWrk 2022)

Fair Use Sources

'Remote Work: Remote First, Working Remotely, Remote Work Bibliography, Remote Teams, Distributed Teams, Work from Home, Questions about Working Remotely, Remote Culture: Remote Work and The GitLab Handbook, Retrofitting Fully Remote Culture; Remote Work Physical and Mental Impact, Remote Interviewing, Remote Meetings, Remote Tools and When to Use Them, Awesome Remote. (navbar_remote_work - see also navbar_jobs)

'Jobs - Work - Employment:' Job Interviews, Coding Interviews - Coding Tests - Stop Interviewing with Companies That Require a Coding Test, Professional Certifications - Programming Certifications (Oracle Java CertificationInterviewing Skills, Job Boards - Job Search, Contracting, Remote Work - Work from Home. (navbar_jobs)


© 1994 - 2024 Cloud Monk Losang Jinpa or Fair Use. Disclaimers

SYI LU SENG E MU CHYWE YE. NAN. WEI LA YE. WEI LA YE. SA WA HE.


remote_work_and_the_gitlab_handbook.txt · Last modified: 2024/04/28 03:41 (external edit)