Data Operations: Shruthi Bhate on Governance and Observability

During a recent conversation on The Executive Outlook, Isha Taneja spoke with Shruthi Bhate, Head of Data Engineering & Operations at TalkTalk. 

Shruthi leads where transformation becomes real: platforms, pipelines, governance, quality, and the operational habits that determine whether a modern data estate earns trust or creates friction. Her perspective is grounded in delivery: the kind that must work quietly in the background while customers remain unaffected; leadership expects outcomes, and teams still need accurate, timely data every single day. 

What stood out wasn’t only what she had delivered, but how she thought. Shruthi doesn’t describe migration as a platform change. She describes it as a cultural and organizational change where people and processes are the make-or-break factor. And she keeps returning to one idea: strong data operations are what turn transformation from an announcement into a stable reality.

The shift that defines her work: transformation must be runnable

In many organizations, migration is treated like a finish line: move systems, move pipelines, declare success. Shruthi’s view is different. She treats migration as the beginning of a new operational contract. 

A platform only creates value when it can be run consistently. Pipelines must be reliable, not heroic. Data quality must be visible and measurable. Ownership must be clear, not assumed. Issues must be caught early, not discovered by business users. Change must not break continuity. That’s the mindset of DataOps leadership: not just building but ensuring what’s built can be trusted at scale. As organizations adopt self-serve analytics and automation, the dependency on stable foundations grows. The cost of unreliable data multiplies quickly. One break can trigger multiple downstream failures: dashboards fail, decisions slow, customer experience suffers, and teams lose confidence.

A career built on one trait: problem solving with data

Shruthi began her career as a software engineer. But one pattern repeated: she was always a problem solver, and she consistently reinforced that problem-solving mindset with data-driven decisions. Over time, she realized that the more data she used to solve problems, the more she was drawn toward data itself. That pull became direction. She moved into data engineering and has now spent more than 14 years as a data professional, growing into leadership roles at the intersection of engineering execution and business outcomes. Her leadership style is shaped by two consistent drivers.

1. Progressing the estate across people, process, and technology.
2. Learning and adapting with every new role and challenge.

That combination creates leaders who don’t treat change as disruption. They treat it as a disciplined upgrade, not an event but a continuous practice.

What she owns: foundations, pipelines, governance, and operations

In her role today, Shruthi Bhate is accountable for the engineering and operational engine of the data platform. This includes the data platform and pipelines, governance and data quality standards, operational readiness across platform operations and DataOps practices, and ensuring customer migration happens with minimal disruption. 

She has already been part of one major shift away from a legacy data warehouse into a modern cloud state, and she is now part of another migration wave where the pressure isn’t simply “move faster”, but “move safely while the business continues”. 

This is where DataOps becomes the differentiator. In stable organizations, DataOps isn’t a separate team that “handles production”. It is a discipline embedded in how engineering teams build. It shows up through patterns and standards that prevent inconsistencies, automated checks that catch problems early, monitoring that makes the system visible, response processes that reduce downtime and confusion, and governance that’s practical enough to follow.

 In short, Shruthi doesn’t just deliver pipelines. She helps create conditions where the platform can be trusted. And trust, in practice, is an operational outcome.

Cloud migration isn’t tool adoption. It’s culture change.

One of Shruthi’s strongest reframes in the episode was simple: migration is frequently misunderstood. 

Many companies treat cloud migration as a technical exercise: adopt a platform, move workloads, migrate processes. But in her experience, what migration demands is cultural change, because people and processes sit at the heart of success. 

She emphasized that businesses must not view migration as “another platform being moved”. They must view it as a shift defined by outcomes and expectations, including what the organization gains from the new platform, which business outcomes are expected, what KPIs define success, what trade-offs are acceptable, and what roles and responsibilities shift during the journey. 

This changes the dynamic entirely. Instead of the data team owning migration, migration becomes a shared journey with stakeholders helping define success and validating outcomes. Her point is practical: if stakeholders can’t articulate what they need, engineering teams are forced to guess. And guessing it is expensive. 

Strong data operations depend on clarity: what should be monitored, what should be validated, and what “good” looks like after go-live.

How culture change actually happens: sponsorship, literacy, reinforcement

Shruthi’s operational truth is direct: culture change cannot be driven from one layer of the organization. It must be sponsored by the top. When senior leadership is aligned and committed, teams feel safe adopting new ways of working. 

When leadership is uncertain or inconsistent, teams hedge. Standards become optional, governance becomes paperwork, and adoption becomes fragmented. Three practical lessons stood out.

1. Sponsorship isn’t a kickoff speech. It is ongoing reinforcement, especially when timelines tighten and trade-offs appear.
2. Education builds trust. Stakeholders need literacy around what’s changing and why. Otherwise, migration becomes something tech is doing, not something the business is shaping.
3. Accountability must be clear at the implementation level. Teams need to know who owns what, what success means, and how decisions get made, so delivery doesn’t become a tug-of-war.

Culture change also isn’t quick. It requires continuous effort across executive sponsorship, leadership alignment, and delivery reinforcement.

Case study: global data unification without breaking local ownership

Shruthi shared a standout case study from Unilever Food Solutions, part of Unilever, operating across 75+ markets. 

The starting reality was tough. Each market managed its own local data. Order, inventory, and sales data weren’t unified. Leadership lacked cross-country visibility. Marketing propositions weren’t consistently customer-centric. Local markets resisted centralization due to fear of losing control.

This is a classic challenge: technical work is hard, but organizational work is harder. 

The approach she described was intentionally nuanced. Define a common global data model to enable cross-country insight. Centralize collaboration into a shared data lake for unified analysis. Preserve local accountability and local control, so markets still own their context. Prove value early through dashboards showing cross-market product performance. 

Once teams could see tangible insights, resistance softened because value became real. 

She also shared a realistic delivery detail: global rollouts take time. In roughly a year and a half on the programme, the team delivered to around 27 to 28 countries across multiple regions and time zones, laying standards and frameworks that continued after she moved on. 

That’s a strong signal of maturity: transformation that survives beyond individuals is transformation that has been operationalised.

Post-migration: observability isn’t optional

When the conversation moved to post-migration validation, Shruthi answered from the operator’s seat. 

Yes, performance and resilience metrics matter. But post-migration success depends on visibility. Data observability must be monitored day-to-day. Alerting must surface issues early. Response times and SLAs must be defined so “who reacts” isn’t a question during incidents. Dashboards and tools must make the platform understandable for operations teams and stakeholders. 

She made crucial clarification: ops can’t act without steer. 

If requirements aren’t defined, meaning what to monitor, what thresholds matter, and what triggers remediation, then DataOps becomes reactive guessing. And reactive guessing becomes firefighting. 

Strong data operations mean monitoring is designed into delivery, thresholds are agreed with the business, escalation paths are clear, remediation is structured, and visibility is treated as a first-class product.

DataOps checklist for a stable migration

If you want migration to be runnable after go-live, these basics must be in place.

1. Define success using KPIs, quality thresholds, and continuity expectations
2. Establish ownership so approval, remediation, and accountability are explicit
3. Implement observability covering freshness, quality, failures, and lineage signals
4. Set alerting and SLAs with response times, escalation paths, and incident routines
5. Create visibility dashboards for stakeholders and operations teams
6. Treat governance as operational practice, not documentation

Tool philosophy: outcomes first, realism always

In rapid-fire platform preferences, Shruthi took a principled stance: there shouldn’t be loyalty to a tool. Choices should be driven by business outcomes, strategy, constraints, and the organization’s current capabilities. 

She also offered a practical warning.

1. Avoid underbuilding systems that can’t support growth
2. Avoid overbuilding systems that are overengineered for projected needs

Scalability isn’t a slogan. It is a roadmap decision. Build what you know, plan what you expect, and scale as you learn.

And her framing question is one every team should write down before selecting tooling: 

What problem are we trying to solve with this data platform?

Closing reflection

Shruthi’s insight cuts through the usual migration narrative: cloud transformation is not a tool upgrade. It is a cultural and operational shift. Platforms only deliver value when teams trust the data, governance is lived day-to-day, and the system can be run reliably under real business pressure. That is why she emphasizes sponsorship from the top, clear roles and accountability, and a shared understanding that foundations are not just engineering work. They are an organization-wide responsibility. 

Her experience with large-scale programmes also shows what successful change looks like in practice: preserving local ownership, proving value early, and creating visibility that turns resistance into momentum. And once migration is complete, the job isn’t done. Post-migration observability, monitoring, and SLAs become the difference between a stable platform and a recurring fire drill. 

The message is grounded: build what you can operate, govern what you can trust, and scale what you can see, because strong data operations are what make transformation last.

For more leadership stories on data operations, governance, and transformation delivery, stay tuned with The Executive Outlook.