How does an FDE differ from solutions, consulting, and implementation roles?

Scope

Use this guide when designing a field organization, hiring, or clarifying handoffs among sales, services, engineering, and product. It compares responsibility surfaces. Compensation, career ladders, and billable-service accounting require separate design.

Why it happens

Role comparisons begin with titles because titles are searchable. In practice, two companies can use FDE for different jobs, while one implementation engineer may own more production engineering than another company’s FDE. The same ambiguity appears in “solutions architect,” “applied AI engineer,” and “technical consultant.”

The organizational risk is an unowned transition. Discovery finds a real constraint but nobody can change the product. A prototype launches but no one owns adoption. Field code remains in production but core engineering assumes it was temporary. A matrix makes those gaps visible.

Diagnosis

Take three recent customer engagements and identify who actually:

• framed the user and business problem;
• selected the technical approach and success test;
• wrote or reviewed production code;
• obtained data and environment access;
• launched, monitored, and supported the system;
• trained users and measured adoption;
• decided what became configuration, service, or product;
• returned evidence to product planning;
• accepted security and reliability risk;
• exited ownership.

Compare observed ownership with job descriptions and contracts. A role name that says “consulting” may still own production; a role named “engineering” may stop at a demo.

Solution

Define the role around a lifecycle and its decision rights. Specify what the role may promise, build, deploy, access, operate, and escalate. Make core product and customer responsibilities equally explicit.

FDE is most distinct when the same field team can translate ambiguous operational work into a bounded solution, carry it through production and adoption, and return reusable learning to the product. If the role stops before build, production, or feedback, name that boundary honestly rather than stretching the title.

Review the allocation after several engagements. Persistent overlap may be intentional; persistent unowned work needs a redesigned interface.

Artifact

Complete the matrix with owns, contributes, approves, informed, or out of scope:

Lifecycle responsibility	FDE	Solutions	Consulting	Implementation	Core product	Customer owner
Problem discovery
Value test and scope
Architecture and product fit
Code/configuration/integration
Production launch and reliability
Adoption and workflow change
Security/data access
Support and incident ownership
Product feedback/productization
Handoff and exit

Common mistakes

• Defining roles from a single famous company.
• Comparing skills while ignoring authority and production ownership.
• Letting pre-sale teams promise field engineering capacity without acceptance criteria.
• Treating adoption and support as customer responsibilities by default.
• Naming product feedback as a duty without a receiving decision process.