Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Adopting a self-service and self-learning mentality

On this page


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.

Assume your question is already answered

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.

Self-service and self-learning in onboarding

GitLab's onboarding process is highly unique. Each new hire is assigned an onboarding issue with dozens upon dozens of tasks, broken down in small, digestible chunks. While the issue guides new hires to complete certain tasks on certain days, being a manager of one — a sub-value 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 doing things that don't 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.

Proactive approach to answering questions

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.

Documentation in action

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.

  1. An onboarding buddy asked a new hire what feedback she had after two weeks of onboarding.
  2. She responded with feedback that the process felt siloed, and lacked the sense of community she had experienced prior. She referenced onboarding in a colocated space, where all new hires in a given week were forced to be in the same physical setting regardless of what department they would go on to serve in. This created a sense of belonging — that they were all in this thing together.
  3. In discussing a remote solution to this, it was determined that a merge request should be put forth to encourage new hires (announced within the #new_team_members Slack channel) to organize an optional group call with each other for those who prefer a more social new hire orietation experience. This may not be a comprehensive solution, but it is a minimum viable change which can be bolstered in future iterations.
  4. In turn, this merge request was produced and merged into Onboarding Buddy Responsibilities, creating a path for a more social onboarding experience for every successive wave of new team members.

Paying it forward

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 sub-values.

  1. Write things down
  2. Be respectful of others' time
  3. Responsibility over rigidity
  4. Move fast by shipping the minimum viable change
  5. Ambitious
  6. Ownership
  7. Sense of urgency
  8. Bias for action

Why is self-searching and self-learning uncomfortable at first?

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.

Public over private

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 amount 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 less 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.

  1. Making your day more efficient, enabling you to disengage with work earlier and enjoy your surroundings, family, and community.
  2. Allowing the recipient to ingest the answer on their own time.
  3. Removing bias from the answer, which empowers the recipient to iterate further on what is documented by starting a merge request.
  4. Leading by example, showing new team members that they too should strive to answer via documentation.

Say thanks

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.

How self-learning leads to success in your role

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 slowly, 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.

GitLab Knowledge Assessment: Adopting a Self-Service and Self-Learning Mentality

Anyone can test their knowledge on Adopting a Self-Service and Self-Learning Mentality by completing the knowledge assessment. Earn at least an 80% or higher on the assessment to receive a passing score. Once the quiz has been passed, you will receive an email acknowledging the completion from GitLab. We are in the process of designing a GitLab Remote Certification and completion of the assessment will be one requirement in obtaining the certification. If you have questions, please reach out to our Learning & Development team at

Is this advice any good?

GitLab all-remote team illustration

GitLab is the world's largest all-remote company. We are 100% remote, with no company-owned offices anywhere on the planet. We have over 1,200 team members in more than 65 countries. The primary contributor to this article (Darren Murph, GitLab's Head of Remote) has over 14 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.

Contribute your lessons

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.