AI Engineer

Forward Deployed Engineering at Cursor — Pauline Brunet

1931 summary words 9 min summary Watch video

Start with the signal

9 min read

Summary

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: A forward deployed engineering function creates the most value when senior, technically credible engineers co-build strategically important customer workflows with measurable ROI, rather than providing generic implementation help or staff augmentation.
  • Why it matters: Cursor's model provides a reusable operating blueprint for deploying agent systems inside enterprises while maintaining customer ownership, discovering product opportunities, and preventing high-cost engineering talent from becoming an unstructured services bench.
  • Best use: Use the video to design FDE qualification criteria, engagement scopes, team structure, customer co-development requirements, and ROI gates for enterprise agent deployments.

Executive Summary

Pauline Brunet frames FDE design around two variables: the customer's digital maturity and the product's degree of customization. Self-service documentation is usually enough for mature customers using a low-customization product, while conventional SaaS deployment can serve low-maturity customers with straightforward products. FDE talent is most valuable where customization, transformation needs, or product-edge exploration require hands-on technical work tied to business outcomes.

Cursor treats FDE engagements as strategic, project-based co-development rather than open-ended engineering capacity. The team seeks an economic buyer or senior champion, a customer working team, access to the relevant systems and codebase, and a use case with measurable ROI. Requests motivated primarily by understaffing are considered a red flag because they turn FDEs into staff augmentation and undermine adoption, learning, and durable customer ownership.

The recommended delivery model starts with the process owner and an explicit baseline, then defines success and a directional scope that can evolve as the team learns about customer data, systems, and workflows. Customers participate in scoping, design, implementation, human-in-the-loop validation, and ROI measurement. Value should ultimately be expressed as increased revenue, decreased cost, or mitigated risk—not simply agent activity or technical output.

Cursor initially hires experienced engineers who can also navigate executives, developers, and organizational change. As the function scales, Brunet expects today's generalist 'unicorn' role to split across customer-facing and deeply technical profiles, with added industry and product specialization. FDE also serves as a product discovery mechanism: the team tests edge use cases, relays recurring customer needs to product engineering, and identifies offerings that Cursor did not originally anticipate.

Key Takeaways

  • Claim: The right FDE model depends on matching customer digital maturity with the product's required level of customization. | Evidence: Brunet contrasts mature customers using low-customization software, who should receive self-service documentation, with lower-maturity organizations needing embedded transformation and customers using highly configurable products who may need advisory or extension work. | Implication: Ken should reserve scarce forward-deployed talent for deployments where hands-on engineering and transformation support materially improve adoption, business outcomes, or product learning. | Caveat: The matrix is a qualification framework rather than a rigid segmentation model; Brunet allows limited FDE extension work in adjacent cases but warns against spending the team on routine deployment, training, documentation, or bug collection.
  • Claim: An effective FDE must combine strong software engineering capability with customer judgment, emotional intelligence, and change leadership. | Evidence: Cursor's FDEs work across CIOs, CTOs, COOs, transformation leaders, developers, and engineering managers; they must discover use cases, understand processes and culture, stay current with rapid technical releases, and translate customer feedback into product-roadmap input. | Implication: Technical interview performance alone is insufficient for enterprise agent deployment roles; selection and development should test discovery, executive communication, organizational diagnosis, and the ability to guide adoption.
  • Claim: Cursor qualifies FDE work as a strategic co-development project, not as additional engineering headcount for an understaffed customer. | Evidence: Brunet seeks an economic buyer or senior champion, a strategic objective, meaningful ROI, customer-side resources, and access to systems and code. When a customer says it needs Cursor engineers because it is understaffed, she treats that as a red flag and asks, 'Who will be the working team?' | Implication: Enterprise engagements should not begin without an accountable sponsor and named customer builders; otherwise the vendor inherits delivery ownership and the resulting system is vulnerable to abandonment after the engagement. | Caveat: Cursor's customers are often digitally mature and technically sophisticated, so the exact customer staffing requirement may differ for vendors serving less capable buyers.
  • Claim: FDE engagements should sell a defined business problem and outcome rather than a fixed block of engineering capacity. | Evidence: Brunet calls 'two FDEs for six months, do whatever you want with them' a recipe for failure. Her preferred scope identifies the workflow, agent responsibilities, data sources, decisions, human feedback points, phases, target KPI, and an indicative period such as six weeks. | Implication: Agent deployment statements of work should combine an explicit outcome and architecture hypothesis with room to revise implementation details as real workflow constraints emerge. | Caveat: The scope should remain directional because the FDE initially lacks complete knowledge of the customer's data, systems, and processes, and discoveries may justify a pivot.
  • Claim: The customer must participate throughout delivery and own the validation and value case. | Evidence: Cursor involves customers in scoping, solution design, implementation, human-in-the-loop validation, baseline comparisons, and ROI identification while its FDEs remain hands-on in the customer's codebase. Brunet warns that an FDE working alone in a customer cubicle indicates a broken engagement. | Implication: Co-development is an adoption and governance mechanism, not merely a delivery preference: it transfers operating knowledge, exposes workflow assumptions, and creates internal owners who can sustain the system.
  • Claim: Agent economics must be evaluated against business value, with every project mapped to revenue, cost, or risk. | Evidence: Brunet gives a baseline example of reducing a process from three hours to 20 minutes. She also describes an agent costing $2,000 per day whose expense looked excessive until compared with the savings from sending the correct person to repair equipment. | Implication: Ken should judge agent cost as a percentage of verified economic impact and require pre-deployment baselines rather than optimizing token or runtime cost in isolation. | Caveat: The transcript provides the framing but not a full methodology for attribution, counterfactual measurement, or accounting for model and operational risk.
  • Claim: The FDE organization should begin with senior generalists and deliberately specialize as scale and demand patterns become clearer. | Evidence: Cursor currently hires software engineers with at least five years of experience and customer-facing ability, including people from Spotify, Rippling, and Palantir. It expects to split customer-oriented and deeply technical profiles later, evolve from geography toward industry coverage, and maintain product SMEs for areas such as long-running cloud agents and the Cursor SDK. | Implication: An early deployment team should maximize versatility and credibility, but its operating model should anticipate later specialization by industry, product, and customer-facing responsibility. | Caveat: Brunet explicitly says the current roles and hiring profiles may be different within six months as products and customer maturity change.

Detailed Brief

FDE as a product and market discovery function

  • Claims: Cursor uses FDEs as the 'tip of the spear' for testing use cases outside the conventional software development lifecycle.; Repeated customer demand can justify creating an offering that was not part of the original plan.; A clear FDE mission helps both customers and employees distinguish strategic transformation from low-value services work.
  • Evidence: The team is exploring applications across HR, finance, supply chain, e-commerce, call-center ticketing, claims management, and financial-services asset management.; After hearing six or seven requests about how organizations should redesign roles, job descriptions, team structures, processes, and ways of working around AI, Brunet began considering a dedicated offering.; Cursor's stated mission is to partner with organizations to co-design and co-build an 'AI software factory' that transforms how software is designed, developed, and maintained across its lifecycle.
  • Caveats: Experiments outside Cursor's core software-development use case can produce valuable roadmap information, but the speaker does not provide evidence that all cited edge cases have become repeatable or scalable products.
  • Implications: Recurring deployment requests can serve as structured demand signals for adjacent products, organizational services, or vertical solutions.; A written mission is an internal portfolio filter that helps prevent revenue pressure from converting the deployment team into general-purpose consulting.

Partner ecosystem and delivery boundaries

  • Claims: System integrators and consultants can extend reach by handling work that should not consume the product company's highest-leverage engineers.; Rejecting poorly matched use cases can improve trust and lead customers to disclose better opportunities.
  • Evidence: Brunet points to change management and repeatable rollouts as work that partners can perform at scale, citing experience across telecommunications and healthcare/life sciences.; She tells customers directly when Cursor is not the right tool, arguing that honesty builds credibility and avoids making the vendor accountable for a predictably weak deployment.
  • Caveats: Partnering requires a deliberate ownership model so implementation feedback and strategic customer relationships are not separated from the product company.
  • Implications: The scalable model is a layered ecosystem: FDEs handle novel, strategic, product-shaping work while partners absorb repeatable rollout and broader change-management capacity.; Use-case rejection is part of enterprise positioning and risk control, not simply lost pipeline.

Notable Concepts & Terms

  • Digital maturity × product customization matrix: The framework Brunet uses to determine whether a customer should receive self-service, traditional deployment, advisory help, or embedded FDE transformation.
  • Embedded transformation: Hands-on technical and organizational support for customers that lack the maturity or staffing to capture value from a configurable product on their own.
  • AI software factory: Cursor's mission-level description of an enterprise capability for designing, developing, and maintaining software with AI across the full lifecycle.
  • Directional scope: A scope that specifies the problem, phases, agents, workflow, and target KPI while preserving flexibility to pivot after discovering the customer's actual data and system constraints.
  • Long-running cloud agents: One of Cursor's product areas and an example of agent infrastructure used to automate end-to-end workflows over extended execution periods.
  • Human-in-the-loop validation: Customer participation in checking agent decisions and results, which Brunet treats as a required part of implementation and value verification.
  • Staff augmentation red flag: A request for FDEs primarily because the customer is understaffed; Brunet views this as evidence that the proposed work lacks the co-development and strategic-outcome conditions required for FDE.
  • Revenue, cost, or risk: The three economic categories to which Brunet says every FDE project's ROI should ultimately map.

Operator Notes / Why Ken Should Care

  • Create a deployment intake scorecard that records customization level, customer maturity, executive sponsorship, named process owner, working-team capacity, system access, and expected economic impact.
  • Add an automatic escalation or rejection trigger when the customer's primary rationale is insufficient internal staffing or when no customer-side builders are assigned.
  • Require an engagement charter that distinguishes fixed success metrics from adaptable implementation details and includes an explicit pivot mechanism.
  • Instrument agent deployments with pre-launch baselines, operational cost tracking, outcome attribution, and a revenue/cost/risk classification.
  • Establish a recurring review that aggregates FDE discoveries into roadmap signals, especially requests repeated across multiple accounts or industries.
  • Define which work stays with the core deployment team and which work transfers to system integrators, including rules for preserving customer feedback and technical escalation paths.
  • Build reusable handoff artifacts covering architecture, agent behavior, human approval points, operating procedures, and post-engagement ownership.
  • Review the FDE role architecture at least every six months so hiring profiles track changes in products, vertical demand, and customer maturity.

Source/Metadata

  • Title: Forward Deployed Engineering at Cursor — Pauline Brunet
  • Transcript words: 6840
  • Duration seconds: 1247
  • Timestamp note: No timestamps or chapters were provided. The supplied transcript contains substantial duplicated passages, but the repeated material is consistent with the main talk.
Search this video Resume transcript at 0%
Full transcript 3862 words · 30 min read
0:00

[SPEAKER_00] Hello everyone.

0:12

SPEAKER_00

Can you hear me okay? Yeah. [SPEAKER_00] Fantastic. Are we having a great conference? Everyone's excited? Amazing. I would love to introduce myself. My name is Pauline Vernet. I lead the Forward Deployment 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 I've worked at my third tech company, so I'm incredibly excited to share some of the learnings. I encourage discussions.

0:29

SPEAKER_00

I'm incredibly passionate about the FTE function, and only 20 minutes to talk about it is not nearly enough, so please catch me after. I'd love to chat with you about how we're thinking about this, what we've learned, and what we want to do going forward. A couple things about Cursor. We are an AI coding platform, as you're well aware. We have incredible products that we're offering as we're helping people go from autonomous coding to asynchronous and synchronous agents, all the way to an AI software factory.

0:44

SPEAKER_00

I'm really going to focus today on the Forward Deployed Engineering function, and I want to share some of the learnings that we've had, so I'll really strictly focus on that, but always eager to talk to you about what we're doing at Cursor and what we're building. So I always hear about FTE. I'm waiting for the Forbes article that's going to say, 2026 hottest job of the year is the FTE. I feel this is the year, and I really want to talk about it. If you're thinking about building an FTE for your business, for your company, what I would personally recommend you do.

0:55

SPEAKER_00

And 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? And the reason for that is because I think of it on a matrix, right? And a lot of people ask me, hey, is FTE professional services? Is it the same thing as staff augmentation? What is FTE? 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 in for your customers.

1:21

SPEAKER_00

So the first part is, think about your 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 for it? The second part is the product customization. How configurable is your product? Is it SaaS straight out of the box? You just send a login? 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? And think about that on the metric.

1:54

SPEAKER_00

So if you have a customer who is really mature in their digital transformation, they have engineers, it's a low customization on your project, I would really just say, provide your product in a self-service fashion. Great, give great documentation. Probably not a great use of your FTE motion. Same thing on your low maturity, low customization. To me, this is a traditional SaaS deployment, right? I go in, deploy it, you can picture the waterfall project going through. Not a great use of your FTE projects. Then you have customers who are really mature, and you have highly customizable products. Here, you're going to have crazy adoption, right?

2:18

SPEAKER_00

And I would say a lot of it should be your FTE team should be acting as advisors and help accelerate them. And then finally, you have some of your customers that are further back in their transformation journey. They're learning about how to do it. They may not be able to hire or staff the folks that you can. And so they need a lot more help. And here is where I think of embedded transformation. And across this, that blue square that you see is where I think the FTE really fits in. And for a few reasons, which is for those that are very mature, low customization, you can help them maybe extend, right? Create a couple of new features, extend the application.

2:39

SPEAKER_00

You have that great feedback loop that you give to your product and engineering teams, but your FTE 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 their 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.

3:09

SPEAKER_00

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. I think that's not a good use of the FTE function personally. So then once you've decided, hey, where am I 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 FTE. That was an FTE in my opinion.

3:33

SPEAKER_00

So what is a magical unicorn that is the FTE, the Forward Deployed Engineer? To us, it is someone incredibly technical who also has really high emotional intelligence. So what does the job entail? It entails working with all types of customers across all levels of the organization. So CIOs, CTOs, COOs, as well as developers, engineering managers, working with VPs of transformations, VPs of AI. Otherwise, they're going to get bored, rightfully so, and they're going to leave because you sold them FTE. That was an FTE in my opinion. So what is a magical unicorn that is the FTE, the Ford Deployed Engineer? To us, it is someone incredibly technical who also has really high IQ.

4:02

SPEAKER_00

So what does the job entail? It entails working with all types of customers across all levels of the organization. So CIOs, CTOs, COOs, as well as developers, engineering managers, working with VPs of transformations, VPs of AI. And so 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, how you're going to affect change, and then you have to accompany them on that digital transformation journey. So you're an actor of change.

4:29

SPEAKER_00

Of course, you're using technology to do so, but you have to help them 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 finally, as an FTE, you have to be at the cutting edge of the technological advancements. So I don't know about you guys, but there's new releases every week. We've got to catch up. 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. And that's super important.

4:57

SPEAKER_00

And then 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 saying, hey, we're hearing this over and over again. And the FTE team is so close to the customers, embedded in their organizations, they're going to be the first ones, have a really good pulse on what we should build next as a company. So really effective feedback loop. We work very closely with our engineering and product teams. So I want to share a little bit about what Cursor looks like in terms of the FTE team, what we've learned, what works for us, what doesn't.

5:16

SPEAKER_00

So 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. So I recommend you think about who is buying your software and how can you help them and then match the right folks to hire in your FTE team. So for us, it is project-based, highly impactful projects.

5:30

SPEAKER_00

So I usually would 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 for the company, and that they have the resourcing that they're going to put on this project.

5:33

SPEAKER_00

Because you're going to need to be working with them side by side, you're going to need to get access to their systems, because we develop on top of their code base, you're going to need to affect change, so you're going to need to have, of course, the top-down support to do so, and you're going to make sure that you're working on something really meaningful. When you walk away at the end of the engagements, and we, in our case, have deployed cloud agents, long-running agents, we've deployed automations, we've built applications on top of our Cursor SDK, that when we walk away, it is a strict ROI for them that means they're not going to turn things off when we leave.

5:46

SPEAKER_00

Because that's part of the FTE project, we want to make sure that we're affecting change, and that we're building things that matter to them. Meaningful return on investment. We also have some cool things where we push the edge cases for the Cursor platform. As we get really cool use cases that are a little bit outside of the software development lifecycle, the FTE team, to me, is the tip of the spear that is going to test out these new use cases with customers.

5:48

SPEAKER_00

So we have incredible folks working with us on, hey, 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? And as we're pushing the edge use cases for Cursor, we're getting more momentum on how we can help you do other things, not just within the software development lifecycle, which is super important, but also across your entire company. We work in co-development with customer teams in their co-space.

5:57

SPEAKER_00

This is where you have to be really careful that you end up not doing staff augmentation. So 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, I don't think this is the right case for us.

6:00

SPEAKER_00

And so you want to make sure that you're driving something meaningful that they're going to put resources towards, and that you're going to work in collaboration. So my trick is I just ask for who are the people 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? So super important to get that. And then finally, working between our engineering and our product teams to influence the roadmap and our customers. So let them know new things are coming that are going to all of a sudden enable use cases we couldn't do before.

6:07

SPEAKER_00

And that's the beauty of it, is we can actually go and solve more things that scale very quickly. I would recommend you have a mission of the FTE. I'll offer you mine. This is the Cursor FTE 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 life cycle.

6:19

SPEAKER_00

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 of what we should 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 I'm doing that towards our mission. So that's ours. I offer you your own.

6:28

SPEAKER_00

What does the team structure at Cursor look like for the FTE? We are highly technical, highly experienced profiles. For the beginning, it makes sense for you to hire what I call unicorns. So we hire five 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.

6:32

SPEAKER_00

You're trying to drive. It's clear to your team what we should 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 I'm doing that towards our mission." So that's ours. I offer you your own. What does the team structure at Cursor look like for the FTE? We are highly technical, highly experienced profiles. For the beginning, it makes sense for you to hire what I call unicorns. So we hire five 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 deployed engineers, we are hiring very technical folks with customer facing experience. Over time, we will split the roles. So we'll have folks that are a little bit less technical, more customer facing, but still with technical aptitude, and vice versa. Those are 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. So if you talk to a bank and you're not talking about payment systems, if you're not talking about asset management risk, you kind of lost them. And so 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. So 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, and other team members can come in on their projects and say, "Hey, I need to pull in this person because they're important." So for us, 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 then finally, we will change the roles and the structure over time. One thing we always joke about on my team is 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.

6:33

SPEAKER_00

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. Just actually try it out. You will learn so much more than if you're just waiting and planning. I don't recommend doing that.

6:34

SPEAKER_00

Listen to your customers. I'll give you a really concrete example. I was not planning on offering this as an FDA offering. 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? So 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. So we actually might be offering that very soon and we'll hire the right team to actually support that. So listen to your customers. Adopt accordingly. Work with partner organizations. You can always benefit from system integrators and consultants. 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. And let's have the SIs do it. So for example, I'm not really that great at change management. Not a fan favorite. And so a lot of that can be actually accompanied with partners. Same thing on rolling out existing products that we're really good at. And we've done this a bunch across telco. We've done it a bunch across healthcare life sciences. You can roll this out and increase the reach of your organizations. So partner with your system integrators and your consultants so they can go do that at scale and broaden your reach. We talked about this already. Don't be afraid to say no. This one's a hot topic. I have customers who will say, "I want to do this." And I will say, "Oh, Cursor is not the right tool for that." A couple of reasons. One is you build credibility by being very honest about where our applications and our products and our platform are the right tools and where they're not. So you earn feedback from that because they'll say, "Actually, I have this other use case now that I trust you as a trusted partner." And then two, of course, if it doesn't go well, then you're on the hook for that. So I would recommend be very specific in the use cases you're solving. And then finally, attract and pay the right talent. So just make sure that you are hiring the right profile for what you want to deliver on. Very dependent on you. We talked about this at the beginning. And make sure that you are attracting them, paying them, keeping them motivated. So very important, especially in this war for talent that we're currently in. Here are the tips for running through FDE. 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. So just 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 three hours, which is current baseline, is that sufficient for you? Does that measure success?" Yes. Great. I have a lot of opinions about scope. So I think that you cannot just do, "Hey, take two FDs for six months, do whatever you want with them." I think that's a recipe for failure. What I would recommend is you instead are trying to solve a problem, and you establish what you're going to do to solve that problem. So we want to automate this process from our start to finish using long running agents. Long running agents are going to grab data from these. They're going to make these decisions. They're going to involve these people in the feedback loop, and they're going to go and reduce our mean time to resolution. They're going to go and automate this process from start to finish. They're going to reduce, in terms of claims management, the time to answer a customer on their claim.

6:37

SPEAKER_00

Hey, take two FDs for six months, do whatever you want with them. I think that's a recipe for failure.

6:42

SPEAKER_00

What I would recommend is you instead are trying to solve a problem, and you establish what you're going to do to solve that problem. So we want to automate this process from start to finish using long running agents. Long running agents are going to grab data from these. They're going to make these decisions. They're going to involve these people in the feedback loop, and they're going to reduce our mean time to resolution. They're going to automate this process from start to finish. They're going to reduce, in terms of claims management, the time to answer a customer on their claim. Whatever the KPIs that 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. We're going to do as much or as little as we can.

6:43

SPEAKER_00

The reason for that is I do not know the customer processes. I haven't really seen their data. I haven't seen their systems. And so I'm a little bit on the hook if it takes more than six weeks or less. That's the first part. The second part is from a customer perspective, we're going to learn a lot, and they're going to maybe want to pivot once we learn something. And having something that is directional where I can pivot based on the learnings I have, customers actually really appreciate that in the end. And so that would be my recommendation.

6:45

SPEAKER_00

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 the 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. Please raise your hand if that's the case. We need to solve something.

6:50

SPEAKER_00

Finally, measure success. Were we successful? I said that we could do this from three hours to 20 minutes. Did we get close? If not, why not? What can we do about it? And then finally, what's the return on investment? You want to over communicate that. I had someone mentioning to me that an agent was running and costing $2,000 per day. And I said, well, what was the agent doing? And he explained it to me. And I said, hey, that sounds like you're actually reducing costs to send 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 what's 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.

6:55

SPEAKER_00

Finally, leave your documentation artifacts behind so that you can help them. So I'll wrap up in 32 seconds. Build the right FTE motion for your company. Learn, pivot, and scale. Super important. 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. And so the thing I'll leave you with is I would say hire A players. A players hire A players. B players hire C players. So just be very mindful of that. Make sure that you are hiring the right talent for your organization, for your customers, and you're keeping them motivated. Thank you, everyone.

6:57

SPEAKER_00

And the FTE team is so close to the customers, embedded in their organizations, they're going to be the first ones, have a really good pulse on what we should build next as a company. So really effective feedback loop. We work very closely with our engineering and product teams. So I want to share a little bit about what Cursor looks like in terms of the FTE team, what we've learned, what works for us, what doesn't. So 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 of who we hire and the profiles we're looking for.

7:34

SPEAKER_00

So I recommend you think about who is buying your software and how can you help them and then match the right folks to hire in your FTE team. So for us, it is project-based, highly impactful projects. So I usually would 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 for the company, and that they have the resourcing that they're going to put on this project. Because you're going to need to be working with them side by side,

8:11

SPEAKER_00

you're going to need to get access to their systems, because we develop on top of their code base, you're going to need to affect change, so you're going to need to have, of course, the top-down support to do so, and you're going to make sure that you're working on something really meaningful, that when you walk away at the end of the engagements, and we, in our case, have deployed cloud agents, long-running agents, we've deployed automations, we've built applications on top of our cursor SDK, that when we walk away, it is a strict ROI for them that means they're not going to turn things off

8:44

SPEAKER_00

when we leave, right? Because that's part of the FTE project, we want to make sure that we're affecting change, and that we're building things that matter to them. Meaningful return on investment, we also, some cool things is we push the edge cases for the cursor platform, so as we get really cool use cases that are a little bit outside of the software development lifecycle, the FTE team, to me, is the tip of the spear that is going to test out these new use cases with customers. So we have incredible folks working with us on, hey, how do I help across my HR team, my finance team, my supply chain team,

9:18

SPEAKER_00

my e-commerce team, right? Working with retailers, financial banks, how do I do asset management better? And as we're pushing the edge use cases for cursor, we're getting more and more momentum on how we can help you do other things, not just within the software development lifecycle, which is super important, but also across your entire company. We work in co-development with customer teams in their co-space. This is where you have to be really careful that you end up not doing staff augmentation. So if anyone says, yeah, you have to do this, we're understaffed, red flag for me personally. I get a little antsy on

9:55

SPEAKER_00

those phone calls. I'm like, oof, I don't think this is the right case for us. And so you want to make sure that you're driving something meaningful that they're going to put resources towards, and that you're going to work in collaboration. So my trick is I just ask for who are the people 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? So super important to get that. And then finally, working between our engineering and our product teams to

10:23

SPEAKER_00

influence the roadmap and our customers. So let them know new things are coming that are going to all of a sudden enable use cases we couldn't do before. And that's the beauty of it, is we can actually go and solve more things that scale very quickly. I would recommend you have a mission of the FTE. I'll offer you mine. This is the Cursor FTE 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 life cycle. I would just encourage that you have one. It's very clear to the customer what

10:56

SPEAKER_00

you're trying to drive. It's clear to your team of what we should 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 I'm doing that towards our mission. So that's ours. I offer you your own. What does the team structure at Cursor look like for the FTE is we are highly technical, highly experienced profiles. For the beginning, it makes sense for you to hire what I call unicorns. So we hire five plus years software engineers. We don't hire out of school. We don't hire early career professionals at this moment.

11:32

SPEAKER_00

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 for deployed engineers, we are hiring very technical folks with customer facing experience. Over time, we will split the roles. So we'll have folks that are a little bit less technical, more customer facing, but still with technical aptitude, and vice versa. Those are 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

12:10

SPEAKER_00

mature to industries because when you talk to an industry and you don't use their lingo, you immediately lose credibility. So if you talk to a bank and you're not talking about payment systems, if you're not talking about asset management risk, you kind of lost them. And so 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. So 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,

12:43

SPEAKER_00

and other team members can come in on their projects and say, hey, I need to pull in this person because they're important. So for us, 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 then finally, we will change the roles and the structure over time. One thing we always joke about on my team is 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.

13:18

SPEAKER_00

Our customers will have changed in their journey. 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. Right? Just actually try it out. You will learn so much more than if you're just kind of waiting and planning. I don't recommend doing that. Listen to your customers. I'll give you a really concrete example. I was not planning on offering this as an FDA offering. I've heard it six or seven times now. And so I'm going to create one.

13:57

SPEAKER_00

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? So who do I hire? What are the job description? 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. So we actually might be offering that very soon and we'll hire the right team to actually support that. So listen to your customers. Adopt accordingly. Work with partner organizations. You can always benefit from system integrators and

14:31

SPEAKER_00

consultants. 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. And let's have the SIs do it. So for example, I'm not really that great at change management. Not a fan favorite. And so a lot of that can be actually accompanied with partners. Same thing on rolling out existing products that we're really good at. And we've done this a bunch across telco. We've done it a bunch across healthcare life sciences. You can roll this out and increase the reach of your organizations. So

15:02

SPEAKER_00

partner with your system integrators and your consultants so they can go do that at scale and broaden your reach. We talked about this already. Don't be afraid to say no. This one's a hot topic. I have customers who will say, I want to do this. And I will say, oh, cursor is not the right tool for that. A couple of reasons. One is you build credibility by being very honest about where our applications and our products and our platform are the right tools and where they're not. So you earn a lot of sort of feedback from that because they'll say, actually, I have this other use case now that

15:36

SPEAKER_00

I trust you as a trusted partner. And then two, of course, if it doesn't go well, then you're on the hook for that. So I would recommend be very specific in the use cases you're solving. And then finally, attract and pay the right talent. So just make sure that you are hiring the right profile for what you want to deliver on. Very dependent on you. We talked about this at the beginning. And make sure that you are attracting them, paying them, keeping them motivated. So very important, especially in this war for talent that we're currently in. Here are the tips for running through FDE. Check you're solving

16:10

SPEAKER_00

the right problem. It seems easy. It's actually really not. Sometimes you're solving sort of 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. So just 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

16:45

SPEAKER_00

20 minutes instead of three hours, which is current baseline, is that sufficient for you? Does that measure success? Yes. Great. I have a lot of opinions about scope. So I think that you cannot just do like, hey, take two FDs for six months, do whatever you want with them. I think that's a recipe for failure. What I would recommend is you instead are trying to solve a problem, and you establish what you're going to do to solve that problem. So we want to automate this process from our start to finish using long running agents. Long running agents are going to grab data from these. They're going to make these

17:21

SPEAKER_00

decisions. They're going to involve these people in the feedback loop, and they're going to go and reduce our mean time to resolution. They're going to go and automate this process from start to finish. They're going to reduce, in terms of claims management, the time to answer a customer on their claim. Whatever the KPIs that 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. We're going to do as much or as little as we can.

17:50

SPEAKER_00

The reason for that is I do not know the customer processes. I haven't really seen their data. I haven't seen their systems. Right? And so I'm a little bit on the hook if it takes more than six weeks or less. That's the first part. The second part is from a customer perspective, we're going to learn a lot, and they're going to maybe want to pivot once we learn something. And having something that is directional where I can go and sort of pivot based on the learnings I have, customers actually really appreciate that in the end. And so that would be my recommendation. Involve the customer in every step. Scoping. Actually building and designing the solution.

18:28

SPEAKER_00

Implementation. Doing the human in the loop validation. Looking at baseline versus the results. Identifying the ROI we're driving. They should own that. We are supporting them in this journey. Right? 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. Okay? Please raise your hand if that's the case. We need to solve something. Finally, measure success. Were we successful? I said that we could do this from three

19:02

SPEAKER_00

hours to 20 minutes. Did we get close? If not, why not? What can we do about it? And then finally, what's the return on investment? You want to over communicate that. Right? I had someone mentioning to me that an agent was running, was costing $2,000 per day. And I said, well, what was the agent doing? And he explained it to me. And I said, hey, that sounds like you're actually reducing costs to send 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 what's the ROI you're driving.

19:33

SPEAKER_00

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. Finally, leave your documentation artifacts behind so that you can help them. So I'll 32 seconds wrap up. Build the right FTE motion for your company. Learn, pivot, and scale. Super important. 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. And so the thing I'll leave you with is,

20:16

SPEAKER_00

you know, I would say hire A players, hire A players. B players, hire C players. So just be very mindful of that. Make sure that you are hiring the right talent for your organization, for your customers, customers, and you're keeping them motivated. Thank you, everyone.

Reading tools

Type to find a passage

Appearance
Ask this transcript

Notebook

Export Markdown

Add a note