Leo Mehr of Ramp discusses how Forward Deployed Engineering (FDE) works there and how AI agents reshape it. He frames the core discipline as "always be scoping": weighing each customer request (e.g., a last-minute SAP S4 HANA integration ask) against the queue before committing. The second half covers automating the FDE pipeline with agents, notably request intake — turning inbound customer requests into specs via an agent built on Notion — supported by an agent harness, rubric-based evals with human feedback, and grounding in past requests and help articles. He closes arguing the future of FDE combines human judgment with agent-handled volume. # Observation Document: "How Forward Deployed Engineering is done at Ramp — Leo Mehr" ## Speaker Self-Identification - The speaker introduces himself as a **"director of engineering at Ramp"** who joined **"2 and 1/2 years ago"** when the FDE team was "just two engineers." - He states his current organization is **"about 30 engineers across four deployed developer API and our new AI services"** teams. - **Claim type:** explicit self-description by the creator; no independent verification available in the source. ## Presentation Context - The talk is delivered at a **conference**: "every talk in this uh in in this conference is probably some flavor of this," and the speaker notes FDE is "kind of a running theme" — indicating an event audience already familiar with Forward Deployed Engineering. - The speaker opens conversationally and invites follow-up: "if you want to come out and we can chat, we'd love to." ## Claimed Scope of the Talk > "Today my goal is to share with you guys the two most important principles from what we learned doing FDE at Ramp." - The two stated principles: **"Always be scoping and scale with tokens."** - Explicit framing that the content is opinion/experience-based: "these are the principles that I would say have really guided us." ## Intended Audience - **Engineers and technical go-to-market practitioners**, implied by: - Assumed familiarity with FDE ("no one knows what FDE is... I'm just going to spend a moment on that"). - References to internal tooling (Slack, Notion) and AI-agent workflows ("Notion agents," "agent harness," "evals, with rubrics, with human feedback"). - Specifically people doing **knowledge work facing AI automation**, per: "whatever work we are doing today... we have to figure out how to have models and agents do it for us." ## Company Positioning Claims (About Ramp) - **"FDE at Ramp... we live within the engineering organization. And our goal is to help Ramp win upmarket."** - FDE work described as: "work on the core product and our new agentic features and make them work really well for our largest enterprise customers." - The speaker contrasts Ramp's FDE model with a meme portraying FDE as the "final evolution or like boss mode of technical go-to-market roles": "this might be true at some companies, but at least at Ramp, it's a little bit different." - **Note:** These are the speaker's claims about Ramp's internal structure, not externally verifiable from the transcript. ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Anecdote-driven teaching style:** two extended stories — the SAP S/4HANA urgent-request scenario and the mobile reimbursement feature built for a customer who "mandate[s] all of their employees to use iOS devices" — used to illustrate the "always be scoping" principle. - **Concrete tooling walkthrough:** description of an internal Slack channel "FDE requests" and a Notion-based agent workflow that reduced "latency of replies... from like hours or days to like, you know, seconds" and saved "20% of the time that we'd spend on scoping." - **Balanced-thesis structure:** the closing argues both principles are necessary — scoping without agents means "your agent native competitors are just going to... outcompete," while agents without scoping produce "a token maxing slop cannon." ## Human-Judgment Emphasis - The speaker reserves a role for humans despite automation: "ultimately the most important thing here is that as an FD, we still have the responsibility of taste and judgment over the final output." ## Summary for Channel-Level Synthesis - **Observable:** single-author conference talk; technical-practitioner audience; case-study format from a named company (Ramp); opinionated framework presentation ("two principles"). - **Claimed, not verified:** speaker's role/tenure, Ramp's FDE org structure, and quantified efficiency gains (20% time savings, reply latency figures) are all creator claims presented without external evidence in this source. # Delivery Observations: "How Forward Deployed Engineering is done at Ramp — Leo Mehr" ## Overall Tone - **Casual, conversational conference style** with filler words and self-deprecation: > "Um Cool. So, yeah, today my goal is to share with you guys the two most important principles" > "Very easy talk." - **Enthusiastic and informal**, especially when narrating stories: > "We're going to ship this feature. It's going to be so good. Like, hell yeah." ## Structural / Teaching Habits - **Explicitly frames the talk as exactly two takeaways**, repeated throughout: > "there's just two things I'm going to share with you. Literally two things." > Closing: "Always be scoping and scaling with tokens. The future of FD needs both. That's all." - **Two-part organization with a pivot sentence** between halves: > "So, let's say that you and your team have become masters of scoping... this is not enough." - **Story-driven teaching**: both principles are anchored in concrete anecdotes (the SAP S/4HANA Friday-night request; the mobile reimbursement feature built for the wrong platform). - **Recaps and ties the halves together** at the end: > "the problem isn't to tie this to the first half of the talk... you're going to get a token maxing slop cannon." ## Recurring Vocabulary & Phrases - **"Like" as an extremely frequent discourse marker** — appears constantly, e.g., "it's like totally wrong," "like, where are the SAP API docs?" - **Repeated emphasis intensifiers**: "really really painful," "super important," "super high variance," "super excited," "just like learn how to do iOS." - **Recurring product/role shorthand**: "FDE," "always be scoping," "scale with tokens," "agent factory," "pipeline." - **Vivid, meme-like imagery** for memorable framing: > "horses with like rockets strapped to their legs" > "token maxing slop cannon" > "the final evolution or like boss mode of technical go-to-market roles" ## Communication Patterns - **Rhetorical questioning** to model the scoping mindset: > "what's driving the urgency here?" ... "Have we exhausted all the different workarounds?" - **Enacted dialogue/role-play** of internal reactions: > "the default engineering reflex is like, 'Shit. Like, where are the SAP API docs?'" - **Hedging on specifics** where he lacks data: > "probably saved us like a large percentage, I don't know, 20% of the time" - **Asides to the audience** for rapport: > "if any of you work at Notion, by the way, thank you." > "I know this is kind of a running theme, but like no one knows what FDE is." - **Mild profanity** used for authenticity, immediately softened with "Not not to the customer, you know, just internally." ## Uncertainty Notes - Timestamps are absent from the transcript, so delivery timing (pacing, pauses) cannot be observed; observations are drawn from wording only. - Audience reaction is only observable once ("[applause]"); claims about sustained engagement cannot be made. - Verbal disfluencies ("I I I actually," "the the the most important thing") suggest spoken improvisation, but their frequency cannot be precisely measured from this transcript. # Observation Document: How Forward Deployed Engineering is done at Ramp — Leo Mehr ## Speaker - **Leo Mehr**, Director of Engineering at Ramp (self-identified in talk). Joined ~2.5 years ago when FDE was two engineers; his org is now ~30 engineers across deployed developer, API, and AI services. ## Framing: What FDE Is at Ramp - Rejects the meme that FDE is the "final evolution" or "boss mode" of technical go-to-market roles — "I actually think it's like totally wrong." - At Ramp, FDE lives **within the engineering organization**; its goal is to help Ramp **win upmarket** — making core product and new agentic features work well for the largest enterprise customers. ## Principle 1: Always Be Scoping ### Claim: The FDE's job is not to "just say yes to the customer" - "That's wrong." The FDE should try to find a way to say yes, but must build the right thing and deliver good software. - Metaphor: endlessly saying yes would produce "horses with rockets strapped to their legs" rather than "beautiful Waymos." ### Example: The SAP S/4HANA request - Scenario: Friday night, an enterprise sales rep claims a strategic deal only closes if Ramp builds an SAP S/4HANA integration. - Default engineering reflex: hunt for SAP API docs. A well-trained FDE instead pauses and asks: - What's driving the urgency? (Mehr notes he has seen reps driven by end-of-quarter quota pressure, not the customer.) - Who will use the integration? - Have workarounds been exhausted? Is there a manual interim solution? - Can the customer hit Ramp's API themselves? - Crucially, the FDE looks beyond the single request to other prospects/customers who might benefit — context-gathering leads to building the right thing. ### Cautionary story: The mobile reimbursement feature - A large enterprise customer needed a mobile reimbursement feature; the mobile team was swamped, so two FDEs learned iOS and Android development and shipped on both platforms over a couple of weeks. - The customer then revealed they **mandate iOS devices only** — the Android work was wasted. - Stated lesson: even basic assumptions (e.g., which mobile platform) must be validated; this "was really really painful for us." ## Principle 2: Scale with Tokens ### Claim: Scoping mastery alone is no longer enough - "Unless you are scaling with model capabilities, you are going to fall behind." - Knowledge work must be constantly reinvented so models and agents do it. ### Applying tokens to the FDE lifecycle - The FDE lifecycle — gathering context → scoping → writing a spec → implementing — can have each stage replaced with agents. ### Example: The "FDE requests" Slack channel / Notion agent - Channel where account managers, solutions, and sales reps post blockers for large prospects/customers. - Problem: high variance in request quality, from detailed writeups to one-liners ("we need this SAP integration"). Previously FDEs manually read, understood, cross-checked product capabilities, and did back-and-forth with customers. - V1 built with **Notion agents**: took the request and asked a couple of questions. - Results claimed: - Reply latency dropped from hours or days to seconds. - Reps and account managers engaged with the agent quickly. - A later iteration runs multiple rounds of back-and-forth questioning (with a "cute" penguin persona) until it deems a spec ready. - Mehr estimates it saved roughly **20% of scoping time** (stated tentatively: "a large percentage, I don't know, 20%"). ### Remaining challenges (as stated) - First and last pipeline stages are progressing (frontier models can "one-shot medium-size features" from a well-shaped spec); the **middle stage is "super gnarly and like unformed and difficult."** - Future FDE work (6–12 months out): building the "factory" — agent harnesses, output quality via evals/rubrics/human feedback, and context provisioning ("imagine all the knowledge a product manager has in their head — how do you get that into an agent?"). Notion docs and help articles "only give you so much of that." Mentions skills, memories, tools. ### Claim: Humans retain taste and judgment - "As an FD, we still have the responsibility of taste and judgment over the final output." ## Synthesis: The Two Principles Must Combine - Scoping without the agent factory → you get a **"token maxing slop cannon"**. - Agent factory without scoping discipline → fine, but scoping-only practitioners will be outcompeted by "agent native competitors." - Closing claim: "Always be scoping and scaling with tokens. The future of FD needs both." ## Qualifications to Preserve - Mehr repeatedly hedges his time-savings estimate ("a large percentage, I don't know, 20%"). - His claim that the FDE-as-GTM-apex meme is wrong is qualified: "this might be true at some companies, but at least at Ramp, it's a little bit different." - Future predictions ("I think" 6–12 months) are framed as expectations, not settled facts. # Speaker & Provenance Observation Record ## Video Metadata - **Title:** How Forward Deployed Engineering is done at Ramp — Leo Mehr - **Video ID:** `01a15ca8-35ee-7634-8999-72e5c59a604f` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Leo Mehr | **Sole presenter / creator** (self-identified: Director of Engineering at Ramp) | "I'm a director of engineering at Ramp… my org is about 30 engineers" | | Audience | Unnamed attendees (implied talk/event setting) | Applause, greeting "Thank you, guys" | - No **guests**, **narrators**, or additional identified speakers are present. - **Named third parties referenced (non-speaking):** - **Greg** — identified as a CSM at Ramp who posted a request in the internal Slack channel. ## Role Context (as stated by speaker) - FDE at Ramp sits within the engineering organization; goal is to help Ramp "win upmarket." - Speaker joined ~2.5 years ago when FDE was two engineers. ## Referenced Sources & Third-Party Claims - **Meme reference:** Speaker references a meme about FDE roles (no source cited); he labels it "totally wrong." - **Notion workflow/agents:** Internal use case — "if any of you work at Notion, by the way, thank you." - **Notion docs / knowledge base / help articles:** cited as partial context sources for agents. - **Frontier models:** referenced generically as capable of "one-shot[ting] medium-size features" — no specific model or vendor named. - **SAP S/4HANA integration:** cited as a hypothetical/illustrative customer request example. - **Waymo:** referenced as an illustrative comparison ("beautiful Waymos… driving us around in San Francisco") — no claims sourced. ## Promotional Segments - **Flagged:** Notion praise segment ("if any of you work at Notion, by the way, thank you. We like use Notion so much") — brief promotional/appreciative remark, not a sponsorship disclosure. - **Flagged (implicit self-promotion):** Repeated references to Ramp's internal tooling, FDE team, and AI agent factory; consistent with a company-affiliated speaker. ## Anecdotal Claims (speaker's own account, unverified) - Mobile reimbursement feature story: two FDEs learned iOS/Android; customer mandated iOS only. - Notion agent V1 reduced reply latency from hours/days to seconds; saved "~20% of the time" on scoping — speaker's estimate ("I don't know, 20%"). ## Availability & Uncertainty - **Comments availability:** Not specified — no metadata supplied. - **Curated metadata:** None provided beyond title and transcript. - All figures (team size, time savings, tenure) are speaker-reported and unverified. ## Provenance Boundaries Summary - Single-speaker talk; all claims trace to Leo Mehr's firsthand account at Ramp. - No external citations, studies, or quoted third-party sources beyond named products (Notion, SAP, Waymo) used illustratively. \>\> Awesome. Thank you, guys. Awesome. It's great to to meet everyone. I mean, I hope that after the talk, you know, if you want to come out and we can chat, we'd love to. Um Cool. So, yeah, today my goal is to share with you guys the two most important principles from what we learned doing FDE at Ramp. So, just yeah, briefly a little bit about myself. Yeah, I'm a director of engineering at Ramp. Uh I joined the company 2 and 1/2 years ago when it was just you know, FDE was just two engineers at the time. And today, my org is about 30 engineers across four deployed developer API and our new AI services um business. So, I know this is kind of a running theme, but like no one knows what FDE is. So, I'm just going to spend a moment on that. So, yeah, I I I actually kind of like this meme. It's To me, it's kind of funny. Um I um but I I I actually think it's like totally wrong. I don't see this as the actual like true form of what FDE is. Um I don't see it as like the final evolution or like boss mode of technical go-to-market roles. Um now, this might be true at some companies, but at least at Ramp, it's a little bit different. So, FDE at Ramp, uh we live within the engineering organization. And our goal is to help Ramp win upmarket. So, with that in mind, what we do is we basically work on the core product and our new agentic features and make them work really well for our largest enterprise customers. So, that's just a little bit of intro context. I want to dig in and and today, like I said, there's just two things I'm going to share with you. Literally two things. Very easy talk. And these are the principles that I would say have really guided us and I would say probably the two most important things that we have. Always be scoping and scale with tokens. So, let's get with start with the first one. On scoping. So, I would say there's this thing where like people many many people think that as an FDE, your job is to just say yes to the customer. But that's wrong. If you were just to say yes, you know, instead of like beautiful Waymos that we have driving us around in San Francisco, you'd have something like this, you know. Yeah, horses with like rockets strapped to their legs. And the point is you you want to help the customer be successful. You want to try to figure out a way to say yes. But you actually want to deliver good software. You need to build the right thing. So, you don't just endlessly say yes to people. And I I do want to share an example of something that I would say happens somewhat regularly in one form or another at Ramp. So, it's Friday night and an enterprise sales rep comes to us with an urgent request that this super important strategic logo is only going to close if we build out an SAP S/4HANA integration. And I think that the default engineering reflex is like, "Shit. Like, where are the SAP API docs? Like, where do I find them and how do I build this integration?" But what an what a well-trained FDE would do is like pause for a second and say, "Okay. First of all, like, what's driving the urgency here?" Like, one thing I've seen is I've seen sales reps who like go kind of crazy because it's like the end of the quarter and they're trying to hit their quota and close the deal and not because the customer is the one driving the urgency. So, that's like one example. \>\> \[clears throat\] \>\> But, you know, as an FDE, you're asking tons of questions to gather context about what's important um and what actually is the right thing to build. And so, you might ask like, "Who's using this integration? Have we exhausted all the different workarounds? Is there something manual that we can do in the meantime? Does the customer have like technical resources? Can they hit our API such that we don't have to build this thing?" But, I'd say the most important thing that an FDE does is also looks beyond this one request and looks at the other prospects that are coming down the pipeline and other customers to see if anyone else would benefit from this as well. And the point is that by gaining all this context, you can do a better job of building the right thing. So, I want to share another story that was really really painful for us in the early days. We had this large enterprise customer and they needed this reimbursement feature on mobile. Unfortunately, our mobile team was totally swamped. So, we basically just had to roll up our sleeves as FDEs and just get find out a way to get things done. And we had two of the engineers on the team just like learn how to do iOS and Android development. And it was awesome. We were super excited. We're like, "Okay, we're going to ship this feature. It's going to be so good. Like, hell yeah." So, we grinded for a couple weeks, got the feature done on both platforms. And we go to the customer and we're like, "Awesome. Like, can you send us your list of, you know, beta users for Android?" And that's when they told us they only they they they require they mandate all of their employees to use iOS devices. So, you're like, what the Like Not not to the customer, you know, just internally. But like obviously it was super disappointing for us because we'd put all this effort in. And so, it was a a big lesson for us to remember the importance of scoping. Even some of the most basic assumptions like which you know mobile platform you build on it's it's super important um to validate them and and thus kind of emphasizes the importance of scoping up front. Now, Okay, so let's say that you and your team have become masters of scoping. You know, you're you're amazing. In today's world, this is not enough. So, unless you are scaling with model capabilities, you are going to fall behind. Now, I'm not going to belabor this point too much. I think like every talk in this uh in in this conference is probably some flavor of this, but like the point is that we basically have to reinvent our jobs constantly now. So, whatever work we are doing today, you know, for the most part it's knowledge work, we have to figure out how to have models and agents do it for us. And so, that brings me to the second half of this talk and the the other point that I want to convey today, which is all of us have to figure out how to scale with tokens. And the way that I interpret scaling with tokens for FTE is take a look at the whole life cycle of what an FTE does. From gathering context to scoping out a request to writing out a spec and then implementing the feature, each stage of that pipeline can be replaced with agents. And at first it seems kind of daunting. You're like, like how are you going to go and approach and like solve that? But if you break the problem down and then make progress on it, it's it's actually pretty tractable. And so, I'll share share with you guys one example of something Oops. Something that we um that we've done at Ramp. So, we have this internal Slack channel called FDE requests, and this is where account managers, solutions, uh sales reps will post whenever there is a blocker for a prospect or customer that's large enough, basically. And so, we get these requests. In this case, actually uh one of the CSMs on our team, Greg, posted here. And um if you were to It's actually a Notion workflow. If any of you work at Notion, by the way, thank you. We like use Notion so much. Um if you were to click open in Notion, you'd see like a pretty long request that has all the details of what what exactly it is. And the problem is there's a super high variance. Like, some people will submit like really detailed, good requests from the customer. And others are just going to submit like one line, like, "We need uh you know, we need this SAP integration." And before what would happen is we would have FDEs manually kind of go through this request. We'd read the whole thing, understand it, figure out what exists in the product, do a bunch of back and forth with the customer. And this is like exactly what the first half of the talk was about, always be scoping. You know, we would spend a lot of time really digging in and validating what exactly was uh you know, absolutely necessary. And so, you can see here what we what we did then was we basically um used Notion uh Notion agents to build a V1, which literally just took the request and asked a couple of questions. That was it. And um after It was kind of astonishing. Literally, after a couple of weeks, we found that it was like saving us a lot of time because, first of all, immediate like the latency of replies went from like hours or days to like, you know, seconds. And immediately, like the account reps that the account managers, the reps would start kind of engaging with this agent. And one of the things that we did was because it went so well, this this is actually um the more recent iteration of it. It's very cute, you know, the little penguin actually helps make it seem a little more friendly and approachable. Um and what it does is it actually goes and does several rounds of back and forth questioning with the submitter until it deems that it's ready to create a lot a spec, basically. And it's actually been incredible how helpful this has been for us. I I would say it's probably saved us like a large percentage, I don't know, 20% of the time that we'd spend on scoping out these requests. So, you know, this is this is a great example. For us, this has been really helpful. It's I'm super excited about this. It's going to help automate a lot of the work that we've been doing manually. But, um it's really just the first stage of this pipeline that I was alluding to. So, if you look at the first part here, like we've been able to make some progress on it. The last step as well, going from a a well-shaped spec to like a working product, obviously like Frontier models can like one-shot medium-size features. And so, the last part is also is is a lot easier for us. It's this middle part that I would say is super like gnarly and like unformed and difficult. And I'm I'm really excited about our team kind of investing a lot more and spending a lot more of our time just like building out this factory, building out agents to replace each one of these steps. And the thing is, if you look at if I were to say 6 to 12 months from now, like what does FDE at Ramp look like? Like these are the sorts of applied AI problems that we're going to be spending all of our time on, I think. Like, you know, making sure that the agent harness that's running each of those steps is running super smoothly. Um making sure that the the output quality of each of the outputs of the the pipeline is is actually good. That you know, with with evals, with rubrics, with human feedback. Um and there's of course like one of the biggest challenges, which is getting your agent the right context, you know, when you're making the alarm call, ensuring that it has the right context. So, there's like a lot of historical data, data about the the product. Imagine like all the knowledge that a product manager has in their head about their product. Like, how do you get that into an agent? Like, Notion docs and all your existing knowledge base and help articles only give you so much of that. Um yeah, skills, memories, tools. I could go on for a bit, but ultimately the most important thing here is that as an FD, we still have the responsibility of taste and judgment over the final output. So, that's going to be like the underlying kind of throughline. Okay. So, let's say that you've done an amazing job building out this factory. But the problem isn't to tie this to the first half of the talk. If you don't do a good job of scoping out requests or or building upon the principles of scoping things well, you're going to get a token maxing slop cannon. And so, the whole point is that you have to do these both because the other way around is actually quite bad as well. If you are, you know, amazing at scoping, but don't invest in building out this, you know, agent factory, you know, it's going to be over for you. Like, uh your your agent native competitors are just going to overtake you and outcompete. And so, that's why um in the end here, I want to close with the the the most important thing is that if you have both of these, it can set you up for success in the future. Always be scoping and scaling with tokens. The future of FD needs both. That's all. Thank you, guys. \>\> \[applause\]