On this page, we're detailing what it takes to effectively and efficiently manage an all-remote company. The pillars of managing an all-remote company are similar to managing any company, but there are certain areas where all-remote leaders should pay particular attention to.
In this video, GitLab co-founder and CEO Sid Sijbrandij and InVision Chief People Officer Mark Frein discuss the future of remote work, including managing all-remote teams at scale.
"How do you manage when everyone is remote?" is a common question for those leading or managing within an all-remote company.
In truth, managing an all-remote company is much like managing any other company. It comes down to trust, communication, and company-wide support of shared goals, all of which aid in avoiding dysfunction.
Remote forces you to do the things you should be doing way earlier and better. It forces discipline that sustains culture and efficiency at scale, particularly in areas which are easily deprioritized in small colocated companies.
It's important to not assume that team members understand good remote work practices. GitLab managers are expected to coach their reports to utilize asynchronous communication, be handbook-first, design an optimal workspace, and understand the importance of self-learning/self-service.
Leaders should ensure that new remote hires read a getting started guide, and make themselves available to answer questions throughout one's journey with the company.
Tomasz Tunguz describes it as such in an article entitled "The early discipline of remote startups."
As company scale, they need to develop infrastructure to successfully manage and coordinate large numbers of people. But in the early days, by virtue of being close to each other physically, it’s easier to delay some of these investments.
A quick hallway meeting of a few key stakeholders might be all it takes to commit to a strategic change. A last-minute all hands roused through word-of-mouth may be the prelude to a fundraising announcement.
For a business that exists somewhere on the distributed-to-remote continuum these options don’t exist, or at least they are significantly harder. These kind of communications are just as necessary within remote or distributed teams, but they require more planning, more foresight in order to be successful.
Some very early stage companies are bringing in these disciplines from the outset, because of the demands of remote work. And this is a wonderful thing, because this investment will compound over the life of the business. - Tomasz Tunguz, venture capitalist at Redpoint Ventures
Transparency is a term that is often tossed around as a value within most companies. In all-remote environments, it is vital that transparency be more than a buzzword, but something that is embraced and allowed to guide every decision.
This will often feel unnatural and uncomfortable — a sign that your organization truly is living out the value of transparency.
It helps to recognize all-remote organizations not as a collection of rigidly structured machines, but as a living, evolving organism. Leaders must trust their colleagues to operate with empathy, kindness, and concern for the well-being of one another, seeing the free flow of information as universally beneficial.
Learn more on how GitLab defines and implements transparency in our Handbook.
In the GitLab Unfiltered video above, Darren (GitLab) and Anna-Karin (Because Mondays) discuss a number of challenges and solutions related to remote work, transitioning a company to remote, working asynchronously, and defaulting to documentation.
Remote work is what led to the development of our publicly viewable handbook, which captures everything you'd need to know about the company. If you can't tell, we like efficiency and don't like having to explain things twice.
Each department and team's quarterly goals, or "objectives and key results" (OKRs), are also clearly documented in our handbook for visibility across the company. We check in on these goals monthly, so there's as much transparency as possible around what each team is accomplishing.
GitLab relies on GitLab to build, sustain, and evolve its company handbook. 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.
We're often asked, "But how do you whiteboard without everyone physically together?" We use Google Docs for collaboration. Every meeting has a Google Doc agenda, which is used for documenting discussions, decisions, and actions. Everyone in the meeting can add notes at the same time, and we even finish each other's sentences sometimes.
By brainstorming in text instead of drawings, we're forced to clearly articulate proposals, designs, and ideas, with less variance in interpretations. A picture may be worth a thousand words, but it's also open to as many interpretations as there are people viewing it.
With Google Docs, we use indentations to go more in-depth on a given topic. This method retains context for comments, discussions, and ideas, even if someone wasn't present for the original conversation.
Documentation also helps with transparency, which is critical to remote work. While decisions made around office water coolers may be familiar in traditional workplaces, input is limited to those present. Those who are not present feel left out, and you're missing an opportunity to hear different perspectives.
The GitLab way of working is more inclusive. By documenting everything, no one is left out of the conversation and a diverse set of perspectives can be heard, not only from GitLab team members but also from customers and community contributors.
In the interview above between GitLab co-founder and CEO Sid Sijbrandij and The New Stack's Alex Williams, Sid explains the importance of "handbook first" when it comes to maintaining velocity and efficiency in scaling a team.
Because we're all-remote, we've been forced to adopt a lot of best practices early on. It scales a lot better. If you're colocated and on the same floor, that works well. If you're on multiple floors in the same building, that starts to deteriorate a bit. If you're in multiple buildings in the same city, that gets worse. If you're in multiple cities, it's harder, and if you're in multiple countries, it starts to break down. It's how most companies work, and that's one of the reasons why companies are really hard to scale.
We never scaled by doing that. We always scaled by writing things down and recording things. As we grow bigger, it's paying off.
At GitLab, we have a rule that says handbook first. If you're going to communicate a change to people, first put it in the handbook and then communicate that change to people.
Our handbook has grown to over 3,000 pages — it's impossible to read all of it — but you're going to read the sections that are relevant to the job that you have to do. We encourage people to record things and share things. We're continuously trying to move conversations out of Slack and into GitLab Issues where everyone can see them. We encourage people to stream to YouTube on GitLab Unfiltered. - GitLab co-founder and CEO Sid Sijbrandij
This is one of the harder things to apply on a daily basis. Taking the time to document a solution isn't very satisfying in the moment, and is easy to deprioritize when other seemingly urgent tasks are vying for your attention.
To relieve tension, empower DRIs to make decisions, and create a more productive future for a team, it's vital to place a high degree of value on pausing to document. This requires leadership to praise and reward the act of documenting, measuring these contributions as diligently as one would measure sales or conversions.
This applies to all companies, though it can produce outsized gains in all-remote organizations where there are fewer opportunities for information to be shared in a physical space.
This also requires humility, and a recognition that human memories aren't perfect. It's impossible to predict the future, but documenting a solution as soon as it is discovered guarantees that the answer will be available should it ever be needed later.
When you open your talent acquisition pipeline to the world, you create an opportunity to hire people in an array of time zones. The ability to hand projects off across time zones is a competitive advantage, but minimizing disconnects, frustrations, and awkwardly-timed meetings requires an intentional approach.
The first step in creating an atmosphere where colleagues are comfortable working asynchronously is to avoid the default mentality as it applies to meetings. By making meetings optional, recording and documenting everything, being diligent to follow an agenda, and leveraging tools like GitLab Issues and Slack, all-remote companies are less reliant on colleagues being online at the same time.
This mentality must be actively reinforced. For example, in team social calls where dozens of people join a video chat to bond as a team, an agenda allows those who cannot make it to add shout-outs or discussion points that a fellow colleague can verbalize. This is an intentional approach to not only working asynchronously, but socializing asynchronously.
[Asynchronous] allows you to reorganize the company in a divisional organization more easily and embrace remote working even if you’re colocated. Everything that works in an async fashion can also work sync but not vice-versa.
Asynchronous versus synchronous is traditionally seen as a process choice. What we've found at GitLab is that it's also a cultural element.
Being fully committed to asynchronous communication can improve morale and wellbeing. If you operate with a mindset of having no other colleagues online at the same time, it forces you to encapsulate your work on a project in a way that can be ingested by others at a time convenient to them. This not only improves documentation, but it relieves everyone of the burdens associated with needing to be at work at the same time.
When you approach your work in this manner, it's less chaotic. The sense of urgency is not on rushing something out, but on the thoroughness and thoughtfulness in documentation. — Darren M., GitLab
There are considerations that go beyond productivity metrics. Companies should ask if demanding synchronous communication is impacting their team's ability to reason and process challenges in the most efficient and healthy way.
With synchronous communication, the problem is that it creates a fake sense of emergency. It creates a heavy interruptive environment with a lot of context switching. You end up highly stressed all the time.
We don't realize it because we, as a society, are so used to our stress. We live with it, and we don't even know what a life without bad stress is. By removing that interruptive effect [with asynchronous communication], that's how we go into the future.
We cannot sustain, as a humanity, this way of life. We cannot keep up with it. — Emna G., founder and CEO at Veamly
All-remote companies that have colleagues spread out across time zones will encounter scenarios where one has to compromise in order to be online at the same time for critical calls, meetings, or projects. However, there is great freedom in being able to disconnect from work at an appointed time with the understanding that your colleagues will communicate asynchronously rather than pressuring you to be available outside of your work hours.
When referencing time and productivity, Remote CTO Marcelo Lebre shares a potent thought on asynchronous communication in a relevant blog post.
Async communication shines with great power here, as it shields everyone’s time and focus while reducing meaningless time sinks. When you’re comunicating async, this types of interruptions happen much less. And the total time that you’re able to do deep work is longer, the chance of achieving Flow much higher.
Paralysis by analysis is something all companies should seek to avoid. In managing through this at an all-remote company, leaders should ensure that all colleagues understand that consensus doesn't scale.
Thus, there should be no goal to achieve consensus. This may feel awkward or unnatural to those coming from colocated corporate environments, but trusting decision makers and living out the value of iteration prevents unnecessary slowdowns in your organization.
By intentionally separating the process of decision gathering and decision making, you provide ample opportunity for everyone to add input, offering up fresh angles for consideration that may well sway the mind of the DRI (directly responsible individual).
It is vital for all-remote companies to foster an atmosphere of trust and learning, such that grudges are not held against decision makers after decision gathering has occurred. At GitLab, this is manifested in our Collaboration value, which includes kindness, sharing, short toes, no ego, and assuming positive intent.
In the GitLab Culture Open House video above, GitLab People Experience Team Lead Beverley R. shares how she uses GitLab to separate decision gathering from decision making, creating a more inspired way of working. A portion of her presentation is transcribed below.
"Not defaulting to a meeting on my part initially felt like a leap while transitioning to an all-remote environment. Using merge requests and issues within GitLab as a tool has fostered a more decisive and efficient way of working, and allows for consensus gathering to happen simultaneous to solution finding and iteration. I have come away feeling so empowered and inspired, having eliminated the massive pressure of finding or presenting a full solution or applying a big bang approach. But rather, starting with and documenting a thought and collaborating from there." — Beverley R., GitLab People Experience Team Lead
In the video above, published on the GitLab Unfiltered YouTube channel, Emilie Schario, Data Analyst, and Sid Sijbrandij, co-founder and CEO, discuss the best way to organize the Metrics pages in the company Handbook.
Iteration is oft applied to engineering, but asking only part of the company to iterate can create discord. All-remote companies must empower every member of the team, across every function and job level, to approach their work with an iterative mindset.
By applying iteration to everything, it removes the barrier of fear and judgement. It also enables faster cycles, and it makes miscues far less damaging.
For example, don't write a large plan, only write the first step. Trust that you'll know better how to proceed after something is released. Iteration can be uncomfortable, even painful. If you're doing iteration correctly, it should be.
Instilling this in an all-remote team is difficult. Most people are naturally inclined to only showcase polished work. In turn, managing this aspect of an all-remote team requires reminders that it's preferred to share unfinished work.
Leaders should work diligently to ensure that teams have a low level of shame and believe that everything is in draft and subject to change.
Learn more about GitLab's value of iteration in our Handbook, and read how one team used survey results to iterate on culture.
There are no corner offices in an all-remote company. Although you should consider the organizational structure that makes the most sense for you (and iterate as the company evolves), one thing that should not change is the level of transparency.
To give each member of the company an equal view of how the organization is structured, how job levels/families are established, and what reporting structures look like, it's wise to consider an org chart accessible to all team members.
This removes ambiguity and enables clearer lines of communication.
We invite other all-remote companies to mirror GitLab's approach to publishing its team structure.
In all-remote companies, it is easy to fall into a situation where you work with a day-to-day lead but report to someone else. There are no physical office structures to reinforce reporting structures.
Leaders in an all-remote company must work to avoid dotted lines and matrix organization. Everyone should report to exactly one person, and that person should understand your day-to-day tasks and be well-positioned to assist you in removing obstacles to thriving in your role.
Whenever there is need to work on a specific, high-level, cross functional business problem, a working group should be established for that need.
Learn more about GitLab's approach in the Leadership section of our Handbook.
Perhaps the easiest way to avoid overanalyzing management in an all-remote company is to focus on results. Focusing on results over hours worked creates an atmosphere where colleagues direct effort on the right things — shipping great code, making a client happy, solving a teammate's problem, etc.
This enables team members to complete their work and turn their attention to non-work activities (family, exercise, reading, caregiving, philanthrophy, etc.) as quickly as possible.
By focusing on results, each team member has less of a mental burden to carry. They're aware that results are what matter as opposed to items like personal success, status, and ego.
Learn more on GitLab's Results value in our Handbook.
All-remote companies should go beyond striving for results. They should add as much detail and clarity as possible to what those results are, and what is measured along the way.
This can be achieved by implementing Objectives and Key Results (OKRs), a widely used framework for setting strategy and removing ambiguity over what matters.
Learn more about GitLab's implementation of OKRs.
Managing results requires clear communication of what's being measured. KPIs strip away guesswork and allow global teams to look at uniform data for making decisions.
It's vital that all-remote companies make KPIs available to all. This not only helps each team member focus their efforts on driving results that move needles that matter, but it creates empathy.
Although KPIs are emotionless, allowing teams to understand what other teams are working towards creates an atmopsphere of compassion, and enables team members to more easily offer help that is specific to an indicator.
Learn more about KPIs at GitLab.
In a conversation with GitLab's Head of Remote about company values, community contributor JD Lewin suggested that much of what leaders concern themselves with (surrounding management) can be addressed by creating a respectful work atmosphere.
When considering a new employer, he noticed that many conversations focused on the work rather than the environment. His articulation of this was powerful, and is transcribed with permission below.
It's not about what the work is. I ask this: "Does the organization support and complement what the rest of my life consists of? Does going to work each day snap into what the rest of my life is?"
For example: being a dad in the early 21st century means you need to show up in your child's life. I need to know that I can step away from my work in the middle of the afternoon if that's what my family requires of me. The culture must support that. In turn, I'll want to work the rest of my life for an employer who creates such an atmopshere.
Waking up and wanting to work each day is a function of the relationship between the people at a company.
There are others who join and travel the world with remote coworking and coliving organizations. Many of our team members appreciate the ability to still be able to work while visiting friends or family away from home.
Even for those who typically work in their home office, this flexibility means they can do things like run errands on a weekday, take their child to school, spend more time with family, or walk their dog during the day.
We have a channel on Slack called
#office-today where our team members can share photos of their work location or view on any given day.
It's important to clarify that being able to work from anywhere does not replace the need to take time off of work.
We recognize how crucial it is to build in time where you can mentally take a break from your work, and as a company, we encourage our team members to do that. Learn more about how time off works at GitLab.
“I work closely with our executive team here, and they have been so supportive and encouraging when family-related conflicts arise. They are constantly reminding me that “family first” is our mantra, and give me ease of mind to take time away when needed. Sid, our co-founder and CEO, told me if it’s a beautiful day out and I just want to go enjoy it, I should do that. Moments like these make me so proud to be a part of the GitLab team." - Cheri, Manager, Executive Assistant
It's sometimes hard to remember to stay active when you work from home. If you're an employer, it's important to be intentional about voicing support for self-care and overall wellness. Here are some tips that might help:
"Getting out of the house before I start my day is very important for me. Either walking the dog or going for a swim to clear my head and get the blood flowing.” - Daniel G., Product Manager
At GitLab, we want to ensure each team member takes care of themselves and dedicates time to stay healthy. You can also join the Slack channel
#fitlab to discuss your tips, challenges, results, etc. with other team members. For other all-remote companies, consider a similar community channel.
Anyone can test their knowledge on all-remote management 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
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,300 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.