What Working in Live Broadcast Taught Me About Building Better Tools

Working in live broadcast teaches you a useful kind of intolerance.

You stop caring very quickly about what sounds clever if the workflow is awkward. You stop admiring features just because they look advanced. You become sensitive to friction in a way that people outside the environment often are not. Delay stands out. Uncertainty stands out. Extra clicks stand out. Poor interface choices stand out. Anything that makes a user stop, think too long, second-guess, or hunt under pressure starts to feel unacceptable.

That has shaped how I think about building products far more than any trend cycle ever could.

Because in live production, the test is brutal. A tool does not get judged by how impressive it sounds in a meeting. It gets judged by whether people can trust it when the pace goes up, the feed gets messy, and no one has time for theatre. A modest feature that works every time is worth more than a flashy capability that collapses when the workflow becomes real.

That is one of the biggest lessons live broadcast teaches you.

Reliability beats theatre.

There is a lot of technology in media that looks strong from a distance and feels weak the moment it touches actual operations. Not because the engineering is worthless, but because the people building it often underestimate what pressure does to usability. A feature can be technically impressive and still be operationally wrong. If it adds doubt, hides key information, interrupts the sequence of work, or creates more checking than confidence, it is not helping. It is getting in the way.

That is why good tools, in my view, do not demand attention. They reduce wasted attention.

They do not ask the operator to learn a whole new religion. They slot into the rhythm of the work. They support the decisions already being made. They remove drag from the places where drag is expensive. They behave well in the background until the moment they are needed, and then they surface the right thing clearly.

That principle matters even more in live sport because the chain is never just one action on one screen. Moments do not live in isolation. They move through replay, logging, clipping, approval, archive, digital, rights constraints, sometimes multiple versions of output, and often different teams looking at the same event for different reasons. AWS’s media and sports workflow examples are useful here because they show what happens when the volume of live streams and output demands scales hard: workflow design starts to matter as much as raw technical capability. TV 2 Norway’s scaling work with AWS is a clear example of how rising event volume forces a rethink of workflow architecture, not just infrastructure spend.  

That is another lesson broadcast teaches you.

Context beats isolated capability.

A tool can do one thing well and still fail overall if it does not understand where that thing sits in the chain. A detection layer can identify objects. A retrieval layer can surface clips. A review layer can rank likely moments. But unless those pieces help the operator move through the actual sequence of decisions more cleanly, the product is still incomplete. MMDetection is a good example of a useful building block because it gives a structured way to run object detection inference and build around detected entities, but on its own that is only one layer. In production, what matters is what that layer enables next.  

Working in live broadcast also teaches you something about restraint.

People outside the environment often assume “better” means “more.” More panels, more controls, more overlays, more options, more intelligence everywhere. But in high-pressure environments, more is often worse. Better usually means clearer. Faster to read. Easier to trust. Harder to misinterpret. More forgiving when things get messy. The tool should be doing more work in the background so the person in the chair can do less unnecessary work in the foreground.

That changes how you think about innovation.

You stop asking, “What advanced thing can we add next?”
You start asking, “Where is the drag?”
Where does time get wasted?
Where does confidence drop?
Where does the user have to compensate for the system?
Where are people repeating the same low-value action because the workflow still has not been designed properly?

That is much closer to how I think now.

The most valuable ideas are often not the loudest ones. Sometimes they are surprisingly plain. Better surfacing of likely moments. Cleaner metadata. Less hunting. Better review flow. Easier context around what just happened. Stronger continuity from event to clip to publishable output. None of that sounds glamorous. All of it matters.

And it matters more than ever because live production is being asked to do more with more complexity around it. More live streams, more versions, more digital demands, more speed, more pressure on teams, more expectation that material should be ready almost immediately. Sports Video Group’s recent coverage of vulnerability and monitoring at scale in live sports is a good reminder that operational resilience is not some side issue. It is central. If the workflow is fragile, the whole system becomes harder to trust.  

Sports video group

So if there is one thing live broadcast really taught me about building better tools, it is this:

Better tools are not built by asking what looks advanced. They are built by asking what reduces drag without weakening control.

That is the standard I care about.

Not feature theatre.
Not abstract automation claims.
Not product language that sounds good but ignores how people actually work.

A better tool respects pace.
It respects pressure.
It respects context.
And most of all, it respects the user’s attention.

Because in live broadcast, attention is expensive.

Anything that wastes it is a bad design decision.