The short version. Podcast operations is the work between recording and publish — planning, asset coordination, scheduling, handoffs, post-release tracking. Solo creators do it manually in Notion. At three shows, that breaks. By five shows it has to become a system. This essay is for the people responsible for shipping at that scale: production managers at networks, agency owners with multiple clients, in-house operators at studios. It's about how that system gets built — not about another tool to add to the stack.
The five-show inflection point
A single show running weekly is a craft. One person can hold the whole pipeline in their head: when the guest is booked, when the recording happens, when the edit lands, when assets are due, when it ships. The Notion template the producer built in week three works fine.
Two shows is harder. Three shows is the moment producers start dropping things — not because they're bad at their jobs, but because the cognitive cost of context-switching between three pipelines exceeds what any one person can hold cleanly. The same person who never missed a publish date on one show now ships an episode with the wrong intro music on another.
By five shows, the operation is no longer a craft. It's a system. The question is whether the system is built deliberately or accidentally. Accidental systems are spreadsheets, Slack threads, a half-built Notion database, and the operator's institutional memory. Deliberate systems are documented release trains, role-clear handoffs, instrumented release-day operations, and tooling that the team understands as infrastructure rather than as one person's preference.
Networks that grow past five shows without a deliberate operations system don't grow past ten. They burn out the operator, lose institutional memory when that operator quits, and eat their margin in operational rework that compounds each release.
The asset coordination problem
The bottleneck at multi-show scale is rarely creation. Editing tools are mature. AI transcription is solved. The bottleneck is coordination — getting the right assets to the right people in the right order, every release, every show, week after week.
A single episode produces, at minimum:
- The final audio file (one or more versions: explicit, clean, ad-stitched)
- The transcript (raw and edited)
- Show notes (web-formatted, with timestamps)
- Chapter markers (PSC tags for RSS, plus YouTube descriptions)
- The video edit (audio podcast networks increasingly ship video too)
- Vertical clips (3–6 per episode for Reels, Shorts, TikTok)
- Static social posts (per platform, per show, per release)
- Newsletter copy (if the show has a newsletter)
- A web page (transcript, embedded player, schema markup, internal links)
- Cover art (per episode if the show varies it)
- Sponsor read scripts (if ads are host-read)
- Sponsor metadata (campaign attribution, run dates, frequency caps)
For one show that's ~12 distinct artifacts. For five shows shipping weekly, that's 60 per week, 3,000 per year. The labor isn't in any single artifact — it's in getting all 12 produced, reviewed, approved, and to the right place by the right deadline, across five parallel pipelines.
Studios that grow past this point without ops infrastructure ship a smaller number of artifacts. They cut clips. They skip the newsletter. They publish without a transcript. They lose the long-tail SEO surface every podcast already has but few exploit. Their operation looks productive because the shows ship, but they're leaving discoverability on the table because the pipeline can't carry the full asset set.
When to hire an ops lead vs buy tooling
The two levers studios have to scale past the asset coordination problem are people and tooling. Most networks default to people because hiring is a familiar muscle. Hiring solves the throughput part of the problem — a senior producer who used to ship one show now ships two, plus coordinates assets across three more. But hiring doesn't solve the coordination part. It just routes more pipelines through a more experienced operator, who eventually runs out of working memory.
The signals that you've crossed from "hire another person" into "build the system" usually show up in three places. Release-day operations time per episode is the clearest. If your team is spending three or more hours per episode on operations after editing is finished, you've passed the point where another hire fixes it. Handoff failures — episodes that miss publish dates not because of editing, but because someone forgot to update a sponsor field, or the social posts weren't built, or the metadata pushed wrong — are the second signal. Operator dependency is the third. If your ops lead can't take a vacation without releases slipping, the system is the operator. That's fragile.
The right move when those signals show up is to add tooling that captures coordination — what's owed by whom, by when, where it is in the pipeline, and what blocks it. The tool itself isn't the change; the change is making coordination visible and transferable rather than locked inside one operator's institutional memory.
Tooling without the process change is worse than no tooling. A team that adopts Notion or Airtable but doesn't restructure how handoffs work has just added a SaaS subscription to the same broken workflow. The process change comes first. The tool supports it.
Building a release cadence at multi-show scale
The single highest-leverage system change is making the release cadence explicit. Most studios run on what they'd call "weekly" releases, but if you measure actual publish dates against the calendar, the median variance is ±2 days. That variance is the operational cost of an informal cadence.
A formal release cadence at scale has four characteristics. First, it's keyed to a specific weekday and time per show — Monday 6am Eastern for Show A, Wednesday 6am for Show B, and so on, immovable except for explicit pre-planned exceptions like holidays. Second, it's reverse-engineered from the publish moment back through the pipeline: if the episode publishes Monday 6am, the social-post batch is due Friday 12pm, the asset pack is due Thursday 5pm, the audio final is due Wednesday 5pm, and so on. Each handoff has a name (who delivers, who receives) and a deadline. Third, it's visible to the whole team in one canonical view — not five Notion pages, not three Slack channels, but one calendar that everyone references and one place where the current state of each release lives. Fourth, deviations from the cadence are visible and named. When a release slips, the team can see which handoff broke and why — not just that the publish date moved.
This is what most multi-show studios are reinventing in Notion. It works, but it's brittle: it depends on one operator maintaining the template, and it doesn't carry across operators. The next layer of tooling is the one that captures release cadence as a primitive rather than as a template a specific operator built once.
What to instrument
Operations at scale is a measurement discipline. You can't tighten a cadence you can't see. The five metrics that matter for podcast operations are:
Release variance. The distance between scheduled and actual publish time, per show, per release, in hours. Median should trend toward zero as the system matures. If the median is widening, the system is degrading.
Asset completeness at publish. What percentage of the planned asset set (transcript, chapters, social pack, newsletter, web page) actually ships with each episode? If the planned set is 12 artifacts and the actual median is 7, you're leaving 40% of your distribution surface on the floor.
Handoff cycle time. The hours between when an asset is "due" and when it's actually delivered. If your average is more than 25% over the planned timeline, the cadence is theatre.
Re-work rate. How often does an asset need to be re-edited, re-cut, or re-shipped after first delivery? Re-work is the cheapest thing to measure and the most actionable: a 20% re-work rate is almost always a process problem (unclear specs at handoff), not a craft problem.
Sponsor read accuracy. For shows with host-read sponsorships, the rate at which sponsor reads ship correctly (right copy, right dates, right placement, right CPM tracking). Sponsor accuracy below 95% is a direct revenue leak.
These aren't vanity metrics. They're the operational equivalent of CPU and memory graphs for a production system — boring on a good day, urgent on a bad one.
The next layer
The pattern across the studios that have actually scaled past 10 shows is this: someone, at some point, decided that operations was the product. Not the audio. Not the talent. The operation that wraps around the talent and ships them on time, every time, with the full asset pack the modern distribution surface demands.
That's the orientation shift this essay is about. Recording is craft. Editing is craft. Publishing is operations. The studios winning at scale in 2026 aren't outproducing their peers on audio quality — they're outproducing them on release reliability, asset completeness, and the boring discipline of shipping every Tuesday at 6 a.m. without anyone noticing the machinery.
The tooling layer that captures this — that makes release cadence a first-class object, makes asset coordination visible, makes handoffs transferable across operators — is what we mean by podcast operations as a category. It's the missing layer in most multi-show stacks. It's why most studios run their pipeline in Notion or Airtable: not because those tools are right for the job, but because nothing else has shown up yet.
If you've read this far, you're probably already running an operation that's outgrown its tooling. The 2026 Podcast Operations survey we're running asks 200+ networks, studios, and agencies exactly the questions this essay raises: how many shows, how many tools, how many hours per release, what breaks, what costs what. If your operation is at the scale described above, your data would meaningfully sharpen the dataset. Take the survey →
And if you're at the point where adding another person hasn't solved the coordination problem, the systems described here are what EpisodeOps is built around. See how it works →