What Does "Remote-First" Actually Mean, and How to Tell It From "Remote-Friendly"

A remote-first company treats working remotely as the default, and designs its processes, communication, and decision-making around people who are not in a room together. A remote-friendly company permits remote work as a policy while its actual operations still center on an office.

The words sound similar and are used interchangeably in job listings, but they describe two different working realities. At a remote-first company, your location does not affect your access to information or your prospects. At a remote-friendly one, it often does, whether or not anyone intends it to.

This piece defines both models, explains the failure mode that makes the distinction matter, and sets out the concrete signals you can check before accepting a role.

The core distinction

The cleanest formulation comes from the software company Wildbit, which frames it this way: remote-friendly is a policy, whereas remote-first is an ideology. One is a permission granted to employees. The other is a design principle the organization is built on.

In practice, the difference shows up in where the default sits.

A remote-first company assumes people are distributed and builds accordingly. Decisions are written down rather than made in hallway conversations. Communication defaults to asynchronous and documented. Performance is judged on output rather than presence. Many remote-first companies still maintain an office; the point is not that offices are forbidden but that being in one confers no advantage. As CircleCI describes its own practice, remote-first means remote employees are not an afterthought, which requires deliberate attention to any artifact or ritual that would otherwise disadvantage the people who are not co-located.

A remote-friendly company keeps the office as its operational center and permits remote work alongside it. Typically that means employees may work remotely some days per week, often one to three, and sometimes only certain employees qualify. Processes, meetings, and informal information flow remain tuned to people who are physically present. Remote work is a benefit rather than a given.

Why the distinction matters more than it sounds

The reason this is not a semantic argument is that remote-friendly organizations tend to produce a specific, predictable failure, and it lands on the remote employee.

GitLab CEO Sid Sijbrandij has described the hybrid approach as "the worst of both worlds", on the grounds that without deliberate process change, information becomes siloed inside offices and remote employees end up treated as second-class participants. The result is an unintended hierarchy: the people in the room are heard, recognized, and promoted, while the people on the call are gradually forgotten. Nobody has to intend this for it to happen. It is the natural consequence of a system whose default assumes presence.

The practical consequences for a remote employee at a remote-friendly company are worth naming plainly. Decisions get made in conversations you were not part of, then relayed to you after the fact. Context that circulates informally in an office never reaches you. Visibility, which drives advancement, accrues to people management sees. And because the office remains the center of gravity, a return-to-office policy is always available as a reversal, since nothing structural was ever rebuilt to make distance work.

None of this means remote-friendly companies are bad employers. It means that if you are the remote person at one, you are working against the grain of how the organization actually operates.

The signals that distinguish them

You can usually tell which model a company follows before you accept a role, because remote-first is expensive to fake. It requires visible infrastructure.

Written, public documentation. Remote-first companies write things down as a matter of course, because that is how distributed people stay aligned. GitLab's public handbook, which runs to thousands of pages covering how the company operates, is the reference example. A company that documents its processes publicly, or even extensively internally, has done the work that remote-first requires.

Asynchronous defaults. Look for written standups, recorded meetings, decisions logged in searchable places, and explicit response-time expectations. Remote-friendly companies tend to rely on synchronous communication and expect the team available at the same time. Remote-first companies use meetings for discussion and debate, not for status.

Flexible hours over fixed presence. If there is an expectation that you be online at a particular time simply to demonstrate availability, the company has replicated the office virtually rather than moved past it. Remote-first organizations value flexible working hours and evaluate results over hours logged.

No headquarters advantage. Ask directly whether the leadership team is distributed, whether major decisions are made in a specific office, and how remote employees have been promoted recently. A company where the executive team sits together in one building, and everyone else dials in, is remote-friendly regardless of its stated policy.

Explicit remote policy, stated durably. A company that states a long-term remote commitment, rather than describing remote work as a current arrangement or a perk, is telling you something about its structure. Language such as "remote for now" or "currently remote" signals a policy, not a design.

Onboarding and inclusion mechanics. Remote-first companies build for the remote newcomer: documented onboarding, assigned points of contact, and deliberate inclusion practices. Where onboarding assumes you will absorb things by proximity, distance will be a permanent handicap.

How to check before you accept

Read the company's careers page and any public handbook or "how we work" documentation. Ask in the interview where the leadership team is located, how decisions are recorded, what proportion of the workforce is remote, and how many remote employees were promoted in the last year. Ask what happens when a decision needs to be made and half the team is offline. The answers to those questions describe the working reality far more accurately than the word in the job listing.

The word "remote" in a posting tells you where you may sit. Whether the company is remote-first tells you whether that will cost you anything.

Frequently asked questions

Is remote-first the same as fully remote? No. Remote-first describes the default and the design, not the absence of offices. Many remote-first companies maintain physical offices for people who prefer them. What defines the model is that working from one confers no advantage in information, influence, or advancement.

Is remote-friendly the same as hybrid? In practice they overlap closely. Remote-friendly companies typically operate a hybrid arrangement in which employees work remotely part of the week, often one to three days, while the office remains the operational center. Some restrict remote work to certain roles or employees.

Why do remote employees get overlooked at remote-friendly companies? Because the default assumes presence. Information circulates informally among people who are physically together, decisions get made in unrecorded conversations, and visibility accrues to those management sees. GitLab's CEO has characterized the unmanaged hybrid model as producing exactly this hierarchy, with remote workers treated as second-class.

How can I tell if a company is genuinely remote-first? Look for written documentation of how the company works, asynchronous communication defaults, distributed leadership, results-based performance evaluation, and a stated long-term remote commitment. These require real investment and are difficult to fake.

Can a company with an office be remote-first? Yes, provided the office confers no structural advantage. The test is whether decisions, information, and advancement flow equally to people who are not in it.

References

  1. Wildbit, Remote-first vs. remote-friendly: what's the difference?
  2. Himalayas, Remote-first vs. Remote-friendly: Definitions, Benefits, and Differences (quoting GitLab CEO Sid Sijbrandij).
  3. CircleCI, What it means to be remote-first vs. remote-friendly.
  4. Density, Remote-First vs. Remote-Friendly: Why You Need Both (on GitLab's public handbook and async defaults).
  5. Lano, Remote-first vs. remote-friendly: What's the difference?