FDE vs. Solutions Architects and Other Customer-Facing Engineers
Distinguish the responsibilities of Forward Deployed Engineers (FDEs), solutions architects, and other customer-facing engineers by examining their actual contributions rather than relying on job titles. Assess ownership, implementation responsibilities, and the timing of involvement throughout the delivery lifecycle. Recognize the broad mandate of FDEs, including customer-facing solution delivery, production deployment, operational accountability, and contributions to core platform development. Differentiate these responsibilities from those of solutions architects, who typically focus on solution design and integration without necessarily owning production rollout. Evaluate FDE readiness through clear evidence of technical contributions, end-to-end ownership, deployment outcomes, and sustained customer impact. Establish accountability and verify demonstrated capabilities to determine whether an individual is prepared to fulfill FDE responsibilities.
“You were a solutions architect. Why should we believe you can do this job?” This practice question asks you to connect previous experience to FDE responsibilities. Solutions architects, solutions engineers, sales engineers, and ML engineers can all do work that overlaps with the role. A title alone does not establish readiness. Explain what you owned, what you built, and when your involvement ended. This lesson compares the roles on those three dimensions and helps you describe your experience with evidence.
How do we compare two roles?
A person’s mandate is the result they are expected and authorized to see through. Compare any two roles on three axes: ownership (which result and which decisions are theirs), implementation (how much they personally design, build, test, or operate), and timing (when they join and what ends their involvement).
On all three, the FDE mandate is wide. OpenAI describes the team as working “at the intersection of customer delivery and core platform development,” owning discovery, technical scoping, system design, build, and production rollout with customer engineering and domain teams. FDEs write production code across the stack when progress depends on it, and success is measured by production adoption, workflow impact, and eval-driven feedback. An approved architecture or a persuasive demo answers a narrower question.
Who did what at Alder?
Alder Field Services wants read-only appointment lookup for its dispatch staff, inside the existing dispatch application, across three service queues: East, Central, and West. Five people contributed. Before looking at anyone’s title, look at what the engagement produced. Here is Alder’s evidence packet, with job titles left out for now.
Scope: Read-only appointment lookup for dispatch staff across East, Central, and West, inside the existing dispatch application. Appointment changes and autonomous messages are outside the authorization.
Architecture: An approved component design describes the application boundary, identity approach, and integration design.
Implementation: A 240-line appointment-lookup adapter connects the dispatch application to lookup, with configuration instructions.
Demonstration: The sponsor sees the intended lookup workflow succeed.
Independent customer action: Customer engineering deploys the rehearsal build and executes 60 scheduled lookups, 20 per queue, without the author running them.
Results: East returns expected records on 20 of 20 attempts, Central on 20 of 20, and West on 2 of 20, with 18 access denials. That is 42 of 60. The rehearsal service identity, the account the application uses to reach customer systems, lacks West’s queue entitlement.
Now add the titles. The sales engineer joined first, gathered the sponsor’s requirements, and gave the ...