Paramount

Olga Arkadieva

Data Trust Authority

One Source of Truth Across Every Stream

Most people think scale means more: more users, more events, more data. It doesn't. Cloud tools solved that years ago. The real challenge is making sure everyone means the same thing.

Picture twenty systems asking, "Is this person watching kids' content right now?" They should all get the same answer, worked out the same way, at the same moment.

In streaming, that's surprisingly hard. Live TV and on-demand run on different clocks. Several brands share the same back end but have different front ends. And sooner or later, every platform team decides it's quicker to work out the answer itself than to wait for the source. Do that across five platforms and you don't have five copies of one system. You have five different "truths," and nobody can say which one is right.

So before any platform team starts implementing, I want one thing settled: who is the one official source for each fact, and will everyone downstream agree to stop recalculating it? Adding more pipes doesn't help you scale. What helps is deciding, once, what the water means and not letting anyone change it on the way through. That's why I put so much effort into aligning specs across platform teams early, so everyone builds from the same definition. You can swap out your tools and vendors. You can't swap out that agreement.

Separating Consent Signals at the Source

Privacy doesn't slow innovation. Ambiguity does. When nobody can say for sure what a user agreed to, every product discussion stops while legal, product, and engineering argue about the risk. Good privacy rules aren't the brakes on a fast car. They're the suspension that lets the car go fast over bumpy ground without falling apart.

  Looking finished isn't the same as being trustworthy. That gap is where a leader earns their job.  

The common mistake is treating consent as one single thing. It's not. What a user chooses inside the app is a deliberate choice, and we're responsible for honoring it. A device's ad setting is just a default set by the platform, and we don't control it. Mix the two into one flag and sooner or later you'll break one of them without knowing it. You'll probably find out when an audit does. Treat GDPR and U.S. defaults as an afterthought instead of part of the design, and it gets worse.

My rule: how we classify something and what a user consented to must never be decided by the same logic, even when they give the same answer. Privacy is fastest when you decide it once and it stays boring. It's slow when you have to argue it out every time someone builds something new.

Turning AI Adoption into Measurable Impact

When a team adopts AI, the first problem isn't productivity. It's measurement, and most teams skip it. Saying "we deployed the tool" or "people ran this many queries" only tells you there was activity. Activity is the easiest number in the world to make look good.

The number I want is smaller and harder: how many hours a week did this give back to one specific engineer? If I can't answer that, I don't know whether the tool works. I only know that it exists.

Then comes a tougher question: what happens to that hour? Does it go to better thinking? Or does it quietly turn into higher expectations, so the person just runs faster for the same result?

I handle trust the same way. I don't ask whether an AI-written report "looks right." I ask how many issues it caught compared with a person doing the same review, and how exactly we're measuring "accurate." AI doesn't remove the need for careful measurement. It makes skipping it more expensive. I'd rather roll out slowly with a real number than fast with only adjectives.

Choosing Trust Over Launch Speed

Leading through the AI shift changed how I think about trust more than it changed how I think about technology. Trust is the one thing in this work that you lose instantly and rebuild painfully slowly. You can fix a broken pipeline over a weekend. You can't rebuild a user's confidence that quickly, and sometimes you can't rebuild it at all. The same goes for an engineer's confidence in a system.

Trust has to run in two directions. Users need to trust that their data is handled the way we told them, especially when the stakes are highest, like when a child is on the other end of the session. And my team needs to trust systems that now move faster than their habit of double-checking can keep up with.

That's why I'll delay a launch over a doubt I can't fully explain yet, even with a deadline looming. A day's delay is cheap. A trust incident is expensive, and after one, people believe the next one much more easily. Looking finished isn't the same as being trustworthy. That gap is where a leader earns their job.

Building Trust through Measured Outcomes

Good intentions don't build trust, and neither does a policy document. Two unglamorous habits do: measuring results carefully, and acting on what the numbers tell you, even when you don't like it.

Most teams measure what's easy, like how often something is used or what people say in surveys. What matters is different: does the output hold up when someone checks it carefully, every time, and not just in the demo chosen to impress leadership? A trustworthy system is one where there's very little difference between how it performs when we're watching and how it performs on an ordinary day.

The harder half is acting on the results. Say a tool is right ninety percent of the time, but the other ten percent quietly wears down people's confidence. It's tempting to call that "mostly reliable" and move on. The right move is to treat the ten percent as the real story and pull the tool back until it's fixed, even if that looks like going backward on a number everyone wants to see go up.

You can't announce trust or add it later. It's what you get from the discipline you showed when nobody was checking your work.