Explore, Then Exploit: A Conversation with Leo Mehr
Director of Engineering at Ramp
Leo Mehr leads Forward Deployed Engineering at Ramp, where he has grown the function from a handful of engineers to fifteen-plus, and also runs the Agent Developer Platform team. Before Ramp he co-founded Lumos and ran its engineering team, and before that he worked at Hudson River Trading and Google, studied engineering physics at Cornell, and spent a year on computer science and philosophy at Oxford. We talked about why he left physics, what former founders bring to FDE, how Ramp is trying to scale the function with agents rather than headcount, and why he thinks every B2B company is heading toward some version of this role.
You did plasma physics research at Cornell and presented at the American Physical Society. That is a long way from where you ended up. What pulled you away from physics?
You do all sorts of things early in your career. My first jobs were at an office supply store and being a soccer referee. But physics was the thing I fell in love with first. It was my favourite subject in high school, and I thought computer science was fun but more of a toy. You could make cute little programs, but I did not directly see it as a way to have a massive impact on the world. That was 2010, and I had not really been exposed to the world of startups or how fast tech could move.
So I went to Cornell as an engineering physics major. Plasma research was genuinely cool, the extremes of it, insane temperatures and conditions you cannot find anywhere in the world but can create with science, and then studying what happens as a result.
The turning point was a conference in Denver where we presented some of our work. The median age in the room must have been in the sixties, and there was not a lot of energy. The growth potential of the field, where it was heading, did not feel as promising as tech. Around the same time I got an internship at Google and saw the pace the company was moving at and scale of impact. That energy was hard to ignore.
You also spent a year at Oxford studying computer science and philosophy. That combination is uncommon in tech. Is there anything from the philosophy side you still use?
First, I have a pretty basic understanding of philosophy. But Oxford is one of the renowned places to study it, and part of what drew me in was the sense that I would never otherwise get to do something like that.
I do think philosophy and tech overlap more than people realise. A lot of the ideas around existential risk and effective altruism came out of that world. Nick Bostrom ran the Future of Humanity Institute at Oxford, and those ideas were a big part of the early discussions and culture at OpenAI, and arguably part of what led to Anthropic. My understanding is that a lot of Anthropic’s founding arc traces back to ideas in the sphere of existential risk and effective altruism, which came very directly from philosophy. So a company like Anthropic exists, in part, because of ideas from philosophy that found their way into tech. There is more overlap there than people give it credit for.
Leo’s path into FDE did not run through Palantir, the way many do. It ran through founding a company.
You are a former founder, not a career FDE. What about Ramp made this the right place to land after building your own company?
What I have found is that former founders often make excellent FDEs. As an early-stage founder you are talking to customers, building the product, and figuring out what to build. As an FDE it is very similar. You are talking directly to customers, working on unshaped and ambiguous problems, deciding whether to hack something together or build something robust, and doing a mix of customer, product, and engineering work. The tie between FDE and entrepreneurship is close in both directions. It is a strong fit for former founders, and it is also good training for anyone who wants to found a company later.
As for Ramp specifically, I had followed the company for a couple of years and had a lot of respect for it. It was one of the fastest-growing organisations I had seen, founded in 2019 and at an enormous valuation within a couple of years. By the time I had stepped back from my startup and was thinking about what to do next, I wanted to be somewhere that was going to grow, in an environment that rewards ambitious individuals, and where I could still draw on my startup experience. If I had gone to big tech or somewhere more mature, I do not think I would have been able to use everything I had learned, and I do not think I would have grown the way I have.
I am extremely bullish on the company’s trajectory and on what it offers ambitious builders. If your direct aspiration is to found a company, go and do that first. But if you want to see what high-calibre execution looks like, or you are early and do not yet have the conviction to start your own thing and want to build the skills and experience, and maybe meet a future co-founder along the way, this is a strong place for that.
A large share of FDEs at Ramp are former founders. That looks deliberate. What does founder experience give people that you cannot get from senior engineering experience alone?
It is less the fact of having been a founder and more what it implies about your character, skills, and motivations. The thing I care about most, and that a lot of people are thinking about now, is intrinsic drive. How genuinely motivated are you to achieve a business or customer outcome? That is hard to assess in an interview, so one of the best signals is what someone has actually done. Starting a company from scratch, and especially getting any traction, usually says something strong about ownership and motivation. Those are the characteristics that make people effective in front of customers, because they are driven to solve the customer’s problem and build good technology rather than just complete a task.
Ramp’s FDE function has grown from a handful of engineers to fifteen or twenty. I asked what changes at that size.
You have scaled the team from around five to fifteen or twenty. What do you have to pay attention to when you scale an FDE function?
My view is that FDE has emerged as a way to grow a B2B business, particularly through delivery to large customers. You cannot serve thousands of customers with dedicated humans, so the model is built around contracts large enough to justify dedicated engineering time. Scaling looks different at every organisation. Palantir is the extreme and the most mature.
Ramp’s FDE function is a little different from the more traditional version. We are oriented around unblocking our largest customers and helping us reach product-market fit in enterprise, rather than embedding a single engineer inside one customer for three to six months. Because we sit close to core product, it became impossible for everyone to be productive across the entire surface area. Ramp has a couple of hundred engineers, and no one can know every surface. So the way we scaled was to split into areas of specialisation and embed engineers in each. One team focuses on bill pay and procurement, another on the core card and reimbursement and expense experience, another on reading and writing data from Ramp in a low-effort, high-automation way.
Most leaders I speak to are trying to scale non-linearly, not just by hiring more people. Is there anything you can share about how you are approaching that?
The way you scale is by scaling with tokens, not headcount. Any time a human is doing something through their own cognition, you want that documented, you want the context available, and you want the read and write interfaces available to an agent, so that an agent can eventually do the work the human was doing. The fundamental requirement is getting context into a single place. We are heavy Notion users at Ramp, and I am excited about the shift from FDEs doing a lot of manual work to agents doing tasks on our behalf.
One concrete example. Every customer blocker or request for FDE involvement comes through a single Slack channel called FDE-Requests. In the past, someone from solutions or sales would write up notes and post them, and then we would wait, sometimes a day or two, for an FDE to pick it up, understand it, scope it down, and figure out what was needed. Now we have a Notion agent that searches our knowledge base, looks at past requests, categorises the new one, asks clarifying questions, and tags the submitter. We are starting the scoping process with an agent immediately.
To use a driving analogy, this is not full self-driving. It is closer to going from a manual to an automatic transmission. We are a long way from full autonomy on the request process, but that is the direction we are working towards.
In that fully automated world, what does an FDE actually do?
There will be plenty for FDEs to do. I am not worried about that yet. The first real challenge is managing the quality and token efficiency of agentic systems, and that architecture is not easy. Building high-quality agentic systems still takes real engineering. Agents do not just go and solve the world’s problems. You need people who understand how to do engineering well to craft and guide them. Eventually they may become stable enough that many people stop thinking about them, the way I do not think about TCP, IP, or DNS anymore. The internet just works, and we move on to the next problem.
The way the pipeline would look is a request comes in from solutions or sales, gets scoped down by an agent that is good at the back-and-forth of figuring out exactly what is being asked, possibly producing documents that go to the customer. Once you know the minimum viable request, another agent can scope the technical work by looking at the product roadmap, specs in flight, and where the feature would live in the codebase. Then a coding agent can execute and validate the change. You can imagine no human involvement from the moment a request comes in through to the feature being live. I think that is six to twelve months away.
Leo also runs Ramp’s Agent Developer Platform. He was clear it is separate from FDE, though it grew out of it.
You run the Agent Developer Platform too. How did that come about?
It is a little separate from the core FDE function, though it has roots there. On the FDE team we interfaced heavily with the developer API because we built on top of the platform, so we had a lot of opinions about it. I took on the developer API team about a year ago. It was clear that AI was going to massively change how you work with programmatic interfaces, so we started investing early in MCP and built our MCP server over a year ago. We ran experiments, including one a few months back where we had an agent try to run its own little business and use Ramp to pay for things. Those experiments into the boundaries of what the developer platform could be turned into what we now call the Agent Developer Platform. It happened gradually, and it originally came from FDE.
What changes when the customer interacting with the product is not a human but an agent?
It will still be a while, but we are seeing it more and more. MCP usage on Ramp has skyrocketed in the last six months. For about a year there were a lot of people building on MCP and almost no usage, but with Claude adoption took off. Having a good API is becoming a necessity. If you do not have one, you risk becoming obsolete.
At the same time, the interfaces humans see will become much more custom. If you think about the modalities for consuming information, audio has clear limits, text has limits too, and a two-dimensional visual representation on a screen is a very powerful interface that is here to stay. Humans will keep using software, but the experiences will become richer and far more specific to what the individual actually needs. A lot of the tedium people feel with software today, clicking through a checkout flow, waiting for something to load, should start to disappear.
Leo also invests and advises, mostly among founders he knows. I asked what he tells them about FDE.
You are an investor and advisor as well as an operator. What do you tell founders when they start thinking about an FDE team, and what do you pay attention to in the startups you work with?
Investing is a small part of my mind space. It started the way it usually does. Once you start a company and get some traction, your startup friends emerge, you exchange notes, you hire early employees who care about the world of startups, and many of them go on to found companies themselves. A lot of my first investments were friends and former early employees starting their own things. Living in San Francisco, you meet a new founder almost every day, so it is a fairly normal path.
The other part is knowing how much it means in the early days to have someone understand and support your vision. One of the first people who really believed in me and my co-founder back in 2020 was Ali Partovi at Neo, which has grown into one of the most impressive early-stage firms, early in companies like Cursor and Cognition and Kalshi. Having someone with some experience and standing say they get it, that they think you can do it, and then make introductions, meant a lot. Part of why you invest later is to pay that forward.
On FDE specifically, it is just a well-established business model now. If you are doing B2B, the biggest growth levers tend to come from landing large contracts, and that naturally puts you on the path to having an FDE function.
Most readers of this newsletter are still getting familiar with the role. Why do you think FDE is going to spread across so many companies?
It is the trend of the last year or two, and trends can change, but from what I can tell every early-stage B2B company with any enterprise ambition is creating something like FDE. They might call it something different. It is some combination of what large customers expect, how software is delivered, and how much easier coding agents have made the actual building. That mix of industry dynamics and the evolution of tech has created the role, and the growth has been an absolute explosion. I think it is roughly a hundred times year over year.
We finished where we started, with the path that got him here.
Last question. You have moved across physics, high-frequency trading, search, teaching, founding, FDE, and agents. Do you have a theory for why you have crossed so many domains, or did you just take what felt right at the time?
I actually don’t think my background is nearly as extreme as some people I’ve met, like a former colleague who dropped out of college, worked on video games, then high-frequency trading, then AI. I do not think my path is a wild outlier. Everyone is on their own path to find a place where the work aligns with their skills and values, and it took me a while to find what I was most passionate about. I have found something I feel I’m thriving in and highly aligned with now.
It is a big journey of self-discovery. Some people genuinely love big tech, the stability, the consistency, working on a specific set of problems that do not change dramatically over time. There is a wide range of archetypes for what people look for, and everyone should be seeking out the one that fits them, especially early on. Explore, and then exploit later.
Leo Mehr is Director of Engineering at Ramp, where he leads Forward Deployed Engineering and the Agent Developer Platform.