Sharing a work calendar with your team

Everyone on the team can see everyone else's calendar. The scheduling emails have not stopped. Somebody still writes "what does your Thursday look like" to a colleague whose Thursday is fully visible on screen, and the round trip takes two days.

That is not a habit problem. People ignore shared availability because they have learned it is unreliable, and they are usually right. Fixing it means understanding which of three specific failures is happening, because the remedies are different and only one of them is a settings change.

Why shared availability goes untrusted

Three things make a colleague look past the calendar and ask directly.

The first is access level. When sharing is limited to busy blocks with no titles, a viewer cannot tell whether a block is a client meeting, a commute, or focused work. Since some of those can be moved and some cannot, the only way to find out is to ask, which puts the conversation back where it started.

The second is missing work. Anyone who keeps commitments to themselves in a task list rather than on the grid presents an afternoon that reads as free. It is not free, and the person who books into it knows from experience that the booking will be met with a wince. After a few of those, the safe move becomes asking rather than booking.

The third is lag. One person who agrees to a meeting verbally and records it an hour later is enough to make the whole shared view provisional. Trust in a shared calendar is set by its least current participant, not its average one.

Only the first and third are fixable with configuration and tooling. Access level is a setting. Lag is a function of how long it takes to record an event, which is a tooling question. The second is a team agreement, and no product setting substitutes for it.

Three arrangements that get called the same thing

Most organisations run all three at once without distinguishing them, which is why discussions about sharing go in circles.

Arrangement	Visible to others	Used for	Where it breaks
Organisation-wide default	Busy blocks for everyone	Internal scheduling	No detail, so people ask anyway
Per-calendar sharing	A project, room, or rota	Shared resources	Stays empty if nobody writes to it
Public booking link	Only offered slots	External scheduling	Offered slots drift from reality

The first is often already switched on. Google Workspace and Microsoft 365 both tend to expose busy times inside a domain by default, so a team that believes it has not configured sharing may already be sharing more than it realises. Checking the current state is a better first step than changing anything.

The second is for things that outlive the person handling them. A meeting room, a vehicle, an on-call rota. Recorded on an individual's calendar, that information vanishes when the individual changes role. Recorded as its own calendar, it survives handovers intact.

The third belongs to external scheduling, where exposing a full calendar is not appropriate. The thing to verify is whether offered slots are checked against the live calendar at the moment of booking. If they are generated from a snapshot, double bookings are a matter of time.

Only what is on the grid counts as busy

The idea of free and busy time is not a vendor invention. The iCalendar standard has carried a dedicated way to publish occupied time without disclosing event contents since long before any current scheduling product existed, and the definition is narrow. Occupied means an entry exists on the calendar for that interval. Nothing else qualifies.

This has a blunt consequence. Work that lives in a task list, a ticket queue, or someone's head has no defence at all. A colleague scanning for a slot sees white space and books it, correctly according to every rule the system knows. Protecting deep work therefore requires putting it on the grid as an event, not declaring it in a team channel.

Teams that skip this end up with a gap between stated policy and observed behaviour. "Thursday mornings are for focused work" survives about three weeks if Thursday mornings look empty to the scheduling tools. The same statement holds indefinitely once the block exists as an entry, because the meeting is never proposed in the first place.

There is a limit worth respecting. A calendar blocked out completely reads as permanently unavailable, and colleagues start routing around it by messaging directly, which is the outcome the blocks were meant to prevent. Two or three protected blocks a day is the level that holds. Setting their visibility to busy without a title keeps the reason private while still occupying the space.

Duplicates, RSVPs that go nowhere, and time zones

Three complaints dominate the first month of any new sharing arrangement.

Duplicate events come from putting a meeting on a team calendar that everyone subscribes to and also sending invitations for it. Both copies are legitimate, and both appear. Invitations should be reserved for meetings that genuinely need attendance tracking. Everything else can live on the shared calendar alone.

Declines that seem to vanish are usually a configuration detail on the organiser's side. If an event was created without guest responses enabled, a decline changes nothing that the organiser can see. Checking the guest options at creation time, including whether guests may modify the event or see the attendee list, prevents a class of confusion that otherwise gets blamed on the attendee.

A related irritation is the recurring meeting that nobody owns any more. Series created by someone who has since changed role keep generating entries, and because they occupy real time on every attendee's calendar, they distort availability for everyone. Reviewing recurring events once a quarter and deleting the series rather than declining individual instances removes a surprising amount of phantom busy time.

Time zones bite distributed teams in two ways. The obvious one is offset arithmetic, which a secondary time zone displayed alongside the main column mostly solves. The subtler one is daylight saving, since regions change on different dates. A recurring meeting that has held steady for months will silently shift by an hour for half the participants, and the calendar will be technically correct throughout.

Four things to agree before changing settings

Configuration goes faster when four questions have answers.

Decide what sharing is for. Scheduling meetings and knowing what colleagues are working on are different goals, and the second one requires far more disclosure. Conflating them turns a ten minute setup into a long argument about privacy.

Decide the default access level. A two-tier arrangement works well: busy-time-only across the organisation, full detail within a project team where people may need to move each other's events.

Decide whether focused work goes on the calendar. If the answer is no, then shared availability cannot be treated as bookable, and that has to be said out loud rather than discovered.

Decide where things get written. Personal commitments on personal calendars, shared resources on their own calendars. This is the rule most often broken, and it breaks for a practical reason rather than a stubborn one.

That reason is entry speed. An event agreed in a corridor or at the end of a call gets recorded only if recording it is nearly free. Some Mac calendar apps accept a plain sentence or spoken input in place of a form, so "meeting with finance tomorrow at ten for thirty minutes" becomes an entry without any fields being touched. The approach is described on the Entering events page. The mechanism matters less than the outcome: the shorter the entry step, the more accurate every shared view downstream becomes.

Start with one team, not the whole company

Rolling sharing out company-wide before the conventions are settled produces inconsistent permissions and inconsistent writing habits, and unpicking those later costs more than the original setup. A group of five to ten people who already work together daily is the right size to start with, because conventions can be agreed in conversation and failures surface within days.

Two weeks of running it reveals which agreements are not being kept. Almost none of those failures are attitude problems. A rule that gets ignored is nearly always a rule that costs too much effort at the moment it applies, which means the fix is to shorten that step rather than to restate the rule.

A small pilot also makes the result measurable, and the measure is not satisfaction. It is the number of round trips per meeting arranged. Three emails becoming one means the shared view is being trusted. No change means the bottleneck is still access level or update lag, and the log will say which.

A workable sequence looks like this.

Check what is already shared by default, since a domain may be exposing busy times without anyone having configured it. Create one team calendar and put only shared resources on it, such as rooms, rotas, and cover arrangements. Decide whether focused work goes on the grid, and if so standardise on showing it as busy without a title. Keep external scheduling on a separate mechanism that never exposes the calendar itself.

Each of those steps is reversible on its own. Changing organisation-wide defaults first is not, which is the main argument for the order.

The meetings that were never possible

For anyone who leaves the building, shared availability that ignores travel is worse than no availability at all, because it invites bookings that cannot be honoured. A one hour client meeting across a city is not a one hour commitment, and the gap between those two numbers is where afternoons collapse.

The effect compounds across a team. One person's unrecorded commute becomes another person's late start, and a chain of three meetings that each looked feasible in isolation turns into an afternoon that was never achievable. Nobody scheduled badly. The shared view simply reported the wrong thing, and everyone acted on it correctly.

Blocking travel manually works for a week and then stops, which is why some calendars attach it to the event itself once a location is present. The Travel time page sets out how that is handled. Either way, a shared calendar that shows only the meeting is quietly telling colleagues something untrue about the surrounding hours.

Where a genuine product comparison is needed, three things actually differ: how many calendars can be subscribed to at once, how finely permissions can be set, and the range of Google Calendar and Exchange syncing. Those are covered on Compared with other calendars, and per-seat licensing is set out under Buy.

What to change first

Run the current setup unchanged for two weeks and record every scheduling round trip along with its cause: no detail visible, calendar out of date, or focused work never entered. That log names the fix. If entry lag turns out to be what is breaking trust in the shared view, Caltimate is one of the Mac calendar apps built around making that step short enough to actually happen.