In an industry defined by constant evolution, "innovation" is a word I hear every single day. It gets attached to the latest platform, the newest tool, the freshest trend. But after years working at the sharp end of broadcast and media technology, I've come to believe that real innovation has very little to do with chasing what's new. It is about improving the way we work. It is about revisiting the requirements and the ways to deliver. Innovation is a re-iterative process, not a one-time job. Also, it's about building systems that work, scale, and endure and about maintaining genuine control over the technology you rely on.
That conviction shapes almost every decision we make.
The Hidden Layer of Innovation
When people talk about innovation in our industry, they tend to focus on the visible stuff, the platforms, the hardware, the headline partnerships. What they rarely talk about is the software layer underneath it all.
In my view, every technology company must have software development capability, but I don't mean that in the narrow sense of having a team of dedicated programmers. What I mean is that engineers working with systems, broadcast engineers, IT specialists, AV media professionals need to understand the core principles of programming techniques and be able to use them to produce what I'd call "software glue." That's the integration layer that makes products from different vendors work together, without having to rely entirely on external development partners.
When you build that capability internally, it changes the dynamic entirely. Systems become more adaptable, integration problems get solved faster, and crucially, the knowledge stays inside the organisation. Innovation becomes something you own, not something you outsource.
Enabling Engineers to Evolve
The talent doesn’t come from hiring differently it comes from developing what we already had. The engineers who've built this capability are people from the IT domain, from broadcast, from media operations. What they share is an open mindset and a willingness to learn. The job of leadership is to enable that.
We have supported access to micro-degree programmes through local universities, online learning platforms like Coursera, and technology conferences. But honestly, the most important thing has been the culture we've built around it. If an engineer wants to learn something new, we say yes. If someone has an idea for how to improve a process, we listen. If it's a good idea, we try it. That sounds straightforward, but it's rarer than it should be.
The result is a team that evolves alongside the technology rather than being left behind by it.
AI: A Powerful Tool, If You Stay in Control
Used in the right way, AI is a genuine enabler. I see it as a partner in the learning process, something you can use to validate ideas, explore different approaches to technical challenges, and accelerate your understanding of new domains. That's valuable. But if you trust it too much, it will bring problems.
The issue is dependency. If you allow AI to do your job for you rather than support you in doing it, you can end up in a situation where you don't fully understand what you have built. And the day that system collapses, you have no means to fix it. I've seen this pattern emerging, and it concerns me.
The trend of low-code and no-code development is a good example. It's genuinely useful for prototyping, for testing ideas, for helping people without deep engineering backgrounds see what's possible. But to build something solid, something secure, scalable, and maintainable over time you still need to understand the underlying process. You need domain knowledge. You can't just chain together AI prompts, add a new module because it seemed to work, and call it a system. It doesn't work like that.
My principle is simple: AI should support expertise, not replace it. Stay in control of what you build, validate the output, and make sure your team understands every layer of what they've created.
Security Is Not a Layer, It's a Foundation
Security cannot be retrofitted. When we implement something, we do it securely from day one, not as an afterthought, not as a final checklist item. That means validating the software solutions we write ourselves, but it also means understanding how our partners' development processes work and what their cybersecurity policies actually look like in practice, not just on paper.
There is a specific risk I want to highlight that doesn't get nearly enough attention - software supply chain attacks via programming libraries. When AI suggests a library to use in building a software product, that library may contain vulnerabilities. If you automate that process without scrutiny, you can automatically introduce serious security flaws into your own system. The very efficiency that makes AI appealing can, if you're not careful, become a liability.
This is exactly why working with experienced partners matters. The ability to build something quickly is different from the ability to build something that is secure, reliable, and fixable when something goes wrong.
Cutting Through the Noise
Fear of missing out is one of the most expensive forces in our industry. The pressure to adopt the next big thing leads to decisions that aren't well thought through, and systems that don't perform when they meet real-world conditions.
We try to be genuinely mindful of technology hype without dismissing anything outright. We meet potential partners at trade shows, visit them, test their solutions, and, critically, we make a clear distinction between what a product actually does today and what is promised on a roadmap. We're transparent with our customers about that distinction. If a function isn't there yet, we say so. If a vendor's roadmap looks credible, we say that too. We give vendors direct feedback on what we've found in testing, which shapes how we work with them going forward.
Occasionally, we walk away entirely. From time to time, we reach a point where we can see that a vendor has stopped improving their products, that the willingness to evolve isn't there anymore. When that happens, we start looking for alternatives. Organisations, like their products themselves, have a lifecycle.
The Role of a Technology Partner
If you are a content owner or broadcaster building a modern media workflow, the amount of groundwork involved is significant: evaluating vendors, testing interoperability, understanding where solutions fall short, and planning for how everything evolves. Most organisations simply don't have the time or expertise to do all of that thoroughly.
What we offer isn't just access to technology, it's the practical, tested knowledge of what works. That's a meaningful difference, particularly as low-code tools and AI make it easier than ever to build something that looks like it works but hasn't been properly validated.
Innovation Starts with Challenging Assumptions
If there's one piece of advice I would give to any organisation in this space, it's this: "we've always done it this way" is not a strategy.
I say this to my own team as often as I say it to customers. We constantly ask ourselves whether we're solving problems in the best way, whether the landscape has shifted beneath us, whether we're holding onto assumptions that stopped being true. That kind of internal questioning is uncomfortable, but it's necessary. And when we work with customers, if we can see that a change would genuinely benefit them, we say so and help them think through how to make it happen.
For content owners specifically, I'd encourage the same mindset around platforms. Don't be afraid of YouTube or TikTok, use them. Upload promotional content, pilot series, build an audience, create attention. Then bring those viewers into your own ecosystem. Use every platform available as an opportunity rather than seeing it as a threat to your existing environment.
Looking Ahead
I'm genuinely excited about what's coming. AI will continue to improve what's possible, if carefully applied, it's going to make a real difference. I'm also watching developments in TAMS, Time Addressable Media Store, closely. TAMS' magic lies in changing how content is stored and making it easily accessible via an open API. TAMS will be the enabler of building content-centric workflows in hybrid cloud environments. The potential gain in increased efficiency is significant, and I'm keen to see how that develops in practice.
But if I'm honest, the technology itself isn't what excites me most. What excites me is the capability we are building the combination of internal expertise, trusted partnerships, and the discipline to cut through hype and focus on what actually works. That's what will make the difference for our customers, not the tools themselves.
The organisations that succeed in the years ahead will be the ones that maintain real control over their technology, build genuine expertise inside their teams, and stay honest about what's proven versus what's promised. That's the approach we've always taken, and I remain convinced it's the right one.