A CTO’s View on the Expanding Role of Data

Why Data Has Become a Core Operational Lever

When asked why data has taken up more of his attention, Russ pointed to a combination of forces that emerged naturally within his environment.

One is simply the expansion of digital activity. People who used to rely heavily on phone calls now follow up with emails or Teams messages. Customer requests that once lived in someone’s memory now come through PDFs, online forms, or notes typed into free-text fields. A brokerage operation might still hinge on human judgment, but the breadcrumbs of those decisions are increasingly captured in systems and correspondence.

A second factor is the accessibility of cloud platforms. When every team works inside a different system, context gets trapped. When Snowflake or similar platforms sit at the center, data from those systems can be combined, compared, and aligned. That accessibility doesn’t guarantee value on its own—but it creates the conditions under which value becomes possible.

The third factor Russ emphasized was the rapid maturity of natural language processing. Five years ago, trying to extract structured meaning from thousands of emails or call transcripts would have been a major engineering effort. Today, it is becoming a standard capability. That shift is what makes unstructured information a realistic input into operational decision-making rather than an untapped archive.

These forces do not redefine the CTO role everywhere, but they have reshaped the set of problems Russ chooses to attack.

The CTO as a Data Product Builder

A consistent theme from Russ was the distinction between ingestion and use. Getting data into the warehouse has become straightforward. Tools are more reliable, platforms are more elastic, and integrations are easier to configure. The bottleneck—or rather, the opportunity—sits on the modeling and product side.

This is where the CTO becomes directly connected to the way salespeople, operators, dispatchers, and customer teams work. In Russ’s environment, data products are not limited to dashboards or reports. They are defined, governed sets of logic and context that support specific decisions and activities. They might help a salesperson understand which prospects are likely to convert. They might help an operator detect early signs of a delay. They might help a manager understand the pattern behind exception calls.

Modeling the data correctly becomes central. For that modeling to work, structured and unstructured sources need to be combined in a way that represents the real workflow, not just the system-captured version of it. And governance must extend beyond tables and columns to include the outputs of LLMs and the prompts that generate them. For Russ, this is now routine CTO work: defining what the data products are, how they behave, and how different teams will consume them.