Forward Deployed Engineering at Cursor — Pauline Brunet

My name is Pauline Brunet. I lead the forward deployed engineering team globally at Cursor. I'm super excited to share some of the learnings that we've had as a company as we build out this function. I have been doing AI deployments to enterprises for the last 10 years across consulting, and this is my third tech company. I encourage the discussions — I'm incredibly passionate about the FDE function, and only 20 minutes to talk about it is not nearly enough.

A couple things about Cursor. We are an AI coding platform, as you are well aware. We have incredible products that we are offering as we're helping people go from autonomous coding to asynchronous and synchronous agents all the way to an AI software factory. I'm really going to focus today on the forward deployed engineering function.

So I always hear about FDE. I'm waiting for the Forbes article that's going to say 2026 hottest job of the year is the FDE. I feel like this is the year and I really want to talk about it.

Should you build an FDE team? The maturity/customization matrix

If you're thinking about building an FDE function for your business, the first thing is I want you to understand your customers, or at least the target market that you're going after, and where they are in their transformation journey. And then I want you to understand your own product. What are you offering to those folks? How customizable is it? The reason for that is I think of it on a matrix. A lot of people ask me, "Hey, is FDE like professional services? Is it the same thing as staff augmentation? What is FDE?" And I have some pretty strong opinions about where it fits and where it's not a great use of your 10X engineers to invest that time for your customers.

The first part is the digital maturity of your customer. How mature are they? How technically advanced are they? Where are they on their transformation? And how can you actually help them with it? The second part is product customization. How configurable is your product? Is it SaaS straight out of the box, you just send a login — like, for example, Teams? Is it super easy to get set up and get running by yourself? Or is it highly customizable, highly configurable for your customers?

If you have a customer who is really mature in their digital transformation, they have engineers, and it's low customization on your product, I would really just say provide your product in a self-service fashion and give great documentation. Probably not a great use of your FDE motion. Same thing on low maturity, low customization: to me, this is a traditional SaaS deployment. I go in, deploy it — you can picture the waterfall project going through. Not a great use of your FDE projects.

Then you have customers who are really, really mature and you have highly customizable products. Here, you're going to have crazy adoption, and I would say a lot of it should be your FDE team acting as advisers to help accelerate them. And then finally, you have some customers that are further back in their transformation journey. They're learning a little bit about how to do it. They may not be able to hire or staff the folks that you can. They need a lot more help, and here is where I think of that embedded transformation.

Across this, the band in the middle is where the FDE really fits in. For those that are very mature with low customization, you can help them maybe extend — create a couple new features, extend the application — and you have that great feedback loop that you give to your product and engineering teams. But your FDE team won't be as helpful or as impactful with those folks. Same thing on high maturity, high customization: there's definitely room to help them, but they can do a lot of the work themselves, and you don't want to be a solution architect, you don't want to be writing down bugs, you don't want to be updating documentation. You really want to focus on what's going to drive business for them. Same thing on the traditional deployment: maybe you can do some configuration extension, but I would be very mindful that you're not doing a product 101, 201 session, that you're not holding workshops for everyone in the company to be trained on your latest SaaS software. That's not a good use of the FDE function, personally.

Once you've decided where you are in this box, hire accordingly, because you have to attract this talent, you have to pay them, and then you have to make sure that they are working on critical, interesting, important things. Otherwise, they're going to get bored, rightfully so, and they're going to leave, because you sold them FDE that wasn't FDE, in my opinion.

What the magical unicorn actually does

So what is the magical unicorn that is the FDE, the forward deployed engineer? To us, it is someone incredibly technical who also has really high EQ. What does the job entail? It entails working with all types of customers across all levels of the organization — CIOs, CTOs, COOs, as well as developers, engineering managers, VPs of transformation, VPs of AI. You have to be able to really quickly lead a discovery, find the right use case, understand their processes — how are they doing things today, how can you help them do things better. You have to understand their culture and how you're going to effect change, and then you have to accompany them on that digital transformation journey. You're an actor of change. Of course you're using technology to do so, but you have to accompany them. I always say, if you put in the latest and greatest tech in your organization, and you don't accompany people, no one's going to use it.

And then, as an FDE, you have to be at the front edge of the technological advancements. There are new releases every week. You have to be curious. You have to be able to enjoy it and want to learn from it. Otherwise, this is not a fun job, let me tell you, because your customers are expecting you to be the expert.

Finally, you have to work very delicately between the product and engineering teams and your customers, where you want to give that feedback loop to your product team: "Hey, we're hearing this over and over again." The FDE team is so close to the customers, embedded in their organizations, they're going to be the first ones to have a really good pulse on what we should build next as a company. Really effective feedback loop. We work very closely with our engineering and product teams.

How Cursor runs FDE

I want to share a little bit about what Cursor looks like in terms of the FDE team — what we've learned, what works for us, what doesn't. As you know, we are an AI coding platform. A lot of our customers are incredibly mature organizations, deeply technical buyers and users, and that has informed who we hire and the profiles we're looking for. I recommend you think about who is buying your software and how you can help them, and then match the right folks to hire in your FDE team.

For us, it is project-based, highly impactful projects. I usually like to work with the economic buyer or a very senior champion within my accounts to make sure that we are scoping something that is a strategic objective for the company — that is going to drive meaningful ROI, and that they have the resourcing they're going to put on this project. Because you're going to need to be working with them side by side. You're going to need access to their systems, because we develop on top of their code base. You're going to need to effect change, so you need the top-down support to do so. And you want to make sure you're working on something really meaningful, so that when you walk away at the end of the engagement — and in our case we have deployed cloud agents, long-running agents, automations, and applications built on top of the Cursor SDK — it is strict ROI for them. That means they're not going to turn things off when we leave. We want to make sure that we're effecting change and building things that matter to them. Meaningful return on investment.

Something cool: we push the edge cases for the Cursor platform. As we get really interesting use cases that are a little bit outside of the software development lifecycle, the FDE team to me is the tip of the spear that tests these new use cases with customers. We have incredible folks working with us on "How do I help across my HR team? My finance team? My supply chain team? My e-commerce team?" — working with retailers, financial banks. How do I do asset management better? As we push the edge use cases for Cursor, we get more and more momentum on how we can help you do things not just within the software development lifecycle, but across your entire company.

We work in co-development with customer teams in their code base. This is where you have to be really careful that you don't end up doing staff augmentation. If anyone says, "Yeah, you have to do this, we're understaffed" — red flag for me personally. I get a little antsy on those phone calls. I'm like, "Ooh, I don't think this is the right case for us." You want to make sure that you're driving something meaningful that they're going to put resources toward and that you're going to work on in collaboration. My trick is I just ask who the people are we're going to work with: "That's great, we'd love to partner with you on this use case. We'd love to build long-running agents to automate your call center ticketing system. Who will be the working team?" Super important to get that.

And then finally, working between our engineering and our product teams to influence the roadmap, and our customers — letting them know new things are coming that will all of a sudden enable use cases we couldn't do before. That's the beauty of it: we can go and solve more things at scale very quickly.

I would recommend you have a mission for the FDE team. I'll offer you mine. This is the Cursor FDE mission: we partner with your organization to co-design and co-build your AI software factory. We transform how you design, develop, and maintain software across your entire lifecycle. I would just encourage that you have one. It's very clear to the customer what you're trying to drive. It's clear to your team what to focus on. And it helps our team members think, "Hey, when I'm hearing this project that sounds like staff augmentation, I don't feel like that's driving toward our mission."

Team structure: unicorns first, specialization later

What does the team structure at Cursor look like for FDE? We are highly technical, highly experienced profiles. For the beginning, it makes sense for you to hire what I call unicorns. We hire 5-plus-years software engineers. We don't hire out of school. We don't hire early-career professionals at this moment. Once we grow the team bigger, we will — and so I welcome those folks that are reaching out to us. For the first set of founding forward deployed engineers, we are hiring very technical folks with customer-facing experience. Over time, we will split the role, so we'll have folks that are a little bit less technical, more customer-facing, but still with technical aptitude, and vice versa: highly technical folks who perhaps are not as customer-ready, but have the aptitude to learn it.

We have a matrix organization. We are ready to pivot in any way, shape, or form — that will happen. We are geography-based for now, but at some point we will likely mature to industries, because when you talk to an industry and you don't use their lingo, you immediately lose credibility. If you talk to a bank and you're not talking about payment systems, asset management, risk — you've kind of lost them. You really have to have that industry knowledge. And then finally, across our product areas, we really want to focus on having the right SMEs who then become the experts. For example, we have someone on the team who is the expert on our long-running cloud agents. We have someone who's an expert on the Cursor SDK. Other team members can come in on their projects and say, "Hey, I need to pull in this person because they're important."

We have phenomenal folks from Spotify, from Rippling, from Palantir, from a lot of organizations, where we have found that we get the best people because they are incredibly excited to work with customers and they have the aptitude to do so. And finally, we will change the roles and the structure over time. One thing we always joke about on my team is that what we're doing today is not what we're going to do six months from now. We won't be hiring for the same profiles. We'll have changed. New products will have come out. Our customers will have changed in their journey.

Best practices

Here are some best practices. By the way, we are in no way perfect. I have done this for 10 years. I've made a ton of mistakes. Learn quickly and pivot is my recommendation. Just learn from it. Try out a project with a customer. You might fail. That's okay. Actually try it out — you will learn so much more than if you're just waiting and planning.

Listen to your customers. I'll give you a really concrete example. There's an offering I was not planning on adding to FDE. I've heard it six or seven times now, and so I'm going to create one. The question I get asked is, "Hey Pauline, how do I change my organization now that we have these amazing tools? How do I capture value? Who do I hire? What are the job descriptions? How do I rearrange the teams? How do I change the ways of working together, the processes, to actually go capture this value?" Not something I was going to offer. We actually might be offering that very soon, and we'll hire the right team to support it. So listen to your customers and adapt accordingly.

Work with partner organizations. You can always benefit from system integrators and consultancies. One, they really know your customers. They've been in there for a while. They have great relationships. Two, there's a lot of stuff that I just frankly don't want to do — let's have the SIs do it. For example, I'm not really that great at change management. Not a fan favorite. A lot of that can be accompanied by partners. Same thing on rolling out existing products that we're really good at — we've done this a bunch across telco, across healthcare and life sciences. Partner with your system integrators and your consultants so they can do that at scale and broaden your reach.

Don't be afraid to say no. This one's a hot topic. I have customers who'll say, "I want to do this," and I will say, "Ooh, Cursor is not the right tool for that." A couple of reasons. One, you build credibility by being very honest about where our products and platform are the right tools and where they're not. You earn a lot from that, because they'll say, "Actually, I have this other use case now that I trust you as a partner." And two, if it doesn't go well, then you're on the hook for it. I would recommend being very specific in the use cases you're solving.

And then finally, attract and pay the right talent. Make sure that you are hiring the right profile for what you want to deliver on — very dependent on your situation. And make sure that you are attracting them, paying them, keeping them motivated. Very important, especially in this war for talent that we're currently in.

Tips for running FDE projects

Check you're solving the right problem. It seems easy; it's actually really not. Sometimes you're solving a symptom, not the right problem. Sometimes you're talking to the wrong person who thinks they have the right problem, but they may not. Always inquire, ask questions: who's responsible for this? Can I talk to them? I really like to talk to the person responsible for the process, the workflow, the department, whatever we're trying to solve for.

Define success from the start. If I accomplish this, will this be successful for you? If I automate this process from start to finish and it now takes 20 minutes instead of 3 hours, which is the current baseline, is that sufficient for you? Does that measure success? Yes? Great.

I have a lot of opinions about scope. I think that you cannot just say, "Hey, take two FDEs for six months, do whatever you want with them." That's a recipe for failure. What I would recommend instead is that you're trying to solve a problem, and you establish what you're going to do to solve that problem. We want to automate this process from start to finish using long-running agents. The agents are going to grab data from these systems, make these decisions, involve these people in the feedback loop, and reduce our mean time to resolution — or reduce, in claims management, the time to answer a customer on their claim. Whatever the KPIs we're trying to drive, keep the scope directional. We're going to do phase one and two. We're going to automate these things. We're going to set up these agents for you. It's going to take six weeks, and we're going to do as much or as little as we can. The reason is that I do not know the customer's processes. I haven't really seen their data. I haven't seen their systems. So I'm a little bit on the hook if it takes more or less than six weeks. And from the customer's perspective, we're going to learn a lot, and they may want to pivot once we learn something. Having something directional, where I can pivot based on the learnings, customers actually really appreciate in the end.

Involve the customer in every step: scoping, actually building and designing the solution, implementation, doing the human-in-the-loop validation, looking at baseline versus results, identifying the ROI we're driving. They should own that. We are supporting them in this journey. We are still hands-on keyboard. We are still configuring. We are still developing on top of their code base. But make sure you're not doing it alone. If you're doing it alone in their office in a little cubicle, we have a problem.

Finally, measure success. Were we successful? I said we could take this from 3 hours to 20 minutes — did we get close? If not, why not? What can we do about it? And then, what's the return on investment? You want to over-communicate that. Someone mentioned to me that an agent was costing $2,000 per day, and I said, "Well, what was the agent doing?" He explained it, and I said, "Hey, it sounds like you're reducing the cost of sending the right person to go fix this equipment. Would that not be worth $2,000 a day?" And he said, "Absolutely, but I never measured it this way." So always think about the ROI you're driving. It's always three things, super simple. Am I increasing revenue? Am I decreasing costs? Or am I mitigating risks? That's it. Every company, as complex as they are, that's what they care about. Which one are you doing? Could be all three, which is fantastic, but at least one of them. And leave your documentation artifacts behind so that you can help them.

Wrap-up

Build the right FDE motion for your company. Learn, pivot, and scale. And then create this amazing culture where people want to be a part of it, they want to learn, they want to do their best work — and give them the chance to do so. The thing I'll leave you with: I always say hire A players. A players hire A players; B players hire C players. Be very mindful of that. Make sure that you are hiring the right talent for your organization and for your customers, and that you're keeping them motivated. Thank you, everyone.