All-remote companies such as GitLab thrive through documentation. Crucially, this requires every team member to be equally invested in perpetuating documentation, creating a virtuous cycle of self-searching, self-service, and self-learning.
It's not what you know. It's knowing where to look. This is true at GitLab and other organizations that are intentional about documenting processes, and it is entirely counter to how typical work environments are structured.
From the very first day at GitLab, it is imperative that new team members operate with the assumption that their questions are already answered. This is a profound process shift that may feel unnatural and inefficient.
For many — particularly team members joining from a colocated environment — this requires a retraining of sorts. You must force yourself to not default to tapping on the virtual shoulder of someone as soon as an inquiry comes to mind. Rather, team members should redirect that effort to searching.
GitLab's onboarding process is highly unique. Each new hire is assigned an onboarding issue with dozens upon dozens of tasks, broken down into small, digestible chunks. While the issue guides new hires to complete certain tasks on certain days, being a manager of one — an operating principle of Efficiency — applies from the very beginning.
There is a stark lack of hand-holding. Those who prefer to be heavily guided may struggle with this, but acclimating is vital.
This way of working permeates the GitLab culture, from a bias towards asynchronous communication, to maintaining a low level of shame, to being deliberate about scale.
Through continual iteration, the onboarding issue has become a comprehensive list. Those coming from colocated backgrounds may view this as overwhelming, or perhaps even unnecessary. GitLab would rather you be inundated with useful information to absorb at your own pace than be uninformed. It comes naturally when a company values transparency.
The People Group maintains onboarding issues. This group attempts to proactively answer any question you may have before you have to ask it. If, after completing the onboarding issue, a new hire still has a question about process that wasn't answered, the natural next step is to work with a subject matter expert at GitLab to answer, then document.
Whenever a new hire brings up a valid process point that leads to a previously undocumented answer, the default mindset should be to answer and document right away. This requires a mindset of self-service, self-searching, and self-learning. It also requires diligence and empathy.
GitLab's use of onboarding buddies is well documented. To provide context on how new team members can shape the future for colleagues to come by focusing on improvement, an example is showcased below.
#new_team_members Slack channel) to organize an optional group call with each other for those who prefer a more social new hire orientation experience. This may not be a comprehensive solution, but it is a minimal viable change which can be bolstered in future iterations.
The ideal response to learning a new answer at GitLab is to document said answer in an act of paying it forward, such that every new hire that comes after will be able to find this information more quickly. Plus, it removes the companywide burden of having to develop this answer from scratch again. This mentality encompasses many operating principles.
For many companies, the frenetic pace of business creates a false sense of justification for bypassing documentation. Once this happens, the only way to consistently learn is to ask another person, over and over. At scale, this is an extraordinarily wasteful process that leads to exhaustion, watered-down instructions, and huge knowledge gaps as team members cycle in and out.
However, most employees are not empowered to shift an entire company culture to one that favors documentation. Thus, one typically builds a skillset of how and when to ask other humans in order to extract information vital to achieving their goals. They know it's a suboptimal approach, but may feel that they have no reasonable alternative. When you aren't given a handbook that is regularly updated and reliably actionable, it feels odd to seek answers first in documentation.
Humans tend to trust other humans more than words written in an online repository, which is why it's so vital to humanize a handbook by empowering all members of a company to contribute.
A commonly-rooted habit that requires breaking at GitLab is this: oftentimes, people assume that by asking someone a question privately, they are doing everyone else a favor by bothering the fewest number of people.
At GitLab, we flip that notion on its head. We prefer public discourse over private, as this enables deeper collaboration. We encourage team members to consider making private issues public wherever possible so that we can all learn from the experience, rather than requiring a small group to spend effort translating those learnings in the future.
While making conversations public may feel inefficient in the moment, it is much more efficient long-term. It leads to significantly fewer interruptions. Team members should search for their own answers, and, if an answer is not readily found or the answer is not clear, ask in public as we all should have a low level of shame. Write down any new information discovered and pay it forward so that those coming after will have better efficiency built on top of practicing collaboration, inclusion, and documenting the results.
Minimizing interruptions creates a less chaotic workplace for all, and leads to something that is increasingly precious: long, uninterrupted periods of time where you can get into a state of flow.
By answering with a link, you're doing the following:
For people going out of their way to help you, also consider sharing public kudos in GitLab's #thanks channel, showcasing the link to the entire channel and celebrating specific values that were lived in the process.
A common question for someone joining GitLab, or any company, is this: "What does a successful 3/6/12 months in the role look like?"
While the answer to this will vary depending on role level and department, it is possible to answer this more broadly. Regardless of where you operate within the organization, your ability to self-search, self-learn, and self-service will undoubtedly impact your success at GitLab.
GitLab's values are more than words on a wall. They are exercised daily and guide every decision.
Those who prefer significant amounts of guidance, are uncomfortable finding answers and proposing small changes without fear or ego, or struggle doing things themselves will need to acclimate quickly.
By embracing the autonomy that comes with a role at GitLab, you're able to ship more, and do so more quickly. Success is tied to one's ability to ship quickly, iterate deliberately, rely on themselves as a fact-finding resource, and to not lean on someone else to do something you're capable of accomplishing.
Success is also determined by your ambition to find and document answers that do not yet exist, collaborating with a spirit of blameless problem solving.
Said another way, success is less about specific outcomes and more about the way you approach work. It's impossible to know what will come your way on a day-to-day basis, but you can control the methodologies that drive your actions.
Complete all knowledge assessments in the Remote Work Foundation, to receive the Remote Foundations Badge in GitLab Learn If you have questions, please reach out to our Learning & Development team at learning@gitlab.com.
GitLab is one of the world's largest all-remote companies. We are 100% remote, with no company-owned offices anywhere on the planet. We have over 1,500 team members in more than 65 countries. The primary contributor to this article (Darren Murph, GitLab's Head of Remote) has over 15 years of experience working in and reporting on colocated companies, hybrid-remote companies, and all-remote companies of various scale.
Just as it is valid to ask if GitLab's product is any good, we want to be transparent about our expertise in the field of remote work.
Effective onboarding and positively influencing workflow habits is a challenge for all companies. If you or your organization has an experience that would benefit the greater world, consider creating a merge request and adding a contribution to this page.
Return to the main all-remote page.