FDE vs Solutions Architect: Which Role Do You Need?

The substitution that costs six months

A pattern recurs often enough to be worth naming. Enterprise implementations are running long. Leadership concludes that the problem is insufficient technical rigour in the engagement, so they hire a solutions architect. The architect is competent, produces genuinely good integration designs, and six months later the implementations are still running long, because the constraint was never design quality.

Design and delivery are different bottlenecks and they require different people. If your integration plans are sound and your integrations are not live, adding another plan does not help. That is a capacity and ownership problem, and it is solved by somebody who writes the code.

This is not an argument that solutions architects are unnecessary. It is an argument that the two roles solve genuinely different problems, and that diagnosing which problem you have is worth doing carefully before you write the job description.

Where the two roles diverge

Signs you need a Forward Deployed Engineer

• Integration designs exist and are good, but nothing has reached production
• The customer is blocked on work that only somebody writing code can unblock
• Your product roadmap is being consumed by one-off customer requests
• Time to value is the metric under pressure, not deal conversion
• The same integration problem keeps recurring and nobody owns fixing it properly
• Customers describe your product as powerful but hard to actually adopt

Signs you need a solutions architect instead

• Deals are stalling during technical evaluation rather than after signature
• Prospects are asking architectural questions nobody on the team can answer confidently
• Implementations are shipping but the designs behind them are inconsistent across accounts
• You need reference architectures that several delivery teams can follow
• The bottleneck is technical credibility in the sales conversation, not delivery throughput

Why the roles are so often conflated

Part of the confusion is historical. Before Forward Deployed Engineering was named as a distinct discipline, the customer-facing technical role was called solutions architecture almost everywhere, and the title absorbed a very wide range of actual work. Some organisations still use it for people who write substantial production code, which is fine internally and confusing externally.

The other part is that both roles look similar from a distance. Both are technical, both are customer-facing, both spend time in meetings that product engineers avoid. The difference only becomes visible when you ask what artefact they produce at the end of a week, and whether a customer is closer to production because of it.

A practical test when reading a candidate's history: ask for a specific integration they delivered and then ask a detailed question about something that broke in production. Architects who have never written the code cannot answer at that level of detail, and they usually say so straightforwardly rather than bluffing.

How to diagnose which one you need

Run a simple audit before writing any job description. List your last five enterprise implementations and, for each, identify the specific thing that delayed it. Then group those causes. If most of them are decisions that were never made, or designs that turned out to be wrong, you have an architecture problem. If most of them are work that was designed and then sat unbuilt, you have a delivery problem.

The audit is worth doing because intuition is unreliable here. Leadership tends to attribute implementation delays to insufficient rigour, partly because rigour is easier to procure than capacity and partly because a design document is a more visible artefact than a merged pull request. The audit forces the question onto evidence rather than instinct.

One further signal is worth checking: ask the engineers currently doing implementation work what they need. In our experience they almost always answer with capacity or access rather than with better designs, and they are usually right, because they are the ones watching the work queue rather than the roadmap.

Part of the Forward Deployed Engineering cluster · Read the pillar page