The FDE Competency Framework

Knows the names and roles of the people in their working sessions. Asks how the current process works before proposing a change. Brings surprises back to their lead instead of acting on them alone.

Maps the stakeholders around their workstream without being asked, including the ones not in the meetings. Identifies who has to change their behaviour for the work to land, and factors that into sequencing. Recognises a political objection dressed as a technical one and escalates it rather than arguing the technology.

Holds an accurate model of the account: budget cycle, competing internal initiatives, who is protecting headcount, which executive's reputation is attached to this. Uses it to time proposals and to route decisions to the person who can actually make them. Predicts internal resistance before it appears.

Reads a whole class of customer, not one account. Can say what is structurally true about deployments in this sector and what changes between them. Advises sales and product on which customers are winnable and which will fail regardless of engineering effort, and is right often enough that people plan around it.

Productive in one primary language and comfortable reading a second. Can build a working integration against a documented API, query and shape data, and put a usable interface in front of it with review.

Works across the stack without hand-off: ingestion, transformation, service layer, and interface. Picks up an unfamiliar customer system, including a poorly documented legacy one, and is contributing within days. Distinguishes the part that must be durable from the part that is scaffolding, and builds accordingly.

Designs the technical shape of a whole deployment: data model, boundaries, integration surface, failure behaviour. Makes defensible build-versus-configure calls under time pressure and can justify them to both the customer's architects and their own engineering team. Deliberately leaves some things unbuilt.

Establishes the reference architecture that other deployments start from. Recognises when a class of customer problem has been solved enough times by hand that it belongs in the product, and makes that case with evidence from the field. Sets the technical bar the rest of the team is measured against.

Asks clarifying questions instead of building straight from a ticket. Can describe who uses the thing they are building and what it replaces. Flags to their lead when a request seems to miss the point.

Reframes requests within their workstream and gets the customer to agree to the reframing. Defines measurable acceptance for their own work. Pushes back on scope that does not serve the stated outcome, and offers a smaller alternative rather than a flat refusal.

Takes a vague executive-level goal and decomposes it into a sequence of deliverables that produce visible value early. Regularly kills proposed work that would not have moved the outcome, and is thanked for it. Separates what the customer wants from what the customer needs without condescension.

Reframes at the level of the engagement itself, including recommending against a deal or a direction when the underlying problem is not one this product should solve. Teaches the framing method to others rather than applying it personally. Trusted to tell an executive their premise is wrong.

Works effectively within an environment someone else set up. Raises blockers early and specifically. Follows the customer's process for access, review, and deployment without needing reminders.

Anticipates environmental blockers for their workstream and clears them ahead of need. Gets something demonstrable working early, even against incomplete access or partial data. Documents and hands over what they built so the customer is not dependent on them for routine operation.

Owns the delivery path for an account: sequencing around freeze periods, security review, procurement, and competing internal projects. Consistently produces visible value before the environment is fully ready, which is what keeps a sceptical stakeholder engaged. Builds the operational hand-off in from the start.

Changes what is possible to deliver, not just what gets delivered. Establishes the patterns, tooling, and pre-cleared paths that shorten every future deployment. Handles the environments others consider undeliverable, and turns what was learned there into something the next person inherits.

Communicates clearly in writing and in working sessions. Gives honest status, including when something is late. Presents their own work without needing a senior person to translate it.

Runs their own workshops and demos and drives them to a decision. Adjusts register between engineers, operators, and managers without changing the substance. Raises risks early with a proposed option rather than only a problem.

Holds executive-level conversations and is trusted in them. Delivers unwelcome news, including about their own team's product, without damaging the relationship. Builds internal advocates inside the customer who make the case when the FDE is not in the room.

Is brought into the conversations that decide whether an engagement continues. Repairs relationships others have damaged. Sets the standard for how the organization communicates in the field and coaches others toward it.

Reports friction, gaps, and customer reactions back to the product team clearly and without editorialising. Notices when they have built the same workaround twice.

Recognises patterns across their own work and raises them with evidence rather than anecdote. Distinguishes a one-account request from a recurring need. Keeps bespoke work contained so it does not silently become an unsupported product.

Influences the roadmap with field evidence and is taken seriously doing it. Makes the productise-or-keep-bespoke call for their account and is accountable for it. Actively argues against generalising things that should stay specific, which is the harder and rarer half of this skill.

Is a structural input to product strategy. Turns accumulated field reality into direction the roadmap reflects, and can point to shipped product that exists because of it. Builds the mechanism by which field knowledge returns, so it does not depend on any individual remembering to send it.