Posts, videos, podcasts, articles and repos about Forward Deployed Engineering. Spam, job ads and self-promotion are filtered out, and everything is rated for how much it actually teaches.
A
Alex Vacca
@itsalexvacca · 2w ago
Palantir has a playbook for getting teams to use the software they pay for: Forward Deployed Engineering.
This year OpenAI, Anthropic, AWS and Microsoft put billions behind it.
At Teikametrics, we used it to take manual list building to zero. Run it on your team in 7 steps:
1/ Sit where the work happens.
→ Get into the team's Slack, the weekly pipeline meeting, the CRM, the sequencer and every enrichment tool.
→ Watch a rep build a list. Write down every copy-paste, every CSV export and every tab opened just to check a record.
→ At Teikametrics, the BDRs were carrying the work between Apollo, HubSpot and SmartScout by hand.
2/ Time the workflow your reps repeat most.
→ Time 3 real runs with a stopwatch and use the average.
→ Log every step: the tool, whether a person touches it, and the minutes.
→ Skip the stopwatch and you're guessing which step costs the most.
3/ Get your glue number.
→ Reps x lists per rep per week x minutes per list, divided by 60, is the hours your team spends moving data by hand.
→ Example with round numbers: 20 reps building 5 lists a week each, with 8 manual handoffs and 40 minutes per list, is 66.7 hours a week. That's 1.67 full-time people, almost 2 salaries a year.
4/ Fix the biggest group first.
→ Rank the manual steps by minutes per run x runs per week, then group the steps that 1 build can replace.
→ In that example, 1 Clay table covers 6 of the 8 handoffs. A list drops from 40 manual minutes to 8, the team's glue from 66.7 hours a we…
Founding FDE | O’Reilly Author, The FDE | Ex-Google, Bloomberg SWE · 9d ago
A post with 242 reactions this week says AI is deleting the junior engineer path. I spent a day trying to argue with it and I couldn't. AWS CEO Matt Garman called firing juniors because AI can do their jobs "the dumbest thing I've ever heard." His reason: "How's that going to work when ten years in the future you have no one that has learned anything." He's right.
Juniors learn on the boring work. CRUD endpoints. Glue code. "Add a field to the form." Five years of that and you've got a senior.
AI eats the boring work. So the pipeline breaks. That part is true and I'm not going to pretend it isn't.
What I can tell you is where some of the work went, because I've been standing in it.
It went into the room with the customer. Figuring out what they actually need (they'll say three things, the real one is a fourth). Deploying into their VPC, their security review, the one guy who owns SSO. Owning it when it breaks on a Friday.
My title for that is Forward Deployed Engineer. Before anyone chases it, the honest version:
- Roughly 70% of my week is context, not code. Stakeholder calls. Docs I didn't write.
- You own outcomes you don't fully control.
- You WILL have to tell a room of directors and CTOs no at some point, sometimes regularly.
- If you want clear priorities and tickets, this role will wear you down fast.
If you got into this to write software, that's a real cost. Some weeks I feel it.
The path isn't deleted. It just doesn't start where it used to.
♻️ Follow if yo…
Bhavik Shah
Leading Enterprise Architecture for AI-Driven Platforms & Data Strategy at Scale · 3w ago
Forward deployed engineering is one of the hottest titles in hiring right now. I wrote about a part of that job that rarely gets talked about.
The story: a use case built in two weeks on a personal laptop, three demos, approved on day 13. Then the real work started.
→ Asset registration in the enterprise catalog
→ Migrating off a laptop onto approved infrastructure
→ Rebuilding logging, observability, and resiliency from the ground up
→ Reworking every data access pattern for enterprise rules
→ Clearing 20+ gateway controls before go-live
None of that was infrastructure sitting next to the prototype. Almost every step meant rewriting the prototype itself.
I also dig into where this actually overlaps with the forward deployed engineer role everyone's hiring for right now, and where it doesn't.
Full post: https://lnkd.in/ednamHnF
If you've made this same trip from prototype to production inside your own company, what part of the gap surprised you most?
#ForwardDeployedEngineer #SoftwareEngineering #EnterpriseArchitecture #MLOps #TechCareers #ProductionEngineering #AI
Founding FDE | O’Reilly Author, The FDE | Ex-Google, Bloomberg SWE · 8d ago
Microsoft reportedly cut its monthly AI spend limit per employee from $100,000 to around $10,000. Everyone's reading it as a model story. Every pilot I've watched die says it's a receipt story.
That's The Information's reporting, and neither Microsoft nor Meta has confirmed any of it.
Microsoft's internal Claude spend was reportedly tracking toward about $1 billion a year. Token usage ate the budgets way faster than anyone projected. Most internal Claude Code licenses reportedly end June 30, with engineers pointed at GitHub Copilot CLI.
Meta, per the same report, limited Claude and Codex for AI-model work over distillation concerns and is steering people to its in-house MetaCode. Claude Code users there reportedly went from about 60,000 to about 30,000, partly from layoffs.
Nowhere in any of that does anyone say the model got worse.
The HN thread under the news is the same story at a smaller scale. One engineering lead tracks token spend against tickets shipped, and a dev burned over $2,000 in a month on the biggest model with almost nothing to show for it. Another person just said "my company took away my Claude because it's too expensive."
Imagine a customer with a 300-person engineering org. The pilot crushes. Leadership buys seats for everyone. Month three, finance pulls the usage report and the top 5% of users are 60% of the bill, and nobody can connect that to a single shipped thing.
That's where pilots die. Not in the demo. In the invoice review with no column fo…
Paden Gayle 🦘
Founding FDE | O’Reilly Author, The FDE | Ex-Google, Bloomberg SWE · 2d ago
A founder owns the outcome and picks the constraints. I own the outcome and inherit them. That’s the whole FDE trade.
Here’s what inheriting looks like on a Tuesday.
Imagine a customer where the pilot has to ship in six weeks. Security review eats three of them and I didn’t pick the reviewer. Four stakeholders, two of whom want opposite things, and I didn’t hire any of them.
If the pilot dies, it dies with my name on it.
🎯 What you get
- Founder-grade ownership, and someone else already paid for the runway.
- Reps. A founder gets one company. I get a new one every few months. (This is the part I love, ngl.)
⚡ What it costs
- You never get to say “we’ll rebuild that later.” Their stack is the stack.
- Your best idea loses to their deadline. Every time.
- When it works, their logo gets the win. You get the next deployment.
That trade is why chapter one of the book is called “The Founder Inside Someone Else’s Company.” Took me longer than it should’ve to read that as a title and not a complaint.
♻️ Follow if you want more of this, or DM me if you have questions about the role.
Senior Forward Deployed Engineers at Anthropic can clear $785K/year in total comp
In a 20-min talk, Anthropic's Kevin Bai (ex-Palantir, first FDE at Rippling) explains why the role exists:
- you're not selling software or time. you're selling an outcome. "a leader in oil and gas cares about throughput, not how the data is organized"
- FDE fits one case only: technical product + non-technical buyer. everything else runs on DevRel or sales
- every AI platform is now agentic and customizable, so every AI company is in that case. "your customers have no idea what you actually do"
- the payoff, by his numbers: Palantir ~$4M average contract value, ServiceNow $1.2M, Workday ~$600K. no other public SaaS cracks $500K
watch, then read the guide below ↓
Beth Lambert
🚀 Senior Principal, AI & Data for Anthropic at Slalom | MBA • Biochemist | Creator of Safe to Scale™ | Multi-Cloud Cer… · 4d ago
Yesterday I was a Technical Architect. Today I’m an FDE. Now what?
Twenty years in, I’ve seen plenty of reorgs. This one felt different.
One morning you’re at the top of your game. You know the platform, you know the customers, you have a clear path to next step in your career. The next morning, an email or annual sales kick-off says your role is now Forward Deployed Engineer. The title changed overnight. Your plan didn’t.
Here’s what I’ve learned: the skills didn’t disappear. Architecture judgment, customer trust, and delivery scars all transfer. What’s missing is a map. FDE work weights things differently. You ship production code inside the customer’s walls, own outcomes, and move from design to deployed in weeks, not quarters.
The biggest risk isn’t the new role. It’s waiting for someone else to define it for you.
So take ownership. Build your own FDE Individual Development Plan (IDP). Not a wish list, a working plan: where you are, where the role needs you to be, and how you close the gap in 30, 60, 90 to 180 days.
You don’t need a big block of free time to start. You need one honest hour.
Three actions this week:
▶️ Rate yourself against FDE competencies (agents, evals, AI security, rapid prototyping, production engineering). Mark each one Strong, Developing, or Gap.
▶️ Pick your top three gaps. List top three gaps, not ten.
▶️ Block two protected hours a week on your calendar to work on gaps before delivery work claims them.
Your title changed overnight. Your…
Praveen Jonnala, Ph.D
Global Chief Information & Digital Officer (CIDO) | Ph.D., AI | Board & Audit Advisor · 3w ago
The engineer across the table knew the model cold.
Not vendor-deck cold, he could tell me where it would break, what it would cost, which benchmark numbers to ignore. One of the better technical minds who has ever sat in that chair.
Forty minutes in, I asked which of our problems he'd point it at first.
He named a minor workflow one of my directors had mentioned that morning.
The easy read is that he didn't know my business. True, and not very interesting.
The interesting read is that the people who sent him are making the same mistake they're being paid to fix.
Roughly $10B has gone into forward-deployed engineering this year. It is a serious answer. I think it answers the wrong question, and I'll make that case properly in a piece that's with an editor now.
In the meantime, one question for anyone who has run one of these engagements:
When it ended, was your team better at finding the next problem on its own?
#EnterpriseAI #ForwardDeployedEngineer #AIAdoption #CIO
Paden Gayle 🦘
Founding FDE | O’Reilly Author, The FDE | Ex-Google, Bloomberg SWE · 2w ago
Everyone says learn to code and you're safe. I think the safe bet moved, and nobody is teaching the part that actually moved. That's the FDE job. And every piece of it is teachable. Buttt, nobody teaches it because it doesn't fit in a LeetCode grid. So I will 🗣️ !
What the job is actually made of:
1️⃣ Product thinking before the first line
Someone says "we need an AI assistant." The stated ask is almost never the real problem. You find who's in pain, what they do today instead, and what "solved" looks like to them specifically. Skip this and you build the wrong thing fast.
2️⃣ Starting small on purpose
One workflow, one team, one measurable thing. Not the platform. The demo that works on ten documents is not the system that works on ten million, and pretending otherwise is how pilots die.
3️⃣ Deploying means their environment, not yours
Their data, their permissions, their legacy system with the API that rate limits at 50 calls a minute. Deploying is the moment your clean build meets someone else's mess and you own the outcome anyway.
4️⃣ Testing means "does it survive real users"
Not unit tests. Does it hold when a VP pastes in a 40 page PDF and asks a question the docs don't answer. Does it fail loudly or hallucinate politely.
5️⃣ Evals are the whole job in one word
Deciding what "good" means, writing it down, and measuring against it every time you change a prompt or a model. The model will always agree with you. Evals are how you know when it shouldn't have.
6️⃣…
H
Henrikh
@henrikhinai · 5w ago
Kevin Bai (Anthropic, ex-Palantir, founding FDE at Rippling) just gave an 18-minute masterclass on the job driving Palantir's $4M contracts:
• 3:30 - The pitch: you're not buying software or a service - you're buying an outcome
• 4:34 - The only real reason to build an FDE team: selling something technical to a non-technical buyer
• 6:15 - The receipts: Palantir's $4M average contract, nowhere close to #2 ($1.2M)
• 7:32 - The line between "FDE" and an expensive dev shop: never write from scratch
• 10:04 - Before you copy this: the two questions to ask your own org first
• 11:50 - Why it matters more in 2026: every platform is now agentic, and customers have no idea what you built
Full talk, audience Q&A included, free on AI Engineer's channel
18 minutes that explain why "forward deployed engineer" quietly became one of the highest-leverage titles in AI go-to-market
New AI guides and workflows you can actually use - every day
Satya Joginipelly
Early-Stage Startup Recruiter | Ex-Glean, Ex-AWS · 4d ago
Placed FDEs at Northslope Technologies and Palantir Technologies.
The #1 thing I learned: nobody agrees on what an FDE is.
Every company is hiring Forward Deployed Engineers right now. Every job description looks different.
Here’s who shows up for ONE FDE role:
→ A CSM who has run exec QBRs and knows the customer’s business cold
→ A TAM who has debugged production at 2am
→ A Solutions Engineer who knows what closes a deal
→ A Founding Engineer who shipped from zero with no spec
→ An ex-founder who did all of it
All five can be great.
None is the “obvious” hire.
Why? The FDE role sits where engineering, product, consulting, and customer success meet.
Some days you write code.
Some days you sit with a skeptical VP and work out what they actually need, not what they asked for.
Every background has a gap:
• CSMs: strong on empathy and stakeholders, often need technical depth.
• TAMs: strong on debugging and calm under pressure, often need to move from supporting to building.
• Founding engineers: strong on ownership and speed, often struggle with relationship-heavy work.
The best ones are curious, scrappy, and grow fastest by being in the room with the customer.
𝗪𝗵𝗮𝘁 𝗜’𝗱 𝗱𝗼 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆:
• Decide which gap you’re filling
• Screen for the spine, not the title
• Test with a vague customer problem, not a leetcode round
• Hire for range, then coach the edges
The best FDEs I’ve worked with never say “that’s not my job.”
Hiring FD…
Fractional GTM Leader | Certified GTM Advisor | Turning fragmented GTM into predictable, forecastable growth for $25M+… · 2w ago
Is the Forward Deployed Engineer the next CSM?
For most B2B companies, no. The exception is real, though, and it comes down to one question: how finished is your product for each customer?
Two data points from Gainsight's 2025 CS Index:
• Only 34% of CS teams list running the renewal process as a primary responsibility, down from 45% in 2023. Executives report more accountability for the number, but frontline ownership of the renewal motion is slipping.
• Among teams that cut CS investment, 94% cut customer-facing headcount. Only 12% cut AI.
I wrote up where the FDE theory holds, where it breaks, and what CS leaders should do about it.
#CustomerSuccess #GTM #ForwardDeployedEngineer #AIinCustomerSuccess #CSLeaders
D
David Senra
@davidsenra · 5w ago
Every company says they have Forward-Deployed Engineers now.
ElevenLabs CEO and former Palantir Deployment Strategist @mati gives one of the best explanations of what an FDE is—and says companies are missing the key piece of what actually makes FDEs valuable:
“In our case, FDEs are part of the product team. They are not part of the go-to-market team. They are deeply embedded in understanding what the roadmap of the product is.”
“You want all the FDEs to actually solve the customer problem and stretch your product in that direction. But the second thing you want them to do is bring any of that knowledge back to the product, so the product becomes better for the next generation of companies building on top of it. I feel like the second part is frequently missed.”
“The beauty of that is—everybody benefits because you work with one customer, learn, and you bring that into the product experience. Both of those customers benefited from having their product optimized for better work.”
“The domain expertise they have is still theirs. They can win based on their domain expertise. But the product experience of how you build based on that domain expertise can be abstracted, and can be reusable.”
