A forcing function is any task, activity, or event that forces you to take action and produce a result. This term comes from interaction design, where it refers to a constraint that shapes behavior.
Transitioning to remote is challenging but worthwhile. For many leaders, the question of "How do we do it?" is a giant one. Whether it's entirely disconnecting from offices and going all-remote, or attempting to create a level playing field for in-office and remote team members in a hybrid-remote arrangement, leaders should consider using some of key forcing functions outlined below to ensure a commitment to remote-first practices. At GitLab, we use forcing functions to empower and encourage team members to use best practices and to reinforce our values.
Use the content from our presentation at GitLab Culture Open House 2020, which details tactical, actionable steps to send a clear message that leadership is serious about implementing remote-first in the organization. There are many forcing functions you can choose to implement that will help encourage remote-first mindsets and behavior.
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, 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 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).
This not only forces work to happen in the open, where more people can provide feedback as they work to see each other succeed, but it's also a far more inclusive way to work.
In the video above, GitLab's Head of Remote discusses the topic of scaling culture during an interview with Stuart Miniman, host of theCUBE and GM of Content at SiliconANGLE Media. 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 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
The only way a hybrid-remote setting is beloved long-term is if leadership treats everyone as remote, regardless of where they are. The office must simply be regarded as another single-person dwelling. It's simply a place one goes to work remotely, treated the same as a home or apartment.
The office must become a physical embodiment of a carefully curated remote culture, not vice-versa. The culture cannot be tied to a physical location, or else those outside of the office will always feel deprioritized — like outsiders that don't belong.
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 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. This enables people to openly converse about informal topics such as parenting, fitness, travel, music, and mental health.
Because we do not use a chat tool such as Slack for work, we need a tool that's built for remote collaboration. GitLab is a collaboration tool designed to help people work better together whether they are in the same location or spread across multiple time zones. Originally, GitLab let software developers collaborate on writing code and packaging it up into software applications. Today, GitLab has a wide range of capabilities used by people around the globe in all kinds of companies and roles.
You can learn more at GitLab's remote team solutions page.
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, 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.
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.
Remote teams have an easier time speaking freely about travel. Because they're remote, they're autonomous by default, and location is decoupled from output. 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 by Deel to create an opt-in program 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.
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 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.
Every meeting should be a review of a concrete proposal, and only called when it will lead to a more efficient outcome than would be possible asynchronously.
If you get a meeting invite without an agenda — and it's not an informal coffee chat — 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.
Put simply, meeting organizers are on the hook for documentation. They can either document themselves, transcribe with a tool like Otter, 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 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 first. While this may seem absurd, it's a key example of going slow to go fast.
In the GitLab Unfiltered 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" approach to companywide documentation.
I think documentation has to be instilled as a value. It has to start there, and the whole leadership team in an organization has to be onboard.
All of 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.
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., Senior Product Manager, GitLab
In the video above, Darren Murph, Head of Remote at GitLab sits down with Jeff Frick for a Digital CUBE Conversation about the way the global Covid-19 crisis is affecting the way people work, and work from home. Discover more in GitLab's Remote Work playlist.
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 which are relavant to your firm.
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 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. This is a more inclusive and healthier way of working.
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.
In the GitLab Unfiltered video above, Darren (Head of Remote, GitLab) and two co-founders at Yac discuss the significance of relying on a company handbook as the single source of truth.
"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
Values drive action. If your values are structured to encourage conventional colocated workplace norms (such as consensus gathering, or recurring meetings with in-person teams), rewrite them.
Feel welcome to study GitLab's values, and learn more on how this collection contributes to an all-remote environment.
We've gathered our top 5 tips for successful remote working:
Despite having many advantages, all-remote work can have some downsides.
In this video, GitLab Director of Technical Evangelism Priyanka Sharma discusses pros and cons of remote working with a panel of experts from TFiR, Arm and ISG Research.
You can do a deep dive on remote-work challenges and solutions here.
Anyone can test their knowledge on How to use forcing functions to work remote-first 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 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.
GitLab believes that all-remote is the future of work, 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 and adding a contribution to this page.
Return to the main all-remote page.
