Skills Every Forward Deployed AI Engineer Needs
Every FDE skill exists in service of a single goal: delivering a working pilot that answers a real customer question on real customer data within a constrained time window. The skills that matter most are not the ones that look impressive on a resume. They are the ones that determine whether the system works on Thursday night before Friday's demo.
There is a tendency when listing skills for any role to compile everything that could be useful and present it as a comprehensive checklist. That approach produces lists that describe a mythical superhero rather than a hireable person. This is especially true for the FDE role, which sits at the intersection of software engineering, AI systems, customer engagement, and domain expertise.
The approach here is different. Rather than listing everything that could be useful, this post focuses on the skills that are genuinely determinative: the ones whose absence reliably causes FDE engagements to fail, and whose presence reliably causes them to succeed. Some skills that appear on standard job descriptions are not on this list because they are nice-to-have rather than load-bearing.
Tier One: Non-Negotiable Technical Skills
A concrete example of what Tier One looks like in practice: a customer has 40,000 PDF contracts stored in an S3-compatible storage system. They want to know which contracts contain a specific liability clause with variations in phrasing. The FDE should be able to build and run the following type of pipeline in a single day:
import boto3, anthropic, json
s3 = boto3.client('s3', ...)
client = anthropic.Anthropic(api_key="...")
def extract_clause_presence(doc_text: str, clause_desc: str) -> dict:
response = client.messages.create(
model="claude-opus-4-5",
max_tokens=256,
messages=[{
"role": "user",
"content": f"""Does the following contract contain a clause
matching this description: {clause_desc}?
Contract text:
{doc_text[:6000]}
Respond as JSON: {{"present": bool, "excerpt": str_or_null, "confidence": "high"|"medium"|"low"}}"""
}]
)
return json.loads(response.content[0].text)
results = []
for obj in s3.list_objects_v2(Bucket='contracts')['Contents']:
text = extract_text_from_pdf(obj['Key']) # custom PDF parser
result = extract_clause_presence(text, "limitation of liability")
results.append({"file": obj['Key'], **result})
This is not elegant engineering. It is the kind of working, readable code that can be shown to the customer's technical lead and extended by a product engineer in the handoff. Tier One is about building this kind of thing confidently and correctly under pressure.
Tier Two: High-Value AI-Specific Skills
Tier Three: Discovery and Communication Skills
Technical skills get the pilot built. Discovery and communication skills determine whether the pilot is the right thing to have built and whether the customer trusts it when they see it.
The T-Shape: Depth Plus Range
The most useful mental model for thinking about FDE skill development is the T-shape: a horizontal bar of broad knowledge across many domains, and a vertical bar of genuine depth in one or two areas.
The horizontal bar covers the basics of all skills listed above, enough to be competent and credible in each area. The FDE who has no SQL can be blocked by a data access problem. The FDE who cannot write a basic RAG pipeline cannot deliver the most common AI pilot pattern. Horizontal breadth prevents blockers.
The vertical bar is where the FDE becomes genuinely hard to replace. An FDE with deep healthcare domain expertise builds faster in healthcare engagements, earns trust sooner, and produces better scoping documents because they know the workflows, the regulations, and the failure modes before they arrive. An FDE with deep prompt engineering depth can iterate toward reliable outputs faster than one who is learning prompt design on the job.
The choice of what to put in the vertical bar is a strategic career decision. Domain expertise compounds with industry experience and is hard to acquire quickly, which makes it more durable as a differentiator than any specific technical tool. Technical tools change; domain patterns are more stable. An FDE who has worked with healthcare payer data across five engagements has pattern recognition that is worth more than expertise in any particular API that the healthcare payer systems expose.
Skills That Are Overrated for FDEs
Understanding what not to spend time on is as important as understanding what to invest in. Several skills appear frequently in FDE job descriptions but are less determinative of actual engagement success than they appear.
Deep ML theory. The FDE who can describe backpropagation and transformer attention mechanisms in detail but cannot build a working RAG pipeline in a new environment is less useful than one with the opposite profile. The FDE is a practitioner, not a researcher. ML theory is background knowledge that helps when something goes wrong, but it is rarely the bottleneck in an engagement.
Advanced DevOps. Kubernetes expertise, CI/CD pipeline design, and infrastructure-as-code are valuable in product engineering. In a two-week pilot, they are usually a distraction. The pilot runs on whatever the FDE can spin up quickly. Production infrastructure is a handoff concern, not a pilot concern.
Presentation design. A well-designed slide deck is not what makes an FDE demo successful. A working system on real data is. FDEs who spend Thursday evening designing slides instead of running test cases are optimizing the wrong thing. The most effective FDE demos are often visually minimal and technically deep, because the audience is looking for evidence the system works, not for visual polish.
How to Build the Skill Set Intentionally
The FDE skill set cannot be acquired through reading alone. Every skill on the list above is built through doing, and the most effective doing is building pilots on real problems with real data and real constraints.
Concretely: find a problem in your organization or community that could benefit from an AI application. Run a mini discovery sprint to define the scope. Build a working pipeline in one week. Show it to the people whose problem it was. Write a one-page description of what you built, what you learned, and what would be required to take it further. Repeat this three or four times. Each iteration builds the pattern library, the debugging instinct, and the communication reflex that characterize effective FDE work.
The Forward Deployed Engineer course is structured around exactly this progression. Each module teaches one phase of the engagement arc, and the capstone requires completing a full pilot from discovery through handoff on a realistic scenario with real constraints. The skills compound across modules in the way they compound across real engagements.
Build These Skills Through Practice
The Forward Deployed Engineer course teaches every skill on this list through realistic scenarios: a discovery sprint, a scoping exercise, a pilot build, a demo, and a handoff. Each module builds on the last. Free, six modules, practical.
Start the CourseReferences
- Lewis, P., et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. arXiv:2005.11401. Foundational paper on the RAG pattern used in most enterprise AI deployments.
- Yao, S., et al. (2022). ReAct: Synergizing reasoning and acting in language models. arXiv:2210.03629. On AI systems that interact with external data sources.
- Dreyfus, S. E., & Dreyfus, H. L. (1980). A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition. University of California, Berkeley.
- Sommerville, I. (2010). Software Engineering (9th ed.). Addison-Wesley. On the distinction between practice-oriented and theory-oriented technical competency.
- Kay, A. C. (1993). The early history of Smalltalk. ACM SIGPLAN Notices, 28(3), 69-95. On the value of "learning by doing" in technical skill acquisition.
- Chen, L., Zaharia, M., & Zou, J. (2023). FrugalGPT: How to use large language models while reducing cost and improving performance. arXiv:2310.11409. On cost modeling for LLM API usage in deployment contexts.
- Liang, P., et al. (2022). Holistic evaluation of language models. arXiv:2211.09110. On evaluation methodology for LLM outputs in applied settings.