Who Belongs in an AI Deployment Team?

An AI deployment team needs people who understand the customer's work, build and maintain the software, and can authorise changes to the process. A forward deployed engineer can connect those activities, but the team still needs clear commercial and business decisions. Start with the responsibilities and available time, then decide which people can cover them.

Map the delivery responsibilities

The FDE works close to the customer and builds the agreed implementation. A core developer maintains shared software. An account lead manages commercial commitments, while a product manager orders the work against the intended outcome. A change lead prepares staff to use the new process, and a customer process owner decides what acceptable business performance means.

Titles overlap. A sales-engineering discussion about the FDE role asks whether the two titles describe the same work. Use that question to examine your own boundaries: who builds the production integration, who can promise its scope, and who accepts the result? The discussion doesn't establish a universal role definition.

Employer descriptions provide concrete examples. Anthropic's FDE posting describes building production applications in customer systems, working with Post-Sales, Product, and Engineering, and returning repeatable deployment patterns to the product team. That is the employer's stated design, rather than evidence that every company needs the same reporting lines.

This map describes functions, not six mandatory hires. A founder can cover account leadership and product priorities, while a manager can cover process ownership and local staff preparation. Record the responsibilities separately even when the same person holds them. Include specialist security, data, or risk reviewers where the proposed access and actions require them.

Agree who can make each decision

Give the team a short decision record before discovery becomes a delivery commitment. Name who approves the first use case, who orders the backlog, and who can accept an additional request. Set a route for decisions that affect another department or exceed the process owner's authority.

Commercial scope needs technical review. The account lead should confirm an integration date only after the delivery team has examined access, dependencies, and available capacity. The FDE can explain what the build requires; that doesn't automatically give them authority to change the contract.

Shared-product changes need an explicit owner too. If a customer needs a connector that affects every tenant, the core developer and product owner must agree its design and priority. A local workaround may fit an initial pilot, but the team needs to state who maintains it and when it will be replaced.

OpenAI's Deployment Lead posting describes coordinating FDEs, researchers, and customer engineers, sequencing dependencies, and leading readiness and adoption. It shows that delivery coordination can be a named function alongside engineering. It doesn't establish a staffing ratio or remove the customer's own approval responsibilities.

Name who can pause the pilot and what approval permits it to restart. Keep access approval and any required independent review with the appropriate authority. Combining roles in a small team shouldn't allow the builder to approve their own security exception.

Staff a startup's first customer deployment

An illustrative starting team has a core developer, an FDE, and a shared account lead, with a named process owner at the customer. This can fit a bounded deployment where the existing product already handles most of the task. It is a planning option to test against workload, rather than a benchmark for all AI startups.

The core developer protects shared behaviour and reviews changes that other customers will use. The FDE observes the customer workflow, builds the local integration, and tests it with staff. The account lead keeps the commercial promise aligned with the delivery plan and brings unresolved customer commitments to the right person.

A founder may cover product priorities and account leadership initially. Give them scheduled decision time, not an assumption that they will approve everything between sales calls. The customer process owner needs time to provide examples, resolve business rules, and accept the pilot's results.

For a small pilot, the FDE can prepare operating instructions and work with the customer's manager on training. If the deployment changes several teams' work or removes an approval step, allocate change-management capacity explicitly. An engineer can demonstrate a screen without having authority to change a manager's staffing plan.

Check whether the FDE function is needed. A product engineer may cover discovery and implementation when the integration is repeatable and customer contact is limited. Use the FDE need assessment to identify recurring delivery obstacles before creating a permanent role.

Build a consulting engagement around delivery

For an illustrative consulting engagement, give an engagement lead responsibility for scope and the client relationship. Allocate a product or delivery lead to the outcome and backlog, an FDE to the customer implementation, and engineering capacity to the application and shared components. Add a change lead when the work alters operating routines across teams.

The engagement lead can also cover account leadership. A product manager can coordinate delivery if they have the required technical understanding and time. State both responsibilities in the plan; don't count a person as fully available for each role when estimating capacity.

The client still needs a process owner and contacts for its source systems. A consultant can recommend a new routing rule, but the client must authorise the business change. Agree how quickly the owner will review sample cases and who can decide when they are absent.

Keep advisory outputs tied to implementation. A process map should identify the cases the FDE will build and test. The backlog should carry the acceptance evidence the client will inspect. Staff preparation should show the revised handoff and exception route, rather than training people on a process that the software doesn't support.

Agree the end of the engagement while designing the first release. Name who receives code, configuration, and support duties. If the consultancy will maintain the system, state the coverage and commercial terms; if the client will operate it, allocate time for a tested transfer. A final presentation doesn't establish that transfer.

Design an internal transformation team

Inside an SME or corporate group, the deployment customer is the business unit that will operate the workflow. An embedded engineer can perform the FDE function without that title. Pair them with the process owner and the staff who do the work, and identify the platform team that maintains shared infrastructure.

Give a product or programme lead responsibility for priorities across the business and technical teams. If there is no external sale, replace account leadership with a sponsor who resolves funding and cross-department commitments. The sponsor should have an explicit decision route, not simply appear on the project slide.

A manager may cover local change work for a narrow pilot. A programme affecting several sites may need a change lead who coordinates manager preparation, revised procedures, and feedback. Use the manager workflow workshop to prepare managers for the decisions they will make during rollout.

For a PE portfolio, distinguish group coordination from company-level authority. A shared team can provide deployment methods and engineering support, while each company still has a named owner for its business rules and operating result. Agree data access separately for each deployment rather than assuming a group mandate grants it.

A platform specialist can support several pilots if their available time covers the requests. Reserve that time in the plan and name a backup. Calling someone a shared resource doesn't create capacity or guarantee a response when several projects need them at once.

Make handoffs produce an accepted decision

Follow an illustrative support-triage deployment through the team. During discovery, the process owner supplies ordinary tickets and difficult exceptions. The product manager and FDE turn them into a bounded first scope, such as recommending a queue while staff retain routing approval.

Before committing, the account or engagement lead checks the agreed scope with the delivery team. The source-system owner confirms access, and required reviewers examine the proposed data boundary. The commitment record should identify dependencies and what happens if approval or access arrives late.

During the build, the FDE implements the ticket integration and evaluation cases. The core developer reviews any change to the shared routing service and accepts its maintenance. If the implementation needs a product capability that isn't planned, the product owner makes a recorded priority decision.

Before the pilot, the change lead and team manager walk staff through an accepted recommendation and an exception. The process owner confirms the acceptance criteria and reviewer availability. The technical team demonstrates monitoring, the stop procedure, and the manual route.

At each handoff, name the receiving person and the evidence they accept. A discovery document is ready when its recipient can use it to decide scope. A pilot is ready when its operators can run the agreed cases and fallback. Keep unresolved decisions visible with an owner and a due date.

Check capacity before adding another deployment

Estimate work by phase and by person. Discovery consumes customer-facing time, integration consumes engineering time, and evaluation consumes both technical and process-specialist time. Include existing support commitments and the coordination needed to move decisions between teams.

Consider an illustrative week for an FDE with 40 nominal working hours. Eight hours go to internal meetings and eight to support for existing deployments, leaving 24 hours for the new deployment. If its plan needs 16 hours of implementation, eight of discovery, and eight of evaluation, it needs 32 hours. The gap is eight hours.

Resolve that gap by changing the plan: move work to another qualified person, reduce the scope, or extend the schedule. Assigning another role title to the FDE won't close it. These hours are a planning example, not a recommendation for working time or a measured staffing norm.

Check the customer's capacity separately. A reviewer with two hours available can't accept six hours of pilot review in the same week. The team may need fewer pilot cases or protected review time before adding engineering capacity. Identify the constrained decision or task before deciding which role to hire.

Use delivery evidence to revise staffing. Repeated customer-specific integration work may justify more FDE capacity. Repeated changes to shared code may justify core engineering time. A queue of unresolved business decisions needs an available process owner or sponsor; more developers won't automatically resolve it.

Confirm the team can launch and transfer the work

Before launch, ask each owner to demonstrate their part of the operating arrangement. The technical operator should investigate a failed case and run the fallback. The process owner should judge an output against the agreed criteria. The team manager should explain the new handoff and the route for staff feedback.

Confirm that review and support coverage match the proposed operating hours. Name backups and give them the access they need. If the team can support only a limited pilot window, make that limit visible in the release decision rather than promising continuous operation.

Record the receiving technical and business owners when the deployment team moves on. Our post-launch ownership guide covers the ongoing support and change decisions. Keep the delivery team responsible for completing that transfer, with clear acceptance from the receiving people.

For investors reviewing an AI startup, inspect whether customer delivery consumes unplanned engineering work and whether product ownership receives repeated field requirements. For a business commissioning a project, inspect its named customer responsibilities and the time it must provide. Both need an operating team whose commitments fit its authority and capacity.

Approve the team design when you can trace a customer request through scope, build, acceptance, and ongoing operation to named people. Keep that record current as the deployment expands. A new site, customer, or action permission can change the work and the people required to carry it.