Rehearsal schedule vs release branch

I already wrote about how music directing and technical leadership share structure – program coherence, listening as instrumentation, versions that refuse to stay put. This note is the narrower cousin.

Two artifacts I live with:

• A rehearsal schedule (and the cue sheets / cut lists that trail it).
• A release branch (and the commits / PRs that trail it).

They look nothing alike on paper. They solve the same problem: what is true right now, for the people who have to act?

Schedules are not suggestions

In musical theater, the schedule is the downbeat for the week. Who is called. What we’re working. Which cast. Which pit. When the room thinks “music only” and when it thinks “stumble through with set pieces that still smell like paint.”

If the schedule lies, people waste irreversible time. A singer drives in to rehearsal for a cut song. The MD is holding three PDFs and a text thread that all claim to be final. I’ve lived that archaeology. It is not cute.

In shipping software, the release branch (or main, or the tagged cut you actually deploy) is the same kind of lie-detector. What is going out. What is not. Which hotfix is on the train and which clever idea can wait for the next one.

If the branch lies – or if “we’ll merge it later” becomes the permanent architecture – you get a different archaeology: half-deployed features, dependency bumps that never got hygiene, and a postmortem that starts with “we thought that was already in.”

Different clocks, same honesty problem

Rehearsal time is rude. The number starts whether your PDF is current.

Release time is softer than a downbeat and harder than a blog draft. You can slip a day. You cannot slip forever without the product becoming a rumor, and then vaporware.

Both punish the fantasy that every option stays open. Cuts get locked. Features get deferred. Someone has to say which.

That’s why I care about thin slices on the Organon bench and call times that match reality. Not because I’m in love with bureaucracy. Because future-me will invent a past that never existed if present-me doesn’t leave a legible version.

What transfers (and what doesn’t)

Transfers:

• One living source of truth beats five channels of “final.”
• Change control is kindness when the room is noisy.
• “Not this pass” is a complete sentence.
• The person who owns the program owns the dangerous verbs – publish the new schedule, merge the release, say no to the late cut that breaks the vamp.

Doesn’t transfer:

• Theater hierarchy as an org-chart template.
• Applause as a KPI.
• Treating a git log like a rehearsal report for humans who don’t read diffs.
• Pretending a show’s irreversible night is identical to a canary deploy. Different stakes. Same need for honesty.

Agents don’t get the podium

On the software side I use agents constantly. They draft. They prepare. They do not get to declare the release branch sacred or ship because the tests were green in a sandbox I didn’t inspect.

On the theater side, no chatbot is calling the half-hour. Humans still own the room.

Different tools. Same rule: the living program has an owner.

Why this belongs on Notes

Because LiveBytes keeps saying instruments, not vibes – and a schedule or a branch is how a program stays an instrument when the room gets loud.

Also because I commute between these rooms on purpose. Eleven-hour theater days and late deploys ask the same rude question: is the current version worth defending?

If yes, write it down where the cast – or the repo – can find it. If no, stop calling it final.

~ Trish