FDE vs implementation engineer: the line is the first line of new code

By the second week of the project, the configuration sheet is filled in, users have accounts and the sample data is loaded. Then the customer asks a question that no field on the admin screen can answer. Who handles that question, and how, tells you whether you are doing the job of an implementation engineer or of an FDE.

The two roles are easy to confuse, because both sit with the customer and both get software running.

But one works inside the limits of the product, and the other is paid to go beyond them. Understanding where that line falls helps you take on the right work during a project, and apply for the right role when you want to change careers.

Same client office, different tools

Rocketlane, a platform for professional services teams, describes an implementation engineer as someone who executes a predefined playbook: configure, set up, then hand over. FDE Academy, a commercial training site and so worth reading selectively, puts it more bluntly: they mainly use the product’s existing configuration tools rather than writing new code.

TechTarget draws the same distinction: SaaS implementation teams install, configure and customise a core product, while FDEs build bespoke software for a customer’s needs.

Rocketlane sums up the practical boundary in one sentence: FDEs are called in when the playbook is no longer enough. So what decides who takes the work is the type of problem to be solved, not the seniority of the person doing it. If the problem fits within what the product was already designed to do, following the playbook is the fastest and cheapest route.

When the problem falls outside the playbook, the nature of the work changes entirely. TechTarget treats FDE as a software development model rather than just a job title: the engineer is embedded with one customer and spends all their time on that customer.

People in this role must be able to write both quick prototypes and platforms that run in production at scale. SD Times describes the sequence: understand the customer’s needs and capabilities in full, then build the solution yourself. Teams are small too, usually no more than six specialists.

One project, two forks in the road

Picture a company that sells warehouse management software, rolling it out for a retail chain. The requirements list after discovery has four lines. The first task is to classify each line, before anyone opens an editor.

Customer requirement	Configurable?	Who takes it
Create a warehouse per branch, with role-based permissions	Yes, the admin screen supports it out of the box	Implementation engineer
Load the initial product catalogue from CSV	Yes, there is already an import tool	Implementation engineer
Sync stock from the legacy ERP, which only exports fixed-width files, every 15 minutes	No, the product has no connector for this format	FDE
Reorder rules based on the chain’s own seasonal patterns	Partly: minimum thresholds yes, seasonal logic no	Needs splitting

The first two lines are playbook work. Doing them in code would be wrong, because the customer would then have to maintain something the product already does. The third line is where the playbook runs out, and it is the clearest example of an FDE writing new code for exactly one customer.

The fourth line needs the most thought. The right approach is for the implementation engineer to configure the minimum thresholds with the existing tools, while the FDE writes only the seasonal logic the product lacks. A single requirement often contains both kinds of work, and the skill lies in separating them.

New code has to survive after you leave

For the third line, the first version might be only a few dozen lines. The snippet below is an illustrative sketch, not taken from any real project:

FIELDS = [("sku", 0, 12), ("warehouse", 12, 18), ("qty", 18, 26)]

def parse_line(line: str) -> dict:
    row = {name: line[start:end].strip() for name, start, end in FIELDS}
    row["qty"] = int(row["qty"] or 0)
    return row

def sync(path: str, client) -> int:
    with open(path, encoding="latin-1") as f:
        rows = [parse_line(l) for l in f if l.strip()]
    # upsert on (sku, warehouse): re-running the same file does not double the stock
    client.upsert_stock(rows, key=("sku", "warehouse"))
    return len(rows)

This runs within an afternoon, and that is the prototype part. TechTarget says only that FDEs must be able to write things that scale and deploy to production. For this sync, the production part means: re-running it does not corrupt data, a line that fails to parse gets logged, and an alert fires when the file has not arrived for 15 minutes.

The code carries a single comment, placed right beside the upsert key, the spot most likely to go wrong. The reason is that whoever takes over will need to know why the code was written that way.

Three questions before the first line of code

The first is whether the product has any tool that can do this job, even inelegantly. Ask the implementation engineer or read the configuration documentation first. If the answer is yes, your code is just a new piece of maintenance debt.

The second is which part can be configured and which cannot. As the fourth line above shows, the answer is often “partly”. Write that boundary down in one sentence and send it to both sides before starting work.

The third is who will run this code after you leave the project. Implementation engineers finish with a handover, and FDEs must hand over too; it is just that what gets handed over is code rather than a configuration screen. If you cannot yet answer this question, stop at the prototype.

Common mistakes on both sides

A common mistake on the FDE side is writing code for something that can be configured, simply because writing code is faster than reading the product documentation. The result is that the customer has two mechanisms doing the same job, and the one you wrote is likely to break at the next product upgrade.

The opposite mistake belongs to the implementation side: forcing configuration tools onto a problem they were not designed to solve. When you find yourself stacking three or four workarounds to imitate a connector, that is the sign the playbook is no longer enough and it is time to call in an FDE.

The third mistake is treating customer code as something you write and then leave behind. An FDE is attached to one customer, but the code will keep running long after you have moved on to another project.

Read the job description to know which role you are applying for

Palantir’s Forward Deployed Software Engineer posting is an easy example to read. The responsibilities section spells out developing custom applications for customer needs. The requirements section asks for a strong coder, proficient in Python, Java, C++, TypeScript/JavaScript or a similar language. FDE Academy also says the FDE role requires full software engineering ability.

Compare that posting with the one for Deployment Strategist, the non-coding role in the same group at Palantir, and you will see the verbs change completely. The focus there is presenting results and scoping new projects in new industries and markets, not building software.

When reading any job description, count the verbs: build and develop lean towards FDE, configure leans towards implementation engineer, and scope is the verb of strategist roles such as Deployment Strategist.

Your CV should be written along the same line. A bullet like “rolled out the product for 5 customers” does not tell a recruiter whether you wrote code. Use this pattern instead: which requirement fell outside what the product could do, what you wrote, and where it is running in production.

If you are an implementation engineer and want to move into an FDE role, the shortest path is usually not asking for a new title. Watch for the next time the playbook is no longer enough, raise your hand for that piece of work, and write the code so that someone else can take it over.