FDE vs Technical Account Manager: who fixes the system and who talks to the customer when things break

Picture this: on the eve of the biggest sale of the year, the order-processing system you deployed for a customer starts returning errors. The incident channel has two people from the vendor side. One opens a terminal; the other opens the contact list to call the customer’s head of operations.

If both open a terminal, nobody tells the customer what is happening. If both pick up the phone, nobody fixes the fault. The line between a Forward Deployed Engineer and a Technical Account Manager (TAM) sounds like a matter of job titles, but the difference shows most clearly on nights like that.

If you work as an FDE, understanding the TAM role tells you when to hand the phone to someone else and get back to the code. If you are a TAM who wants to move into FDE work, you need to know exactly which skills you are still missing.

Where do the two roles differ?

A role comparison on fde.academy puts it briefly: FDEs build and deliver; TAMs coordinate and advise. More specifically, a TAM can read code but rarely writes production code, while an FDE writes production code every day.

According to the same blog, a TAM’s strength comes from the depth of the customer relationship and the ability to coordinate across departments, not from personally delivering technical work.

The working rhythm differs too. A TAM stays with a customer for the long term, with quarterly business reviews. An FDE works in deployment engagements lasting from a few weeks to a few months.

Christian & Timbers, an executive search firm, stresses that an FDE’s responsibility does not end when the customer signs the contract; it extends until the system runs in production and delivers measurable results.

AWS offers an easy example of the TAM role. It states plainly that a designated TAM is a benefit of its Enterprise Support plan. The TAM, in other words, comes with a paid support package; it is not an engineer working inside the customer’s systems.

The blurriest line is the incident

The two roles share one important trait: both handle customer escalations and feed input back to the product team. That is why, during an incident, it is easy for both to rush at the same task.

AWS describes fairly clearly what a TAM does during a critical business event. Beforehand, the TAM works with the customer to check that the system is ready and can handle the expected load. During the event, the TAM supports the customer.

According to the Enterprise Support page, the TAM coordinates AWS specialists, keeps track of the overall picture and leads the post-event review to identify areas for improvement. The AWS Countdown programme calls this kind of support “TAM-led”.

On the FDE side, there is an example from Palantir, where the role was born. The company has a variant called Forward Deployed Enablement Engineer, who works in a centralised customer success team.

The job posting requires this person to act as first responder when incidents occur and to be on call 24/7 for critical customer incidents. Their job, put simply, is to keep the customer’s systems running.

Example: one sale, two to-do lists

Back to the sale night at the start. Suppose you are the FDE who deployed an agent that automatically handles return requests for a retail chain, and your TAM colleague has looked after this customer for years. The table below suggests how the two might split the work.

Phase	FDE does	TAM does
Two weeks before	Runs load tests at expected traffic, fixes bottlenecks, writes the runbook	Checks readiness and expected load with the customer, confirms who on the customer side has decision authority
During the incident	First response: reads logs, rolls back or patches, writes technical updates	Pulls in internal specialists when the FDE needs them, keeps the customer’s leadership informed
After the event	Writes the root-cause analysis, ships the long-term fix to production	Leads the post-event review, collects feedback for the product team

The part most likely to break is the hand-off of information between the two during the incident. One effective approach is for the FDE to send the TAM a three-line update at fixed intervals, for example:

Broken: 30% of return requests are timing out at the inventory API call.
Doing: rolled back this afternoon's deploy, monitoring the error rate.
Next update: 23:30.

The TAM turns those three lines into the language the customer’s leadership needs to hear: the impact on shoppers and when the next update will come. The FDE does not have to leave the terminal to join calls, and the TAM does not have to promise a deadline without asking the person doing the fixing.

Do it yourself: assign roles before anything happens

Start while things are calm. Write down who owns the system and who owns communication with each person on the customer side, then send it to both teams. If your company has no TAM, the communication owner might be the account executive or your team lead. What matters is that a specific person’s name is on it.

Next, agree on the update cadence and message template before the event, rather than debating them mid-incident. Before each customer peak, schedule a readiness review. The FDE brings the load-test figures; the TAM brings the list of customer stakeholders who need to be notified.

After the event, sit down together before sending anything to the product team. Because both roles feed input back to product, one joint analysis carries more weight than two separate emails describing the same fault in two different ways.

Common mistakes

An easy trap for an FDE is to take on the TAM role as well: sitting in meetings with the customer’s leadership while the fault is still unfixed. The TAM’s opposite mistake is promising the customer a fix time without asking the person reading the logs. Both mistakes come from not assigning roles in advance.

The third mistake is treating the TAM as a lighter version of the FDE. The two roles rest on different strengths: relationships and coordination on one side, production code on the other. Someone good at one is not necessarily good at the other.

How to read job descriptions and write your CV

When reading a job posting, watch the phrasing. Phrases such as “quarterly business review”, “designated” or “relationship” suggest the role leans TAM. “Production code”, “on-call” or “first responder” suggest it leans FDE, even when the role sits within a customer success team, as in Palantir’s case.

On your CV, do not just write “worked with customers”. Describe an incident you handled directly: what you fixed, how long the system took to recover, and which long-term fix reached production.

If you are a TAM who wants to move into FDE work, the missing piece is usually evidence that you have personally shipped code to production, so take on a small patch during the next escalation instead of passing it all to the engineering team.

A good vendor needs both roles on the night of an incident. As long as each person knows their job in advance, the customer will see the system restored and receive updates on time.