Fix broken links

- Line: 1

- Character: 2

To fix markdown errors, review the message. Alternatively, review the relevant section in the [markdown style guide](/docs/markdown-guide).

To fix markdown errors, review the message. Alternatively, review the relevant section in the [markdown style guide](https://handbook.gitlab.com/docs/markdown-guide/).

For all other errors, the error message should provide the information necessary to fix it.

</figure>

<!-- blank line -->

When asked during an [INSEAD](http://insead.edu/) case study interview (shown above) about challenges related to being all-remote, GitLab co-founder and CEO Sid Sijbrandij provided the following reply.

When asked during an [INSEAD](https://www.insead.edu/) case study interview (shown above) about challenges related to being all-remote, GitLab co-founder and CEO Sid Sijbrandij provided the following reply.

> The biggest problem is GitLab not working handbook first. We have an amazing handbook that allows us to collaborate, onboard new people, and think collectively.

>

Once you have the above items, follow these steps to add yourself to the Partners page:

1. Sign into gitlab.com and navigate to the home project of [www.gitlab.com](http://www.gitlab.com) found [here](https://gitlab.com/gitlab-com/marketing/digital-experience/buyer-experience/). Click on the **'Fork'** button at the top right to make a copy of the repository within your account.

1. Sign into gitlab.com and navigate to the home project of [www.gitlab.com](http://gitlab.com) found [here](https://gitlab.com/gitlab-com/marketing/digital-experience/buyer-experience/). Click on the **'Fork'** button at the top right to make a copy of the repository within your account.

1. Next, click on the **'Web IDE**' button to make changes to specific YAML files.

1. Navigate to the '/content' directory in the left pane and you will see the `apps.yml` file within the folder. Click on the file to open it within the WebIDE. Add the following fields to the correct category of the file and enter the following application information into each of the blank fields:

## Assessing the remote workplace experience

1. [RemoteRated](https://remoterated.com/) seeks to rate and rank organizations based on their remote fluency, cutting through what's advertised and focusing on *actual* team member experience.

1. While [Glassdoor](https://www.glassdoor.com/) does not yet offer a dedicated `Remote Experience` filter in reviews, you are able to sort by `COVID-19 Related`. This filter increases the chances of reading reviews relevant to one's remote work experience at an organization. It's also helpful to search for `remote` within an organization's Review section. Glassdoor also offers [remote-related content on its blog](https://www.glassdoor.com/blog/search/remote%20work/).

{{% include "includes/is_this_advice_any_good_remote.md" %}}

The term "documentation" often refers to the process of generating documentation after a change has been communicated. At GitLab, we [write things down](/handbook/values/#write-things-down) *first*, and communicate that (E.g. Document the solution first, *then* announce via Slack or email.). This way there is no need for documentation after the communication, a step that is frequently skipped.

The goal isn't to create a culture of documenting for the sake of documenting; rather, to create an environment where net new solutions are documented in a universally accessible handbook before dissemination, and iterations are made to the universally recognized [single source of truth](/handbook/values/#single-source-of-truth). Each team member must approach documentation the same way, much like an editorial team adheres to a [style guide](/docs/markdown-guide).

The goal isn't to create a culture of documenting for the sake of documenting; rather, to create an environment where net new solutions are documented in a universally accessible handbook before dissemination, and iterations are made to the universally recognized [single source of truth](/handbook/values/#single-source-of-truth). Each team member must approach documentation the same way, much like an editorial team adheres to a [style guide](https://handbook.gitlab.com/docs/markdown-guide/).

## Why does handbook-first matter?

The beauty of using a tool like [GitLab](https://about.gitlab.com/stages-devops-lifecycle) to build and evolve a company handbook is that you don't have to have the full table of contents mapped out in advance. Tools like [Almanac](https://almanac.io), [Notion](https://www.notion.so), and [Guru](https://www.getguru.com) can be used as well. Consider the following as an initial guide for top-level organization, but don't hesitate to deviate based on the size, scope, and needs of your firm.

1. **Company / Building Blocks**: This section houses policies, [values](/handbook/values/), [KPIs](/handbook/company/kpis/)/[OKRs](/handbook/company/okrs), and [cultural principles](/handbook/company/culture) that apply to most or all departments in the organization. The suggested list below was curated by [Luke Thomas](https://twitter.com/lukethomas14) in his book [The Anywhere Operating System](https://friday.app/anywhere).

1. **Company / Building Blocks**: This section houses policies, [values](/handbook/values/), [KPIs](/handbook/company/kpis/)/[OKRs](/handbook/company/okrs), and [cultural principles](/handbook/company/culture) that apply to most or all departments in the organization. The suggested list below was curated by [Luke Thomas](https://twitter.com/lukethomas14) in his book [The Anywhere Operating System](https://www.lukethomas.com/anywhere/).

   - Founding story/history of the company

   - Mission, vision, and values

   - Who we serve (customer personas)