Jeremy Burton, CEO of Observe – Interview Series

Jeremy Burton, CEO of Observe, is a seasoned enterprise software executive with over 20 years of leadership experience across major technology firms including Dell Technologies (DELL ), EMC, Oracle (ORCL ), and VERITAS. He has led global teams in product development, marketing, and strategic M&A, building and scaling businesses in storage, security, and SaaS. Burton also co-founded the Oracle Technology Network, which grew to millions of members worldwide, and currently serves on the Board of Directors at Snowflake and as an advisor to McLaren’s Formula 1 team.

Observe, based in San Mateo, California, is a next-generation SaaS observability platform that helps SRE, DevOps, and engineering teams investigate and optimize modern distributed systems. Built on Snowflake’s data infrastructure, it unifies logs, metrics, and traces into a single, context-rich dataset—allowing teams to accelerate incident response, pinpoint root causes, and improve reliability across complex cloud environments.

You’ve held senior leadership roles at global giants like Dell, EMC, and Oracle, and now you’re leading a startup with Observe. What motivated you to leave behind stability and scale to take the leap into building something from the ground up?

I’ve been fortunate in my career to work for some incredible leaders, including Larry Ellison and Michael Dell. I worked with them 20 or 30 years into their tenure, but what makes them remarkable is that they were there from the beginning. They made the early product decisions, established the routes to market, and set a culture for long-term success. My role was to provide incremental improvements on top of the decades of hard work they had already done. Eventually, I reached a point in my career where I wanted to prove to myself that I, too, could build a company, take a product to market fit, establish a sales motion, and create a culture that I believed could thrive over the long term.

Observe is positioning itself as a new category in observability, integrating logs, analytics, and monitoring into one unified platform. How do you see this approach redefining the space compared to legacy players like Splunk and Datadog (DDOG )?

The big problem facing legacy tools is that they were not built for scale. In conversations with customers, we’ve seen time and again that Splunk and Datadog become cost-prohibitive as the volume of telemetry grows, and that’s fundamentally a problem with how legacy tools were architected.

Observe differs in that our platform is built on a streaming data lake architecture using open formats like Apache Iceberg. That means we can decouple compute from storage, scale elastically, and deliver observability at a fraction of the cost of traditional systems. Competitors like Splunk still rely on monolithic architectures that require planning for peak capacity—and even newer tools like Datadog require data tiering, rehydration, and reindexing to keep costs under control.

We also focus on a unified observability experience. Logs, metrics, traces, and events all live in one place, with a single query language and a Knowledge Graph that automatically maps relationships between services, users, and incidents. That context is what makes troubleshooting faster. By contrast, Splunk and Datadog have separate backends for logs, metrics, and traces, leading to slower analytics.

Finally, we’ve invested heavily in AI-driven troubleshooting. Our O11y AI SRE™ can take natural language input, generate hypotheses, and guide engineers through incident resolution, not just alerting them. And it’s built to make use of our Knowledge Graph, which provides the necessary context for accurate troubleshooting. That’s a step beyond the anomaly detection or alerting most competitors offer today.

Put simply: we’re cost-effective, we’re unified, and we’re open. Those three qualities are what customers consistently tell us set Observe apart from legacy players like Splunk and newer incumbents like Datadog.

Having overseen multi-billion-dollar operations and now running a startup, what lessons about efficiency, agility, or innovation from large enterprises carry over—and what lessons don’t?

It’s counterintuitive, but successful large companies do a small number of things really well, and they understand every detail. The ones that flounder do too much, and everything degenerates into mediocrity.

At a startup, you focus on one thing at a time and obsess over every detail. There is not enough funding to do more than that.  As a result, what makes startups so intense is that you can literally go out of business if you don’t figure things out quickly enough. Therefore, you have to make decisions more quickly, release more quickly, fail more quickly and learn more quickly. On top of all that, you have to do all that with fewer people.

Nonetheless, the most liberating aspect of a startup is that you don’t have an established product, business model, or route to market. This means there is free rein to make new assumptions about all of these things. That’s not the case at a large company. For example, you can’t break the business model with a new disruptive product. Even if technically you could build it, the CFO and Wall Street won’t let you maximize its potential. That’s why startups win quite a lot of the time when, in theory, they should have no chance.

You’ve also been a board member at Snowflake for nearly a decade. What have you learned from Snowflake’s journey that informs your strategy at Observe?

Snowflake attacked an age-old problem with a new architecture. They built their technology on a simple but powerful idea and disrupted a massive market bogged down by legacy vendors. There are a couple of lessons here: play in markets that are massive, and you can build a massive company. In addition, you must have a radically different approach from the incumbents so the customer can see huge benefits in moving.

The observability market we’re attacking is massive, $30B and growing. We’ve solved the observability problem in a very unique way: utilizing a data lake foundation, elastic compute, and open formats. This promises to give customers an order-of-magnitude improvement in both troubleshooting speed and overall cost.

You’ve been deeply involved in product development, marketing, and large-scale M&A. How does that broad background influence the way you prioritize growth strategies at Observe?

In the early days of a startup, it’s quite simple, you build a great product and try to sell it. That’s the growth strategy. That said, my career is very biased toward enterprise software and solving complex problems for large enterprises, so it’s probably not surprising that Observe is focused squarely on that!

Based on my experience, I believe that to build a large observability company, you have to solve the problem for the largest companies in the world. These being the issue of petabytes of data, thousands of users and thousands of applications. There are many observability companies, but very few can win in that environment, I am making sure that Observe can.

Observability has become critical as modern distributed applications grow more complex. Where do you see the biggest challenges and opportunities for enterprises over the next 3–5 years?

The biggest challenge today is scale. Kubernetes, microservices, and now AI workloads are producing data volumes that overwhelm traditional tools. Reliability of these tools plummets as the cost skyrockets and it’s simply not sustainable; a new architecture is needed.

To make matters worse, over the next few years we are going to see more code written, assisted by AI coding tools, than at any point in history. That code is not going to be perfect, and at some point it’s going to fail. The area of growth lies in asking yourself: how do you troubleshoot code that no one wrote? And or, while code-gen tools can look at code and fix bugs, can they truly look at how the application is behaving in production and find the problematic code? That’s a massive opportunity for observability vendors in the future.

Many teams struggle with tool sprawl, using separate systems for logs, metrics, and traces. How does Observe help simplify that experience for engineering and DevOps teams in practice?

Instead of juggling three or four tools, Observe gives customers a single platform to use. A company’s logs, metrics, traces, and alerts live in the same system and are tied together by a Knowledge Graph. The Knowledge Graph provides context that allows users to drill and pivot seamlessly across logs, metrics, and traces to accelerate troubleshooting. This reduces the amount of time they have to spend hopping from platform to platform, instead allowing them to uncover an issue with no data exports or context switching.

Can you share a concrete example of how Observe has helped a customer solve a major problem—something that would have been difficult or impossible with traditional observability tools?

Capital One uses Observe to surface the status of critical customer journeys by correlating and enriching telemetry data with relevant business context. They ingest hundreds of terabytes of telemetry per day, including logs, metrics, traces, change records, VPC flow logs, and AWS config data. Observe provides Capital One with a unified platform for end-to-end observability, so developers and SREs can perform interactive incident response and debugging.

What role does machine learning or AI play behind the scenes at Observe, and how is it helping customers surface insights more quickly or automatically detect issues?

Machine learning has a chequered history in observability because enterprise environments are inherently noisy, and it’s very hard to produce a model that doesn’t result in thousands of anomalies. Generative AI is a very different technology and will have a much more profound impact.

We believe AI will change the way engineers interact with observability tooling. First of all, they will be able to talk directly with their observability data in natural language while sitting in their IDE, half of our users in the future may never log in or learn Observe! Second, AI agents will be present during “peacetime” to scan telemetry and look for potential issues that may eventually result in an incident. AI agents don’t get tired or bored and they can perform work that humans are simply unable to do. Finally, during “wartime,” AI agents will assist engineers and SREs with the course of action they should take to resolve the problem.

Your Formula One –inspired leadership style emphasizes mental toughness and learning from mistakes. How has that perspective shaped your approach to building Observe and leading the team through both wins and challenges?

Success in F1 is bred using data to guide future decisions, both for the driver and the car. By the time an F1 car reaches the end of the season, 90% of the parts have been replaced, and it’s 2 seconds quicker around the race track.

At Observe, we have to have the same mindset to succeed. We release, we measure, we listen, we adapt quickly. I would imagine 90% of our product is different today than even a couple of years ago. This approach takes a lot of discipline, and a lot of humility, it’s not easy to hear bad news over and over again. Yet, if you act on enough bad news, it steadily turns into good news, and ARR accelerates. It’s not magic, it’s logic!

Thank you for the great interview, readers who wish to learn more should visit Observe.