Concepts / Advisory Roles in AI Engineering

Advisory Roles in AI Engineering

A Forward Deployed Advisor is a senior practitioner who runs a solo consultancy and sells FDE work without performing it.

  • Programming

Where the Title and the Work Part Ways

Engineering vocabulary is full of titles that suggest more than they deliver. The label Forward Deployed Advisor is one of them. At first glance it seems to describe someone who sits inside a customer's organization and ships working software. The source material describes something different: a role that works at a distance from the engineering itself. The label has spread informally beyond the core of the industry and has been attached to that advisory role. Understanding the role starts with noticing exactly where the name and the work separate.

What do you think happens?

Based only on the name Forward Deployed Advisor, what would you expect this person to do for a customer?

  • Deploy production code into the customer's live environment

  • Sell strategy, diagnostics, executive coaching, and reusable frameworks without shipping code

  • Manage a team of engineers who build the product

Reveal answer
Answer:

The second option. A Forward Deployed Advisor sells advisory services and does not ship code in the customer's production environment.

The source names the expectation of production deployment as a misconception. The title is borrowed from hands-on delivery work, but the Advisor is not doing that work. A buyer who reads the title as a promise of deployment has misread the engagement before it begins.

How the Role Is Structured

Definition

A Forward Deployed Advisor is a senior practitioner who runs a solo consultancy and sells FDE work without performing it.

The definition has two features that matter. First, the Advisor is senior. The value being sold rests on experience and judgment rather than on a team of engineers executing a build. Second, the consultancy is solo. The person selling the engagement is the same person delivering its advisory output. The model is one practitioner whose knowledge is packaged into services.

The diagram below shows the relationships among the three parties the definition mentions: the solo consultancy, the client, and the FDE work. Trace each arrow to see who holds which relationship. The Advisor runs the consultancy and sells the FDE work, but does not perform it. The client buys the advisory output.

Forward DeployedAdvisorsenior practitionerSolo consultancyrun by the AdvisorAdvisory outputguidance and materialsClientbuys the engagementFDE worksold, not performedrunssells without performingreceivesdelivers
Who holds which relationship, and where does the Advisor sit between the client and the work that gets delivered?

What the Advisor Sells

The Advisor's catalogue is specific and limited. According to the source, the Advisor sells strategy, diagnostics, and executive coaching. In some cases the Advisor also sells high-quality intellectual property, such as frameworks and playbooks. That gives four categories of offering.

  • Strategy
  • Diagnostics
  • Executive coaching
  • Intellectual property such as frameworks and playbooks (in some cases)

Every item on that list produces guidance, assessment, or reusable material. None produces running code in a live system. That shared character is what the rest of the article depends on. The one thing the Advisor does not sell is shipping code in the customer's production environment, which is the work the FDE label evokes.

The comparison below places the Advisor's sales beside the hands-on work the role is named after. Read the left column as the list of things that are sold, and the right column as the work that is sold but not performed by the Advisor.

StrategyShipping code inproductionDiagnosticsExecutive coachingFrameworks andplaybooksin some cases
Side by side, what exactly is on the sell list and what is absent from it, and how do the two differ?

The Deployment Misconception

The source names one expectation directly as a mistake a customer is likely to make: assuming the Advisor will deploy production code. The error comes from reading the title as a job description. The label is borrowed from hands-on delivery work, but the Advisor is not doing that work. The source is explicit that a buyer who expects deployment will be disappointed.

  • Common mistake

    Inferring the engagement scope from the job title

    What it looks like

    A buyer hears the title Forward Deployed Advisor and assumes the person will ship working software into the company's production systems.

    Why it fails

    The source says the title is borrowed from hands-on delivery work and that the scope should be checked directly rather than inferred from the name.

    Do this instead

    Check the scope of the engagement with the Advisor directly, against the four categories the Advisor sells.

  • Common mistake

    Treating an advisory engagement as a delivery promise

    What it looks like

    A buyer signs an engagement expecting a finished, deployed system at the end of the period.

    Why it fails

    The Advisor sells guidance, assessment, or reusable material. The source states that none of these produces running code in a live system.

    Do this instead

    Match the expected output to the advisory categories before the engagement starts.

  • Common mistake

    Assuming the Advisor's team builds the product, when the model is one senior practitioner packaging their knowledge

Evaluating an Engagement Request

When a request arrives, the question is whether it fits what an Advisor provides. The flowchart below turns the source's facts into a sequence of checks. The first check looks for a request to ship code into the customer's production environment, which the Advisor does not sell. The second check looks for a match with one of the four advisory categories. A request that passes neither check should not be assumed to fit. Its scope should be confirmed directly.

Incoming requestAsks for productioncode?Out of scope:hands-on FDE workIn scope for theAdvisorMatches a soldcategory?Confirm scopedirectlyyesnoyesno
Given an incoming engagement request, what sequence of checks determines whether it is in scope for an Advisor or out of scope?
Worked example

Sorting a Hypothetical Request

A prospective client writes: We want an Advisor to review our current AI project, identify where it is stalling, and coach our leadership team on prioritizing the next phase. Our engineers will handle the build. Is this request within what a Forward Deployed Advisor provides? (This request is an illustration written for this article, not drawn from the source.)

  1. 1
    Check for production code

    The request asks for a review, diagnosis of stalling, and coaching. It does not ask the Advisor to ship code into the live environment. The first check answers no, and the client states that engineers will do the build.

  2. 2
    Match against the sold categories

    Reviewing the project and identifying where it stalls is a diagnostic. Coaching the leadership team is executive coaching. Both match categories the Advisor sells.

  3. 3
    Decide scope

    Both requested outputs fall within the advisory categories, so the request is in scope. The client's engineers keep the build, which matches the solo advisory model.

Result

In scope. The request asks for diagnostics and executive coaching, which the Advisor sells, and it leaves the build with the client's own engineers.

Testing Your Scope Judgment

MEDIUM

A startup asks: Can you have your Advisor deploy our new recommendation model into our production environment this month, and also write the code for the integration? Using the two checks from the flowchart, decide which parts of this request are in scope and which are not, and explain your reasoning.

Hints
  • Start with the first check. Does any part of the request ask for shipping code into the customer's production environment?
  • If a part of the request is out of scope, does the rest of the request match one of the four sold categories: strategy, diagnostics, executive coaching, or frameworks and playbooks?

Key Takeaways

  • A Forward Deployed Advisor is a senior practitioner who runs a solo consultancy and sells FDE work without performing it.
  • The Advisor sells strategy, diagnostics, executive coaching, and in some cases frameworks and playbooks. None of these produces running code in a live system.
  • The one thing the Advisor does not sell is shipping code in the customer's production environment, despite what the title suggests.
  • The title is borrowed from hands-on delivery work, so the scope of an engagement should be checked directly rather than inferred from the name.
  • To evaluate a request, first check for production code, then check for a match with the sold categories, and confirm scope directly when neither check settles it.