The FDE Competency Framework is version 0.1.0. The version number is doing real work in that sentence.
This is a first draft written by one person. I have eighteen years across early-stage, growth-stage, and enterprise software, and a strong opinion about what this role is. That is enough to write a starting point and nowhere near enough to write a standard. The gap between those two things closes only if people who do this work argue with it.
So rather than present it as settled, here's how it was built and the four decisions I am least confident about.
The design rules
Observable behaviour, not adjectives. The failure mode of every competency framework is cells that read "demonstrates strong communication skills." That's unusable — two managers will score the same person two levels apart. Every cell here tries to describe something you could actually witness. "Has said no to a request and kept the relationship" is checkable. "Strong stakeholder management" isn't.
Six axes, because four is a caricature and ten is a form. Enough to describe a real person's lopsidedness, few enough to hold in your head.
Four levels, terminal at the top. I,II,III,IV — Deployed, Embedded, Trusted, Principal. FDE IV is a senior individual track, not a management step.
Durable over current. The framework deliberately doesn't have an "AI" axis, which is the choice I expect the most pushback on. See below.
The four decisions I am least sure about
1. No AI axis
Roughly half the forward deployed postings in 2026 are AI deployment roles wanting retrieval, evaluation discipline, and agent orchestration. There's a real argument that this deserves its own axis.
I put it inside Technical Breadth instead, because a standard organised around this year's stack is obsolete in two years, and I would rather the framework still be useful in 2030. The counter-argument — that AI deployment is a genuinely different discipline and not just a new stack — isn't stupid, and if enough practitioners make it I will be wrong.
Confidence: medium. This is the one most likely to change.
2. Product Feedback Loop as a competency
Most FDE job descriptions don't mention it. I made it one of six.
The reasoning: without it, forward deployment is consulting with better equity. The loop back to product is the thing that makes the model pay for itself at company scale. But I am describing what the role should be as much as what it is, and a framework that quietly argues for a different job than the one people hold is less useful as a mirror.
Confidence: high on the substance, medium on including it in a descriptive standard.
3. Four levels, not five
Most engineering ladders have five or six. I used four because I couldn't write a fifth that was distinguishable from FDE IV by observable behaviour — every attempt produced a cell about scope and headcount rather than about the work.
If you run a large FDE organization and have a real fifth level with real behavioural distinctions, that's the single most valuable contribution you could make here.
Confidence: low. I suspect four is wrong for large organizations.
4. Customer Context as axis 01
Putting it first is an argument, not an ordering. It says the organizational read is the foundational competency and everything technical is downstream of it.
An excellent engineer could reasonably say that's backwards — that Technical Breadth is the floor, and everything else is what you layer on someone who can already build.
Confidence: high, but it's a position and should be read as one.
What would change my mind
Concretely, because "feedback welcome" isn't a real invitation:
- A hiring manager showing me a leveling conversation where a cell was ambiguous enough that two people read it oppositely. That's a bug and I want the file and line.
- Three or more practising FDEs saying an axis doesn't match their week.
- Anyone who can write the fifth level properly.
- Evidence that the AI-native split is a real discipline boundary rather than a stack.
How to argue with it
The framework is a single YAML file. Not a database, not a CMS, not a form. A file, with a diff history, in a public repository.
git clone https://github.com/rohithreddygopu/fde-community
$EDITOR content/framework/framework.yaml
Change a cell, open a pull request, say why. If you would rather not use Git, open an issue with the framework-feedback template and someone will land it for you.
Every accepted change goes in the changelog with attribution. A standard with no dissent in its history is a standard nobody used.