When your remote team makes decisions while you're offline

Working across time zones asks you to trust colleagues to carry on while you're away. You should be able to finish your day without staying online to protect your place in every discussion. In return, decisions will sometimes move forward without you.

The difficult part comes when you return with something that could change the choice. Perhaps you know why a similar idea failed before, or you work with the customers who will feel its effects. A clear account of what happened helps you catch up. Your chance to influence what happens next depends on how much remains open.

That distinction matters when you're considering a remote job. Two teams can both document their decisions carefully while giving an offline colleague very different opportunities to shape them. Even on an async-first team, freedom to choose when you respond has to coexist with decisions that keep moving.

What is still open when you return?

Consider a hypothetical customer-support team changing its weekend coverage. You finish work before a discussion begins elsewhere. The next morning, you see the proposed schedule and notice that one region would regularly handle the busiest hours with fewer people.

If the schedule is a proposal, your experience can help shape it before anyone commits. If colleagues have tentatively agreed on it, there may still be time to adjust the arrangement. If the change has already been announced, you are asking people to revisit a commitment. The same observation arrives at three different moments, with different consequences.

GitLab makes a useful distinction in its communication guidance. For a proposal, it calls for an explanation of what people can influence and a timeline for gathering feedback. For a completed decision, it describes a place to submit feedback while acknowledging that the decision may not change soon.

Both allow a response. Only one explicitly invites you to help choose the outcome before it is settled. An announcement can be honest and informative without offering that opportunity.

GitLab's public handbook provides documented examples throughout this article. It describes intended practices; it does not establish how every employee experiences them, or how another company works.

Giving someone time to contribute has a cost

An offline colleague needs an opportunity that reaches into their working day. A discussion that opens and closes while they're asleep can be well documented and still leave them out of the choice.

In the support-schedule example, time to review could reveal a coverage problem before the change is announced. But colleagues waiting for the schedule may also need to arrange childcare, book appointments or plan their own weekends. Leaving a decision open has consequences for them too.

One way to make room for absent colleagues is to leave an outcome open for confirmation after a meeting. GitLab's remote meeting guidance suggests considering 24–48 hours for this when a meeting falls outside some participants' time zones. This is a recommendation for those circumstances, with no guarantee that an objection will change the outcome.

The value of waiting depends on what might still be learned and how difficult the choice would be to undo. A small trial can tolerate more adjustment than a commitment people will organize their lives around. Even a technically reversible change can be disruptive once people have acted on it.

You may have freedom to act without everyone weighing in

There is also something appealing about a team that trusts you to proceed. You can make a modest improvement during your own working hours without waiting until tomorrow for approval.

For someone joining a distributed team, this creates a practical exchange. You gain room to act, and colleagues gain the same room during hours when you are unavailable. You may appreciate that independence while occasionally wishing someone had waited for your advice.

GitLab's collaboration principles allow decisions to proceed without waiting for every contribution, especially when they are reversible. Its decision-ownership guidance also expects the responsible person to consult relevant colleagues. The scope and consequences of the choice matter when applying those expectations.

The pattern matters more than a single missed discussion. If the same group repeatedly settles consequential choices before another region starts work, people there could spend much of their day responding to plans they had little opportunity to shape.

An objection can matter after the decision

Returning too late to shape the first choice need not end your contribution. New information may justify changing course. But raising an objection and stopping the work are separate powers.

GitLab's disagreement guidance allows past decisions to be questioned while expecting people to follow them until they change. That can mean helping carry out a decision you are also trying to improve.

For the support team, there is a difference between trying a schedule that some colleagues would have arranged differently and discovering that it leaves too few people to handle the work. A planned review may be enough to improve a manageable trial. If the first weekend already looks unworkable, the concern needs attention before the team relies on that coverage. Calling the schedule reversible does little to reduce the pressure on the people working those shifts.

When weighing a job, look for how the actual team handles this moment. A recent decision that changed after an absent colleague contributed would tell you more than a general promise that feedback is welcome. So would a candid account of why the team proceeded despite an objection. You are learning what influence looks like there, including its limits.

You will sometimes return to a choice you would have made differently. The more consequential question is whether your knowledge can still improve it, especially when you are one of the people who must make it work.

Frequently asked questions

Does asynchronous work mean decisions wait for everyone?

No. A remote team may gather input at different times while allowing a named person to decide before everyone responds. The opportunity to contribute depends on the decision's scope, the feedback period and whether the choice remains open during your working hours.

How can someone influence a decision made while they were offline?

An offline colleague may contribute while a proposal is still open, respond during a period of confirmation, or provide new information that prompts reconsideration. Being able to read or comment on a completed decision does not by itself guarantee that the outcome can change.

Why not leave every decision open for longer?

Waiting may uncover important information, but it can also delay colleagues who need the outcome to continue their work or make personal arrangements. The useful balance depends on the consequences of the choice and how easily it can be changed after people act on it.

Can I disagree with a decision and still be expected to carry it out?

Yes. GitLab's published guidance, for example, permits questioning a decision while expecting people to follow it until it changes. Other teams may handle this differently. Understanding who can reconsider a choice, and when, helps you assess whether that arrangement would suit you.