Skip to content

Nate B Jones AI Career Business

OpenAI Pays $280,000 For This Job. You Don't Have To Be An Engineer.

Nate B Jones takes apart the forward deployed engineer boom, starting from a confession he reads in the hiring data: every lab selling autonomous intelligence is hiring humans as fast as it can to make that intelligence work inside other companies. OpenAI is paying up to $280,000 base plus equity for the role, Handshake has posted the same title at $300,000, and Anthropic promised to train tens of thousands of engineers for banks and airlines and insurers but has trained 86. He defines the job as three parts, find the leverage point, build and inspect the system, own the deployment after launch, and shows through a worked insurance claims example what leverage concretely means: the point where a small build moves the most work without giving the model dangerous authority. Only one of the three parts is a coding problem, evals are technical but have nothing to do with code, and domain knowledge measurably matters (across roughly 400,000 Claude Code sessions, task experts hit verified success more than twice as often as novices). He closes with a 30 day project you can run at your current desk to prove all three parts, and a decoder for which job titles carry which coding bar.

Published Aug 23, 2026 26:29 video 36 min read Added Aug 24, 2026 Open on YouTube →

At a glance

Every lab selling autonomous intelligence is hiring humans as fast as it can to sit inside other companies and make that intelligence work, and Nate B Jones reads that as a confession. OpenAI is hiring forward deployed engineers at up to $280,000 in base pay plus equity, Handshake has posted the same title at $300,000, and Anthropic said it would train tens of thousands of engineers to install AI inside banks and airlines and insurers and has actually trained 86. That gap is the whole video. Jones spends the rest of it defining what the job is (find the leverage point, build and inspect the system, own the deployment after launch), showing through a single worked example in insurance claims what "finding leverage" concretely means, and telling you which of the three parts you already have depending on whether you come from engineering, operations, or solutions work. The punchline is not that anyone can get the job. It is that only one of the three parts is a coding problem, the other two reward the industry knowledge you already carry, and he lays out a 30 day project you can run at your current desk to prove all three.

The labs are hiring humans as fast as they can (0:00)

The opening line is the argument in miniature. Every lab that promises autonomous intelligence is hiring humans as fast as it possibly can, to go sit inside companies like yours and make that intelligence work. Jones calls that a confession. It is a confession from the labs about how much they still need people.

Then he puts a number on the confession. Anthropic said it would train tens of thousands of engineers to go install AI inside banks and airlines and insurers. How many actually trained? 86. He repeats it: 86. That gap, between tens of thousands promised and 86 delivered, is the entire story of the hottest job in AI, and it is why the job pays what it pays.

The pay: OpenAI is hiring forward deployed engineers at up to $280,000 in base pay, plus equity. And they are not the only ones. Handshake has posted the same title at $300,000. Those numbers, Jones says, have a lot of people trying to figure out what a forward deployed engineer actually does and whether they have any realistic route into the work.

Figure 1. The two numbers the video opens with. OpenAI is hiring forward deployed engineers at up to $280,000 base plus equity; Handshake has posted the same title at $300,000. Jones does not present these as market medians, and he never claims the whole band pays this. They are the postings that made everyone start asking what the job actually is.

So he states the promise of the video plainly. By the end of it, you should be able to look at the job you have right now and see which part of the forward deployed engineer skill set you may already have, whether you are an engineer or not, which part you are missing, and what you could build in the next month or so to make the case for an interview.

And he gives the thesis he will return to in the final seconds: AI is a general purpose capability, the last mile in AI is really hard, and forward deployed engineers bridge that gap. That is why they matter.

Maya and the claims intake problem (1:23)

Jones gets specific on purpose, because specifics help generalize the principles. You run claims operations at a regional insurance company. You are Maya. Your CEO has seen enough AI presentations to know the technology can read documents, and now he wants claims processed twice as fast. (Aside, delivered flat: if you are wondering where he got this story, he has talked to these CEOs before, and he has talked to Mayas before too.)

That sounds like a clear goal. It is not a buildable job, and anyone in engineering or product will tell you why. A claim might include a policy, photographs, repair estimates, medical information, police reports, fraud review, customer calls, and several different approvals. If Maya hands all of that to the technical team and all she says is "speed up claims with AI," she has not done a great job, and the team now has to make most of the product decisions for her.

Maya is a great PM, so she does something else. She pulls up actual files. She takes one claim that moved through intake in a day and another that sat there for almost a week, as counterexamples. In the slow file, the repair estimate arrived on a Tuesday, but the signature page was missing, and nobody noticed until Friday. Three days disappeared before an adjuster made any kind of insurance decision at all.

She finds much harder problems in the files as well. Injury claims can take weeks. Fraud review is very expensive. Deciding whether to pay a complicated claim is clearly worth a lot of money, but those cases vary enormously, they need a lot of experienced judgment, and a wrong decision can send money out the door or create serious legal exposure for an AI initiative.

The missing document problem has a very different shape, and this is where the generalizable principle lives. The missing document problem happens all the time. It sits at the front of the process, and everything behind it waits on getting it right. Run the arithmetic Jones runs. If the company receives a few thousand claims a month and several hundred of them, say 600 or 700, arrive incomplete, and each one loses multiple days before anybody even notices and recontacts the customer, that is roughly 1,800 to 2,000 days of claims sitting still every month.

And here is the part he says kills him. The input needed to make that decision, to contact the customer and say "we need more docs," already exists in the claim packet. Any adjuster can check and get that answer really fast, and a flag can go out before any delay happens at all. That rationale is exactly why Maya picks intake.

Finding the leverage point (4:17)

Zoom out to the rule of thumb. Maya found a point of leverage for the AI work she wants to do, and finding leverage is a generalizable forward deployed engineer skill. Jones defines it precisely: leverage is the point where a relatively small build moves the largest amount of work without giving the model a dangerous amount of authority. It is leverage applied inside a workflow.

Look at how narrow the resulting scope is. The service only has to notice that an incomplete file has arrived. It points to the missing item and prepares the communication appropriately. That is it. Everything more complicated, the injury decisions, the suspected fraud, all of that remains with real people.

Figure 2. What "finding the leverage point" actually looks like. The AI scope is deliberately tiny and sits at the front of the process: notice the file is incomplete, name what is missing, prepare the message. Judgment work stays with people. Jones's test for leverage is the point where a relatively small build moves the largest amount of work without giving the model a dangerous amount of authority, and the same month of engineering spent one square to the right would have bought almost nothing.

Choosing that point in the workflow, regardless of whether you are in insurance or any other industry, is the skill people are desperate for. Jones frames the stakes as an allocation problem: the same month of engineering can remove 1,800 days of waiting, or it can make a rare edge case slightly better. You are applying the engineering either way. A company may have 20, 30, hundreds of plausible places to add AI. The forward deployed engineer has to work out which delay occurs often enough to matter, which pain point is painful enough, and which fix releases a bunch of work farther down the process. How you unbottleneck things.

He names where he learned this. He used to do it very manually as a Kaizen black belt doing process mapping, where you map out a process and find bottlenecks. These days you take the same skills out of the formal Kaizen context and put them into the real world, figuring out how to apply AI to debottleneck real work.

There is a second advantage to picking work this way: now Maya has something she can measure. She can quickly track how long it takes to spot missing material, how often the service she built raises a false alarm or misses a document, and how much time the adjuster then spends checking it. The project can be measured, graded as a success, and she can move on to the next one.

If all of that sounds really producty, Jones says, that is kind of the point. One of the interesting things about the role is that it mixes a lot of product in with a bunch of engineering skills. The title moves around. At one company it can mean a very strong software engineer who works directly with Customers. Somewhere else it looks more like applied AI, or implementation, or a technical product role. The common part is that you stay with the problem, from choosing where to start all the way through to the working system, because you are committed to enabling the capability inside a complex real world environment.

Why enterprise AI deployments hit the same wall (7:11)

Jones has run a lot of enterprise technology deployments over the years, and he says they always run into the same wall. Buying the product from the sales guy is the easy part. Then someone has to get access to the data, understand the policy nobody wrote down, fit the tool into the way people actually work, and deal with the first pain point that comes back from a real Customer.

All of that is familiar from ordinary enterprise tool deployment. AI makes the job harder, because the software is no longer just passively moving data around. It might be making intelligent decisions. It can decide what is missing in a document, draft a response, take actions, and write into other systems. So small misunderstandings and small pain points travel a lot farther in the age of AI.

Which is exactly why the role matters. Maya has to choose where the technology can do the most work with the least potential for downstream harm. She takes a big vague challenge about cutting claim time and decides where the right point is to apply AI to get it done. If she does her job well, by the time she is finished she and the engineers can build side by side and the business gets clean, measurable results it can check.

Jones gives the role its one word definition here. Maya is a translator. She translates from the vague large claims CEOs make, and from the generalized capabilities AI models have, into something specific: specific to her codebase, specific to her product context, specific to her Customers, so that value is actually realized. That is what a forward deployed engineer does.

The three parts of the job and which one you have (9:07)

There are roughly three parts to the job, and almost nobody starts equally strong in all three. Jones says this deliberately as reassurance: if you feel behind listening to this, you are probably not.

The three parts, in his words. A forward deployed engineer has to understand the business well enough to find the leverage point. Then build and inspect the system. Then stay around after launch long enough to learn whether people actually use it and whether the result is worth the cost.

Now map that onto where you are coming from.

Software engineers may find the building part is the part they are least worried about. They have that part. The harder move for them is getting close enough to the Customer to understand why a particular document issue matters, why a missing field matters, and then figuring out how to connect the build architecture they are working on to money and time and risk and capacity.

If you come from operations, or product, or consulting, you may have the opposite feeling. You know why a clean process diagram does not fit the real world. You know which exceptions matter to Customers. Your work is getting technically deep enough to actually build the solution, inspect what the AI is doing, and understand where the solution can fail.

If you come from solutions engineering, implementation, or even sales engineering, you are often somewhere in the middle. You already have to translate between Customers and systems. The question for you is whether you can remain responsible after the traditional handoff point for those roles: after configuration, after handoff, when you have to actually own the result and the bad cases start coming in and you have to change your design.

The three parts	Software engineer	Ops, product, consulting	Solutions, implementation, sales engineering
1. Find the leverage point understand the business well enough to pick where AI goes	the harder move: get close enough to the Customer to see why a missing field matters, and connect architecture to money, time, risk, capacity gap	you already know why a clean process diagram fails in the real world and which exceptions matter to Customers strength	you translate between Customers and systems every day strength
2. Build and inspect the system write it, and know where it can fail	the part they worry about least strength	getting technically deep enough to build, inspect what the AI is working on, and see the failure modes gap	in the middle: configuration yes, full front end and back end varies by posting partial
3. Own the deployment stay after launch, learn if people use it and if it was worth the cost	trained for years to own the code you put in production strength	PMs index high on owning the impact to the Customer strength	the real test: stay responsible past the handoff, when the bad cases arrive and the design has to change gap

Figure 3. The video's spine, laid out. Almost nobody starts equally strong in all three parts, and the point is that each background arrives strong in a different one. Note what the table does not say: no column is empty. The claim is not that engineers are replaceable, it is that two of the three parts are not coding problems at all.

Then he gets practical about how to demonstrate workflow and business judgment. Do not begin by digging into an entire job. This is a failure mode he sees with PMs constantly. Get specific. Figure out how to pull the last 10 instances of the problem you are working on, how to get recent specific data. Then dig into those issues and understand really specifically what is going on and why, what corrections already exist, and where the pain points are in those specific common issues.

As soon as you find recent issues, classify them, then do some rough math. Look at the differences across a sample of 10 or 20. Count how many cases are hitting the problem, and start estimating how much problem you solve if you fix those specific pain points. You do not need a perfect financial model. You just need enough evidence, and you need to know how to get it, so you can talk specifically to the pain point. In the story, Maya can compare incomplete intake against fraud review precisely because she did rough math on both.

And if you are wondering whether you can get that kind of data in interviews: yes. When you are given cases to work on, they specifically provide that type of data, so they can see whether you go after it.

The next step, if you can, is to sit next to the person doing the work and watch the process happen. Jones calls this the most valuable thing he has found in product, and a very producty thing to do. A lot of what people do may not appear on the official process, and you have to learn it to map the pain points effectively. So you may begin by classifying your 10 top pain points with rough math, then come back after sitting with a real Customer and say, well, five of those are fake, or five of those are a bad description of what is actually going on, and here is the real thing. Let reality change how you assess the problem.

Industry knowledge and the Claude Code study (12:53)

Industry knowledge has a very practical role in this work, and this is the encouraging part if you are wondering how you get in. Look at the industry knowledge you already have. A claims adjuster just intuitively knows when a repair estimate is correct and when it is not. A finance operator just knows when two reports use the same name but have different numbers inside them. A support lead just knows that one ordinary looking sentence usually means the Customer needs a person right away. You cannot substitute for that kind of knowledge.

He backs it with data. Researchers looked at roughly 400,000 Claude Code sessions, and people rated as experts in the task reached verified success more than twice as often as novices. Domain expertise matters.

Technical delivery and reading the job description (13:36)

The second part of the work is technical delivery, and this is where Jones wants people to read job descriptions carefully, because they can be scary.

OpenAI is asking its forward deployed engineers to write code across both front end and back end. Palantir, the company that arguably invented the title, describes people building applications, working with data, making architecture decisions, and owning the work through deployment. That is a different job description again.

He does not soften it. If the job says production software engineering, industry knowledge absolutely does not get you past that requirement, and he says explicitly that he does not want to pretend it does. Whether you are Maya doing a small technical version, which is very much a forward deployed engineer thing, or you are trying to build full front end and back end applications, your mileage will vary. You have to read the descriptions, because this particular role has a really wide range of technical expectations.

The good news: if you need to learn technical skills, you absolutely can. There are boot camps. But he also says you can work with AI to learn front end and back end engineering now, by practicing on small projects. He sees people in his Substack community do it all the time. He has watched people scale up to the point where they are technical founders in 12 months, doing simple projects: calling a model, asking for a structured output, displaying the results, learning to authenticate users, going through all the steps you do with software, building and building until they really understand what they are doing.

Why does that work? Because these days AI engineering is not about individually writing lines of code. You do not have to individually write the code. You have to understand how the system works, know the pitfalls, and know how to get AI to go where you want it to go. That is what matters. So you do not have to become an expert in every technical piece before you start. You just have to understand the system well enough to have confidence that you can ask the model to build responsibly.

He gives an example of responsible design, back in the story. Maya's service needs the intake documents in a small part of the claim record, but you would obviously want to lock off payment and medical history, because the model does not need to know that. Those are the kinds of decisions you make as a forward deployed engineer.

Evals are technical and have nothing to do with code (16:09)

The next skill is not a traditional engineering skill but is becoming one, and Jones thinks everyone can learn it: testing and eval. Because you are telling models to build things, you have to tell them what criteria to build to.

Concretely, in the story: Maya may go with 50 correctly adjudicated examples that say this is missing documents, this is not missing documents, as her test set. Then she can find out whether the model is able to write software that passes the test.

Evals are a key part of building agentic workflows, and constructing them is a really important part of the engineering job these days. Here is the line that matters for the video's whole audience: it is usually considered technical, but it has nothing to do with code. You can absolutely learn it. Part of why he made the video is that he does not want people who have the translation skills he has described to run away from the role simply because they are scared of the word code.

He returns to the same Claude Code study for support. The non technical users who started using Claude Code to code got within a few points of the technical users and the engineers on the code they were able to produce. The larger point: you can get AI to write good code if you are willing to take the time to understand systems and take the time to build good evals.

Deployment ownership (17:30)

The third big part is deployment ownership. Maya can have a system that scores beautifully on the files and still not work in production. She has to put live work down, notice what actually happens, and make corrections so that what gets built is actually useful.

That cycle of measuring, learning from reality, and coming back to build the capability is especially important with AI, because when you bring a general capability into contact with specific code and specific workflows, it is an iterative process. You have to turn the flywheel a few times to zero in on where the value actually lands. And that process has a ton of nonlinear value.

Which sets up his bar for impact. Getting AI to deliver extraordinary value, to save those 2,000 hours a month or whatever the equivalent is in your case, is absolutely the impact you should demand and expect. If you are at a point where it is saving 20 hours, or even 200 hours, you are not where you need to be. You need to look at the causes and figure out how to get the larger value you know you can unlock.

That is not a skill that comes intuitively, except, he finds, to PMs and engineers who index highly on ownership. Those two job families have been trained for a long time: you own the code you put in production, you own the impact to the Customer. It is the same mindset in this role.

Then the practical decoder for job titles. Forward deployed engineer and forward deployed software engineer usually carry the highest coding expectations. Applied AI engineer, customer engineer, solutions engineer, implementation engineer, technical deployment lead, AI operations, and AI product jobs may contain a lot of the same work at a different technical balance. If you really want to get to the forward deployed role, you can use those as skipping stones and hop along.

Title on the posting	What the description asks for	Coding bar
Forward deployed engineer (OpenAI)	write code across both front end and back end	highest
Forward deployed engineer (Palantir)	build applications, work with data, make architecture decisions, own the work through deployment	highest
Forward deployed software engineer	the word "software" is doing real work in that title	highest
Applied AI engineer	much of the same work, rebalanced	varies
Customer engineer, solutions engineer	translate between Customers and systems	varies
Implementation engineer, technical deployment lead	delivery and ownership inside the enterprise	varies
AI operations, AI product	heavier on the leverage and ownership halves, lighter on the build	varies

Figure 4. Jones's title decoder. The two "forward deployed" spellings carry the highest coding expectations, and he is blunt that industry knowledge does not get you past a production software engineering requirement. The lower rows describe much of the same work at a different technical balance, and he suggests treating them as skipping stones rather than consolation prizes.

The 30 day plan (19:48)

Here is where he turns the whole thing into something you can run. If he were trying to prove these skills over the next month, this is what he would do.

SetupPick a recurring process you can actually observe in detail. You need access to a few people who do the work, and at least 10 or 20 completed instances you can walk through.
Week 1Pull as much real work as you can and reconstruct what happened. Understand the differences between instances. Classify the issues. Start finding the leverage points.
Week 2Sit next to the person doing the work. Use that lived experience to see which of your mapped intervention points are actually most impactful, then do back of the napkin math. By the end of the week you can say clearly: this is how much work I am going to save, this is what I am doing, this is why it matters.
GateBefore you build, the scale and the safety of the intervention should be visible. This is why it will have impact, and this is how I am securing the guardrails. The point is to keep you from asking AI to invent a product before you understand the real person.
Week 3Build the simplest possible solution, and he means actually get to code, working with your AI agent. Then run it against the old cases: clean cases, ugly cases, real work. Look at the failures. Rerun after every meaningful change until it works locally on all your test cases. This is where the eval piece lands.
Week 4Let two or three people use it while you watch. Learn from them and fix the loop. That is the ownership part.
FinishSummarize the impact. "I came in, I sat down, I saw how real people worked. I mapped out the problems. I built this to fix it. I put it into production and got it to work at enterprise grade." That is the whole skill set.
SpeedrunHe has seen experienced people do the discovery half in 2 days, and the entire loop in three or four days. The 30 days is headroom for your first outing, not a requirement.

Figure 5. The 30 day proof project, exactly as Jones lays it out, including the gate he puts between mapping and building and the speedrun times he says he has watched experienced people hit. Note that every week produces an artifact you can talk about in an interview, which is the actual output of the exercise.

Two pieces of that deserve their own emphasis, because he emphasizes them.

The first is the guardrail work. He has written a lot on Substack about enterprise implementations and guardrails and points there if you do not know where to start. You should understand typical expectations around permissions, around data, around authentication and authorization, and take them seriously even if this is only an exercise. Deployments in this job are almost always in enterprise contexts, which means enterprise workflows, enterprise login, enterprise decisioning, and enterprise IT teams. Those are decisions you will need to explain in interviews.

The second is the discipline of not letting the model design the thing. AI is really good at inventing stuff. You have to understand the actual pain point first.

The FDE Skill Builder (23:41)

If you want a place to start, he has put together a companion skill builder: a self assessment, the 30 day project brief, and a portfolio checklist. He is also linking his AI jobs guide and full interview guide, so you do not have to turn the video into your own curriculum.

He also makes a case for using the Substack community itself. Post a real workflow at the place where you are stuck. His example of a good post: vendor applications arrive through email, half of them are missing one of four documents, here is what I am trying to solve for and here is where I am getting stuck. People jump in. He has watched it happen, and he says it is a rich experience.

Market size and not waiting for a title (24:32)

So where does this leave us. This is a job growing exponentially. There are a few thousand forward deployed engineers now, and demand for tens of thousands or even hundreds of thousands.

Anthropic recently announced that DXC will train tens of thousands of existing engineers as Claude certified forward deployed engineers for banks, airlines, insurers, manufacturers, and government agencies. Jones finds the starting point instructive: DXC is taking people who already work inside complicated systems and adding AI training tied to those industries. You can use the same approach for your own career.

Which is the domain knowledge point again, and he is emphatic about it. The background you bring to the table is really important here. Your industry context matters a lot. If you are deep in healthcare, do not try to jump over. If you are deep in manufacturing, do not jump over. That is where you will be most effective.

And if you are already inside a company trying to figure out how to get to the role, he does not think you need to wait for a title. Find that piece of work, show you can solve the problem with AI, and you start working your way there. He says he knows this because people in his community buttonhole him at happy hours to tell him about it: I got to a forward deployed engineer title, I got to an AI engineer title, because I did exactly this, because I jumped in and started solving problems with AI. He has seen it happen over and over.

He closes on the thesis he opened with. This will be a dependably hot job for the next few years, and it is not a fad. The reason is simple. AI is a general purpose capability, the last mile in AI is really hard, and forward deployed engineers bridge that gap. That is why they matter.

Key takeaways

The pay is real and the numbers are specific. OpenAI is hiring forward deployed engineers at up to $280,000 base plus equity. Handshake has posted the same title at $300,000.
The hiring itself is the evidence. Labs selling autonomous intelligence are hiring humans as fast as they can to make that intelligence work inside other companies. Anthropic said it would train tens of thousands of engineers for banks, airlines, and insurers, and has trained 86.
The job is three parts, and only one is code. Find the leverage point, build and inspect the system, own the deployment after launch. Almost nobody starts strong in all three, and which one you already have depends entirely on where you came from.
Leverage has a working definition. The point where a relatively small build moves the largest amount of work without giving the model a dangerous amount of authority. In the worked example that is intake completeness, not fraud review.
Rough math beats a financial model. Pull the last 10 or 20 instances, classify them, count how many hit the problem, estimate the size. That is enough to talk specifically to the pain point, and interview cases hand you exactly this kind of data to see whether you use it.
Then go sit next to the person doing the work. Half your mapped pain points may turn out to be fake or badly described. Let reality change the assessment.
Industry knowledge is not a consolation prize. Across roughly 400,000 Claude Code sessions, task experts reached verified success more than twice as often as novices.
Evals are technical and have nothing to do with code. Fifty correctly adjudicated examples are a test set. Constructing evals is core engineering work now, and it is learnable without writing code.
Read the job description, not the title. Forward deployed engineer and forward deployed software engineer carry the highest coding bar, and industry knowledge does not get you past a production software engineering requirement. Applied AI engineer, customer engineer, solutions engineer, implementation engineer, technical deployment lead, AI operations, and AI product are adjacent titles with a different technical balance.
Demand the big number. If the deployment is saving 20 hours or 200 hours instead of 2,000, you are not where you need to be. Find the cause.
Do not wait for a title. Find the piece of work, solve it with AI, and the title follows.

Chapters

0:00 The labs are hiring humans as fast as they can
1:23 Maya and the claims intake problem
4:17 Finding the leverage point
7:11 Why enterprise AI deployments hit the same wall
9:07 The three parts of the job and which one you have
12:53 Industry knowledge and the Claude Code study
13:36 Technical delivery and reading the job description
16:09 Evals are technical and have nothing to do with code
17:30 Deployment ownership
19:48 The 30-day plan
23:41 The FDE Skill Builder
24:32 Market size and not waiting for a title

Notable quotes

Every lab that promises autonomous intelligence is hiring humans as fast as it possibly can go to sit inside companies like yours and make that intelligence work. That is a confession. It's a confession from the labs about how much they need people. Nate B Jones, 0:00

Anthropic said it would train tens of thousands of engineers to go install AI inside banks and airlines and insurers. Do you know how many actually trained? 86. 86. And that gap is the entire story of the hottest job in AI. Nate B Jones, 0:12

This sounds like a clear goal from the CEO, but it's not a buildable job. Nate B Jones, 1:33

Maya is looking for the point where a relatively small build moves the largest amount of work without giving the model a dangerous amount of authority. This is leverage. It's leverage applied inside a workflow. Nate B Jones, 4:37

The same month of engineering can remove 1,800 days of waiting or make a rare edge case slightly better. Like, you're applying the engineering either way. Nate B Jones, 5:08

Maya is a translator. Nate B Jones, 8:12

If you feel like you're behind as you listen to this story, you're probably not. Nate B Jones, 9:07

The researchers looked at roughly 400,000 Claude Code sessions and people rated as experts in the task reached verified success more than twice as often as novices. That domain expertise, it matters. Nate B Jones, 13:19

If the job says production software engineering, industry knowledge in general absolutely doesn't get you past that requirement, and I don't want to pretend it does. Nate B Jones, 13:51

AI engineering is not about individually writing lines of code. You don't have to individually write the code. You have to understand how the system works and know the pitfalls and know how to get AI to go where you want to go. Nate B Jones, 14:52

Constructing evals is a really important part of the engineering job these days. It's usually considered technical, but it doesn't have anything to do with code. Nate B Jones, 16:24

I don't want people that have a lot of the translation skills that I've described to run away from the role simply because they're scared of the word code. Nate B Jones, 16:54

If you're at a point where it's saving 20 hours, for example, or 200 hours, you're not where you need to be. Nate B Jones, 18:25

The point is to keep you from asking AI to invent a product before you understand the real person. AI is really good at inventing stuff. You got to understand the actual pain point. Nate B Jones, 21:14

If you're deep in healthcare, don't try to jump over. If you're deep on manufacturing, don't jump over. That's where you'll be an FDE that's most effective. Nate B Jones, 25:03

I don't think you need to wait for a title. All you need to do is find that piece of work, show that you can solve the problem with AI, and you're going to start working your way there. Nate B Jones, 25:12

AI is a general purpose capability and the last mile in AI is really hard. FDEs bridge that gap. That's why FDEs matter. Nate B Jones, 26:03

Resources mentioned

Nate B Jones, the channel (AI News & Strategy Daily), where this analysis lives.
Nate's Newsletter on Substack, where he says he has written extensively on enterprise implementations and guardrails, and where the community he references gathers.
Become a Forward Deployed Engineer in 30 Days, the companion FDE Skill Builder with the self assessment, the 30 day project brief, and the portfolio checklist, plus his AI jobs guide and interview guide.
OpenAI, hiring forward deployed engineers at up to $280,000 base plus equity, with a job description asking for code across both front end and back end. Current openings: OpenAI careers.
Handshake, which has posted the same title at $300,000.
Anthropic, which said it would train tens of thousands of engineers to install AI inside banks, airlines, and insurers, and has trained 86 so far.
Claude Code, the subject of the study he cites twice: roughly 400,000 sessions, task experts reaching verified success more than twice as often as novices, and non technical users landing within a few points of technical users on code produced. He does not name the paper; Anthropic's research index is where its publications are posted.
DXC Technology, the services firm Anthropic announced will train tens of thousands of existing engineers as Claude certified forward deployed engineers for banks, airlines, insurers, manufacturers, and government agencies.
Palantir, whose forward deployed engineer description covers building applications, working with data, making architecture decisions, and owning the work through deployment. See Palantir careers.
Forward deployed engineer, the role itself and where the title came from.
Kaizen and Lean Six Sigma black belt process mapping, the discipline Jones says he used to do manually and now applies to finding AI leverage points.
Evals, the practice of writing test sets and grading criteria for model behavior, which he calls technical work that has nothing to do with code.
Nate elsewhere: X, TikTok, Instagram.

Where it stands

This is a career argument, not a market forecast, and it holds up better than most of the genre because Jones keeps refusing the easy version of it. He does not say anyone can get this job. He says explicitly that if a posting requires production software engineering, industry knowledge will not get you past it. That single sentence is what separates this from the usual "you do not need to code" content, and it is worth crediting.

A few honest footnotes on the specifics.

The comp figures are top of band base pay on two named postings, not medians. The equity on the OpenAI role is unquantified in the video, and a $280,000 base plus unspecified equity is not the same claim as a $280,000 total package. Handshake at $300,000 is one posting at one company. Neither number tells you what the median forward deployed engineer makes, and the video does not claim otherwise.

The 86 number does real work in the argument and deserves a second look. It appears at the open as evidence of scarcity (tens of thousands promised, 86 delivered) and the same DXC program reappears at the close as evidence of demand (tens of thousands to be trained). Both readings are defensible, but they are the same fact pointed in two directions, and the program is new enough that 86 may simply be an early number rather than a structural failure to scale. The honest version is that we do not yet know which it is.

The Claude Code study is cited twice for two findings that pull against each other: expertise more than doubles verified success, and non technical users get within a few points of technical users. Both support the video's thesis as framed, which is convenient. He does not name the paper, the sample, or what "verified success" measured, so the reader cannot check either claim.

There is one arithmetic slip. The claims example builds to roughly 1,800 to 2,000 days of claims sitting still per month, and later he refers back to saving "those 2,000 hours a month." The days figure is the one the worked example actually produces.

The largest open question is the one the video answers by assertion. The whole case rests on the last mile of AI staying human work, and the labs hiring humans to walk it is offered as proof. That is good evidence about today. It is weaker evidence about three years from now, since closing exactly that gap is what the labs are spending their capital on. Jones says the role is dependably hot "for the next few years," which is a more careful claim than the video's energy suggests, and the careful version is the one to hold onto: this is a window, and the advice that survives whether or not it closes is the part about domain knowledge, measurement, and ownership, none of which was invented by AI.

Full transcript

[00:00:00] Every lab that promises autonomous intelligence is hiring humans as fast as it possibly can go to sit inside companies like yours and make that intelligence work. That is a confession, right? It's a confession from the labs about how much they need people. Anthropic said it would train tens of thousands of engineers to go install AI inside banks and airlines and insurers. Do you know how many actually trained? 86. 86. And that gap is the entire story of the hottest job in AI. And it's why [00:00:31] this job pays what it pays. Open AI is hiring forward deployed engineers at up to $280,000 in base pay plus equity. And they're not the only ones. Handshake has posted the same title at $300,000. Those numbers have a lot of us trying to figure out what a forward deployed engineer actually does and whether they have any realistic route into the work. So, this is what I made this video to help you answer. By the end of this video, you should be able to look at the job you have now and see which part of [00:01:03] the FTE skill set you may already have, whether you're an engineer or not, which part you're missing and what you could build in the next month or so to make the case for an interview. AI is a general purpose capability and the last mile in AI is really hard. FTEEs bridge that gap. That's why FTEEs matter. Let's say you run a claims operations at a regional insurance company. Yes, we're getting specific because specifics helps us generalize principles we can all learn from. We're going to call you Maya in this story. Your CEO has seen enough [00:01:33] AI presentations to know the technology can read documents and now he wants claims processed twice as fast. By the way, if you're wondering where I got this story, I have talked to these CEOs before and I've talked to Mayers before, too. Now, this sounds like a clear goal from the CEO, but it's not a buildable job. as anyone in engineering or product will tell you because a claim might include a policy and photographs and repair estimates and medical information and police reports and fraud review and customer calls and several different approvals. If if our friend Maya gives [00:02:05] all of that to the technical team and all Mia says is speed up claims with AI, Maya hasn't done a great job and the team has to make most of the product decisions for her. Maya is a great PM. So Maya instead pulls up actual files. She takes one claim that moved through intake in a day and another that sat there for almost a week as counterexamples. Right? In the slow file, the repair estimate arrived on say a Tuesday, but the signature page was missing and nobody noticed until Friday. [00:02:35] 3 days disappeared before an adjuster made any kind of insurance decision at all. And she finds much harder problems in the files as well. Right? Injury claims can take weeks. Fraud review is very expensive. Deciding whether to pay a complicated claim is clearly worth a lot of money, but those cases really vary. They need a lot of experienced judgment and a wrong decision can send money out the door or create a lot of legal exposure for an AI initiative. The missing document problem has a very different shape. And this is where we [00:03:05] get to the generalizable principle and why I'm telling you this story. Because you see, the missing document problem happens all the time. It sits at the front of the process and everything behind it waits on getting that right. If this company receives say a few thousand claims a month and several hundred say 600 700 arrive incomplete and each one of those loses multiple days before anybody even notices and reconts the customer. That's say 1,800 [00:03:36] 19 2,000 days of claims sitting still every month. And here's what kills me on that. the input to make a good decision and contact the customer and say, "Hey, we need more docs." That already exists in the claim packet. Any adjuster can check and get that answer really fast and a flag can be sent out before any kind of delay happens. That rationale is exactly why Maya picks intake to work on in our story. And it's a it's a rationale I've seen play out specifically in the insurance industry [00:04:06] before, but it's also a little flag hint of how FTEES grab these skills and apply them other places. So if you're looking for a larger rule of thumb here, think about it as Maya finds a point of leverage for the AI work that she wants to do. And finding leverage is a generalizable FTE skill. In this case, Maya is looking for the point where a relatively small build moves the largest amount of work without giving the model [00:04:37] a dangerous amount of authority. This is leverage. It's leverage applied inside a workflow. The service only has to notice that there's an incomplete file when it arrives. It just points to the missing item and it prepares communication appropriately. That's it. Everything else that's more complicated, injury decisions, suspected fraud, all of that remains with real people in our story. Now, choosing that point in the workflow, regardless of whether you work in insurance or you work in any other industry, that is the FTE skill that [00:05:08] people are desperate for. The same month of engineering can remove 1,800 days of waiting or make a rare edge case slightly better. Like, you're applying the engineering either way. A company may have 20, 30, you know, hundreds of plausible places to add AI. The FDE needs to work out which delay occurs often enough to matter, which pain point is painful enough, and which fix releases a bunch of work farther down the process, how you unbottleneck stuff. [00:05:39] I used to do this very manually when I did Kaizen black belt process mapping, and you map out a process and find bottlenecks. These days, you're taking similar skills out of a formal Kaizen context and you're putting them into the real world where you're trying to figure out how you can apply AI to debottleneck real work. And the advantage of picking work like this is that now Maya has something she can measure. She can really quickly track how long it takes [00:06:09] to spot missing material, how often the AI service she's built raises a false alarm or misses a document, and how much time the adjuster then spends checking it. And the project can then be measured appropriately, graded as a success, and she can move on to the next AI project. And so when we think of Maya's story, that's the kind of work I want you to picture when you hear forward deployed engineer. And and by the way, if you hear that and say that sounds really producty, that's kind of the point. One [00:06:39] of the interesting things about forward deployed engineers is it mixes a lot of product in with a bunch of engineering technical skills. The title can move around. At one company, it can mean a very strong software engineer who works directly with customers. Somewhere else, it may more look like applied AI or implementation or a technical product role. But the common part is that you stay with the problem from choosing where to start all the way through the working system because you're committed to enabling the capability inside a [00:07:09] complex real world environment. Every time I have run enterprise technology deployments and I've run a bunch of them over the years, they always run into the same wall. Buying the product from the sales guy, that's the easy part. Then someone has to get access to the data and understand the policy nobody wrote down and fit the tool into the way people actually work and deal with the first pain point that comes back from a real customer. All of this is something we're familiar with in enterprise tool deployment. But AI makes that job even [00:07:41] harder because the software is no longer just passively moving data around. It might be making intelligent decisions, right? It can decide what's missing in a document. It can draft a response. it can take actions and write in other systems. So small misunderstandings or small pain points can travel a lot farther in the age of AI. And that brings me to FTEEs. That is why FTEEs are so important in AI software because Maya has to choose where the technology [00:08:12] can do the most work with the least potential for downstream harm. And so she has to take this big challenge around cutting claim time and she has to decide where is the right point to apply AI to get that done. And if she does her job well by the time she's finished she and the engineers side by side can build and the business gets really clean measurable results that it can check. In other words, Maya is a translator. Maya is a translator from the vague large [00:08:44] claims CEOs make, from the generalized capabilities AI models have, and she takes that larger context and applies it and translates it specifically for her codebase, specifically for her product context, specifically for her customers, so that value is realized. That's what an FTE does. Now, there are roughly three parts to the FTE job, and almost nobody starts equally strong in all three. So, if you feel like you're [00:09:14] behind as you listen to this story, you're probably not. An FTE first has to understand the business well enough to find the leverage point, build and inspect the system, and then stay around after the launch long enough to learn whether people actually use it and whether the result is worth the cost. Software engineers may find that the building part is actually the part they're least worried about. They've got that part right. But the harder move for them is getting close enough to the customer to understand why, you know, a [00:09:44] particular document issue matters, why a missing field matters, and then figuring out how to connect the build architecture they're working on to money and time and risk and capacity. So, if you're coming from operations, let's say you're not from engineering, let's say you're from product or or maybe from consulting, you may have the opposite feeling to those engineers. You may know why a clean process diagram doesn't fit the real world. You may know which exceptions matter to customers, but your work is now getting technically deep [00:10:14] enough to actually build the solution, inspect what your AI is working on, and understand where that solution can fail. If you're coming from solutions engineering or implementation or even sales engineering, you're often somewhere in the middle. You already have to translate between customers and systems. And so the question for you is whether you can remain responsible after the traditional handoff point for those roles after configuration after handoff when you have to actually own the result and the bad cases start coming in and [00:10:44] you have to change your design if you're trying to practice demonstrating workflows and business judgment. I would not begin by digging into an entire job. And this is something I often see as a failure mode with PMs as well. Get specific. I would figure out how you pull the last 10 instances of the problem you're working on, how you get some recent specific data. And then I would start to dig into those issues and understand really specifically what's going on and why, what corrections already exist, where there are pain [00:11:14] points in those specific common issues that you can go after. And as soon as you start to find recent issues, you're going to start to classify them and then do some rough math, right? differences you find across a sample of 10 or 20. Count how many cases are hitting the problem and you start to be able to estimate rough notes how much problem you're solving if you solve some of those specific pain points. You don't need a perfect financial model to be an FTE person. You just need enough evidence and you need to know how to get [00:11:45] it so you can talk specifically to the painoint. Right? Because in in our story with Maya, Maya can now compare incomplete intake with fraud review because Maya did rough math what each of those specifics are. And if you're wondering if you can get that kind of data in interviews, typically when you're given cases to work on, they specifically provide that type of data so they can see if you go after it. The next step, if you can, is to sit next to the person doing the work and watch the process happen. Right? One of the things [00:12:16] that I find most valuable that I've found valuable in product and it's a very producty thing to do. Just sit next to the customer, sit next to the client, see how they do the work. A lot of what they do may not appear on the official process and you're going to have to learn it to effectively map the pain points. And so you may begin by classifying your 10 top pain points and you have rough math and you may come back after you sit with a real client or real customer and say, "Well, five of those are fake or five of those are really a bad description of what's going on and here's the real thing." Let that [00:12:47] reality change how you assess the problem. One thing to note as you're going through this process, industry knowledge has a very practical role with a lot of FTEEs. And so another thing that can encourage you if you're wondering how do I get this is look at the industry knowledge you already have, right? Like a claims adjuster can just intuitively know when a repair estimate is correct and when it's not. A finance operator can just know when two reports use the same name but have different numbers inside them. A support lead can just know that one ordinarylooking [00:13:19] sentence usually means the customer needs a person right away. You can't substitute for that kind of knowledge. The researchers looked at roughly 400,000 claud code sessions and people rated as experts in the task reached verified success more than twice as often as noviceses. That domain expertise, it matters. The second part of FTE work is technical delivery and this is where I want people to read their job descriptions carefully because it can be scary. Open AI is asking its FTEEs to write code across both front end and back end. Plantier describes [00:13:51] people building applications, working with data, making architecture decisions, and owning the work through deployment. That's a different job description. Uh now look, if the job says production software engineering, industry knowledge in general absolutely doesn't get you past that requirement, and I don't want to pretend it does. Uh, and so whether you are Maya and you're just doing a small technical version in our story, which is very much an FTE thing, or whether you're trying to build full front-end and backend applications, your mileage will vary. You will have to [00:14:21] look at the descriptions because this particular job role has a really wide range of technical expectations. Now, the good news is if you need to learn technical skills, you absolutely can do that. There are boot camps for technical skills, but I will also say you can actually work with AI to learn front-end and back-end engineering now. And you can do so by simply practicing building small projects. It's something that I see people in my Substack community do [00:14:52] all the time. I've seen people scale up to the point where they are technical founders in 12 months doing just simple projects where they're calling a model, they're asking for a structured output, they're displaying the results, they're learning to authenticate users, they're just going through all the steps that you do with software and they're just building and building and building till they really understand what they're doing working with AI. Why does that work? Because these days AI engineering is not about individually writing lines of code. You don't have to individually [00:15:22] write the code. You have to understand how the system works and know the pitfalls and know how to get AI to go where you want to go. And that's what matters. So you don't have to become an expert in every technical piece before you start. You just have to understand the system in a way that gives you confidence that you can ask the model to build responsibly. as an example of responsible decision-making. In our story, Maya's service needs the intake documents in a small part of the claim record, but of course, you'd want to lock off payment and medical history because the model doesn't need to know [00:15:53] that stuff, right? You need to think about those kinds of things when you're designing systems as an FTE. The other thing that's really important for FTEES that is not a traditional engineering skill but is becoming an engineering skill and is one that all of us can learn from is testing and eval because you are telling models to build things. You have to tell them what criteria to build to. In our example, Maya may absolutely go with 50 different correctly adjudicated examples that say [00:16:24] this is missing documents, this is not missing documents as part of her test set. And so she can then find out if the model is able to write software that passes the test, etc., etc. Evals are a key part of building agentic workflows. And constructing evals is a really important part of the engineering job these days. And it's not it's got nothing to do with code. It's it's key to FTE skill sets. It's usually considered technical, but it doesn't have anything to do with code. You can absolutely learn it. And part of why I'm [00:16:54] making this video is I don't want people that have a lot of the translation skills that I've described to run away from the FGE role simply because they're scared of the word code. Don't be scared of that. In fact, in the same study I mentioned with claude code, the non-technical users who started using claude code to code got within a few points of the technical users and the engineers on the code they were able to produce. The larger point here is that you can get AI to write good code if you [00:17:25] are willing to take the time to understand systems and willing to take the time to build good evals. The third big part of the role here is deployment ownership. Maya can have a system that scores really beautifully on the files and it still might actually not work in production. And so she needs to be able to put live work down to notice what actually happens and to make corrections so that what gets built is actually useful. That cycle of measuring and learning from reality and coming back and building the capability is [00:17:55] especially important for FTEES and AI because what I find is that when you have an AI capability that's general and you're bringing it into contact with specific code and specific workflows, it is an iterative process. It's a process where you have to turn the flywheel a few times to make sure that you're zeroing in on where the value is actually applied. And that is a process that has a ton of nonlinear value. In other words, getting AI to really deliver extraordinary value to save those 2,000 hours a month or whatever it [00:18:25] is in your case, that's that's absolutely the impact you need to demand and expect. And if you're at a point where it's saving 20 hours, for example, or 200 hours, you're not where you need to be. And you need to look at the causes and figure out how to get the larger value that you know that you can unlock with AI. And that is not a skill that comes intuitively except I find to PMs and engineers who index highly on ownership. Those two job families have been trained for a long time. You have to own the code you put in production. You have to own the impact to the customer. It's the same mindset with an [00:18:56] FTE. Now I'm going to give you some clues on the job description next because like I said there's a whole range of them and I want to give you a sense of what works and what doesn't for different skill sets based on my analysis. So if it's forward deployed engineer, forward deployed software engineer, those usually have the highest coding expectations. Applied AI engineer, customer engineer, solutions engineer, implementation engineer, technical deployment lead, AI operations and AI product jobs may contain a lot of [00:19:26] the same work but a different technical balance. And so you can look at those if you really want to get to FTE as uh skipping stones along the way. like you can hop along and get to FTE by taking some of those adjacent titles. Now, let's turn this into something that you can use specifically. If I were trying to prove skills around FTE over the next month or so, the first thing I would do is I would pick a recurring process that I can actually observe in detail. And I would need access to a few people who do [00:19:57] the work. and I would need at least 10 or 20 completed instances that I can go through and see how the work ran. During the first week, I would actually pull as much real work as I can and I would reconstruct what happened. I would try to understand differences. I would try to classify issues. I would try to start to find the leverage points, right? Then I would talk to the person who's doing the work. I would sit there. I would sit next to them, which is what I described. And I would figure out from that lived experience where the intervention points [00:20:29] that I've mapped out are likely to be most impactful. Where is the leverage but in real life sitting next to a person? And I would use that understanding to start to do back of the napkin math so that I can figure out the impact because FTEES have to have that business impact. And by the end of that second week, by the end of sitting there observing the person, I should be able to say very very clearly, this is how much work I'm going to save. This is what I'm doing and this is why it matters. And if you're like, wow, 2 [00:20:59] weeks is a long time. I have seen people speedrun this in 2 days. People can absolutely, if they're experienced, dive into the data and sit with someone for a day and they're done. It may be your first time, so give yourself a minute. And whatever the answer is, the scale and the safety of the intervention should be visible before you build. You should be able to say, "This is why it's going to have an impact, and this is how I'm securing the guard rails, right? The point is to keep you from asking AI to invent a product before you understand [00:21:30] the real person. AI is really good at inventing stuff. You got to understand the actual pain point." Now, get started building from there. You want to start to build the the simplest possible solution. And I do mean build. Actually get to code. Work with your AI agent and figure out how to build a solution that solves for the leverage point you've identified. I have written a ton on Substack about enterprise implementations and guardrails. I would recommend going there if you don't know [00:22:00] where to start. But you can absolutely dig in. Understand typical expectations around permissions, typical expectations around data, typical expectations around authentication, authorization, take those seriously even if this is just an exercise because FTE deployments are almost always in enterprise contexts and you have to understand how to work with enterprise workflows, enterprise login, enterprise decisioning, enterprise IT teams. Those are decisions you will need to explain in interviews. Now, once [00:22:30] you've built the system, you need to start trying that system against those old cases. You should be doing that by the end of the third week. You should be able to like try clean cases, try ugly cases, whatever it is that's actual work. Run it through your loop. Run it through the thing you've built. Look at the failures, rerun them after every meaningful change. Sit there and make it work so it works locally on all of your test cases. This is where that eval piece comes in. Finally, in week four, let two or three people use it while you [00:23:01] watch. Learn from them and fix the loop. That's really the key. That's that last part. That's that ownership part. And again, I have seen people speedrun this whole process in three or four days. It can be much, much faster, but I'm giving you a chance to dig in if it's your first outing at this skill set. Finally, you want to actually summarize the impact you had. That's the last piece. However long it takes you, you should be able to say, "I came in, I sat down, I saw how real people worked. I mapped out the problems. I built this to fix it. [00:23:32] When I built it, I was able to put it into production and actually get it to work at enterprise grade." That's the whole FTE skill set right there. Now, if you would like a place to start, I put together a companion FTE skill builder that has a self assessment for you. It has that 30-day project brief. It has a portfolio checklist. And I'm also going to link to my AI jobs guide and the full interview guide so that you don't have to turn this video into your own curriculum. I also think that this is a particularly good use of the Substack community. Lots of us are there building [00:24:03] and trying interesting stuff. I would recommend posting a real workflow in the place where you're stuck. You might say, "Hey, vendor applications arrive through email. Half of them are missing one of four documents. Here is what I'm trying to solve for and here's where I'm getting stuck." And people will just jump in. Like I've seen folks come back and just jump in. And it's a really sort of rich experience that way. So where does this leave us? We've talked about training. We've talked about your first 30 days resources that I have in my community. Ultimately, this is a job that is growing exponentially. There are [00:24:33] a few thousand FTEEs now, but there's demand for tens of thousands or even hundreds of thousands. Anthropic recently announced that DXC will train tens of thousands of existing engineers as claude certified FTEEs for banks and airlines and insurers and manufacturers and government agencies. And I think that the starting point here is interesting to note, right? DXC is taking people who already work inside complicated systems and adding AI training tied to those industries. You can use the same approach for your own career. Remember I said domain knowledge [00:25:03] matters because the background you bring to the table is actually really important as a forward deployed engineer. Your industry context matters a lot. If you're deep in healthcare, don't try to jump over, right? If you're deep on manufacturing, don't jump over. That's where you'll be an FTE that's most effective. And if you're in a company and trying to figure out how to sort of jump to FTE, I don't think you need to wait for a title. All you do is need to find that piece of work, show that you can solve the problem with AI, and you're going to start working your way there. Do you want to know how I [00:25:33] know that? There are people in my community that come up and button hole me at my at my happy hours, and they're like, "Nate, look at where I got right. I got to an FTE title. I got to an AI engineer title because I did exactly this because I jumped in and I started solving problems with AI. That is the way forward and that's why I talk about it with such confidence. I've seen it happen over and over and over and over again. You can do it too. Uh I hope this has been helpful. FTE is going to be a dependably hot job for the next few years. This is not just a fad. The [00:26:03] reason why is really simple. AI is a generalpurpose capability and the last mile in AI is really hard. FTEES bridge that gap. That's why FTEEs matter. If you're an FTE, let us know in the comments and let us know how you got there. If you would like to be an FTE, drop the project you're working on in the comments or head over to the Substack and share what you're working on. We'd love to hear about it. All right, cheers.