Capabilities guide
The capabilities behind forward deployed engineering
Practise the work itself: connect an API, trace wrong data, test failure cases, deploy, hand over. Each skill below names the failure that exposes it when it is missing.
These are human capabilities. The FDEOps AI skill pack is instructions for a coding agent; installing it is not evidence of proficiency.
Technical skills
Integration work
Read an unfamiliar API, handle auth, errors and rate limits, and move data between systems never designed to meet.
the tell The happy path breaks the first time the other side is slow.
Diagnosing wrong data
Trace one record through both systems, find why the totals differ, and separate what you proved from what you assumed.
the tell Trusting a column name instead of tracing an example.
Testing failure cases
Test cancellations, duplicate events, missing keys and late files. Rerun the affected checks, then the repository's required ones.
the tell Demonstrating only the cases you already know pass.
Deploying and monitoring
Ship through the permitted release process, verify deployed behavior, prepare recovery, and watch the first real operating cycle.
the tell It ran on your laptop and nobody watched the first real cycle.
Evaluating AI
Pick representative tasks and checks before relying on a model. Track quality, latency and cost. Test scores are not production evidence.
the tell A convincing demo with no representative checks or action limits.
Handing over
A runbook, a named operator, a recovery step they have rehearsed, and a list of what is still unresolved.
the tell The only person who can run it is you.
Client skills
Discovery
Watch the work, ask for a real example, and check what the request assumes. Reuse answers already established.
the tell Treating the proposed solution as proof of the need.
Executive communication
The decision, the tradeoff and the ask, in three sentences a VP can forward.
the tell A status update instead of a decision.
Scope discipline
Agree what the next change must show, what it excludes, and how new requests get decided.
the tell Scope changes stay implicit until they cause rework.
Stakeholder mapping
Know who uses, funds, approves and operates the result. Confirm authority; never infer it from a title.
the tell Agreement from someone who cannot make the decision.
Domain learning
Learn enough vocabulary to ask useful questions. Check your interpretations with domain specialists.
the tell Confidence about a domain assumption you never checked.
Memory discipline
Log material decisions and why, so nobody reopens settled ground without new evidence.
the tell Context that lives only in your head.
A practice rubric
A self-assessment, not an employer's leveling framework. Expect a different column per row.
| Dimension | With guidance | Independently in an agreed scope | Helping a wider team |
|---|---|---|---|
| Scope | Clarifies the assigned change | Negotiates a bounded outcome | Helps teams resolve competing needs |
| Discovery | Collects and checks examples | Tests assumptions and recommends a next step | Improves how teams learn from customers |
| Delivery | Implements and verifies with review | Handles relevant exceptions and recovery | Removes recurring delivery obstacles |
| Communication | Explains progress and blockers | Makes decisions and trade-offs clear | Keeps cross-team decisions understandable |
| Continuity | Records useful evidence | Maintains current decisions and ownership | Helps others reuse supported learning |
Keep decisions and evidence usable
- record
- Consequential decisions, their source, and what is still uncertain.
- before resuming
- Check the summary still matches the current situation.
- confidential
- Stays inside the permissions and systems agreed for the work.
- with an agent
- Give it only the permitted context it needs, verify important claims, and keep the real source of agreement visible.
Chat history is not an operating record. Write decisions where the next person will look.
Questions to test your evidence
| Area | Ask yourself | Weak answer |
|---|---|---|
| Scoping | What did my choice exclude, and who agreed? | Ambition instead of a bounded choice |
| Uncertainty | What did I know, what did I assume, how did I check? | Known and assumed blur together |
| Collaboration | Whose feedback changed my approach, and how? | Feedback with no resulting change |
| Ownership | What did I personally build or coordinate, and what proves the result? | The team's work, no personal part |
Choose what to practise next
Pick one capability you cannot yet demonstrate
Scope a bounded project with an observable result
Ask someone qualified to review the work
Exercises per capability: the learning roadmap. Turning the evidence into an application: the transition guide.
FAQ
What technical skills do Forward Deployed Engineers need?
Integrating APIs you did not design, querying unfamiliar schemas, reconciling data that disagrees, testing failure cases, deploying with a rollback, watching the first real cycles and handing over. For AI work, add evaluation and limits on what the system may do.
Do you need to be a strong coder to be an FDE?
Strong enough to explain, test and debug what you build. Framework breadth does not substitute for correctness or maintainability.
What non-technical skills matter most for an FDE?
Discovery, scope decisions and plain writing. They connect engineering to work someone needs, and keep decisions understandable to the next person.
How do I build FDE skills if I am a product engineer today?
Pick one gap, then find supported work that exercises it: watch a customer work, build an integration, or run a handover. Record your contribution and ask for specific feedback.
Use FDEOps with your coding agent
A method for each stage, from discovery to handoff, and a local record of every engagement. Use one task on its own or run a whole engagement. The decisions stay yours.