The FDE Trinity
Engineer · Strategist · Implementer. Three sub-personas inside one role — and how to read which one is carrying the day.
V1 · Pedagogy
✅ PASS (5/5)
Sweller (1988) CLT, Wiggins & McTighe (1998) UbD, revised Bloom's (2001), retrieval practice, Vygotsky's ZPD — all confirmed.
V2 · Standards / currency
✅ PASS (3/3)
FDE role cross-checked against Palantir's public Lever postings; pharma R&D context anchored to FDA's Jan 2026 "Guiding Principles of Good AI Practice in Drug Development" and Apr 2026 Federal Register pilot announcement.
V3 · Quantitative claims
✅ PASS (3/3)
AI-in-clinical-trials market ≈ $2.7B (2025) → $8.5B (2030); FDA real-time-trial pilot targets 20–40% trial-time reduction. All verified.
V4 · Logical consistency
✅ PASS (4/4)
Section times sum to 75 min; Trinity model used consistently; Apply outcomes assessed by an artifact; Bloom progression Understand → Apply → Evaluate (no >1-tier leap).
Dr. Asha Vargas is the FDE embedded at NeuraGenesis Therapeutics, a mid-sized biotech running fourteen early-phase clinical trials. Her remit: deploy AI-assisted protocol optimization across the early-phase portfolio. NeuraGenesis is a partner on the FDA's April 2026 real-time-trial pilot, which targets a 20–40% reduction in trial time when deployment is done well.
The CMO escalated. The VP of Clinical Ops told Asha's manager she'd "missed the point of moving fast." The CTO said she'd "finally said what the engineers were afraid to say." Same action. Two readings.
Her manager is sitting at his desk with two questions and no framework for either:
- Was Asha being a brilliant strategist who saved the project, or a difficult engineer who slowed it down?
- How would he tell the difference — not just for Asha, but for every FDE on his team?
By the end of this lesson you will be able to tell the difference for yourself, and recommend which part of the FDE role each person on a team should invest in growing next.
By the end of this lesson, you will be able to:
The §7 authentic task — annotate-a-day plus a 200-word manager memo — is the assessment. The Trinity model in §4 is the lens that makes the annotation possible.
Before this lesson tells you who the FDE is, recall what they are for. These two prompts are the §11 spaced-review stems from Lesson 1.1 — they should come back quickly.
If both came easily, you're ready. If they didn't, your spaced-review queue surfaced these stems for a reason. Today's lesson assumes both answers are loaded.
The FDE is one role — one job title, one head, one direct manager. Inside that role live three sub-personas, each with its own accountability, characteristic moves, and failure modes. The FDE is most effective when she moves between them deliberately. She is least effective when one persona quietly dominates the other two.
Engineer
- Accountability
- The system works in production — code is correct, integrations hold, data flows.
- Characteristic move
- Refactors the bottleneck the team has been working around.
- Failure mode
- Optimizes for system elegance; loses the customer's metric. Builds beyond the narrow path.
Strategist
- Accountability
- The right thing gets built, in the right order, for the right reason.
- Characteristic move
- Pushes back on a request because the problem behind it is not yet verified.
- Failure mode
- Confuses opinionated with strategic. Performs strategy. Nothing ships.
Implementer
- Accountability
- The deployment lands inside the customer's environment and changes how people work — including after the FDE is gone.
- Characteristic move
- Writes the runbook the customer's team will actually open. Plans Day-2 before Day-1.
- Failure mode
- Treated as project-management overhead and dropped under cost pressure.
The Trinity is a balance, not a split — and it shifts by lifecycle stage
It's tempting to read the Trinity as 33/33/33 — three equal personas, always on. That's not the shape of the work. The balance point shifts across the implementation lifecycle. Click a stage below to see where weight should sit.
Why a Trinity and not three separate jobs
Palantir's public role description is explicit: "While a traditional software engineer focuses on creating a single capability for many customers, FDSEs focus on enabling many capabilities for a single customer." That single customer cannot survive a relay race between an engineer, a product manager, and a delivery consultant. Hand-offs lose what cannot be written down. The Trinity exists in one head because the customer's problem requires it in one head.
Here are five activities from Asha's morning, drawn from her own running notebook. Each is already tagged. As you read, ask yourself which persona was carrying the activity, and why a different persona would have produced a different action. The pre-set tag and the senior FDE commentary follow.
What the morning shows
Five activities · four hours · three personas — but the morning is dominated by Strategist (3 of 5), with one Engineer move and one Implementer move. That is consistent with where Asha's engagement sits: late-Discovery / early-Prototype, where the strategist's job is to lock the definition of success before the engineer's job ramps up.
Three activities from the second half of Asha's day. First two are annotated for you; the third is yours — click a persona below the activity to tag it. Then a small Evaluate move follows.
The Evaluate move — your turn (scaffold drop)
Asha's whole day now: 3 Strategist · 2 Engineer · 3 Implementer. She is the rare FDE whose Trinity is in balance. If you were her manager, and you had to recommend one persona for her to invest in over the next 30 days, which would you pick? Write the recommendation as a single sentence with three parts: persona, evidence from the day, growth action.
The Evaluate move is one Bloom tier above the annotation move. This is the upper edge of your ZPD for this lesson; productive struggle here makes §7 transferable to an FDE you have never met.
Brief
Daniel Park is a new FDE at OrbitMed Diagnostics, a Series C imaging-AI company. He started six weeks ago. His manager is preparing Daniel's first 90-day review and has asked you — a senior FDE on the team — to review one of Daniel's typical days and produce a 200-word memo recommending which persona to invest in next.
Step 1 — Annotate each activity
Click the persona tag under each activity. The Trinity balance updates live at the bottom.
All seven activities are Engineer-dominant. Engineer ≈ 7 · Strategist ≈ 0 · Implementer ≈ 0–1.
The day is a pure Engineer day. The high-leverage activities Daniel did not do are exactly the Strategist and Implementer moves: he omitted the overnight customer escalation from standup (09:00); replied to support tickets without diagnosing root cause (12:00); rescheduled the radiology-lead call to fix a CI run (13:30). 15:30's Slack post is internal-audience — no Day-2 customer reads it.
Step 2 — Write the memo
Lead with the answer (Pyramid Principle). Recommend the single persona Daniel should invest in over the next 30 days. Support with three specific evidence points (cite time stamps). Close with one concrete 30-day growth action: verb-first, time-bounded, specific.
Daniel should invest in the Strategist persona over the next 30 days. His Tuesday shows seven Engineer activities and approximately zero Strategist or Implementer moves; the highest-leverage missed actions of the day were each the strategist's or the implementer's, not the engineer's. Three pieces of evidence: he omitted the overnight customer escalation from standup (09:00); replied to support tickets without diagnosing root cause (12:00); rescheduled the radiology-lead call to fix a CI run (13:30). By June 16, Daniel will (a) attend two customer calls per week with a pre-call hypothesis written and a post-call note filed in the Companion OS, and (b) write a one-page weekly memo to his manager naming the most important conversation he had that week and the call he made because of it.
Letting one persona dominate (usually Engineer)
"I'll just code it; the strategy will sort itself out." Daniel Park's Tuesday is the archetype.
Correction
Persona balance is a managed variable, not a personality trait. Audit a week: count personas per day, then deliberately schedule the weakest persona's moves on the calendar.
Confusing Strategist with Opinionated
"I pushed back because I had a strong opinion." Pushback without diagnosis is performance.
Correction
Strategist work is verifiable. Before pushing back, name the root cause, the evidence, and the change that would un-push the pushback. Asha's CMO memo was strategist work; a slack "I disagree" would not be.
Implementer as PM overhead
"We'll have the customer success team handle adoption." The Implementer is the first persona dropped under cost pressure.
Correction
Most enterprise AI projects die in adoption, not in build. The Implementer's absence shows up six months later as "the prototype is still in the notebook." Refuse to outsource it.
Bring to mind one Forward Deployed Engineer you have personally worked with — past or present, yourself if necessary.
You'll use this person again in Capstone Milestone 1, when your Engagement Charter must say who on the team is carrying which persona during the first 30 days of the deployment.
Which persona dominates during the Discovery stage of the implementation lifecycle, and why?
Success criterion: Strategist (with Implementer warming up). Until the problem is understood and the customer's workflow is mapped, building anything is premature.
Next lesson
Today's lesson modeled the role at the individual level. Lesson 1.3 zooms out to the FDE organization's maturity — Artisan to Orchestrated.
Capstone hook
The charter must name which Trinity persona each contributor is carrying for the first 30 days, and which persona is currently uncovered. Today's §7 is the rehearsal.
Optional reading
blog.palantir.com — useful for triangulating today's Trinity against an FDSE-shaped variant of the same role.
Companion OS
File your §10 reflection and §11 retrieval card in your Companion OS under this tag — and bring the named FDE forward into Milestone 1.