# How do you work with a forward deployed engineer?

**A forward deployed engineer** brings field evidence into your product or platform team, but does not become a free extra engineer or an unofficial product manager. Their customer access can reveal urgent integration needs that no dashboard shows. Your job as host manager is to make that evidence usable, keep commitment authority explicit, and create a reliable return ritual after customer work.

        
## What is your responsibility as the host manager?

        
This arrangement is different from managing the forward deployed engineer as a direct report. Their actual manager owns performance, development, workload across customers, and career decisions. You own the conditions under which your product or platform team collaborates with them. That includes intake, technical review, roadmap decisions, and knowledge transfer.

        
Start by naming why the engineer is with the team. Perhaps a deployment exposed a missing identity integration, or several customers cannot operate the current setup. Define the question to answer and the time available. Without a bounded purpose, field access turns into a stream of urgent requests that bypasses normal product judgment.

        
Introduce the engineer as a source of customer and deployment context, not as the owner of every customer problem. The team should listen seriously without assuming that the loudest account defines the market. The engineer should be able to challenge assumptions without carrying authority that belongs to product, security, or platform owners.

        
## Why are they not a free extra engineer?

        
Their calendar contains travel, customer calls, environment debugging, and obligations to other deployments. A week that looks empty on your sprint board may already be committed. Ask for actual capacity and expected absence dates before assigning work. Never build a critical path on the hope that a customer week stays quiet.

        
Use their time where field context changes the solution. They might reproduce an integration failure, explain operational constraints, or pair on a deployment tool. Routine backlog work usually belongs to stable team capacity. Filling every gap with product tickets makes the organization feel efficient while starving the field role of its real purpose.

        
When they disappear for customer work, treat it as expected movement, not abandonment. Reassign active ownership before departure and identify which questions can wait. If an item cannot proceed without one person returning, that is a collaboration design flaw to fix.

        
## How should field requests enter the roadmap?

        
- Record the customer problem and affected workflow.
- Separate observed facts from the proposed feature.
- Name urgency, frequency, and contractual commitments.
- Identify the smallest safe product question.
- Assign a product and engineering owner.
- Decide using the normal scope authority.
- Tell the field engineer what happened and why.

        
This intake respects the field engineer without giving one deployment a private roadmap. An urgent integration request may be evidence of a broad product gap, a customer specific configuration, or a promise that should never have been made. The team needs enough context to distinguish those cases.

        
Close the loop even when the answer is no. Field engineers lose credibility with customers when requests vanish into a product queue. Give them a decision, rationale, owner, and next communication. They can then set accurate expectations instead of escalating the same issue through another channel.

        
## What may the engineer promise to a customer?

        
Create a written promise boundary. The engineer can usually promise investigation steps, factual updates, and work already approved for the deployment. New product scope, delivery dates, security exceptions, and support terms require named owners. List those owners and an urgent contact route.

        
Pressure at a customer site makes vague authority dangerous. A reasonable sounding statement such as we can add that next sprint may become a commercial commitment before your team even sees the request. The answer is not to make the engineer silent. Give them language that preserves trust, such as I will bring this evidence to the product owner and return with a decision on Friday.

        
If an unauthorized promise occurs, repair it with the customer and inspect the system. Ask what pressure, incentive, or missing route made the promise feel necessary. Correct the boundary directly, but do not leave the engineer alone to retract a commitment the organization helped create.

        
## Which owner handles each field signal?

        
| Field signal | Primary owner | Engineer contribution |
| --- | --- | --- |
| Reproducible defect | Engineering lead | Provides environment evidence |
| New product need | Product owner | Explains customer workflow |
| Security exception | Security owner | Documents constraint |
| Delivery promise | Commercial owner | States approved facts |
| Deployment pattern | Platform owner | Transfers field learning |

        
A signal can involve several owners, but one person should lead the decision. The forward deployed engineer is often consulted across all rows because they saw the environment. Consultation does not make them accountable for product balance, legal terms, or permanent system ownership.

        
Keep the table available in the intake document and update names before major customer work. An escalation route that points to a departed employee is not a route. Practice one realistic scenario so everyone knows how quickly an urgent decision can travel.

        
## How do you stop urgent context from wrecking the roadmap?

        
Urgency is data, not a complete priority. Ask what happens if nothing changes this week, which users are affected, whether a workaround exists, and what commitment was made. Compare that consequence with current roadmap work. A dramatic customer call may reveal real severity, but volume alone should not reorder the team.

        
Reserve a small, explicit path for field issues if deployments are a regular part of the business. A rotating engineer, a response budget, or a weekly triage can absorb legitimate needs without interrupting everyone. When demand exceeds the budget, leaders must choose what leaves the roadmap rather than asking the team to hide extra work.

        
Let the forward deployed engineer attend the decision without making them defend the customer as an identity. Their role is to provide evidence and correct misunderstandings. Product and engineering owners must weigh the portfolio and own the result.

        
## What should happen when they return?

        
Hold a return ritual within a day or two. Ask what changed in the environment, what surprised the engineer, which workaround was created, what promise was made, and which knowledge could affect other deployments. Capture decisions and artifacts while details are fresh.

        
Use demonstration and pairing rather than a travel story. If the engineer built a new integration path, an internal engineer should run it while the field engineer observes. Move scripts, configuration notes, and failure cases into owned repositories. Knowledge has transferred when someone else can use it, not when slides exist.

        
Close or route every open item. Product requests enter intake, defects receive owners, customer actions return to the account team, and reusable platform lessons enter normal planning. The return meeting should reduce dependence on the traveler, not establish them as the permanent narrator of the customer.

        
## How do you prevent an unofficial product manager?

        
Field engineers can become influential because they bring vivid evidence and fast answers. That influence is useful until the team starts waiting for them to choose scope, define market value, or approve designs. Restate that product authority remains with the named product owner and technical authority remains with the relevant engineering owner.

        
Invite disagreement between field evidence and roadmap assumptions. The product owner should explain how a decision was made, not hide behind title. The forward deployed engineer should explain what the customer actually does, not claim that one account speaks for all users. A healthy tension produces better judgment.

        
Measure the collaboration by reduced surprises and reusable learning, not by how many tickets the field engineer closes. Strong work may lead to a changed roadmap, a rejected custom request, a safer promise, or a deployment pattern the team can support without them next time.

        
## How should you handle a surprising integration demand?

        
Suppose the forward deployed engineer returns from a customer site with a request for a new identity provider before a scheduled launch. Start with the workflow they observed. Which users cannot continue, what configuration was expected, what workaround was attempted, and what date has real consequence? Keep the requested feature separate from the underlying problem.

        
Ask the platform team to reproduce the constraint with the engineer present. The cause may be a missing standard, a product defect, or a customer specific architecture. Each answer suggests different ownership. Reproduction also transfers evidence from one person's memory into artifacts the team can inspect.

        
Then make the roadmap tradeoff openly. If the integration is accepted, name what moves and who communicates the change. If a temporary adapter is safer, record who supports it and when it expires. If the request is rejected, give the field engineer a factual explanation they can use with the customer. Never send them back with a vague statement that engineering said no.

        
Watch for the emotional weight of the field. The engineer may have spent days beside frustrated customer staff and feel that delay is unacceptable. Respect that experience without outsourcing portfolio judgment to it. Ask them to describe consequences and uncertainty, then let the designated owners decide.

        
After the decision, improve the promise system. Perhaps sales material implied support, discovery missed an architecture question, or the engineer lacked an urgent intake route. Fixing that upstream gap is often more valuable than debating whether the field request interrupted the sprint correctly.

## What are common questions?

### Should a forward deployed engineer join the sprint?

Only for bounded work that benefits from field context and fits capacity already agreed with their actual manager.

### Can they promise product features to customers?

They should promise only what written authority allows and route new scope, dates, and exceptions to the named decision owner.

### How should urgent field requests be prioritized?

Record the customer consequence and evidence, then use normal product and engineering authority to decide what changes.

### What is a useful return ritual?

Review surprises, workarounds, promises, and open items, then transfer artifacts through pairing to named internal owners.

### Who owns the roadmap?

The product and engineering owners retain roadmap authority while the forward deployed engineer supplies essential field evidence.

Related: [working with people who are not your reports](https://isilta.com/blog/how-to-work-with-people-who-are-not-your-reports/), [working with a dotted line engineer](https://isilta.com/blog/how-to-work-with-a-dotted-line-engineer/), [working with an embedded consultant](https://isilta.com/blog/how-to-work-with-an-embedded-consultant/).