CTO leaders share playbook for building AI-native engineering organizations

Snowflake hosted CTO Circle during its 2026 Summit in San Francisco, convening more than 350 CTOs from financial services, telecommunications, retail and technology sectors. The forum addressed three core questions that every engineering leader is now grappling with: How should engineering teams be organized? Where should organizations invest as foundation models improve? How do you increase engineering velocity without accepting unacceptable operational risk? And what separates AI-augmented from AI-native organizations?

Vivek Raghunathan, Senior Vice President of Engineering at Snowflake, framed the challenge as a management philosophy shift. Most organizations begin by introducing coding assistants—developers write code faster, documentation becomes easier. These gains are real but superficial; they leave the underlying engineering system unchanged. Raghunathan argued that true transformation requires treating developer productivity as a product problem. Instead of assuming leadership knows what engineers need, Snowflake applied product management principles: they interviewed developers to identify friction points, mapped those points across the software development lifecycle, established baseline metrics, and ran experiments to measure the impact of every change. The approach combined top-down executive sponsorship with bottom-up adoption, ensuring that improvements reflected how engineers actually worked rather than how leaders expected them to work.

The results were measurable. In 18 months, Snowflake increased its internal developer Net Promoter Score by more than 30 points, producing a 4:1 ratio of satisfied to dissatisfied developers. Equally important, that improvement translated into an engineering organization capable of delivering software more efficiently and adapting more quickly as AI capabilities evolved. Raghunathan explained that adoption alone is insufficient; the real leverage comes from depth of usage and mastery at scale. He outlined three stages: Adoption (developers learn to use AI tools daily), Mastery (engineers discover repeatable workflows that consistently produce better outcomes), and Optimization (those workflows become organizational knowledge accessible to every engineer). One example is Snowflake's collection of engineering design patterns. Early AI adopters experimented with prompting techniques, planning methods and debugging approaches. Over time, the organization documented the patterns that consistently delivered better results and made them available across engineering. Every developer had the same AI tools, but engineers using proven workflows consistently outperformed those stuck at early levels of tooling adoption. The competitive advantage came from institutionalizing successful ways of working rather than simply deploying another AI assistant.

Jon McNeill, author of The Algorithm, expanded on this theme by urging leaders to reverse how they approach technology. Too often, companies begin with the technology and search for places to apply it. Successful organizations reverse that equation: they identify the few business constraints that matter most and redesign their engineering systems around solving those problems. As AI moves into production, success will be measured not by who generates the most code or consumes the most tokens, but by who builds the simplest, fastest and most effective engineering system. Perhaps the more interesting leaderboard will include engineers who have eliminated the most unnecessary steps between an idea and production.

Jeremy Burton, General Manager of the Observability Business Unit at Snowflake, addressed a second critical challenge: maximizing velocity while containing risk. AI has entered a new phase where early experimentation is giving way to production deployment, and organizations are expected to demonstrate measurable business value rather than isolated technical successes. At the same time, AI introduces entirely new operational challenges. AI agents generate more telemetry, interact with more systems and make decisions using information distributed across increasingly complex environments. This changes observability from monitoring infrastructure to providing the context AI systems need to operate reliably.

Burton challenged a common enterprise assumption: that better models simply need better data. In reality, AI is only as effective as the context it can access. That context extends far beyond raw telemetry; it includes the semantics that describe what data means, the relationships captured through ontologies and knowledge graphs, and the business context that connects systems. AI agents need standardized interfaces such as APIs, CLIs and Model Context Protocol (MCP) to reliably retrieve and act on information. Organizations that store logs, metrics, traces, operational data and business context across disconnected systems make it difficult for AI to reason accurately about production environments. Instead, engineering telemetry should be treated as data that exists within a common foundation where relationships between systems can be understood and queried.

Aditya Gaur, Engineering Manager at Netflix, demonstrated this principle in practice through the company's work on automated root cause analysis. Although the project is often described as an AI initiative, Aditya explained that its success depended far more on data architecture than on AI itself. Years before introducing AI agents, Netflix invested in connecting fragmented telemetry across systems, modeling operational relationships through an ontology and knowledge graph, and creating a shared context layer. By the time AI entered the picture, the foundation already existed. Rather than searching across disconnected logs and dashboards, AI agents could reason over structured operational knowledge and generate far more meaningful hypotheses during incident investigations.

Caitlin Colgrove, CTO at Hex, approached velocity from an organizational design perspective. She urged leaders to rethink what it means to move fast in the AI era. Organizations cannot afford to be partially AI native; they eventually reach a point where they must commit fully by restructuring how teams build products, make decisions and incorporate AI into everyday work. She described this as "burning the boats." Hex initially responded to generative AI by creating a dedicated AI product team. While the approach delivered useful features, it created an organizational bottleneck. Hex ultimately disbanded the centralized AI organization and distributed responsibility across every product team. Today, Hex delivers product rapidly and embeds AI capabilities throughout the product because ownership lives with the engineers closest to the customer problem.

Chris Kozlowski, Managing Director at Barclays, brought an enterprise perspective, highlighting that speed only creates value when matched with governance and trust. In highly regulated environments, engineering teams cannot afford to choose between innovation and control. Corey Burke, Senior Vice President Engineering at Dialpad, and Arun Rajamanickam, Vice President of Engineering at project44, described how AI is changing the pace of software development. As AI agents become capable of implementing significant portions of a feature independently, engineers spend less time writing code and more time defining intent, orchestrating multiple agents and validating outcomes. They emphasized that maximizing velocity requires building engineering platforms that allow teams to experiment quickly without compromising reliability. AI shortens the path from identifying a customer problem to validating a solution, but only if teams have the infrastructure, shared context and operational discipline to iterate confidently.

Qi Jin, Executive Vice President at Cerebras Systems, raised a final point: organizations optimized for previous generations of software development often become the biggest barrier to AI adoption. Established processes and organizational boundaries were designed to scale proven ways of working, not to continuously adapt to rapidly evolving AI capabilities.