Dev

German TV killed intros. Your codebase should too.

ARD just announced they're cutting TV show intro sequences to save broadcast time. Most engineers laughed at the news. The ones who didn't are probably the ones shipping faster than you right now.

German TV killed intros. Your codebase should too.

ARD, Germany's biggest public broadcaster, made a quiet announcement last month: they're cutting intro sequences from their shows. No more 90-second theme songs. No more slow pans over the cast. You tune in, the story starts. Done.

Twitter dunked on it. 'The Germans are coming for joy itself.' But I couldn't stop thinking about the software parallel, because I've seen this exact same pattern destroy team velocity in ways that are genuinely hard to trace back to a root cause.

The intro problem in your codebase

Every codebase I've ever worked in has intros. They just don't look like TV credits.

They look like this: a 200-line base class every service extends before it can do anything useful. A mandatory Confluence page nobody reads before a PR gets approved. A 40-minute onboarding script that sets up tools you'll never use. A config file that has to be copied, renamed, and half-overwritten before your local environment even starts.

Ceremony. Ritual. Intro sequences.

In 2021, I was a senior IC at a 300-person fintech. Our deployment pipeline had what we internally called 'the gauntlet' — a sequence of seven approval gates that predated half the team. Three of them were checking for things our CI already caught automatically. Two required sign-off from a team that had been absorbed into another org eight months earlier. One was just... there. Nobody knew why.

We estimated the gauntlet added 4.2 days to average deploy time. We had 14 engineers. You do that math.

Nobody had removed it because nobody wanted to own removing it. What if one of those gates was catching something invisible? What if we broke compliance? The intro sequence stayed because starting without it felt dangerous, even though nobody could name what it protected.

What ARD actually understood

Here's the thing ARD got right that most engineering orgs don't: intros aren't neutral. They're not just 'a little overhead.' They actively train your audience — your users, your engineers — to expect delay before value.

Once that expectation is set, people stop noticing. They reach for their phone during the credits. They context-switch during the build. The gap between 'I triggered the process' and 'I see a result' becomes invisible and normalized.

As a manager now, I watch engineers context-switch during CI runs and think: we built that habit. That's on us.

'I just assumed the 20-minute build was a law of nature,' one of my engineers told me last year, two weeks after we got it to 6 minutes. 'I didn't know we were allowed to fix it.'

That sentence lives in my head rent-free.

How to actually find your intros

Pull your Linear or Jira tickets from the last quarter. Filter for 'blocked' or 'waiting.' Notice what they're waiting on. Then ask: is that wait catching real bugs, or is it just where the process assumed bugs would be?

Set up a Datadog dashboard tracking time-from-PR-open to deploy. Not because the number is bad, but because most teams have never seen the number at all. You can't cut what you can't see.

Then do what ARD did. Find one intro. Cut it. See if anyone notices what's missing, or just notices that the story started faster.

Most of the time? The story was always fine without the theme song.

OPEN IN REEDL_ FEED →← Back to feed