- In technological innovation, discovering early on that a hypothesis is incorrect can provide valuable information and prevent more costly decisions.
- A proof of concept allows a technology to be evaluated within clear boundaries, with an acceptable level of risk and a defined learning objective.
- Artificial intelligence applied to audiovisual dubbing can yield different results depending on the type and complexity of the content.
- Experience helps in decision-making, but leadership also requires the ability to change one’s mind when new data emerges.
- Innovating responsibly involves distinguishing between areas where experimentation is possible and those where safety, quality or commitments to customers demand the utmost rigour.
Experimenting in a controlled manner allows us to test hypotheses, identify the true limits of a technology and turn an early mistake into useful information for making better decisions.
Experimenting within defined limits allows us to evaluate new technologies without transferring unnecessary risks to services, content or customers. This approach links innovation with rigorous, effective management based on calculated risks: moving forward is not about experimenting with everything, but about identifying where a test can generate knowledge and improve decision-making.
Why can making mistakes be part of technological innovation?
I can’t remember when I first came to accept that making mistakes was part of my job, although I find it terribly difficult. It probably happened gradually, after enough projects, pre-tenders, tenders and technologies that, on paper, were supposed to behave one way but then decided to do something else. What is clear to me now is that, in the audiovisual world, there are times when not making a mistake can be more dangerous than making one.
I’m not talking about making mistakes just for the sake of it. In our sector, some mistakes are no laughing matter. When there’s a live broadcast or a client expecting what we’ve designed to work exactly as it should, the phrase ‘we were innovating’ is of little use. I’m talking about a different moment: when we’re still deciding which technology to test, which architecture to use, or whether an idea is worth turning into a project.
We don’t always have all the information at that stage. And waiting until we do may simply mean arriving too late.
I’ve never been entirely convinced by that romanticisation of failure that we’ve imported from the world of innovation. Failure isn’t an option; making a mistake is. Wasting time and money isn’t either. And making exactly the same mistake twice is hardly innovative. What does have value is making a reasonable decision based on the available information, testing it in a controlled manner, and discovering that our hypothesis was wrong.
Because then we have something we didn’t have before: information. And, in technology, discovering early on that you’re wrong can be far more valuable than having been right in a meeting.
What do you learn from realising early on that a technology isn’t working as expected?
In audiovisual services, we live with a constant contradiction. We work with solutions or services where error tolerance must be minimal and, at the same time, with technologies that change so rapidly that waiting for everything to be proven before using them would be a brilliant way of always arriving too late.
This has been particularly evident with artificial intelligence.
A while ago, we carried out a proof of concept using a particularly complex language. We wanted to find out to what extent it was possible to automate dubbing and, so as not to make it too easy for the technology, we chose three very different types of content: a film, a TV series and a cartoon.
The answer was quite clear: it wasn’t possible.
At least, not in the way we’d imagined. In the film and the TV series, the result was still a long way from what we’d consider acceptable. It wasn’t enough simply to translate the words correctly. There was the acting, the intent behind the dialogue, the rhythm, the voices, the synchronisation and all those nuances that make a dubbing job work without the viewer even noticing it.
Interestingly, the result was much better with the cartoons. That’s when we began to realise that perhaps the question we’d asked ourselves at the start of the trial wasn’t the right one.
It wasn’t a question of whether it was possible to automate dubbing. It was a question of understanding which content could be automated, which required a semi-automated process, and which still needed much greater human intervention.
At that time, the technology wasn’t ready to take the idea much further. Today, the situation is very different. Technologies now exist that allow us to automate stages of dubbing and reproduce certain characteristics of voices when switching languages, opening up new possibilities for audiovisual processes.
But the lessons learnt from that test remain valid. Just because a technology can do something doesn’t mean it can do it equally well with any content.
In fact, part of the problem has shifted. It is no longer simply a matter of developing better algorithms for dubbing, but of knowing when we can rely on an automated process and when we cannot. We can use specific algorithms to analyse content and help assess whether it is a candidate for automated dubbing, whether it requires a semi-automated workflow, or whether its complexity calls for a different approach.
Our proof of concept didn’t achieve what we’d set out to do at the start. We didn’t manage to automate the dubbing of all three types of content. But we discovered something far more useful: the question wasn’t whether the technology worked, but where it worked and to what extent we could rely on it.
That sort of mistake is well worth it.
What are the risks of confusing experience with always being right?
There’s another pitfall that emerges over the years and which worries me far more than simply making a mistake: experience.
The more projects you’ve seen, the easier it is to recognise patterns. There are situations that someone is facing for the first time, which you’ve already been through three or four times. That helps you make decisions faster and, often, better. Something far less useful can also happen: you start to confuse experience with being right.
I’ve defended ideas with great confidence that later didn’t work out as I’d hoped. I suppose anyone who’s been making decisions for long enough could say the same. The difficult moment comes when you’ve already publicly defended a decision, convinced others, and data starts to emerge suggesting you might have been wrong.
At that point, you can use your experience to explain why the data doesn’t prove anything yet, or you can change your mind.
The second option is considerably harder.
And I think that’s where a side of leadership comes in that we rarely talk about. It’s very easy to tell a team that they’re allowed to make mistakes. The real test comes when you’re the one who’s got it wrong.
Saying ‘you were right, I was wrong’ doesn’t make you lose authority. What can make you lose it is continuing to defend something when everyone in the room already knows it isn’t working.
And it’s not just about yourself. If the first question when a problem arises is ‘who did it?’, the next person who spots something odd will think twice before speaking up. In technology, we’re constantly talking about monitoring and early-warning systems, but one of the best ones out there is still someone saying ‘this doesn’t add up’. Provided they dare to say it.
How can we experiment with technology through small-scale trials and controlled risks?
That’s why I like a fairly simple idea when it comes to innovation: making mistakes on a small scale.
If we believe a technology can improve a process, we may not need six months of meetings to decide who’s right. Sometimes we just need a small trial, clear boundaries and two weeks.
Before we start, I try to answer three questions: what do we think will happen, how much can we afford to lose if we’re wrong, and what will we need to have learnt by the time we’re finished.
The third one is the important one.
A pilot that confirms our hypothesis has an obvious outcome. But one that disproves it should too. If we can say ‘this doesn’t work for these reasons’, we’ve reduced uncertainty. If, on top of that, we discover a use we hadn’t anticipated, we may have found something that wasn’t even in the initial plan.
The real failure would be to end up exactly as we started, only a few weeks later and with a slightly smaller budget.
This, of course, does not mean experimenting with everything. Signal continuity, security, content integrity or commitments made to our customers demand rigour. Leadership also involves knowing where we can experiment and what risk we are prepared to take to learn something we do not yet know.
How does leadership influence learning and technological decision-making?
Over the years, I have stopped placing too much faith in projects which, when recounted some time later, seem to have followed a perfect straight line from the initial idea to the final result.
The real-life projects I’m familiar with don’t usually work like that. No two projects are ever the same, even if they supposedly use the same technology. Needs change, the people who will use it change, new technology emerges, a hypothesis that seemed obvious turns out to be wrong, something we considered secondary ends up being fundamental and, every now and then, an idea that seemed absurd ends up solving a problem we’d been trying to resolve for months.
That’s also why my understanding of leadership has changed. I no longer believe that leading a team is about being the person in the room with the most answers. I think it has far more to do with ensuring the right questions are asked at the right time, and that the people who know something you don’t have the confidence to tell you.
What’s more, I like to think that a good leader is also someone who knows how to surround themselves with people who are smarter than they are.
Especially when what they have to tell you is that you’ve got it wrong.
Sometimes, a mistake is also a success.
FREQUENTLY ASKED QUESTIONS
Why can it be useful to make a mistake during an innovation process?
Because a controlled test that proves a hypothesis was incorrect provides information that was not previously available. That learning can reduce uncertainty and help decide where a technology works, where it doesn’t, and to what extent it can be relied upon.
What is the difference between making a mistake and failing?
A mistake can form part of a reasonable decision made on the basis of available information and evaluated through a controlled experiment. Failure occurs when the experience does not lead to learning, the same mistake is repeated, or time and resources are wasted without reducing uncertainty.
Can dubbing be fully automated using artificial intelligence?
Not all content responds in the same way to automation. The experience described shows that a film, a TV series and a cartoon may require different approaches: ranging from more automated processes to semi-automated workflows or greater human intervention.
What should be defined before starting a technology trial?
It is advisable to establish what is expected to happen, how much can be afforded to be lost if the hypothesis proves wrong, and what lessons should be learnt by the end of the trial.
What does ‘failing cheaply’ mean in innovation?
It means testing a hypothesis through a small-scale trial, with clear boundaries, an acceptable level of risk and a learning objective. It does not mean experimenting without control or taking risks in areas that demand rigour.
What is the relationship between leadership and technological innovation?
Leadership facilitates innovation when it ensures that the right questions are asked at the right time and that people with relevant information are able to voice doubts, highlight problems or challenge a decision.
