← BlogBen LaiSubscribe via RSS ↗

The calendar is part of the architecture

A system that only works when one person is online has a hidden dependency. The calendar is where that dependency shows up.

Architecture diagrams do not show holidays. They should.

The real system includes the one engineer who knows billing retries, the finance person who approves refunds, the founder who can reset a customer contract, and the contractor who maintains the deploy script. If the workflow breaks when they are offline, they are a dependency.

The calendar is the easiest way to see it.

Look for calendar-shaped risk

Three signs:

  1. Work waits for a named person. Not a role. A person.
  2. Incidents slow down on weekends. The system did not get simpler. The humans got scarce.
  3. Release dates avoid vacations. Good instinct, bad architecture.

You do not remove all human dependencies. You make them explicit. Write the runbook. Share the permission. Add the second approver. Move the secret out of the private notes app.

The calendar tells the truth about resilience. If the product cannot survive a normal week of human absence, it is not operationally mature. It is lucky.