When the client's IT team sees the FDE as a threat: how to make them co-owners of the system

Picture your first week on a client site. You need read access to the orders database, but the ticket you filed three days ago is still unanswered. In the technical meeting, the IT lead sits with arms folded and answers every question with “we’ll need to check”.

They are not being rude. Put yourself in their place: a stranger has been brought in by senior management to do work that their own team should arguably be doing.

Palantir likens the job of a Forward Deployed Software Engineer to being the CTO of a startup: a small team, end-to-end responsibility, and often working on site with the client. With a remit like that, you will be doing exactly the work that belongs to the IT team.

Even when a client likes you, they still see you as an outsider. First Round Review recounts that the General Counsel of a Fortune 100 company affectionately called the engineers Ironclad sent over “The Backpacks”. The name sounds friendly, but the point is that people who arrive with backpacks will leave with them too.

Why can’t you do the job without them?

You can route around the IT team by asking the project sponsor in leadership to lean on them. That backfires quickly. A former Palantir FDE recruiter told First Round Review that what you find on site will be very different from what was sold in the contract.

OpenAI’s head of forward deployed engineering said much the same to The Pragmatic Engineer: what the client describes during scoping often does not match the real data and systems.

The people who know where that gap lies, such as which table holds junk data or which job runs at 2am and locks a table, are almost always the IT team.

Push them out and you lose exactly the source of information you need most.

So the question is not how to get past the IT team. It is what they are afraid of, and how you answer that fear.

Change the story: you are here to leave

IT teams usually fear two things. They fear being replaced, and they fear being left with a system they do not understand, so that when it breaks at midnight they are the ones who carry it. Both fears have the same answer.

A guide to FDE project handover on Simpliaxis sets a clear goal: the client’s team must be able to run and extend the system without needing to contact you.

The article also turns the usual view around: making yourself unnecessary does not reduce your value; it is the proof of it. A CIO.com piece on FDEs in the age of agentic AI likewise advises designing for the transfer of ownership up front, so the client’s team can operate and scale the system.

When you say this at the first meeting and act accordingly, you are no longer someone who has come to take their place. You become the person helping them own a new system.

Example: an inventory agent and a four-person IT team

Imagine you are deploying an agent that answers inventory questions for a retailer. The agent has to read data from an ERP system managed by a four-person IT team. There are three things to do, in order.

Step one: a 30-minute meeting before writing a line of code. Do not open by asking for access. Ask about the real system: “Is the inventory table updated in batches or in real time? The last time the numbers were wrong, why? Is there anything on the system you don’t want anyone to touch?” The last question matters most, because it gives them the right to draw the boundaries.

End the meeting with a commitment: “By the end of the project, your team should be able to fix and extend this agent yourselves without calling the vendor. The schedule will be designed around that goal.”

Step two: bring security in during week one. The CIO.com piece stresses that governance in agentic AI cannot be a compliance checklist checked at the final step. ElevenLabs writes that for its FDE team, security, data control and regulatory compliance are mandatory from the outset.

So bring a one-page description of the data flow: which three tables the agent has read-only access to, where the logs live, and whether prompts contain customer data.

Let the security team strike out whatever they like. A change requested in week one costs a few hours; if it arrives in the final week, it can block go-live altogether.

Step three: design and code together. The Simpliaxis guide sets out three concrete practices: invite the client’s engineers into design decisions, pair-program with them during the build, and explain your reasoning as you work. ElevenLabs describes its FDEs working side by side with the client’s technical team, inside the client’s own infrastructure.

In the inventory example, this means a decision log in the shared repo, plus two pairing sessions a week, each with a different member of the four-person team. A log entry can be as short as this:

D-03: Cache inventory query results for 15 minutes
Reason: avoid calling the ERP directly every time the agent answers
Rejected option: read the inventory table directly in real time
Decided together with: [client engineer's name]
To change it, edit: the cache config file, the IT team can do it themselves

The “decided together with” line is the most valuable detail. It turns your decision into a shared one, and tells future readers whom to ask once you have left.

The Simpliaxis guide explains why this works: engineers who build alongside the client’s team hand over continuously throughout the project, so the final handover is very small. By the last week, there is no three-day “handover training” left to run.

What wording calms an IT team down?

Most of the defensiveness starts with how you open. You can still ask for exactly what you need; just change how you say it:

Instead of saying	Say
“Give me admin access to the ERP so I can move faster.”	“I only need read-only access to these three tables. Is there any you think should be left out?”
“I’ll handle this part, you don’t need to worry about it.”	“Let’s pair on this part, since your team will be the ones maintaining it.”
“Demo for leadership on Friday.”	“Let’s do a dry run with the IT team on Thursday, then present it together on Friday.”
“Security can wait for a later phase.”	“Here is the data-flow diagram; could the security team review it before we build?”

Five mistakes that turn allies into blockers

The most common mistake is taking a shortcut through the project sponsor whenever IT is slow to respond. You win a ticket but lose the team. The second is asking for broader access than you need, because that confirms exactly what the security team fears.

The third is demoing to leadership without inviting the IT team, so they hear about a system running on their own infrastructure second-hand.

The fourth is writing code only you understand: no decision log, no runbook, everything in your head. The fifth is leaving security until the end, precisely what both CIO.com and ElevenLabs warn against.

How does this skill go on a CV?

When reading FDE job descriptions, look for phrases such as “work side-by-side with technical teams”, “handoff” or “enablement”. If they appear, it signals that the company cares about handing over to the client, not just building.

For interviews, have a story ready about a time you brought a wary team into the work. Be specific about what you asked at the first meeting, when you brought security in and whom you paired with.

On your CV, write about the outcome of the handover: how many engineers the client team had, how long after you left they were running the system on their own, and which features they added themselves.

Those numbers must be your real ones. They map directly onto the goal that FDE handover guides set: the client’s team runs and extends the system without you.

The final measure is simple. The system is still running after the day you shoulder your backpack and leave, and the person maintaining it is the lead who sat with folded arms at the first meeting.