How to Become a Forward Deployed Engineer: What the Role Does, What It Takes and a 30-Day Plan

In short: A forward deployed engineer (FDE) works inside a customer's operation and, with what they learn about the business, builds systems that run in production. The job has three moves: understand how the work happens today, decide where intelligence goes and build the system that joins the two. At Puente OS we call this role Growth Ops. To get there, take one real process from discovery to production: in 30 days you end up with a complete case study.

Today any retailer in Santiago, Lima or Mexico City can buy the same artificial intelligence as its competitors, on the same day. The difference between two companies shows up afterward: which processes that intelligence goes into, under which rules, and who takes charge of putting it to work.

That person is the forward deployed engineer. At Puente OS, the platform that builds the systems that run your business, we call the role Growth Ops, and it sits at the center of how we work with retail, eCommerce and logistics companies in Chile, Peru and Mexico.

I'm Cris Ugarte, CEO and co-founder of Puente OS. My business partner, Octavio Flores, and I did this work at Walmart Chile before we knew what it was called: we spent our days copying data between systems that didn't talk to each other, and we built the first version of Puente OS as an internal tool so that work would run on its own. This guide sums up what we learned along the way and how we train the people who do this work today.

What is a forward deployed engineer?

A forward deployed engineer is an engineer embedded in a customer's operation, with access to its systems and to the people who do the work, who is accountable for technology solving a real problem in production. They measure success in the customer's business: hours recovered, errors avoided and volume the team can absorb.

The term comes from Palantir. On its engineering blog, the company separates two roles: the product engineer, who builds one capability for many customers, and the forward deployed engineer, who takes one customer and combines many capabilities to solve its problem.

With the arrival of large language models, the title spread across the AI industry. The labs that sell models and the startups building on top of them hire people with this profile to carry the technology from the demo into their customers' daily operations.

Why is the forward deployed engineer one of the most in-demand roles?

The forward deployed engineer is one of the most in-demand roles because intelligence got cheap and implementation became the bottleneck. The cost of using a model at GPT-3.5's level fell more than 280-fold between November 2022 and October 2024, and most companies' AI projects stall before they reach production.

Three data points show it:

• Intelligence got cheap. Stanford's AI Index 2025 found that querying a model that performs like GPT-3.5 went from $20 to $0.07 per million tokens over that period.
• Projects stall along the way. According to S&P Global Market Intelligence, 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before, and on average they scrapped 46% of their proofs of concept before production. The obstacles they cited were cost, data privacy and security risks.
• The market put a price on the role. In June 2025, Joe Schmidt of a16z called the FDE the hottest job in startups. In April 2026, job postings for the role grew more than 729% year over year, with an average base salary of $171,911 in the United States, according to Indeed data published by LeadDev.

The takeaway fits in one line: you buy the intelligence, and you implement the advantage. What separates one company from another is where, how and for what it puts that intelligence to work, and the forward deployed engineer is the one who makes those calls.

What does a forward deployed engineer do day to day?

A forward deployed engineer does three things, in order. First, they learn how the work happens today, with its tools, people and exceptions. Next, they decide which part of the process runs on rules, which needs an AI model and which stays with a person. Finally, they build the system, put it in production and answer for how it performs.

1. Learn how the work really happens

The written procedure describes the official version of the process. The real operation lives in the screens, spreadsheets and chats of the people who run it, and that is where the complexity to solve sits.

An illustrative example, built from patterns we see often in eCommerce: reconciling marketplace payouts. The procedure says "download the settlement report and match it against sales." When you sit next to the person who does it, the real process shows up:

• Every marketplace settles in its own format and on its own calendar, and one of them changed the report's columns two months ago.
• The commission depends on the product category, and partial refunds show up in settlements weeks later.
• Reviewed sales get color-coded in the master spreadsheet, and that file is the record the whole team checks.
• When an amount doesn't match, it gets sorted out over WhatsApp with someone in finance, and the rule applied stays in that person's head.

At Puente OS, discovery starts with two questions: "Show me how you do this, step by step" and "What happens with the exceptions?" The first reveals the real process. The second, the complexity the procedure hides. That discovery is half the job, and it's done by a person sitting next to whoever runs the process.

2. Decide where intelligence goes

Each step of the process gets the piece that fits it:

• A rule, when inputs and criteria are predictable: matching a payment to a sale by amount and date, assigning a courier by zone and cost.
• An AI agent, when the goal is clear and the input varies: reading a customer email, interpreting a PDF, classifying a claim.
• A person, when the decision carries ambiguity, accountability or consequences that are hard to reverse: approving an off-policy discount, settling a large dispute with a supplier.

In the reconciliation example, the download and the match by amount and date run as a workflow with rules. An agent reads the marketplace emails that explain an adjustment and proposes which sale it belongs to. The finance person decides the differences above the tolerance, from a screen that shows the candidate sales.

Almost everything a company runs is predictable, and a workflow with a business rule handles it. The AI model comes in where interpretation is needed. At Puente OS this gets built with four pieces: workflows for repeatable work, agents to interpret, apps for the team to decide and databases for context. It's the discipline we call autonomous operations design.

3. Build the system that joins both worlds

The forward deployed engineer builds on the systems the customer already has: their ERP, storefront, marketplaces and couriers stay in place. The system reads from them, crosses the information, executes the clear cases and writes each action back where it belongs, with a record and rollback. That's what we call a system of action.

From go-live on, the operation depends on that system to ship, collect or respond. That's why the FDE stays after launch: measuring, fixing and answering for the result.

What skills does a forward deployed engineer need?

A forward deployed engineer combines business judgment, to know which problem is worth solving and how to measure its value, with technical judgment, to build a system that works with the customer's real data and systems. Their value shows up when both halves work on the same process.

Business judgment

• How the operation makes and loses money: margin per product, cost per order, delivery promise.
• Who decides, who executes and what incentives each of them has.
• What risk each decision carries and which ones can be undone.
• How a team adopts a new tool, and what sends it back to the spreadsheet.
• How value gets counted: hours, errors, cost and volume.

Technical judgment

• How an ERP, a storefront, a marketplace and a courier store information.
• The ways systems connect: APIs, webhooks, FTP files and exported reports.
• An operation's data: what an order, a line item, a shipment and a payment are.
• When a language model helps and when a rule is enough.
• How a system gets tested, how it fails and how it recovers.

The people who do this job best come from operations, consulting, product or engineering, and they learn the missing half in the field.

At Puente OS, the technical half weighs differently. Growth Ops builds with Puente Studio: they describe in plain language what the process needs and get apps, workflows, databases and agents running. That opens the role to people who come from operations and know the business from the inside. It's also why a single person can carry a whole customer's software operation: at a Mexican multichannel electronics seller, one person built 20 apps and 75 processes in ten months.

How does Growth Ops work at Puente OS?

Growth Ops works in three phases: the Diagnosis maps and prioritizes processes, the Sprint puts one live in production in 2 to 4 weeks and the Partnership runs it, measures it and adds the next one. Each phase starts from what the previous one left behind. For new customers, the Diagnosis and the first Sprint fit into a one-month pilot.

Diagnosis: find the process worth redesigning

The Diagnosis decides what gets built before anyone builds. Growth Ops sits with the people who run each process and writes down every step: tool, time, person and frequency. Then, for each process, they write four things: its trigger, the information it crosses, the rules for the clear cases and the owner of each exception.

Next they classify it with our process taxonomy, I/T/O/C/BP: where the data comes from (input), what happens to it (transformation), how the result is delivered (output), which integrations it needs and which of ten business process types it belongs to: orders, pricing, customer communication, catalog, finance, sales, marketing, logistics, inventory and operational intelligence. We built it from more than 200 meetings with commerce companies, and it shows that most processes are variations on the same patterns. So every Diagnosis starts from what we've already seen at similar companies.

The deliverable is a prioritized map: the classified processes, their impact measured in hours and transactions, and the first process headed to the Sprint. Start with one that has volume, repetition, team hours tied up in it and a return visible in under 90 days.

A tip that saved us weeks: ask for production access in the first week. A vendor's test environment behaves differently from production, and finding out on go-live day is expensive.

Sprint: build, test and go live

In the Sprint, Growth Ops builds the process on the customer's systems and puts it live in production in 2 to 4 weeks. Before trusting it, they test it on real cases: the typical ones, the rare ones, the ones that arrive with incomplete or contradictory data and the ones that involve a lot of money or a key customer. The correct answer for each case is written by whoever knows the process best, and every result is recorded.

The Sprint also sets the operating rules: what always goes to a person, what happens when data is missing and what happens when a system doesn't respond.

The first version ships with a person approving. We learned this at a logistics operation: when the system makes the decision from day one, the team distrusts it and goes back to the spreadsheet. When the system proposes and the coordinator approves, rejects or comments, trust gets built on evidence, case by case.

Partnership: run it, measure it and add the next one

With the process in production, Growth Ops runs it alongside the customer's team. Every action is logged, runs within the company's rules and approvals, and can be rolled back to the previous version. Rule changes go through the team's approval before reaching production.

The core metric is the human intervention rate: the share of cases that needed a person to do something. Autonomy grows with that evidence: when a type of case goes weeks without corrections, the system takes it over.

The result shows up in the operation. At the Mexican multichannel seller, generating shipping labels took 5 to 7 hours per cutoff, twice a day. Today a cutoff takes 15 minutes, and 97.9% of orders ship with their label without human intervention.

Every process solved brings the next bottleneck into view, and what's already built speeds up the next one. At a Chilean pet retailer, the time from requesting a use case to seeing it in production went from 105 days for the first one to 7 for one in July 2026. That's how an operation can grow 2 to 5 times without multiplying headcount.

How do you become a forward deployed engineer in 30 days?

To become a forward deployed engineer in 30 days, take one real process end to end over four weeks: map it, build the first version, test it on real cases and put it in production with controls. Each week leaves a deliverable, and by day 30 you have a case study that proves you can do the job.

Pick a real process: your company's, a nearby business's or a client's. The plan runs alongside your job or your search, and it works with whatever tool you have at hand. At Puente OS we do it with Puente Studio.

Week 1 (days 1-7): map a real process

1. Pick a process with volume, repetition and hours tied up in it: generating shipping labels, reconciling payments, syncing inventory across channels or answering "where's my order?".
2. Sit with the person who runs it and ask them to show you, step by step, on their screen.
3. Write down every step: tool, time, person and frequency.
4. Write the current design: the trigger, the information it crosses, the rules for the clear cases and the exceptions.
5. Measure for a week: how many cases, how many hours and how many errors.

Day 7 deliverable: a map of the current process and its cost in hours.

Week 2 (days 8-14): design and build the first version

1. Decide step by step what runs on rules, what needs an agent and what stays with a person.
2. Connect the data sources through whatever each system offers: API, file or exported report.
3. Build the flow end to end on real data, in a test environment.
4. Give the person a screen to decide exceptions, with the context in view.
5. Log every action: what came in, what the system decided, what it did and when.

Day 14 deliverable: a flow that runs end to end and logs every step.

Week 3 (days 15-21): test and measure it

1. Collect real cases and, with whoever knows the process best, write the correct answer for each one: typical cases, rare cases, cases with incomplete or contradictory data and cases that involve a lot of money or a key customer.
2. Run the system on those cases and record every hit and every miss.
3. Group the failures by type: missing data, match against the wrong sale, badly written rule, system down.
4. Set the operating rules: what always escalates to a person and what happens when a system doesn't respond.
5. Measure the cost and time of each run.

Day 21 deliverable: an evaluation report with the accuracy rate, the failure types and the cost per run.

Week 4 (days 22-30): go live and defend it

1. Go live with human approval: the system proposes and the person approves each action.
2. Turn on alerts and a rollback to the previous version.
3. Write the business case: hours recovered, errors avoided, cost, risk and what stays in people's hands.
4. Present it to the person who runs the process, with the detail of how it works, where it fails and what you changed in each version.
5. Present it to the person who approves or pays for it, on one page: problem, result, evidence and risk.

Day 30 deliverable: a complete case study that both the person who runs the process and the person who approves it can read.

Where to focus depending on your background

• If you come from operations or consulting, you already have the business half. Focus on weeks 2 and 3: learn how each system stores its data and how to test what you build.
• If you come from engineering or product, you already have the technical half. Focus on week 1: spend hours with the person who runs the process and learn how the operation makes and loses money.

What sets a good forward deployed engineer apart?

A good forward deployed engineer shows in their habits: they measure before building, write the rules with whoever knows the process best, ask for production access in the first week, give every exception an owner, add autonomy based on evidence and count results in hours, errors and cost.

• Measures before building. A week of measurement gives the project its baseline and its business case.
• Writes the rules with whoever knows the process best, in words anyone on the team can read.
• Asks for production access in the first week.
• Gives every exception an owner: the system resolves it, or it reaches a named person.
• Adds autonomy based on evidence: ships a scoped first version with human approval and gives the system more authority as it racks up resolved cases.
• Counts results in the language of the business: hours, errors, cost and volume.

How does it compare with a consultant, a solutions engineer or a product engineer?

Each role covers a different stretch of the path between the problem and the system in production. The consultant recommends, the solutions engineer designs the solution during the sale, the product engineer builds capabilities for many customers and the forward deployed engineer builds for one customer, puts the system in production and answers for the result.

• Consultant: diagnoses and recommends, and the customer's team executes.
• Solutions engineer: designs the solution and the demo during the sale.
• Product engineer: builds capabilities that many customers use.
• Forward deployed engineer: takes one customer, builds the system on its operation, puts it in production and answers for the result.

At Puente OS, Growth Ops covers the whole path: they diagnose, build with Puente Studio, go live and run the process alongside the customer's team.

Key takeaways

• A forward deployed engineer works inside a customer's operation and, with what they learn about the business, builds systems that run in production.
• The role became one of the most in-demand because intelligence got cheap and implementation became the bottleneck.
• The job has three moves: understand the real process, decide where intelligence goes and build the system on what already exists.
• It takes two kinds of judgment: business and technical. At Puente OS, Growth Ops builds in plain language with Puente Studio, which opens the role to people from operations.
• At Puente OS the work runs in three phases, Diagnosis, Sprint and Partnership, with a process live in production in 2 to 4 weeks.
• The 30-day plan takes one real process end to end and ends with a complete case study.

---

Want to see this work in your operation? We begin with a one-month pilot: that month covers the Diagnosis and the first Sprint, and your first process goes live in production. If you continue, what you invested in the pilot is credited toward implementation. Book a demo with Puente OS.

Want to do this work? If you've built your case study with the 30-day plan and want to talk it through, write to me at cugarte@getpuente.com.