Career
The two sides an FDE has to master
An FDE isn't the average of a consultant and a developer — it's the best of both. What that means in skills, and how to build the weaker side.
There’s a misunderstanding around the title “FDE” that is producing more and more disappointment. Many read it as an in-between role: someone who codes well enough and communicates well enough.
It’s exactly the opposite. An FDE is not the average of the two skill sets. It’s the best part of both — which is why they’re rare.
Left side: business understanding
What a good strategy consultant brings:
- Capturing a workflow by observation, not by questionnaire. Noticing when someone “just quickly asks something” — and knowing that was the most important step in the process.
- Reading cost and risk. What an error costs, who notices, and when.
- Reading incentives. Who benefits from this project, who doesn’t, and who will quietly stall it.
- Getting it adopted. A system nobody uses doesn’t work.
- Closing in numbers. In a form the CFO will accept.
Right side: engineering depth
What a good software engineer brings:
- System design. Data models, APIs, error handling, idempotency.
- Building an agent that finishes the task even when the request is badly phrased.
- Measuring. Eval sets, failure modes, regression.
- Making it reliable. Logging, alerting, retries, stopping conditions.
- Operating it. When it falls over at night, knowing where to look.
Why one side isn’t enough
With only the left side you specify systems that can’t be built, or that can be built but don’t work the way the presentation said. The classic symptom: a beautiful specification and six months of slippage.
With only the right side you build a technically excellent system for the wrong problem. That’s more common, and more expensive. The symptom: everything green, the measurements good, and nobody using it.
How to build your weaker side
If you’re coming from engineering
Sit with a non-engineering team for a full day. Don’t help, don’t suggest. Just watch. Count how many times they copy data by hand and how many times they ask someone verbally. That exercise teaches more than ten articles.
Learn to talk about cost. Don’t say “this scales”, say “nine cents a case, €360 a month at 4,000 cases”.
Practise saying it twice. The same project to an engineer and to an executive. If the second is harder, that’s the part to work on.
Accept that organisational politics isn’t noise. If someone is blocking you, they usually have a good reason from where they sit. The FDE’s job is to find out what it is.
If you’re coming from the business side
Build one, end to end. It doesn’t have to be a production system, but it has to run on its own, failures included. The 30-day plan is for exactly this.
Learn the failure modes. Not how it works well — how many ways it breaks. That’s what makes you credible in an engineering conversation.
Understand the cost model. What costs money in a model call, and why.
Don’t claim what you haven’t measured. An engineering team will discount you for months after one imprecise technical claim.
What we look for
When we hire, we ask for one thing: tell us about the same project twice. Once as if explaining it to an engineer, once as if explaining it to a CFO.
Most people do one of them well. The person who does both is the one we’re looking for.
If that’s you, get in touch. If it isn’t yet but the path interests you: the 30-day plan.
Questions on this topic
Which side is easier to cross from?
Engineering, slightly — the technical base is harder to pick up on the job. But people from engineering tend to underestimate how hard the other side is, and that's where they come unstuck.
How do you tell in an interview whether someone is genuinely strong on both?
Ask them to explain the same project twice: once to an engineer, once to a CFO. The difference — or the absence of one — tells you everything.
What does this look like at your company?
If this problem sounds familiar, let's start with one process. Tell us which department burns the most manual hours — we'll come back with a concrete proposal.