# Chapter 2: Boundaries with Adjacent Roles

## Lesson objectives

- **O1** Can compare FDE, solutions architect and implementation consultant against the same dimensions (artifact: adjacent-role responsibility matrix)
  - Evidence: The adjacent-role responsibility matrix fills three parallel columns for FDE, solutions architect and implementation consultant using the same dimensions
- **O2** Can construct a adjacent-role responsibility matrix whose columns use the same questions and evidence standard (artifact: adjacent-role responsibility matrix)
  - Evidence: Every column in the adjacent-role responsibility matrix includes one reviewable fact and one open question
- **O3** Can divide FDE, solutions-architect and implementation-consultant ownership for one customer event (artifact: adjacent-role responsibility matrix)
  - Evidence: The artifact assigns ownership, handoffs and gaps for all three roles in one customer event

## Learning paths

- **Novice**: Chapter transfer task: Can divide FDE, solutions-architect and implementation-consultant ownership for one customer event. Use the diagram's comparison relationship to complete the first evidence item in the adjacent-role responsibility matrix, then check each owner and decision rule.
- **Experienced**: Apply this task to a current project before reading the explanation: Can divide FDE, solutions-architect and implementation-consultant ownership for one customer event. Submit the adjacent-role responsibility matrix, then check the relationship type, missing evidence and authority boundary.

## Teaching diagram

- **Required artifact**: adjacent-role responsibility matrix
- **Diagram kind**: role-comparison
- **Relationship semantics**: The three columns are parallel comparisons against shared dimensions; their order conveys neither process sequence nor maturity.
- **Core concepts**: FDE · solutions architect · implementation consultant

![Chapter 2 teaching diagram for the adjacent-role responsibility matrix](/learning/diagrams/en/chapter-02.svg)

Read the adjacent-role responsibility matrix across shared dimensions, compare differences, and only then make a choice.

The diagram places FDE, solutions architect and implementation consultant in three parallel columns crossed by a shared comparison line. The columns have no sequence or rank; read each row against the same dimension before recording a choice and reservation.

> **Adapted public course.** Concepts, procedures and examples are adapted from the internal textbook. Case sizes, timings, improvement figures and target thresholds are illustrative, not site delivery results or universal standards. Verify tools, platforms and skills in your environment. Prompts do not grant permissions and retry counts do not authorize recovery. Preserve work and verify targets, sharing and external-state effects first.

## Lesson explanation

### 2.1 Why Boundaries Matter

Chapter 1 defined FDE through four elements: embed at the customer site, write production code on customer infrastructure, own the entire process, and answer for customer outcomes. A definition is only the beginning. In an actual workplace, at least three groups of close relatives surround you: consultants; Solutions Architects (SA) and Solutions Engineers doing presales advisory work; and internal AI/agent product engineers. Titles vary by company. Capitalization does not create a separate solutions-engineer role confined to internal products. This chapter compares work modes: Section 2.3's SA/FDE facts are specific to the cited OpenAI interview, while Section 2.4 separately discusses internal product engineering. Their daily actions overlap with an FDE's: meeting customers, discussing technology, designing solutions, and potentially writing code.

That similarity creates the danger. Blurred boundaries most often lead not simply to extra work for another role but to doing FDE work using another role's methods: responding to customer needs like a consultant, starting with a thick proposal; judging success like presales, stopping once the demo passes; or coding like an internal engineer, checking that it runs without asking who at the customer can actually use it. Each deviation seems harmless alone. Together they silently replace accountability for customer outcomes with accountability for delivery activities.

This chapter draws the boundaries group by group. The tests remain Chapter 1's three questions: Do you write customer production code? Own the end-to-end process? Answer for customer outcomes? Add a question specific to the AI era: Does field experience feed back into your own product? After three comparisons, a consolidated table, and a scenario self-check, you should be clear about what work you are and are not doing.

### 2.2 FDE versus Consultant: Rapid Composition, Not Patchwork

Outsiders confuse this pair most readily. Palantir's official FDSE blog Q&A directly asks, "Is an FDSE similar to a consultant?" Its blunt answer is, "No, not really." Two statements capture the distinction:

- The consulting model works through large, multiyear project portfolios, stitching customer situations into extended programs of work. Deliverables are largely analysis, plans, and recommendations.
- The FDE model sends small teams directly to the field, rapidly composing working systems from the platform's off-the-shelf capabilities so customers see results in weeks rather than years.

Neither model is inherently superior; they are different work. Multiyear transformation in large organizations, reconciliation of cross-department interests, and purely managerial diagnosis belong to consulting. FDEs should not sign them up as a miniature consultancy and work through them slowly. FDE value lies in using platform capabilities to compress work that would require an army of consultants into work for a few engineers and a platform. When that compression is impossible, telling the customer honestly that this is not your arena is more professional than signing a contract both parties will regret.

For an individual FDE, the boundary has an everyday measure: Does your calendar say "interview, write report, review" or "connect data, build system, launch"? The first tends toward consulting; the second is Forward Deployed work. Where existing platform capabilities can rapidly solve a customer's problem, the FDE response is to build it directly, rather than study it for three months.

### 2.3 FDE versus Presales/SA: Advisory Demonstrations versus Production Code

SA is the second close relative. At OpenAI, according to The Pragmatic Engineer's August 2025 interview with its FDE leader, SA and FDE are explicitly separate roles with visibly different working methods:

| | SA: presales / solutions engineer | FDE |
|---|---|---|
| Nature of the role | Advisory | Delivery |
| Data | Builds MVPs/PoCs with anonymized data | Connects real customer data |
| Where code runs | Almost never writes production code on customer infrastructure | Writes production code directly on customer infrastructure and toolchains |
| Ambiguity | Can select a demonstration path and contain ambiguity | Must absorb the customer's full reality, with substantially greater ambiguity |

Notice "almost never." SAs do write code, but in demonstration environments and PoCs: an anonymized dataset runs through an optimal path to prove that product capability is real. That work has real value; many contracts would never exist without the SA's PoC. The roles form a relay, not a competition: the SA wins the opportunity with a PoC; the FDE turns it into a system in customer production.

The handoff occurs precisely where ambiguity jumps. Demo data is anonymized, clean, and manageable in size. Production introduces actual legacy systems, permissions, data-quality problems, change windows, and on-call response. An SA can say the product supports a scenario; an FDE must explain how it runs in this customer's environment today and who fixes it when it fails. Between those answers lies Chapter 1's gulf between a working demo and a usable system.

The personal warning is simple: if your card says FDE but every quarterly output is a demo, PoC, or technical proposal, you are doing SA work. Conversely, the boundary tells you when to involve an SA. While the customer is comparing products and needs rapid validation on anonymized data, the SA is in their own arena. An FDE taking over that work is an expensive substitution.

### 2.4 FDE versus Internal AI/Agent Product Engineering: A Two-Way Product Feedback Channel

The third group is subtler: daily activities can overlap substantially. Writing prompts, building agents, running evaluations, connecting data, and debugging integrations can make internal AI/agent product engineers and FDEs almost indistinguishable by their code. The distinction is whom the work serves and where its value accumulates:

- Internal AI/agent product engineers primarily serve their own company. Systems run on company infrastructure, value accumulates in its product and codebase, and customers, if any, consume the results through an API.
- FDEs primarily serve the customer site. Systems run on customer infrastructure and value appears directly in customer business outcomes. They also maintain a feedback channel: codify field-tested patterns into reusable tools, playbooks, and templates that return to the company's product and model teams. OpenAI's FDE responsibilities explicitly include codifying reusable patterns; see the job description cited in Chapter 1's source note.

This two-way channel distinguishes FDE from senior outsourced on-site development. Serving only the customer without capturing reusable learning produces an expensive embedded outsourcing team that is unsustainable for the company. Building assets without going into the field makes you a product engineer. Healthy FDE practice always produces in both directions: production systems and business outcomes for the customer, field-tested patterns and building blocks for the company. Part Nine, Chapters 27-29, develops concrete mechanisms for this "outer knowledge loop."

### 2.5 A Consolidated Comparison

The three comparisons can be brought into one table across five dimensions: focus, code destination, time horizon, success criteria, and relationship to the company's product. This is a teaching comparison of modes, not a universal job-title rule. Verify actual team responsibilities, project authority, and acceptance objects.

| Dimension | Consulting work | Presales advisory work: Section 2.3's SA | Internal AI/Agent product engineering | FDE delivery work |
|---|---|---|---|---|
| Focus | Customer problems and recommendations | Sales opportunities and product demos | Own company's product and codebase | Customer business outcomes |
| Code destination | Generally no production code; delivers reports and plans | Demo environment, PoCs on anonymized data | Own infrastructure | Production code on customer infrastructure |
| Time horizon | Multiyear, multiple staffing tiers | Sales cycle: weeks to months | Product iteration cadence | Projects lasting weeks to months; small teams directly in the field |
| Success criteria | Recommendations adopted, reports accepted | Sales closed, effective demonstrations | Product metrics: adoption, performance, retention | Customer production adoption and business outcomes |
| Product relationship | Unrelated or third-party | Sells own product | Builds own product | Combines own product and customization to fill gaps, feeding field patterns back into the product |

Use this table to locate yourself, not to label other roles or rank their worth. On any working day, you can identify the column describing your center of gravity. Several consecutive weeks outside the FDE column signal role drift.

### 2.6 A Day in the Role: Scenario Self-Check

Finish with a self-check. These four realistic scenes describe an "FDE's day." Answer each question before reading the reference judgment.

Scene one: 10 a.m., customer executive meeting room. The CIO says: "This direction looks good. Give us a three-year roadmap. Start phase one with a consulting team for diagnosis, allocating person-months across three staffing tiers." You are the only engineer on site.

Question: Is this an FDE way of working? How should you respond?

Reference judgment: This is a typical consulting-style patchwork opening. The FDE response is to reframe the need, not reject it: identify goals that can be validated in weeks by composing working systems from existing platform capabilities, substituting actual results for a three-year paper roadmap. If the customer truly wants pure organizational-change consulting, draw an honest boundary: that is the consultant's arena.

Scene two: 2 p.m., customer data team. A data scientist asks: "Could you take a de-identified sample and build a PoC to show the business team?"

Question: Who should do this work, and how would you arrange it?

Reference judgment: A PoC on anonymized data is SA territory. Bring an SA colleague into the collaboration rather than spending two weeks yourself on a demo-grade prototype; your time belongs with real customer data and infrastructure. If the company has no dedicated SA, you may stand in, but recognize it as a temporary role and accept the work against SA criteria -- persuading the business team -- rather than FDE criteria of production adoption.

Scene three: 4 p.m., returning to the hotel. You realize that the customer's automatic ticket classification with human fallback is almost identical to a workflow at your previous customer.

Question: Who owns this discovery? What comes next?

Reference judgment: This is the entry to the FDE feedback channel. Codify the pattern into a reusable tool or playbook and return it to product teams and other FDEs through the company's field-knowledge mechanism, detailed in Part Nine. Quietly implementing it again misses the other half of the FDE responsibility beyond customer service.

Scene four: 8 p.m., weekly report. Every end-to-end flow works in the demo environment, and the demonstration video is ready. The customer's business lead replies: "Great. When will this reach our production environment?"

Question: What state is your project in now?

Reference judgment: It is at the endpoint of SA work and the starting point of FDE work. Passing a demo proves that capability is real. An FDE delivers a system on customer infrastructure with actual traffic and adoption data. Make production rollout the first priority of the next cycle rather than a footnote to demonstration success.

All four scenes lead to the same conclusion: boundaries are everyday work choices, not theoretical categories. Once exclusions are clear, the next question follows: as coding agents sharply reduce code-production costs, how will these boundaries move? Which parts of FDE work expand, and which erode? Chapter 3 takes up that question.

---

> Sources for the industry facts in this chapter: Palantir's official FDSE blog Q&A supplies "Is an FDSE similar to a consultant? No, not really" and the distinction between multiyear consulting patchwork and rapid composition with off-the-shelf platform capabilities. The Pragmatic Engineer's August 2025 interview with OpenAI FDE leader Colin Jarvis supplies the internal SA/FDE distinction: advisory SAs build MVPs/PoCs on anonymized data and almost never write production code on customer infrastructure; FDEs write directly on customer infrastructure and toolchains under greater ambiguity. OpenAI's public job description and that interview describe serving customers while feeding the company's product through codified reusable patterns. No additional industry statistics are cited; case timings and proportions are teaching assumptions. Titles alone do not determine boundaries: Solutions Engineers may cover different customer phases, and internal product engineers may join field research. Ask who maintains production, approves changes, and owns adoption and business outcomes; then verify this task's authority rather than assigning a handoff from a business card.

---

## Independent exercise

Use fictional or authorized deidentified material. Answer independently before revealing the reference. Save `chapter-02.md` with versions, decisions, evidence and gaps.

Make a three-row ownership table for a sales demo, a production incident and a product roadmap request: owner, collaborators, artifact and escalation.

<!-- chapter-artifact-requirement -->
### Required chapter artifact: adjacent-role responsibility matrix

The submission for this independent exercise must contain the evidence below. The existing prompts supply content but do not replace these acceptance items.

- O1: The adjacent-role responsibility matrix fills three parallel columns for FDE, solutions architect and implementation consultant using the same dimensions
- O2: Every column in the adjacent-role responsibility matrix includes one reviewable fact and one open question
- O3: The artifact assigns ownership, handoffs and gaps for all three roles in one customer event

<details>
<summary>Reveal reference feedback (answer first)</summary>

## Reference feedback

Sales and solution staff confirm demo commitments; on-call and system owners lead incidents, supported by FDE context; product owners decide the roadmap using reusable requirements and evidence. A title does not grant authority.

### Self-review and next steps

Check whether your decision is explicit, evidence reproducible and unknowns honestly recorded. The reference illustrates one defensible approach, not a unique answer. Seek peer review for alternatives with equivalent evidence. Mark unsupported parts unfinished and revisit the corresponding step.

</details>

## Sources and boundaries

Registered sources support only the external claims used here. The adjacent-role responsibility matrix, example numbers and exercise scenario are internal instructional design and require project-specific validation.

- [Forward Deployed Engineer role — San Francisco](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) — OpenAI, 2026-09-28. This OpenAI role covers discovery, scoping, design, build, rollout, adoption and field feedback; it is not an industry-wide standard.
- [Palantir: Dev versus Delta engineering roles](https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87) — Palantir, 2026-09-17. Palantir frames Devs as building one capability for many customers and Deltas/FDSEs as enabling many capabilities for one customer, distinct from one-off consulting.
- [FDE origins, role distinctions and OpenAI work phases](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers) — The Pragmatic Engineer, 2026-09-17. This interview reports FDE origins, OpenAI SA/FDE distinctions, three customer-project phases and team knowledge-sharing cadences; it is secondary interview evidence, not an industry standard.