Module 6: Growing as an FDE · FDE Course

The FDE role rewards a specific kind of development: broad technical skill combined with genuine depth in one or two domains, layered on top of a repeatable deployment methodology. This module covers how top FDEs develop that combination over time, what the career ladder from IC to team lead looks like, and how to build a personal playbook that compounds across deployments.

The Two Growth Axes

Unlike a traditional software engineer who grows primarily along a technical depth axis, an FDE grows along two axes simultaneously: technical depth and domain expertise. Both are required, and the combination is what makes a senior FDE valuable in a way that is difficult to replicate with generalist contractors.

Technical depth for an FDE means staying current with the AI tools and frameworks that matter for the kinds of deployments you are running. An FDE deploying RAG-based document intelligence systems needs current knowledge of embedding models, vector retrieval, reranking techniques, and prompt design for extraction tasks. An FDE working on agentic systems needs to understand tool orchestration, error handling, and state management. The specific depth varies by specialization, but breadth alone is not sufficient: customers expect FDEs who have actually built the thing they are proposing, not just read about it.

Domain expertise means understanding the customer's business context at a level that makes your technical choices more appropriate. An FDE who has deployed AI in three healthcare organizations understands the difference between how a clinical documentation team and a billing team use data, why audit trails matter in ways that go beyond compliance checkboxes, and which failure modes a Chief Medical Officer will find acceptable and which will end the engagement. That contextual knowledge cannot be acquired from a product manual.

The T-shaped FDE The most effective FDEs are T-shaped: broad enough to adapt to any customer context quickly, and deep in one or two domains where their expertise makes their technical choices distinctly better than a generalist's. The vertical bar of the T is your most valuable differentiator.

The FDE Career Ladder

FDE I

Executes with guidance

Runs discovery sprints and builds pilots under the supervision of a senior FDE or engagement lead. Handles well-scoped problems in familiar technical territory. Seeks guidance when constraints are ambiguous.

FDE II

Executes independently

Owns an engagement end to end: discovery through handoff. Handles novel constraints and unfamiliar technical territory without supervision. Writes scoping documents that hold under review from a senior FDE.

Senior FDE

Defines approach for others

Develops reusable patterns and frameworks that make junior FDEs more effective. Handles the most complex engagements. Reviews scoping documents. Advises on technical architecture for pilots outside their personal experience.

FDE Lead

Builds the team's capability

Manages a team of FDEs across multiple simultaneous engagements. Responsible for team-level quality and methodology. Works with product leadership on where FDE learnings should feed back into the product roadmap.

Building a Personal Playbook

A personal playbook is a living document that captures the reusable patterns, decision templates, and lessons from past engagements. It is not a record of what was built (that is the handoff document). It is a record of how you approached recurring challenges: how you structured the stakeholder interview for a compliance-heavy organization, how you handled the data access problem when the data team was not in scope, how you scoped a pilot when the success criteria were initially too vague.

The most valuable playbook entries are not the ones where everything went well. They are the ones where something went wrong and you learned specifically what to do differently. Each time you finish an engagement, add three entries to your playbook: one thing that worked better than expected and why, one thing that went worse than expected and what you would change, and one structural pattern you used that you expect to reuse on future engagements.

Fig 6 · FDE Growth Model: Technical Depth vs. Domain Expertise

Three Signals That You Are Ready to Lead

Moving from individual contributor to FDE team lead requires a specific change in orientation. The shift is not primarily about technical ability: most senior FDEs who become leads are already technically capable. The shift is about where you invest your energy.

Signal 1: You are spending more time preventing your team's mistakes than making your own. When you find yourself reviewing a junior FDE's scoping document and anticipating the problems before they happen, you are doing leverage work. That is what a lead does.

Signal 2: You have a playbook entry for most problems you encounter. When a new engagement's challenges feel like variations on problems you have already solved rather than genuinely novel situations, you have accumulated enough pattern knowledge to teach others. A playbook is not just for personal use: it is the foundation for team methodology.

Signal 3: Your most satisfying engagements are ones where someone else did the building. Leads who still need to be the builder on every engagement become bottlenecks. If you find yourself genuinely energized by watching a junior FDE deliver a pilot you coached them through, you are oriented toward leadership.

How do FDEs balance staying technically current with the depth required to become domain experts? ▼

The practical answer is intentional scheduling. Most experienced FDEs reserve a block of time weekly, often a half day, for technical exploration: reading new papers, building small experiments with new frameworks, or reviewing recent model releases. This is not optional and it is not done during engagements. It is protected time that prevents technical debt from accumulating while domain expertise grows. The risk for FDEs who work long engagements without this protected time is that they become very good at a specific customer's context and progressively less useful in the broader market.

Text · Personal Playbook Entry Template

PLAYBOOK ENTRY
Date: [Date]
Engagement: [Anonymous descriptor, e.g., "FS-doc-intelligence-01"]
Category: [Discovery / Build / Demo / Handoff / Career]

SITUATION
What was the context? What made this engagement unusual?
Be specific about the industry, problem type, and constraints.

WHAT WORKED (and why it worked)
Describe the approach that worked better than expected.
Explain the specific conditions that made it effective.
This helps you know when to reuse it.

WHAT DID NOT WORK (and why it did not)
Be honest about what failed or went worse than planned.
Describe what you tried, why it seemed reasonable at the time,
and what you observed that told you it was not working.

WHAT YOU WOULD DO DIFFERENTLY
The single most important change for the next similar engagement.
Be specific: not "communicate better" but "hold a stakeholder
alignment meeting before the build phase starts."

REUSABLE PATTERN
If there is a generalizable pattern here, describe it in one
paragraph as a rule you could hand to a junior FDE.
Example: "When the data access person is not in the discovery
meeting, always request a separate 30-minute data access
session before committing to pilot scope."

Try this

Write your first playbook entry today. Think of the last project where something went significantly better or worse than you expected. Fill in the template above for that situation. Do not worry about making it perfect. A rough entry that captures a real lesson is worth ten polished entries about things that went smoothly. The habit of writing playbook entries is more valuable than the individual entries.