In 2014, I landed in Hong Kong with a team, a tight deadline, and no safety net. A decade on, the technical headaches have changed — but the patterns haven’t.

By Ben Anchor — Tuesday, 22 April 2025 · Listen to the podcast episode

There’s a reason I’ve never forgotten my first contract gig. Not because it was glamorous (it wasn’t), or because everything went smoothly (it didn’t), but because it laid bare a truth that still holds: most broadcast projects don’t fail on the tech. They fail on the handover.

In the latest bonus episode of Reinventing Broadcast, I walked through my notes from that March 2014 assignment in Hong Kong — my first time out as a contractor, working with Kenneth, Brian, and Peter to validate a new playout environment around Skylight software. It was a baptism by fire: standards mismatches, subtitle muxing nightmares, firewall tangles blocking NTP access, and a looming deadline for a report that had to land with stakeholders in both the UK and the US. Looking back now, what strikes me isn’t the technical firefighting — it’s how much of the project hinged on closing the loop.

The Issue Log I Couldn’t Live Without

From day one, I kept an issue log. Every hiccup — admin access problems, Brian’s laptop refusing to connect, missing teletext profiles, the NTSC/PAL HD black screen fiasco — went straight into that log. At the time, it felt like paranoia. In hindsight, it was survival.

Because here’s the thing: when you’re working across time zones, with hardware being installed by Kenneth and Brian while Peter’s managing content transfer and schedules, and you’re trying to get your head around a new system’s permissions, you will lose track. The issue log wasn’t just documentation — it was a forcing function for clarity. It kept me honest about what was solved, what was parked, and what was still bleeding.

I still use that approach today. On every Ancast engagement, whether it’s workflow consulting or an AI transformation project with Ancast Intelligence, the first thing I set up is a living issues register. It’s not sexy. It’s not cutting-edge. But it works.

When the Subtitle Standard Doesn’t Support Your Subtitles

The toughest moment came late in the project: we hit a wall with two-byte, multiple-language subtitle muxing. The teletext standard we were working with simply didn’t support it. Equipment was being returned, profiles were missing, and time was running out. We couldn’t test what we needed to test.

I had two choices: gloss over it in the report, or call it out. I chose the latter, pulling the critical issues into a separate appendix so the main report stayed operational and focused, but the limitations were documented in full. It wasn’t comfortable. But it was the right move.

That decision echoes in every Ancast project since. When we’re working with broadcasters on AI-driven metadata enrichment or nowcasting workflows (we’re currently training on UC Berkeley’s nowcasting project), there are always constraints — legacy systems, missing integrations, data gaps. The temptation is to overstate capability or bury the caveat. But clients remember when you’re straight with them about what can’t be done. That trust is the foundation of everything else.

Cloud Automation (Before It Was Cool)

Mid-project, I had a conversation with Ian about cloud automation. We were talking about Zencoder, Amazon services, cloud-only versions, commercial plans — this was early 2014, remember, when “the cloud” still felt like a buzzword more than a strategy. We weren’t using those technologies on the Hong Kong project, but Ian was adamant: we needed to understand where the industry was heading.

That forward-looking mindset stuck with me. Even when you’re knee-deep in waveform validation and DVB embedding workarounds, you have to keep one eye on the horizon. Today, that’s the AI transformation conversation. Traditional broadcast workflows are still the bedrock — but the broadcasters who’ll thrive in the next five years are the ones thinking now about how AI augments, not replaces, their teams.

The Report That Never Stopped Evolving

By the time I left Hong Kong, we’d gone through ten versions of the report. V.3 to V.10. Each iteration reflected new feedback from the UK and US teams, refined findings, and clearer recommendations. We used Google Docs for shared collaboration — not groundbreaking now, but transformative then. Everyone could see the latest version, comment, track changes. The report became a living document, not a final decree.

And even as my assignment ended, I was planning feedback loops — ensuring Miranda, the vendor, would get consolidated input from both regions. That’s what I mean by closing the loop. It’s not just about delivering the report. It’s about making sure the findings land, the lessons are absorbed, and the next project starts from a higher baseline.

What’s Changed (And What Hasn’t)

A decade on, the technology has moved on. Skylight, Kaleido MV, Harris ADC, teletext profiles — some of that kit feels like broadcast archaeology now. But the patterns? Those are evergreen.

You still need an issue log. You still need to communicate constantly across time zones. You still need to be honest about limitations, even when it’s uncomfortable. You still need to think ahead, even when the urgent is screaming for attention. And you still need to close the loop — not just finish the work, but ensure the feedback flows, the vendor learns, and the client’s stakeholders are aligned.

That’s the lesson from Hong Kong. It’s not about the tech stack. It’s about the hygiene around the work — the documentation, the collaboration, the communication discipline. Those are the things that make a contractor someone you call back. Those are the things that turn a chaotic first gig into the foundation of everything that follows.

If you’re just starting out, or if you’ve been doing this for years and feel like you’re constantly firefighting, go back to basics. Start the issue log. Version the report. Close the loop. The rest will follow.