The calendar as a published document

You publish a document every week, though nobody calls it one: your calendar.

The OKRs get skimmed and the all-hands deck gets watched and forgotten, but the calendar is the record anyone can open on a Monday and see what you spent your hours on. A deck states its intentions for free, while every block on the calendar was paid for in hours, so peers and reports read the calendar as the most credible weekly statement of priorities you make, whether you meant to make one or not.

A busy calendar is not the same thing as a calendar that lines up with your stated priorities. A week of wall-to-wall meetings can mean the opposite, because when people cannot agree on what matters, they meet about it, repeatedly.

The job is to treat the calendar like the document it already is: read it deliberately and shape it with a few rules, then review it on a cadence. The team's calendar gets the same treatment, with one strict limit on how you read it.

Read your calendar as the source of truth on priorities

Open the last two weeks and add up where the hours went, then compare that picture with what you would say out loud if someone asked what your priorities have been.

OKRs say what should be true and the calendar records what is, and comparing the two is as honest a read on yourself as you are going to get.

The blank slots count as much as the filled ones. If thinking time, skip-level meetings, reading, or the standing architecture review are on your stated list of priorities and never appear on the calendar, the calendar is the one telling the truth. The Friday afternoon that quietly fills with status updates, the quarterly planning block that never materializes: both are legible to anyone who looks, and they say more than the priorities memo does.

Treat cadences as conviction, one-offs as intent

A one-time block on the calendar is a wish that something will happen once. A recurring slot says you have decided the thing is worth revisiting on this rhythm and are willing to commit a recurring chunk of attention to it, and a weekly is a different size of commitment from a monthly, which is different again from a quarterly.

The strongest signal of what you value is which recurring slots survive a high-pressure week. Cancel a 1:1 the first time a launch goes sideways and the team learns what the 1:1 is worth under pressure, while keeping it through three bad weeks in a row teaches them the opposite.

The inverse holds too. A recurring meeting whose original reason has rotted is still broadcasting priority: the team treats its recurrence as evidence of what you still think matters, even when you no longer remember why it exists (they will assume you do).

Hold maker and manager shapes inside one week

In 2009, the essayist Paul Graham (the co-founder of Y Combinator) wrote about two incompatible time shapes. The manager runs on hour blocks: the day is a sequence of slots, and one more meeting at three in the afternoon costs one slot. The maker runs on half-days: the morning is one block of work, and a three-o'clock meeting destroys the afternoon, because the maker cannot pick up the same shape of thinking on either side of an interruption.

An engineering leader's week has to hold both shapes: coordination is manager-shaped, while architecture thinking, code review, hard problem-solving, and writing are all maker-shaped. Squeezing the maker work into the gaps between meetings does not work, because either a maker block exists on the calendar or it does not.

How to decide whether each individual meeting earns its slot is the subject of a separate essay in this playbook, but the number worth holding here is the refocus cost: every unscheduled drop-in onto a maker block costs twenty-three minutes of recovery before deep work resumes (the figure comes from Gloria Mark's attention research at UC Irvine). A calendar of scattered thirty-minute meetings, none individually expensive, can destroy every maker block in the week.

Holding both is simple to describe and hard to do: cluster meetings onto certain days, and defend maker mornings or maker afternoons on the others. The calendar is the only place where that decision becomes visible and enforceable.

To prioritize something, put it on the calendar

Aspirational priorities are the ones you keep meaning to start but never quite make time for:

• The new technology you keep meaning to learn.
• The reading list.
• The thinking time.
• The catch-up on whatever new tooling has just appeared.

If any of these is a real priority, give it a slot on the calendar. Fifteen minutes is enough, thirty if the week can spare it. If you cannot find fifteen minutes a week for the thing you claim matters most, it does not matter most.

Scheduling the slot and then quietly killing it every week is worse than never scheduling it, because the calendar now contains a lie about what you intend to do, and the team reads it the same way they read everything else there.

Keep the calendar honest with a 5-minute threshold

One rule keeps the document faithful: if a sync runs longer than five minutes and looks like a meeting, it goes on the calendar; anything shorter is a chat ping.

Without the rule, the quick calls never get logged, and the calendar looks lean while the day fills with unrecorded coordination. A lean-looking calendar is flattering right up until you try to read it and find the document lying about where the hours went.

Read the team's calendar for trends

One limit comes before anything else: you are reading for trends across the whole team, and never auditing one person. Surveillance of engineering work (keystroke counts, activity dashboards, individual time audits) has its own essay in this playbook.

Team-level questions to ask:

• Is meeting load eating the team's overall bandwidth?
• Are there too many small or quick calls, a sign that async coordination has broken down and urgent unplanned discussions are filling the gap?
• Do the engineers have any clear two-hour blocks anywhere in the week?
• Are 1:1s and skip-level meetings happening on cadence, or have they quietly started drifting?
• Is the structural week (which days are meeting-heavy and which are clear) deliberately designed or accidental?

Reading the team calendar is the cheapest signal a leader has, and one of the most underused. I learned this during a deep review of the team's priorities, run to work out why velocity had dropped. We went past sprint output and task boards into the team's calendars, and one of the senior developers, whose role was meant to be high-output individual-contributor work, was spending forty percent of the week in meetings. The forty percent had been visible the whole time; our velocity conversations had stayed at the task level, so nobody had opened the calendar.

Without that look we would have called it a skill problem or a motivation problem and applied the wrong fix. What it needed was a conversation about meeting load and a hard look at which of those meetings the engineer needed to be in at all.

Watch for the slide from trend-reading into per-person audit. Once you cross that line, hiding becomes the rational move: a vague calendar label costs an engineer nothing and buys back some privacy, and the team calendar stops being a document anyone can read.

Review the calendar on a cadence

The document goes stale silently: things get added in a hurry and forgotten, and recurring meetings survive past the reason anyone created them. Run a quarterly review by default, faster if your own calendar shifts faster than that.

The review has a short job list:

• Kill what no longer earns its slot.
• Renegotiate what survived for the wrong reason.
• Restore the thinking time or the standing skip-level meeting that fell off without anyone noticing.

Skip it for a few quarters and the calendar accumulates a sediment of old yeses nobody remembers agreeing to, and it gets genuinely hard to read your current priorities off it.

Peers and reports will go on reading the Monday version whether you shape it or not. The two-week-old copy is for you: it shows what you chose, which by then is sometimes news.