Shared calendar or published schedule?

Two different models, frequently confused, and choosing the wrong one is why the last three things you tried did not stick.

There are two models for getting a schedule in front of other people, and they are not variations on one idea. Choosing the wrong one is the most common reason a system gets abandoned.

Model one: the shared calendar

One calendar. Several people can see it, and usually add to it. Everything on it is visible to everyone on it.

Examples: a Google calendar shared with your partner, Apple Family Sharing, TimeTree, Cozi, the fridge.

It suits: a household coordinating shared plans. School events, holidays, who is cooking, the joint social calendar. Several contributors, one shared picture.

Where it fails for shift work: privacy is per-calendar rather than per-event, so keeping something to yourself means a second calendar and remembering which one you are adding to. And it does not solve data entry — a rotating rota still has to be typed in by somebody.

Model two: the published schedule

You own a schedule. Chosen people follow it. They see it; they do not edit it. You choose what is visible.

Examples: Freeish, a calendar subscription feed, a printed rota on a grandparent’s fridge.

It suits: one person with a schedule other people need to plan around. One author, several readers, one-directional.

Where it fails: it is not a household calendar. If four people all need to add things, this is the wrong shape.

The test

Ask: how many people are adding things?

  • Several people adding → shared calendar.
  • One person’s schedule, several people reading → published schedule.
  • Both → you need both, and that is fine. They do different jobs and most households that get this right run one of each.

Why the distinction matters more than it sounds

Three practical consequences.

Privacy works differently. A shared calendar is a shared space, so anything on it is shared by default. A published schedule is yours, so per-event control is natural rather than bolted on.

Ownership works differently. Everyone on a shared calendar has equal standing, which is right for a household and wrong for your work schedule — you should not be able to have your shifts edited by somebody else, and you should not lose them if a relationship ends.

Data entry works differently. A shared calendar assumes typing, because it is built for appointments. A published schedule can assume import, because it is built for a schedule that already exists somewhere else — which is why photo import and rotation generation exist in one category and not the other.

The common wrong turn

The usual sequence: a shift worker shares their Google calendar with a partner, types shifts in for a month, stops typing, and the calendar quietly becomes wrong.

The diagnosis is normally “I’m not disciplined enough”. It is more often that a shared calendar was the wrong model — the problem was one person publishing, not a household coordinating, and the tool was assuming typing for a schedule that arrives as a photograph.

What to run

For most shift-working households:

  • A published schedule for the shift worker’s hours, visible to whoever needs them, with per-event privacy.
  • A shared calendar for household plans, if you have enough of them to justify one.
  • A subscription link for anyone who will not install anything, feeding the first into whatever calendar they already use.

That is more moving parts than one app, and it maps onto how the information actually flows — which is why it survives past March.

Further reading

Free… ish. Ready when you are.

Now on iPhone — Android coming soon. Free to start. Free to share. It just wants your week to be a little less of a mystery.

Download on theApp StoreComing soon toGoogle Play