The calendar as a published document

An engineering leader publishes a document every week, but they almost never call it that: the calendar.

The OKRs get skimmed and the all-hands deck gets watched and forgotten, but the calendar is the one record peers and reports can inspect on any given Monday to read off what the leader actually cared about, so whether anyone meant it that way or not, the calendar gets read as the most credible weekly statement of priorities the leader makes.

A busy calendar is not the same as a calendar that lines up with the leader's stated priorities, because lots of meetings does not mean anyone in the room agrees on what matters; often it means the opposite.

The leader's job is to treat the calendar like the document it already is: read it deliberately, shape it on a small set of rules, and review it on a cadence; the same goes for the team's calendar, with one strict limit on how to read it.

Read your calendar as the source of truth on priorities

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

OKRs tell you what should be true; the calendar tells you what is, and comparing those two pictures gives the leader the most honest signal they can get.

The blank slots on the calendar count as much as the filled ones: if thinking time, skip-level meetings, reading, or the standing architecture review meeting are on your stated list of priorities and never appear on the calendar, the calendar is telling the truth and you are not; the empty Monday morning slot, the Friday afternoon held open or filled with status updates, the absence of a quarterly planning block, each says more than any priorities memo could.

Treat cadences as conviction, one-offs as intent

A one-time block on the calendar is a wish that something will happen once, but a recurring slot is something else: a statement that the leader has decided this thing is worth revisiting on this rhythm, and is willing to commit a recurring chunk of attention to it; a weekly is a different commitment from a monthly, and a monthly is a different commitment from quarterly.

The strongest signal of what a leader actually values is which recurring slots survive a high-pressure week: cancelling a 1:1 the first time a launch goes sideways shows the team how much the leader values it under pressure, while keeping it through three high-pressure weeks in a row shows the opposite, and the team can read the difference.

The inverse also holds: a recurring meeting whose original reason has rotted now tells the team the wrong thing about priority, and everyone treats its recurrence as evidence of what the leader still thinks matters, even when the leader no longer remembers why it exists.

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.

The 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. Leaders most often fail by pretending the maker work can be squeezed between meetings, when in reality 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 roughly twenty-three minutes of recovery before deep work resumes (the figure from Gloria Mark's attention research at UC Irvine), and a calendar with scattered thirty-minute meetings across every day, none individually expensive, can destroy every maker block in the week.

Holding both is simple to describe and hard to do: cluster meetings into certain days, and defend maker mornings or maker afternoons on the others, because 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 a leader keeps meaning to start but never quite makes time for:

• The new technology the leader keeps 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, because the slot is the priority; if a leader cannot find fifteen minutes a week for the thing they claim matters most, the thing does not matter most.

Scheduling the slot and then quietly killing it every week is worse than never scheduling it: the calendar now contains a lie about what the leader intends to do, and the team can read the lie just as clearly as they would read a real commitment.

Keep the calendar honest with a 5-minute threshold

Keep the document faithful with one rule: 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 this rule, the small "quick call" never gets logged and the calendar looks lean, even as the day fills with unrecorded coordination and the document starts to lie about where the hours actually went.

Read the team's calendar for trends

Set one strict limit before reading the team's calendar: this is not surveillance; surveillance of engineering work (keystroke counts, activity dashboards, individual time audits) lives in its own essay in this playbook. Read the team calendar for trends across the team, never to police one person.

Team-level questions to ask:

• Is meeting load eating the team's overall bandwidth?
• Are there too many small or quick calls, usually 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 diagnose why velocity had dropped; we looked beyond sprint output and task boards to include the team's calendars, and one of the senior developers, whose role was meant to be high-output individual-contributor work, was running roughly forty percent of their week in meetings, a 40% that had been visible all along, but our velocity conversations had stayed at the task level, so no one had looked at the calendar.

Without reading the calendar, we would have misdiagnosed the gap as a skill or motivation problem and applied the wrong intervention; the right one was a conversation about meeting load and a careful look at which meetings that engineer actually needed to be in.

Watch for the slide from team-level trend-reading into per-person calendar audit: once you cross that line, people start hiding work behind vague calendar labels and the team calendar stops being a useful document at all.

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 they were put on the calendar. Run a quarterly review as the default, or faster if your own calendar shifts faster than that, catching drift before it sets like sediment.

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.

Without the review, the calendar accumulates into a sediment of old yeses no one remembers agreeing to, and it becomes harder to read what the leader's current priorities actually are.

The calendar gets read whether the leader meant it as a document or not: peers and reports read off the leader's priorities from it, while the leader, looking back two weeks later, sees what they actually chose.