Your Company Has AI Tribes. Send an Engineer as Emissary

A thesis on whether the forward-deployed mindset can help AI adoption spread between teams with different tools, incentives, and habits.

This is not a how-to manual.

It is also not an ROI story.

This is an exploration of a narrower question: can the Forward-Deployed Engineer mindset be borrowed inside one company to help new behavior travel across teams that do not share the same habits, tools, or instincts?

An FDE, in the Palantir sense, is an engineer who leaves home, embeds in a customer's shop, and makes the product solve the customer's real problem. A forward mission into another tribe, serving the interests of the tribe they came from. I kept that image in my head for a while, then realized I didn't need a flight. The tribes were already inside my own company.

Different teams. Different tools. Different processes. Different rituals. Teams that share my logo but not my instincts. I'd been trying to reach them the usual way - an email from leadership, a mandate, a "please adopt AI" slide deck. It worked, sometimes. A lot of the time it didn't.

So this article is a thesis, not a playbook. I'm not claiming we already proved the ROI. I'm asking whether the best pattern we have for taking technology into a foreign environment can also work inside a company where AI adoption is uneven, political, and deeply local.

Nobody Joins Your AI Future Because You Sent a Slide Deck

Here's a situation you've probably lived. There's a team - call it mine - that has gone deep on AI. We have a way of thinking, a set of tools, a rhythm that's become second nature. When a problem shows up, our first instinct isn't "write a script," it's "is there a model-shaped answer here, and can we ship it safely?" We've internalized the trade-offs: evaluation, cost, latency, and all the small failure modes that only show up once this stuff is real.

Then there are the other teams. They're not behind because they're less capable. They're behind because their priorities are different, their tools are different, and their instincts were tuned for a different problem. They have real delivery pressure, real pain, and a healthy distrust of anything that smells like a trend.

Leadership sees this and does the obvious thing: a mandate. "Every team will adopt AI." A training session. A policy document. A list of approved tools.

Some teams comply. Some genuinely find value. Some file the mandate next to last quarter's mandate and go back to shipping.

A mandate treats the whole company as one tribe. It isn't. It's a collection of smaller tribes, each with its own dialect, incentives, rituals, and reasons for doing things the way it does. HBR had a good phrase for this years ago: the real company lives in the informal network behind the org chart. That feels exactly right here. You cannot order culture into existence. You can only send someone to live inside it.

That is the FDE's entire job description.

The Best Adoption Pattern We Have - And We Rarely Use It on Ourselves

Palantir popularized the FDE role. Internally, they call them Deltas. The distinction is clean: a traditional engineer - a "Dev" - builds one capability for many customers. A Delta enables many capabilities for one customer. The Dev optimizes for reuse. The Delta optimizes for the customer's outcome.

What separates a Delta from a consultant is that the Delta is technically dangerous and lives inside the customer's problem. They don't hand over a report. They configure the platform, ship the workflow, and sit with the end users when it goes live. The feedback loop is measured in days, not quarters.

The traits that make a good one are not "smart" and "experienced." They're:

Empathy with the problem, not the technology. A Palantir engineer put it this way: you have to pay attention to the problem and show empathy - otherwise you build a good solution at the expense of the one that actually elevates how the customer operates. Most internal technology demos would fail this test in the first five minutes.

Ownership without handoff. Autonomy is a function of ownership. The Delta owns the outcome, not the deliverable. There is no "I built it, someone else deploys it."

Radical curiosity. You get dropped into a domain you know nothing about, and you get fluent fast. Cyber one quarter. Healthcare the next. You cannot hide behind your original job title.

Outcomes trump technology. Always. The customer comes first, not the tool. The platform is the means, never the point.

Voice of the field. This is the trait nobody talks about. Deltas don't just deploy outward - they feed what they learn back to the product team. Palantir's own account: some of their most valuable product features originated in the field.

Read that list again and ask yourself if it doesn't sound like the exact person you need to fix AI adoption inside your own company.

You're Not Rolling Out Tools. You're Rewiring Tribal Behavior.

I had to admit something uncomfortable. For a long time, I assumed other teams weren't adopting our AI tools because they just hadn't seen the light. If I built better tools, if I demoed harder, they'd come around. They didn't.

GitHub's public AI adoption playbook calls this out with what might be the most honest sentence in the entire document: companies fail at AI adoption because they treat it like installing software, when it's actually rewiring how people work.

The difference between success and failure isn't buying licenses. It's building the human infrastructure that turns skeptical employees into power users. That's a change-management problem wearing a technology costume.

And change management, it turns out, already has a mechanism that looks almost exactly like an FDE.

GitHub calls them "AI Advocates" - a volunteer network of internal champions who scale adoption through peer-to-peer influence. Microsoft's research arm, run by the people behind the SPACE framework, calls them "local champions." HBR makes a similar point from another angle: the people who drive hard change tend to be the ones who bridge disconnected groups, not just the ones with authority. The numbers here are the kind that should make a senior engineer, tech lead, or early manager stop and reconsider the whole rollout playbook:

Leadership advocacy alone makes developers roughly 7x more likely to become daily users. Just leaders consistently saying "we want you to use this, here's why," not "we're requiring it."
Local champions - peer-to-peer, no corporate wrapper - make an organization about 22% more likely to have most or all developers adopt.
Formal training adds roughly another 20%.

Nobody in that research is saying "the mandate helped." The single most effective lever is a credible peer who has already walked through the door and can tell you what's on the other side.

That person is an internal FDE. Same equation, different tribe.

Or maybe that's too generous a label. Maybe this is partly just a champions program with better branding. If so, the only reason the analogy is worth keeping is if it points to something more demanding than advocacy: not just encouraging adoption, but embedding long enough to ship something real and return with signal that changes the source team too.

Embed. Ship. Return With What the Tribe Actually Needs.

So here's the hypothesis, stripped down: stop broadcasting AI adoption, and start embedding engineers in the teams you want to change.

Not permanently. Not as auditors. As a time-boxed, two-way exchange. An engineer from my team - someone who has internalized the AI-native mindset and the tools - embeds with another team for a stretch. Their job is not to lecture. It's to do what a Delta does, in three moves:

Listen. Before proposing any tool, understand the pain. What is actually slowing this team down? What are they proud of? What do they quietly dread? The goal is to earn the right to suggest something by showing you understand their problem better than the person who just showed up with slides. Most adoption efforts fail here - they start with the technology and work backward to find a problem it fits.

Ship. Not a demo. A real thing that matters to that team, built their way, using our instincts. Something the team can point to and say "that made my sprint easier." The AI-native mindset doesn't travel through talks. It travels through artifacts. The embedded engineer isn't evangelizing. They're building alongside, and the mindset leaks out through the keyboard.

Return with signal. This is the step most internal adoption efforts skip entirely. The embedded engineer comes home with a field report: here's what the other team actually needs, here's where our tools missed, here's the feature we should build next, here's what the other team does better than we do. Some of your best platform improvements will come from the field, not from your roadmap.

But not every field win becomes a platform win. Some fixes are deeply local - glued to one workflow, one compliance shape, one mess of legacy constraints. That's fine. The point of the return signal isn't to pretend every artifact generalizes. It's to learn which frictions are reusable product gaps and which ones are just the honest cost of one tribe being different from another.

The role is a bridge in both directions. Most adoption programs are a firehose in one direction and a suggestion box in the other. The internal FDE closes that gap.

So Here's Why This Can Fail in the Field

Any article that doesn't interrogate its own idea turns into marketing. So let me be the first to tell you why this might fail.

Tribal identity is real, and it resists outsiders. My company, like yours, has competing ideas and duplicated effort across teams. An embedded engineer can be treated as an outsider - or worse, as an auditor sent by leadership to report back. Microsoft's research is blunt: developers are skeptical by nature, and roughly 30% think AI is a gimmick. Hype is the single biggest barrier. If your FDE shows up with hype, they're done by day two. If they show up with a real fix for a real pain point, the skepticism flips into curiosity. But you only get one shot at the first impression.

Some barriers are not tribal at all. Sometimes the team is not resisting because they need a better story or a more credible peer. Sometimes they're blocked by regulation, brittle architecture, missing data plumbing, or a workflow where an LLM genuinely adds latency and cost without enough return. An embedded engineer can expose those constraints clearly. They cannot wish them away with a sprint artifact.

It might just create another fiefdom. If the embedded engineer is evaluated on "number of teams converted," they'll optimize for adoption theater. Fake demos. Shallow integrations. The healthier instinct is to think like a Delta - in host-team outcomes, not your own scorecard. Did their cycle time drop? Did their toil reduce? Would they be sad to lose what you built? Microsoft's data says 80% of developers who adopt AI would be sad to lose it. Measure that, not a PowerPoint.

Competition between tribes can curdle. Healthy competition helps - Microsoft found that leadership scoreboards showing adoption percentages light a fire under managers. But it can also breed resentment if the embedded engineer is perceived as the reason another team looked bad. The rule: measure at the team level, never name individuals, and never, ever shame.

To the CTO Reading This: Don't Mandate the Future if You Can't Lower the Friction

If you're in the C-suite, here's your part. It is smaller than you think, and harder than it sounds. This article is mostly for senior engineers, principals, tech leads, and early managers - the people who actually carry new behavior between teams - but leadership still sets the weather.

Your job is air cover, not command. Three responsibilities, and the discipline to stop there.

First: signal the "why" relentlessly. Not once. Every few weeks. Microsoft measured this - leaders who consistently communicate the value of these tools are the difference between a 7x boost and nothing. Don't say "your job is safe." Say "here's how our work will change, and here's how we'll support you." The first builds fear. The second builds trust.

Second: protect the embedded engineers. The moment an internal FDE gets pulled back to "real work" by their home team, the experiment dies. Give them a protected time-box, a named sponsor, and explicit permission to say no to their team's roadmap while they're deployed.

Third: fund the bridge, not the broadcast. Every dollar you'd spend on a company-wide AI training event is better spent on one engineer embedded with one skeptical team for one sprint. One converted team is worth ten informed teams. One team that can show the others a real artifact is worth a hundred emails.

And the thing you must stop doing: overpromising. The C-suite has a bad habit of announcing AI as a productivity revolution. It isn't, and your engineers know it. According to the SPACE researchers, the real measured gains hover around 10%, not 10x. The moment you overclaim, you hand every skeptic exactly the evidence they were looking for. Frame AI for what it actually is: an unevenly useful assistant. Your credibility is the scarcest resource in the entire adoption effort. Don't burn it on a press release.

This Is Bigger Than AI

I've framed this around AI because it's the need of the hour. But the FDE pattern doesn't care what the payload is.

The same embedded engineer who seeds an AI-native mindset can seed a testing mindset, an observability mindset, a security mindset, a platform-engineering mindset. The pattern is: a credible peer, embedded in another tribe, shipping real outcomes in both directions. The technology is just the cargo.

That's the real reason this matters. If you build this muscle once, you're not just an AI-adoption person. You're a change-fluency person. And in a company full of separate tribes - separate dialects, separate instincts, separate histories - the engineer who can move between them, who can translate, who can build trust, who can bring the field back home, becomes quietly indispensable.

That transition - from "I build things" to "I make things spread" - is the move from technologist to adoption mindset. For a senior engineer or early manager, that's one of the highest-leverage shifts available right now. It's not a new framework. It's learning to be dangerous inside someone else's tribe.

These Are the Questions Worth Arguing About

Here are the three things I genuinely don't know, and I'm putting them here because I want to hear where I'm wrong.

One: does a grassroots movement only work if you don't call it one? The theory says volunteers self-select - you don't nominate champions, you wait for them to raise a hand. Find the senior engineers whose voice already carries weight. Let them tell their own story in their own dialect. But nobody writes down the actual mechanics of getting the first volunteer to step forward. If you've done this - if you've been the first person in another tribe who said "send me" - how did it happen? What made you say yes?

Two: how do you keep an embedded engineer from going native? A month in, whose priorities win - the mission they were sent on, or the P0 bug screaming at them from the host team's board? Every field deployment has this problem. Palantir solved it with organizational separation and a clear chain back home. Inside one company, the lines are fuzzier. I suspect the answer is: you don't fully prevent it, and you shouldn't try. A little going-native is the whole point. But how much is too much?

Three: what if the honest version of this doesn't scale? What if the model is one engineer at a time, forever, with no multiplier effect? If that's true, then the dream of "driving AI adoption across the entire company" collapses into something smaller, slower, and more human: a series of individuals who each walked into another tribe and made one thing better. I think I'd be okay with that outcome. But I suspect a lot of tech leads wouldn't be - and I'd like to know what you'd do instead.

Maybe that's the real boundary of the idea: not a company-wide operating system, but a high-touch intervention for a few high-friction crossings where trust, translation, and artifact-building matter more than another round of executive messaging.

Hit me in the comments. Have you been the engineer dropped into another tribe's way of working? Have you watched a mandate fail in a way an embedded engineer might have saved? Are you a principal, lead, or early manager already doing this work without having a name for it? Or do you think this is still just a dressed-up champions program?

More importantly: can this actually work as a path to AI adoption inside one company, or does it only sound elegant because it borrows a strong name from somewhere else?

I don't want the polished answer. I want the field answer.