--- layout: markdown_page title: "Adopting a self-service and self-learning mentality" twitter_image: "/images/opengraph/all-remote.jpg" --- ## On this page {:.no_toc} - TOC {:toc} ## Introduction All-remote companies such as GitLab thrive through [documentation](/company/culture/all-remote/management/#scaling-by-documenting). 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](/company/culture/all-remote/getting-started/), 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 has [assembled a guide to searching the website like a pro](/handbook/tools-and-tips/searching/) — an essential tool for those who are establishing this habit. - The above pairs well with [GitLab's guide to starting a remote job](/company/culture/all-remote/getting-started/). ## Self-service and self-learning in onboarding GitLab's [onboarding process](/handbook/general-onboarding/) 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](/handbook/values/#managers-of-one) — a sub-value of [Efficiency](/handbook/values/#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](/company/culture/all-remote/values/), from a bias towards [asynchronous communication](/company/culture/all-remote/management/#asynchronous), to maintaining a [low level of shame](/handbook/values/#low-level-of-shame), to [doing things that don't scale](/handbook/values/#do-things-that-dont-scale). Through continual [iteration](/handbook/values/#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](/handbook/values/#transparency). ### Proactive approach to answering questions The [People Group](/handbook/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](/handbook/general-onboarding/onboarding-buddies/). To provide context on how new team members can shape the future for colleagues to come by [focusing on improvement](/handbook/values/#focus-on-improvement), an example is showcased below. 1. An onboarding buddy asked a new hire what [feedback](/company/culture/all-remote/effective-communication/#feedback-is-a-gift) she had after two weeks of onboarding. 1. 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. 1. 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_labbers` 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](/handbook/values/#minimum-viable-change-mvc) which can be bolstered in future [iterations](/handbook/values/#iteration). 1. In turn, [this merge request](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/29045) was produced and merged into [Onboarding Buddy Responsibilities](/handbook/general-onboarding/onboarding-buddies/#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](/handbook/values/#write-things-down) 1. [Be respectful of others' time](/handbook/values/#be-respectful-of-others-time) 1. [Responsibility over rigidity](/handbook/values/#responsibility-over-rigidity) 1. [Move fast by shipping the minimum viable change](/handbook/values/#move-fast-by-shipping-the-minimum-viable-change) 1. [Ambitious](/handbook/values/#ambitious) 1. [Ownership](/handbook/values/#ownership) 1. [Sense of urgency](/handbook/values/#sense-of-urgency) 1. [Bias for action](/handbook/values/#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](/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 repositiory, which is why it's so vital to humanize a handbook by empowering [all members of a company to contribute](/company/strategy/#why). ## 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](/handbook/communication/#avoid-private-messages), as this enables deeper [collaboration](/handbook/values/#collaboration). We [encourage](/handbook/values/#share) 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. ## Answer with a link While making conversations [public](/handbook/values/#public-by-default) may feel inefficient in the moment, it is much more [efficient](/handbook/values/#efficiency) 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](/handbook/values/#low-level-of-shame). [Write down any new information discovered](/handbook/values/#write-things-down) 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](https://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work?language=en) where you can get into a [state of flow](https://medium.com/steveglaveski/37-lessons-on-productivity-and-work-from-basecamps-jason-fried-4815bb87c52d). 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](/company/culture/all-remote/people/), family, and community. 1. Allowing the recipient to ingest the answer [on their own time](/company/culture/all-remote/management/#asynchronous). 1. Removing bias from the answer, which empowers the recipient to [iterate further](/company/culture/all-remote/management/#applying-iteration-to-everything) on what is documented by starting a [merge request](/blog/2019/08/02/gitlab-for-the-non-technical/). 1. 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](/handbook/communication/#say-thanks) 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](/handbook/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](/handbook/values/#make-a-proposal) without [fear](/handbook/values/#short-toes) or [ego](/handbook/values/#no-ego), or struggle [doing things themselves](/handbook/values/#do-it-yourself) will need to acclimate quickly. By embracing the [autonomy](/handbook/values/#give-agency) 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](/handbook/values/#make-small-merge-requests), [iterate slowly](/handbook/values/#when-we-iterate-slowly), rely on themselves as a [fact-finding resource](/handbook/values/#tenacity), and to not lean on someone else to do something [you're capable of accomplishing](/handbook/values/#do-it-yourself). 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](/handbook/values/#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. ## 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](https://docs.gitlab.com/ee/user/project/merge_requests/) and adding a contribution to this page. Return to the main [all-remote page](/company/culture/all-remote/).