Why I joined Everest

Across all of these companies, I worked with exceptional teams solving complex problems in very different contexts. That diversity of environments and perspectives has shaped how I think about technology and, more importantly, learn how systems actually get built and scaled inside real organizations.

In retrospect, it’s clear that this cumulative journey led me here.

I vividly remember the moment at JPMorgan Chase & Co. when my colleague Sam Yen told me about a conversation he had that morning with Franz Faerber, who had just demoed Everest. Sam pulled up a recording of the demo and walked me through it.

My immediate reaction was simple: why aren’t we working there?

I am, in a sense, returning to where I started—rejoining prior colleagues, ex-leaders at SAP who had played a pivotal role in its transformation to the cloud era. I am going from a 230,000-person organization to a ~150-person startup, but to one with a large ambition —building transformative AI technology for the enterprise. 

Here, I want to share what gave me the conviction to make that leap.

Leaving the enterprise to help the enterprise

My professional journey has always been about scaling complexity. At SAP, I spent 13 years launching new business units—from energy and sustainability to sports and mobile—expanding the reach of core ERP. I then dove into the world of ML/CV, drones and robotics with startups before returning to the complexity of a large company…well… a very large company, J.P. Morgan Chase & Co. as Managing Director for New Business Ventures.

Through all of this, I’ve realized a fundamental truth about software: Writing code was never the problem.

Most developers love to code. The friction and the failures almost always stem from everything that happens before and after the code-write:

• The "Before": how requirements are defined and solution is designed

• The "After": how the code is deployed, maintained, and governed in production.

At SAP, I saw firsthand how long planning cycles, distributed teams, and fragmented documentation could dilute the voice of the customer. Requirements would evolve across documents, systems, and conversations until something essential – the true customer voice – got lost.

The same applied to customer projects. Even when we deeply understood SAP systems, we didn’t always fully capture the nuances of each customer — their processes, governance, and change management realities. Somewhere along the way, intent and implementation would drift apart.

At SAP, Sam and I had instituted design-thinking practices across the company to address this—bringing teams closer to the problem before jumping to solutions. That principle still holds: get it right early, and you avoid exponential complexity later.

Today, LLMs have taken us a step forward. They enable rapid iteration on ideas and requirements. But they’ve also introduced a new challenge: Specifications can start anywhere, evolve everywhere… and never truly converge. Design of enterprise-grade systems demands more. Specs development is a highly collaborative process to account for traceability, governance, and alignment with real-world constraints—security, compliance, architecture, and operations.

Speed matters. But quality, consistency, and accountability matter more.

Here is another paradox: LLMs have dramatically improved how fast we can generate code. But the bottleneck in software engineering was never coding speed. It has always been architecture, design, and lifecycle management. And when those are weak, we accumulate technical debt — the kind that consumes 50–80% of IT budgets.

In some ways, LLM-driven code generation amplifies that problem. Ask the DevOps teams, ask the infrastructure engineers, ask the teams responding to Sev2 incidents at 3am.

Now layer in a highly regulated environment like a global bank as J.P. Morgan. Every change Every change must be traceable: who requested it? Why was it made? Who approved it? When did it go live? Now imagine reconstructing that lineage from evolving prompts and shifting model behavior

AI’s true value isn’t just in writing code faster. It’s in helping organizations: 1) create complete, consistent, and governed specifications 2) design coherent, production-grade architectures 3) develop and deploy software that is testable, auditable, scalable, and secure.

Here is where it gets interesting. If a company can trust its AI solution to help build the right software, the right way—fully aligned with its architectural framework, enterprise governance, and system landscape—it fundamentally changes the build-versus-buy equation. Why continue paying for user licenses on software that only partially meets your needs, rely on expensive professional services, or defer critical refactoring initiatives, when you can build precisely what you need—by function, geography, or segment—at a fraction of the cost?

That’s what caught my attention when I first saw the Everest demo. I already had deep respect for the team behind it—many of the architects who shaped SAP’s most critical systems. But what stood out wasn’t just the technology

It was the idea that AI could finally close the gap between true intent and aligned execution in the enterprise – that's a powerful lever. That’s why I joined Everest. Because scaling AI in the enterprise isn’t just about generating more code. It’s about building better systems—end to end.