---
layout: markdown_page
title: "How to use forcing functions to work remote-first"
twitter_image: "/images/opengraph/all-remote.jpg"
---
## On this page
{:.no_toc}
- TOC
{:toc}
## Introduction
[Transitioning](/company/culture/all-remote/transition/) to remote is challenging but worthwhile. For many leaders, the question of "How do we do this?" is a giant one. Whether it's unwinding from offices entirely and going [all-remote](/company/culture/all-remote/terminology/), or attempting to create a level playing field for in-office and remote team members in a [hybrid-remote](/company/culture/all-remote/hybrid-remote/) arrangement, leaders should consider key forcing functions to ensure a commitment to remote-first practices.
On this page, we're detailing tactical, actionable steps that will send a clear message that leadership is serious about implementing remote in the organization.
## Expire your Slack or Teams messages after 90 days
{: .shadow.medium.center}
When you work synchronously, tools like Slack or Microsoft Teams enable conversations that can go on for months. The upside is the potential for immediate replies. The downsides are numerous. A never-ending strand of red bubbles (unread notifications) can take a toll on one's [mental health](/company/culture/all-remote/mental-health/), and completely destroys a human's ability to find a state of flow.
Letting Slack pings dictate your working life is a recipe for burnout. It's also a terrible way to work. Messages are [siloed](/handbook/communication/#avoid-private-messages) outside of public channels, so it's impossible for others to transparently see what others are working on.
To solve for this, only pay for a chat plan that retains messages for 90 days or less. If your team knows that they'll never be able to query a message thread for context on a project, they will not use the tool for work. Instead, they'll be forced to start, discuss, and complete work in the place where it should end up. At GitLab (the company), this is GitLab ([the product](/stages-devops-lifecycle/)).
This not only forces work to happen [in the open](/handbook/values/#transparency), where more people can provide feedback as they work to [see each other succeed](/handbook/values/#see-others-succeed), but it's also a far more inclusive way to work.
*In the [video](https://youtu.be/IU2nTj6NSlQ) above, GitLab's Head of Remote discusses the topic of scaling culture during an interview with [Stuart Miniman](https://twitter.com/stu/), host of [theCUBE](https://www.thecube.net/) and GM of Content at [SiliconANGLE Media](https://siliconangle.com/). A portion is transcribed below.*
> Remote is much better for your mental health and sanity than other settings, and it's because it forces you to work asynchronously. At GitLab, we have people spread across 65 countries, so almost every time zone is covered. But, that also means that someone on your team is likely in a vastly different timezone. In fact, they may be asleep the entire time you're up working.
>
> With an asynchronous mindset, it enables all of us to take a step back and assume that whatever we're doing is done with no one else online. It removes the burden of a nonstop string of messages where you're expected to respond to things immediately.
>
> From a mental health standpoint, when you have an entire company that embraces that, we're all given a little more breathing room to do really deep work that requires long periods of uninterrupted time.
>
> As a society, we're getting close to [a tipping point](https://medium.com/@gcvp/going-distributed-choosing-the-right-remote-friendly-team-model-6a04f833267c) where people are at their limit on how many more messages, or emails, or seemingly urgent pings they can manage while also doing their job well. We may be a bit ahead of the curve on that, but my hope is that the industry at large embraces asynchronous communication, and allows their people more time to actually do the work they were hired to do
## Use chat tools strictly for informal communication
When your chat tool(s) expire messages after 90 days, it renders it useful for only one primary thing: informal communication. This is intentional.
In all-remote settings, [informal communication](/company/culture/all-remote/informal-communication/) must be structured. The beauty of using a tool like Slack purely for this purpose is it enables even more genuine and intimate conversations than you'd typically experience in a colocated space.
For example, GitLab has group, location, section, values feed, and social group [channels](/handbook/communication/chat/). This enables people to openly converse about informal topics such as parenting, fitness, travel, music, and mental health.
## Implement discretionary bonuses for exemplifying values
Intentional companies can surface their values during onboarding, but you should consider how this will be reinforced on an ongoing basis. Forcing your company to honor and respect remote employees, and not forget their presence and value, can be done very simply: implement [discretionary bonuses](/handbook/incentives/#discretionary-bonuses), where the only mechanism for earning one is to be nominated by another team member for living out one or more of the [company values](/handbook/values/).
These bonuses aren't about sales targets, added revenue, or working late. They are *purely* about values. When you create an incentive program that recognizes someone publicly for exemplifying a value, this serves as a constant reminder to all that values have meaning, and they should be lived out daily β even when (and especially when) it's difficult.
At GitLab, we celebrate each discretionary bonus which is earned and bestowed, with a few sentences explaining which value(s) were exemplified in a public Slack channel. This gives context to how a value can be lived out, and serves as a model for everyone else to replicate.
When you give the bonus and celebrate the bonus in Slack, it also serves as a reminder to in-office colleagues that values can be lived out by team members you don't see. This has long-tail benefits as well, like removing barriers for praise, promotion, and career growth for remote team members.
## Use technology to remind people to take time off
Remote teams have an easier time speaking freely about travel. Because they're remote, they're autonmous by default, and location is [decoupled from output](/handbook/values/#measure-results-not-hours). In-office teams face stigmas related to conversing about vacations in the office.
An easy way to force this toxic cloud of taboo out of your team is to use a digital program to remind team members to take time off. At GitLab, we've worked with [PTO Ninja](https://treehoppr.com/pto-ninja) to create an [opt-in program](/handbook/paid-time-off/#monthly-reminder-to-consider-taking-pto) which sends a direct message on the first working day of each month asking the individual to consider what time they plan on taking this month to rest and recharge. It also gives permission to the team member to directly confront their manager if they feel as if they cannot possibly take time off.
GitLab's verbiage is below.
> Hi there! Have you thought about what days you may take off this month? π΄β°οΈ We want to make sure you stay healthy! If you feel like you canβt reasonably take time off, feel welcome to add this note to your next 1:1 with your manager and discuss further. Learn more about paid time off at GitLab: `https://about.gitlab.com/handbook/paid-time-off/`
This remote-first behavior triggers a healthy reminder for people to chat about travel or spending time in their community β informal communication that is centered about prioritizing [mental health](/company/culture/all-remote/mental-health/).
## Everyone must use their own webcam (no hybrid calls)
{: .shadow.medium.center}
Imagine this scenario. You're in a conference room with five others, being joined by a group of five remote team members in a video call.
Those in the office are inclined to use the office camera, dialing in as a single participant with five heads and voices. This creates an unlevel playing field, where the remote team members are immediately seen as inferior, and are given a substandard call experience. (We've detailed why [hybrid calls are horrible](/handbook/communication/#hybrid-calls-are-horrible) in the Communication section of the GitLab handbook.)
The forcing function here is to mandate that everyone, at all times, use their own webcam. This would mean that each individual in the aforementioned conference room would need to open their own laptop and join. This would feel remarkably awkward to those in the room, which is precisely the point. The next logical question is the intended conclusion: *why did everyone in the office bother commuting*?
The call can be taken from anywhere, and your remote team will function more cohesively if you simply [close the office](/company/culture/all-remote/transition/#close-the-office).
## Decline all meetings which lack an agenda
Every meeting should be [a review of a concrete proposal](https://about.gitlab.com/handbook/values/#make-a-proposal), and only called when it will lead to a more efficient outcome than would be possible [asynchronously](/company/culture/all-remote/asynchronous/).
If you get a meeting invite without an agenda β and it's not an [informal coffee chat](/company/culture/all-remote/informal-communication/#coffee-chats) β leaders should empower their teams to decline. This will force team members to think long and hard on whether a meeting is necessary, and the burden of adding an agenda shows those who are invited that the organizer is proactively thinking through the meeting's purpose.
It's also respectful, as it allows those in different time zones the opportunity to contribute questions and topics in advance, asynchronously.
## Mandate meeting organizers document all takeaways
Put simply, meeting organizers are on the hook for documentation. They can either document themselves, transcribe with a tool like [Otter](https://otter.ai/login), or line up a dedicated scribe for the call.
It's not enough to merely document the call. The meeting organizer must also contextualize key takeaways using [low-context communication](/company/culture/all-remote/effective-communication/#understanding-low-context-communication) and add to relevant handbook pages. This ensures that decisions and progress are made public to the entire team.
This added burden forces team members to consider approaching work [asynchronously](/company/culture/all-remote/asynchronous/) first. While this may seem absurd, it's a key example of [going slow to go fast](/company/culture/all-remote/handbook-first-documentation/#make-handbook-first-documentation-a-value).
*In the [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A) video above, Darren (Head of Remote, GitLab) and Gabe (Senior Product Manager, GitLab) talk on the topic of going slow to go fast, as well as the importance of a "[handbook-first](/handbook/handbook-usage/#why-handbook-first)" approach to companywide documentation.*
> I think [documentation](/company/culture/all-remote/management/#scaling-by-documenting) has to be [instilled as a value](/handbook/values/#write-things-down). It has to start there, and the whole leadership team in an organization has to be onboard.
>
> All of [leadership](/handbook/leadership/) needs to understand the importance of documentation β not just with lip service. A true, genuine understanding of its value. If they *truly* understand the value of it, they'll emanate that to their direct reports.
>
> For companies looking to transition to fully remote, a helpful step for leadership is to say: "OK, we're going to be remote-first as a start." This means that a company in transition would optimize everything in its physical office space to be remote-first. Instead of optimizing conference rooms with lots of tables, for instance, you have each employee sit in their own office and wear headsets all day. This is how you prevent remote employees from feeling [disconnected and isolated](/company/culture/all-remote/hybrid-remote/#disadvantages-to-hybrid-remote).
>
> This is going slow to go fast. Lots of energy up front β you go slow β but that accelerates things dramatically a year or so down the road. β *[Gabe W.](https://gitlab.com/gweaver), Senior Product Manager, GitLab*
## Make the executive team remote
The *quickest* way to send the *clearest* signal that remote is the future is to start at the top of the organizational chart. Remove execs from the office, and youβll quickly figure out what gaps you need to fill with tools and process.
If you force the executive team to work remotely for a meaningful amount of time (over one month, in most cases), you'll discover communication gaps, as well as voids in tooling and process.
While each company is unique, this approach ensures that you develop a priority list of elements to address in [going remote](/company/culture/all-remote/transition/) which are relavant to your firm.
## Remove companywide "set working hours"
{: .shadow.medium.center}
So long as your company adheres β even if unofficially β to set working hours, you'll be biased towards candidates who are in your preferred time zone.
The only way to remove that bias and open your company to a [truly global and diverse workforce](/company/culture/all-remote/hiring/) is to destroy the epicenter of power as it relates to working hours.
This also enables your workforce to design their work around their life, empowering them to be [managers of one](/handbook/values/#managers-of-one). This is a more [inclusive](/blog/2019/12/06/how-all-remote-supports-inclusion-and-bolsters-communities/) and [healthier](/company/culture/all-remote/mental-health/) way of working.
## If it's not in the handbook, it doesn't exist
Your goal should be to answer everything with a link. If a team member asks you a question that you can't answer with a link, you should work according to company values to generate an answer, and immediately document that answer in the appropriate place in the handbook. This ensures that anyone who has the same inquiry at any point in the future will not have to impede on anyone's time to find the answer.
Read more about this forcing function in GitLab's guide to [adopting a self-service and self-learning mentality](/company/culture/all-remote/self-service/).
*In the [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A) video above, Darren (Head of Remote, GitLab) and two co-founders at [Yac](https://www.yac.chat/) discuss the significance of relying on a company handbook as the [single source of truth](/company/culture/all-remote/handbook-first-documentation/#creating-a-home-for-a-single-source-of-truth-ssot).*
> "GitLab's founders made a fundamental decision early on to work handbook-first to document everything about the company. Everyone who has joined since benefits from that initial step.
>
> In my onboarding process, I simply read and ingested what was already documented. There was no ambiguity. A few weeks in, if I had a question, I simply queried the handbook to find an answer.
>
> At a conventional company, you have to tap someone on the shoulder, interrupt their day, and ask them to walk you through it. At scale, the ability to query a handbook for solutions creates massive efficiencies.
>
> You have hundreds or thousands of people that are able to self-service and find the answers they need when they need them, regardless of what time zone they're in, instead of having to bother someone to find something that's already written down." β *Darren M., Head of Remote at GitLab*
## Reconsider what your values reinforce
Values drive action. If your values are structured to encourage conventional colocated workplace norms (such as [consensus gathering](/company/culture/all-remote/management/#separating-decision-gathering-from-decision-making), or recurring meetings with in-person teams), rewrite them.
Feel welcome to study [GitLab's values](/handbook/values/), and learn more on how this collection [contributes to an all-remote environment](/company/culture/all-remote/values/).
## Is this advice any good?
{: .shadow.medium.center}
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](/handbook/marketing/readmes/dmurph/), GitLab's Head of Remote) has over 14 years of experience working in and reporting on colocated companies, [hybrid-remote](/company/culture/all-remote/hybrid-remote/) companies, and all-remote companies of various scale.
Just as it is valid to [ask if GitLab's product is any good](/is-it-any-good/), we want to be transparent about our expertise in the field of remote work.
## Contribute your lessons
GitLab believes that all-remote is the [future of work](/company/culture/all-remote/vision/), and remote companies have a shared responsibility to show the way for other organizations who are embracing it. If you or your company 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/).