FDE Isn't a Full-Stack Role: How Frontline Squads Assign Responsibilities

FDE Is Not a New Full-Stack Role

The article opens by challenging the common perception of an FDE as a "super engineer" who handles business, architecture, code, data, models, security, deployment, and long-term on-site support alone. This view conflates two distinct issues: an individual's breadth of technical skills versus who judges, executes, approves, and provides evidence for each responsibility. The author states: "FDE owns the problem-to-production loop, but that does not mean the FDE does all the work inside that loop."

Nine Responsibility Areas in a Frontline Squad

Using a synthetic case—"manufacturing enterprise using AI to assist abnormal order processing"—the article identifies nine responsibility categories that converge in every customer project. Each category answers specific questions, has typical owners, and must produce concrete evidence or decisions:

Business Value: Why do this, what to prioritize, when to continue or stop. Owner: customer business owner/executive. Evidence: value hypothesis, priority, metrics, go/no-go decision.

Product: What enters the official product, support scope, version commitment. Owner: supplier product/platform owner. Evidence: roadmap decision, support boundary, version/deprecation policy.

Architecture: System boundaries, sources of truth, integration paths, failure modes. Owner: FDE, architect, customer IT jointly. Evidence: boundary diagrams, architecture decision records, interface and failure contracts.

Engineering Implementation: Who builds, configures, integrates, fixes, and how changes enter controlled environments. Owner: FDE and development teams. Evidence: code, config, build artifacts, change logs.

Data Semantics: How objects, states, rules, sources, and validity periods are defined. Owner: customer business, data team, and FDE jointly. Evidence: business source models, mappings, quality rules, version baselines.

Security: Whether data can be used, how permissions are granted, who confirms high-risk actions. Owner: customer security, data, and source system authorities plus organizational risk acceptor. Evidence: authorization records, egress lists, permission policies, residual risk descriptions and acceptance decisions.

Testing: Whether functional, contract, model, boundary, and regression tests meet entry criteria. Owner: quality lead with business and engineering participation. Evidence: independent acceptance baseline, test results, blocking issues, retest records.

Operations: Who monitors, releases, rolls back, reconciles, takes over, and handles incidents. Owner: agreed operations team and relevant system owners. Evidence: SLOs, alerts, runbooks, drills, incident records.

Customer Adoption: Who puts the capability into real work, handles organizational resistance and behavior change. Owner: customer business leads, managers, and frontline teams. Evidence: enablement scope, work paths, adoption evidence, improvement decisions.

The article emphasizes these nine responsibilities are not nine fixed roles; a small project may have one person cover multiple areas, while a large project may have dedicated teams. The non-negotiable elements are: who owns the artifact, who has decision authority, and whether the decision basis is auditable.

FDE owns the problem-to-production loop, but that does not mean the FDE does all the work inside that loop.

One Person Can Wear Multiple Hats, but Execution and Approval Must Not Collapse

Frontline squads rarely staff nine dedicated roles. An FDE may simultaneously do field research, business modeling, architecture design, coding, and testing; a customer IT person may also be system owner, permission admin, and operations lead. The problem arises when organizations treat "same person can do" as "responsibility fulfilled" without preserving an independent approver, evidence baseline, and escalation path.

Three decision types must never disappear regardless of team size:

High-Risk Decisions Cannot Be Self-Approved by the Executor

Decisions such as expanding to more orders, allowing agents to submit high-impact actions, lowering quality bars, or stopping when key assumptions fail are not purely engineering choices. The FDE can assemble impact analysis, propose options, and give engineering judgment, but business scope, operational risk, and residual risk must be accepted by an authorized principal. The executor cannot automatically gain the right to decide for the customer just because they understand the system best.

Production Validation Cannot Be Replaced by "Code Runs"

Developers can write tests and organize pre-production validation, but production entry cannot rely solely on self-test conclusions from the same implementation context. The minimum requirement is not a dedicated test team per project, but an acceptance baseline independent of implementation convenience, critical tests executed in a controlled environment, clear handling of blocking issues, and final entry approved by an authorized owner based on evidence. NIST AI RMF 1.0 notes that independent review helps reduce internal bias and conflicts of interest, supporting the direction of independent verification without prescribing organizational form.

Security Authorization Cannot Be "Self-Done, Self-Signed"

An FDE may know how to connect data, request permissions, and implement tool calls, but cannot thereby self-approve data usage, data egress, source system writes, or high-risk actions. Technical access permission only means the system can access; it does not mean this business use is authorized. Security, data, and source system authorities must leave auditable approval records specifying scope, validity, revocation conditions, and residual risk.

The same person can execute multiple work items, but high-risk decisions, production entry, and security authorization must have independent evidence and be confirmed by authorized principals.

Customer Teams Are Not Spectators

In the abnormal order case, the FDE can map relationships among orders, contracts, inventory, and scheduling; design business models and agent chains; and participate in integration, evaluation, and production validation. However, the FDE cannot alone answer questions such as:

Which order status represents the enterprise's current valid commitment;

Which business person can confirm delay handling proposals;

Which source system owns final write authority;

What purposes order/contract/inventory data may serve;

Who responds to night alerts and how business continues during failures;

Which field differences should be retained long-term and which feedback can enter the product roadmap.

These answers must come from distinct customer and supplier responsibility holders. Treating the customer as only "requirement proposer" and "acceptor" while the FDE makes all judgments in between yields a system only the original team can explain and operate.

Minimal Responsibility Matrix for a Single-Customer Project

The article provides a matrix defining steady-state division of labor (not a fixed org template) across five columns: Responsibility, FDE's Role, Customer Primary Responsibility, Supplier Product/Platform Responsibility, and Independent Confirmation/Approval. Key rows include:

Business Value: FDE forms field evidence and validation paths; Customer Business Owner defines goals, priorities, outcomes; Supplier provides product capabilities and cost boundaries; Customer business/management confirms investment, scope, stop decisions.

Product: FDE categorizes feedback and adds engineering context; Customer business/IT confirm field applicability and upgrade impact; Supplier Product Owner decides roadmap, support, versions; Product roadmap approved by Product Owner; reuse rights confirmed by customer authority.

Architecture: FDE drives proposal and trade-off evidence; Customer IT, business, data owners confirm live, process, data constraints; Supplier confirms product foundation, extension points, compatibility boundaries; Customer architect/IT owner confirms field solution, high-risk boundaries to respective owners.

Engineering Implementation: FDE participates in key build, integration, fixes; Customer IT and data teams co-build deployment, interfaces, mappings, environments; Supplier provides platform capabilities and official extension points; Quality owner verifies artifacts, changes released by agreed approver.

Data Semantics: FDE drives model convergence, mapping, traceability; Customer business and data owners confirm meaning, rules, sources, versions; Supplier absorbs stable, reusable product semantics; Domain owner confirms business semantics, data owner confirms mapping and quality.

Security: FDE produces threat, permission, action, residual risk evidence; Customer security, data, source system owners confirm usage and enforce controls; Supplier provides platform permission, isolation, audit capabilities; Authorized security, data, source system principals approve or block; residual risk accepted by organizational designee.

Testing: FDE provides scenarios, implementation, reproduction conditions; Customer business, IT, data teams provide standards, environments, representative samples; Supplier provides product regression and compatibility evidence; Quality/verification owner establishes independent baseline and conclusion; production entry separately approved.

Operations: FDE drives loop closure and early issue convergence; Customer agreed operations team and system owners responsible for release, recovery, business takeover; Supplier handles platform operations per SaaS/managed boundary; Service, business, source system owners each confirm operational status within their remit.

Customer Adoption: FDE surfaces resistance, provides usage and failure evidence; Customer business leads, managers, frontline teams organize rollout and behavior change; Supplier improves product experience, docs, support; Customer business/management decides expand, shrink, or stop based on adoption and value evidence.

The matrix's "primary" does not mean "solely execute". Business value owned by customer business does not ignore technical cost and risk; architecture driven by FDE does not mean customer IT merely accepts; testing concluded by quality owner does not mean business experts exit acceptance. The "Independent Confirmation/Approval" column marks only the minimum necessary separation; actual approval chains must follow risk and organizational authority.

Responsibility Matrix Must Bind Objects, Evidence, and Triggers

Many projects create RACI tables or contact lists with only names and "responsible/assist", which cannot drive real decisions because "responsible for security" or "responsible for testing" lacks boundary definition and evidence-of-completion criteria. Each critical responsibility must record eight fields:

Responsibility Object: Which business flow, system, data, action, or outcome.

Applicable Scope: Which customer orgs, users, environments, versions are in scope.

Artifact Owner: Who maintains the current artifact and its state.

Executor: Who does the concrete work; can be one person wearing multiple hats.

Approver/Confirmer: Who has authority to accept conclusions, risks, or changes.

Evidence Location: Where models, code, tests, authorizations, run records are stored.

Escalation Conditions: What signals trigger escalation and to whom.

Invalidation & Re-review: When to re-confirm after personnel, version, scope, or risk changes.

Example: Instead of "Customer IT responsible for operations", a runnable version: "In customer self-ops mode, the application operations team maintains the designated production environment for the abnormal order agent, responsible for releases, alert response, and rollback within agreed windows; config, versions, runbooks, and drill records reside in a specified repo; unknown source system write state or continuous error budget exceedance triggers stop of automated actions and escalation to source system owner and business owner." Responsibility only stays effective during incidents, changes, and personnel shifts when bound to objects, evidence, and trigger conditions.

Executives and FDX Drive Organizational Push; FDE Is Not an External CEO

Even with a responsibility matrix, projects can stall due to shifting business priorities, unavailable key people, unresourced data departments, cross-department goal conflicts, or no one willing to decide on high-risk pilots. These issues cannot be solved by adding more duties to the FDE. The FDE can use field evidence to show impact of inaction, propose scope reduction, adjusted solutions, or project stop, but lacks inherent authority to approve budgets, adjust organizations, set business targets, or accept risks on behalf of the customer.

The concept of "FDX (Forward Deployed Executive)" helps analyze organizational push responsibilities, though it lacks a standard definition and stable role boundaries. The article distinguishes three layers:

FDE provides: Field facts, engineering constraints, solution options, production evidence, risk and stop signals.

Customer executives or delegated FDX drive: Form value priorities, coordinate budget and resources, handle organizational resistance, push management actions.

Customer internal authorized principals ultimately decide: Budget approval, organizational adjustments, risk acceptance, business targets, final change accountability.

An external FDX can help leadership understand technical and organizational issues and drive decisions, but cannot replace internal ultimate owners. Otherwise, "all technical problems to FDE" merely upgrades to "all business problems to FDX", creating another unauthorized role expected to catch everything. NIST AI RMF 1.0 explicitly states organizations should clearly document risk management roles and communication paths, and senior leadership must bear decision responsibility for risks associated with AI system development and deployment. This underscores that technical work and senior risk accountability must connect, but customer management responsibility cannot be outsourced to field engineers.

Four Responsibility Cracks That Most Often Disable Frontline Squads

The matrix's real value is not filling cells at kickoff but knowing where to return when disagreements arise. Four common cracks:

Responsibility Crack: Customer waits for FDE to give business answers Surface Symptom: Endless solution discussions, no one confirms business rules Actual Problem: Customer business owner absent Boundary to Return To: Business owner confirms objects, rules, priorities, human judgments

Responsibility Crack: FDE oversteps to decide for customer Surface Symptom: Project moves fast but decisions lack authorization basis Actual Problem: Push responsibility morphs into decision authority Boundary to Return To: Submit options and evidence to authorized principal for confirmation

Responsibility Crack: Security requirements deferred to later Surface Symptom: Technical path connected, so assumed usable Actual Problem: Ability to access mistaken for authorization Boundary to Return To: Return to data, security, and source system approval chain

Responsibility Crack: Organizational resistance dumped on FDE Surface Symptom: Solution feasible but resources, budget, cross-dept action long missing Actual Problem: Management responsibility packaged as engineering problem Boundary to Return To: Driven by executives or delegated FDX, decided by internal authorized principals

A subtler crack: an experienced person temporarily fills all gaps, making the project appear smooth while hiding organizational gaps inside personal capability. When that person leaves, business meaning, release process, security judgment, and customer relationship all lose owners. A healthy frontline squad is judged not by "this FDE knows everything" but by the absence of any single person long serving as an irreplaceable responsibility container.

Scope and Next Steps

The article limits itself to steady-state positions in a single customer project: which responsibilities belong to customer, which to supplier product/platform, which FDE drives, which are co-built, and which decisions must retain independent approval. Multi-customer FDE team concerns (resource priority, on-call coverage, cross-customer isolation) and multi-vendor projects (implementer, cloud vendor, model vendor, customer in-house team interfaces, change and failure responsibilities) are left for future extensions.

FDE Owns the Responsibility Loop, Not Organizational Capability

In the frontline squad, the FDE must at minimum drive three things:

Establish the responsibility matrix early, not after problems surface.

Bring customer business, IT, data, security, quality, and supplier product teams into real collaboration, not just attendance at reviews.

When budget, organization, risk acceptance, or change actions exceed engineering authority, escalate evidence and options to executives or delegated FDX; do not privately decide for the organization.

This responsibility has a clear ceiling: FDE cannot define business targets for the customer, cannot authorize on behalf of security and source system owners, cannot declare production validation passed for the quality owner, cannot approve budgets and org changes for executives, and cannot turn "one person, multiple hats" into "all responsibilities belong to me."

If the responsibility matrix has blanks, the correct action is not to let the FDE temporarily fill them and expand scope, but to shrink the loop, fill the responsible roles, or stop advancing to the next phase. The organization's unreadiness to assume responsibility is itself a project fact that must be exposed.

FDE is not a new full-stack role, nor is it one person doing all the work. The frontline squad's strength comes from assigning nine responsibilities to the right people, giving each responsibility artifacts, evidence, and decisions, and ensuring high-risk decisions are never absent regardless of team size.

This tenth article answered how responsibilities are allocated. The next article will address: to uphold these responsibilities, what concrete, artifact-verifiable capabilities does an FDE actually need—beyond a vague list of "knows business, knows tech, strong communication."

References

FDE Series Preface: Why Enterprise AI Needs a Responsibility Loop from Problem to Production

FDE Is Not On-Site Development: Why Enterprise AI Needs Someone Responsible for "Problem to Production"

From Full-Stack to Front-Back Separation and Back to "Full-Stack": AI Changes Not Roles But Responsibility Boundaries

OpenAI: OpenAI launches the OpenAI Deployment Company

NIST: AI Risk Management Framework Core

Chu Xingjuan: FDE Is Still Not Enough