Why does the same person always take the early meeting?

Posted 22 May 2026.

The pattern

You run a distributed team. Three timezones, maybe four. Six months ago you agreed, in a retro, that the rotating standup would actually rotate. Nobody should have to keep doing 7am or 9pm every week. Everyone nodded. It was a good decision.

This week, you look at the calendar and the standup is at 8am London. Tokyo is on at 4pm, which is fine; San Francisco is on at midnight, which is not. You scroll back. Last month the standup was at 8am London. The month before that, 8am London. The Tokyo-friendly slot you'd agreed to alternate to has been missed seven times.

Nobody decided this. Nobody is being malicious. There is no scheduling-tool bug. And yet the meeting keeps drifting toward the same person's working hours, and the cost keeps landing on the other two.

This essay is about why that happens, because the reasons are surprisingly structural, and because once you can name them, you can do something about them.

Reason 1: The default-slot gravity well

Every recurring meeting has an inertial slot: the time it was first scheduled in. That slot was almost always picked under time pressure (“we need a standup, when can we all do Thursday?”), in a moment when one or two people happened to be in the room, and it was set up to recur indefinitely because that's the default in every calendar tool.

That inertial slot has a gravitational pull. Re-scheduling it requires:

• Somebody to notice it's been the same slot for a while.
• That somebody to care enough to raise it, which is heavily skewed toward the person it's costing the most.
• The team to negotiate an alternative, which takes time, energy, and (often) one round of: “does Wednesday at 3pm work? No? OK, Thursday at 4? Half the team can't”.
• Somebody to actually go into the calendar invite and change it.

Each step has a friction cost. The total friction is high enough that, in most teams, the slot never gets re-negotiated unless something forces the issue: usually somebody pushing back hard, usually after months of the cost landing on them.

The first-mover problem here is the key thing. The person who's paying the cost is the only person with a reason to raise it. Everyone else is fine. So “the cost lands on one person” and “the cost stays landed on one person” have the same root cause: the person bearing it is the only one with skin in the negotiation.

Reason 2: Availability asymmetry

When the team negotiates a new slot, the people whose working hours straightforwardly include the candidate slot say “yes, that works for me” quickly. The person for whom the slot is 6am or 10pm has to do a more complicated thing: weigh whether they want to absorb the cost, whether they have the social capital to push back, whether the alternative slots are actually any better, whether they want to be seen as the difficult one.

This asymmetry isn't symmetric. Saying “yes, 3pm works” is one second of effort. Saying “3pm is 6am for me, can we look at something else” is several minutes of social effort plus the risk of being read as inflexible. Multiplied across a few candidate slots, the negotiation systematically biases toward whatever slot is convenient for the largest number of people, even when the cost-per-person on the inconvenient side is much higher than the savings-per-person on the convenient side.

This is the same dynamic as a tragedy-of-the-commons problem. Each individual yes is rational; the aggregate outcome is unfair.

Reason 3: Most scheduling tools answer the wrong question

Open any scheduler: Calendly, Google Calendar's “find a time”, Outlook's Scheduling Assistant. Ask it to find a meeting time for your six-person distributed team. It will show you the slots where everyone is free.

That's the wrong question.

“Is this slot free?” treats every available hour as equivalent. 9am London is treated the same as 5am London. The tool doesn't know that 5am London is a sleep window and 9am London is a working hour. It doesn't know that 7pm Buenos Aires is family-dinner time and 11am Buenos Aires is fine. It doesn't know that Person A has already taken three early meetings this month and Person B has taken zero.

The tool surfaces availability and lets the humans reason about cost. Most humans, under time pressure, reason about cost badly: they pick the first slot that says “everyone free” in green, because the alternative is an hour of negotiation and they have other work to do.

That isn't the tool's fault, exactly. Most schedulers were built for external bookings, where a freelancer publishes their available slots and a stranger picks one. Internal recurring meetings are a different problem and most tools haven't been redesigned for it. But the consequence is real: the dominant scheduling workflow today produces the drift we're describing, by default.

Reason 4: The data is invisible

Suppose you wanted to actually check whether your team's meeting load is fairly distributed. Right now, with the tools most teams have, how would you?

You'd have to open everybody's calendar, look at every recurring meeting, work out what each meeting time is in each member's local time, decide which ones count as “outside working hours”, count them up by person, and present the results. For a six-person team across three timezones with 15 recurring meetings, that's maybe two hours of work. Nobody does this. Even good managers don't do this. It's not because they don't care. It's because the data is invisible and the work to make it visible is large.

If you can't see who's bearing the cost, you can't redistribute it. And you can't see it, because no tool in the standard distributed-team stack is set up to surface it. Calendars show events; HR tools show payroll; project management tools show tickets. The fact that one teammate has done 14 early calls this quarter while another has done 1 is nowhere, until that teammate is in a one-on-one telling you they're thinking about leaving, and then it's everywhere.

Reason 5: The person bearing the cost often hides it

This is the reason that surprises managers most.

The team member who's doing the 6am calls isn't, in most cases, going to walk into a one-on-one and say “I'm doing too many early calls.” They are far more likely to:

• Quietly absorb it for months, because they don't want to be seen as inflexible or as the person who can't hack distributed work.
• Mention it once, glancingly, and read the room. If the room doesn't immediately respond, drop it.
• Find workarounds (skipping the meeting occasionally, claiming a conflict, half-paying-attention while doing other work) that make the cost less visible but don't reduce it.
• Eventually, after six to nine months of accumulated cost, mentally check out and start looking for another job.

The first time most managers hear about the problem clearly is the resignation conversation. By then it's too late.

This isn't a character flaw of the team member. It's the rational response to a social dynamic where complaining about your own meeting load is read, by default, as a flexibility problem rather than a fairness problem. Until the dynamic itself changes (until the data is visible enough that the manager can raise it without the team member having to), the complaint stays under the surface.

What actually fixes this

The reasons above suggest the fix has to do four things, not one:

1. Make the cost legible. Convert “Carlos has done several early calls recently” from a vague impression into a number that any team member can see. The exact number doesn't matter much; what matters is that the count exists and is auditable.
2. Surface the cost before the meeting is scheduled, not after. When the team is picking a slot, the scheduling UI should show “this slot is 6am for Carlos, who has already absorbed three early meetings this month”, not just “everyone is free.” This re-frames every scheduling decision as a cost decision, which is what it actually is.
3. Remove the first-mover cost. If the data is visible to everyone, the person bearing the cost doesn't have to be the one to raise it. The manager, or any teammate, can notice and propose a rotation. The asymmetry that traps the cost on one person dissolves.
4. Let the team make the call, with the data in front of them. No algorithm should auto-schedule meetings to optimise fairness, because fairness is multi-dimensional and the team is the only entity that knows the full context. The tool's job is to make the data legible; the decision is human.

This is what fairness-aware scheduling is. It's not a different algorithm for picking slots. It's a different display of the same slots, where the cost-per-person is visible alongside the availability-per-person. The team still decides; the team just decides with better information.

The thing you can do this week, with or without a new tool

If your team isn't ready to adopt new tooling, the lightest-weight version of this is a five-minute exercise in your next team retro:

1. List every recurring meeting on the team's shared calendar.
2. For each one, write down what local time it is for each team member.
3. Count, for each member, how many of those recurring meetings fall outside their working hours.
4. Look at the counts.

You'll almost certainly find that one or two members are carrying a disproportionate share. Once that's visible, the conversation about what to do is much easier, because the team is now negotiating from data rather than from individual complaints. The hardest part of fairness conversations is getting them started; making the cost legible does most of the work.

The next step, if the team wants to keep an eye on it, is whatever tooling makes that visibility durable rather than a one-time retro exercise. That's the gap FairlyRemote was built to fill. But the retro exercise alone, done quarterly, will catch most of the drift.

The thing you can do this week, with FairlyRemote

If you'd like to see the visibility part working without committing to anything: the sample team loads instantly with four members across four timezones and three months of meeting history. You can see what “Carlos has absorbed three early meetings this month” looks like in a UI, including how the cost is surfaced when proposing a new meeting.

If you want the explainer of the underlying math, the fairness scoring explainer walks through what the score is and what it explicitly is not. If you run on-call rotation rather than recurring meetings, the related essay on rotating on-call across timezones covers the same structural problem in that domain.

A note on what this isn't

This essay is about a structural problem in distributed-team scheduling, not about blaming people or measuring anyone's productivity. The drift toward one person carrying disproportionate meeting cost isn't anybody's fault: not the manager's, not the teammates who happily said yes to the convenient slot, not the team member who quietly absorbed it. The whole point of making the cost legible is to take the moral weight off individuals and let the team negotiate as a team.

Fairness data is also not a measure of individual performance, wellness, or commitment. A member who's done many early meetings is not “a better team player”; a member who's done none is not “less committed.” The data is descriptive, not evaluative. Treating it as evaluative would re-create exactly the social pressure that made the cost hide in the first place.