A Forward Deployed Engineer (FDE) combines work with users and hands-on software delivery. They learn how a process runs, test decisions with the team and adapt software to those conditions. When commissioning this work, I would assess the agreed responsibilities and ability to deliver alongside the job title.
Atlassian's description of its FDE role illustrates direct customer work and feeding those lessons back into a product. That program serves its platform. My work fits within my automation and applied AI services, using your company's tools and constraints.
When an FDE fits your business
I would consider this approach when rules are spread across people and systems, and the work needs observation before development can be scoped. For example, operations checks a request in a spreadsheet, consults another system and emails back an exception. The missing requirement may be who has authority to change a status, rather than which AI model to use.
- There is one specific workflow and a business owner who can resolve questions and accept changes.
- The team can supply normal cases, exceptions and authorized access to the required tools.
- Implementation involves discovering rules with users and testing them during development.
- A person or team can take over operation of the system.
If configuring an existing tool solves the problem, I would start there. If ownership, access or user review time is missing, I would resolve those dependencies before committing to delivery. AI is optional: some tasks need rules or an integration.
FDE, consulting, development or fractional CTO
These responsibilities can overlap. Consultants can implement software; developers can discover requirements. I would compare what each proposal actually takes on:
| Main need | Support to consider | What to put in writing |
|---|---|---|
| Choose a direction or assess alternatives | Technical consulting | Diagnosis, decisions and whether implementation is included |
| Build an already defined scope | Development team or individual | Requirements, tests and acceptance owner |
| Discover and build alongside operations | Embedded engineering / FDE | User access, process decisions and handover |
| Coordinate technology, people and ongoing priorities | Fractional CTO | Authority, time commitment and roadmap oversight |
If you need direction across several teams or projects, review the scope of CTO as a Service. Taking on one operational process does not imply taking responsibility for the company's entire technology function.
What to agree before work starts
I would use a short engagement brief to set boundaries. It should help both sides decide whether a new request belongs to the commissioned work or needs another estimate:
- Workflow boundary: trigger, useful output, users and steps that stay manual.
- Decisions: who sets business rules, approves exceptions and accepts delivery.
- Access: systems, environments, authorized data and dependencies on other suppliers.
- Starting evidence: representative cases, current errors and review workload.
- Deliverables: included code, configuration, tests, documentation and training.
- Change and continuity: how scope is revised, who handles incidents and which maintenance requires a separate agreement.
If discovery could materially change the budget, I would separate it from construction. Discovery should end with a specific decision: build one part, configure an existing tool or defer. Choosing between agents and workflows follows that boundary.
A hypothetical example: delivery change requests
Imagine operations receives requests by email and copies changes into a delivery system. This is a design example, not a customer case or measured result. First, I would observe how staff identify the order, who authorizes a change and what happens when the delivery is already in progress.
An initial version could prepare a structured request for review. If the identifier is missing or the order status prevents a change, it stays pending. The operations owner validates the rules; engineering builds the integration and records execution; an authorized person approves the change. If extraction requires AI, the model output is validated before use.
To review delivery, I would reproduce an unknown order, a repeated request, a rejected authorization and an external system outage. I would check that none causes a silent change and that the operator understands how to continue. The initial scope can exclude automatic customer replies and unapproved changes.
Costs and evidence for deciding whether to continue
Cost depends on discovery time, integrations, data quality, tests, deployment and support during adoption. I would also count the time your team spends explaining and reviewing the process, external service usage and ongoing maintenance. I would not quote a figure without understanding those conditions.
Use the software quote comparison guide when evaluating offers. A proposal that only delivers a prototype and one that includes operation and handover do not cover the same work.
Before expanding, I would compare completed tasks, errors, remaining review and operating cost against the starting position. The savings and remaining-work log separates recovered capacity from spending actually removed. Hiring an FDE does not guarantee profitability; stopping or simplifying the project can be a valid decision.
How to receive a system your team can operate
I would ask the person taking over to run a normal case and resolve an exception using the documentation. Together, we would review:
- Company access to the agreed repository, configuration and deployment accounts.
- Instructions to deploy, stop the process and recover the previous version.
- Execution records, alerts and a way to locate a failed request.
- Repeatable tests, known limitations and outstanding decisions.
- An operational owner, incident contact and agreed scope for ongoing support.
The Adslyfy case shows dashboards, workers, alerts and screenshots for investigating checks. This is evidence of engineering and operational visibility; it does not demonstrate AI savings or an FDE engagement for a client. Your handover would need verification against your own cases.
What I need to assess your workflow
As part of my work as a technical CTO and product builder, I can help connect the operational problem to implementation. I would start with an anonymized input and output example, the current tools, a common exception and the person who accepts the change.
To assess that scope, tell me about the process you need to resolve. We can use that information to decide what needs discovery, what can be built and what needs to remain under the team's control.