FDE, Solutions, and Customer Success are not title variants; they are different ownership models with different failure modes.
01 THE PROBLEM
Technical field role overlap is the failure mode where customer-facing technical work has no single, stable owner across pre-sales, implementation, and post-launch operations.
The symptom is not confusion over titles. The symptom is a revenue-critical queue of work that nobody can prioritize cleanly.
A prospect asks for a non-standard integration. Sales says the Solutions Engineer can handle it. The Solutions Engineer assumes Delivery or an FDE will build it. Customer Success expects Engineering to productionize it. Engineering thinks this is one-off services work. Three weeks later, the deal stalls, the launch slips, and the customer now believes your product is less mature than the roadmap deck implied.
This usually surfaces between 10 and 40 enterprise customers, or earlier if your product touches identity, data pipelines, private cloud, or regulated workflows. It becomes acute within one to two quarters after the first few large deployments close.
The reason this matters is simple: these roles sit directly on the fault line between product truth and revenue promises.
If that fault line is unmanaged, one of three things happens.
First, your sales cycle lengthens because every technical question becomes an escalation. Second, your implementation burden explodes because every customer gets a quasi-custom version of the product. Third, your roadmap gets hijacked by the loudest deployment, not the most repeatable market need.
The industry keeps collapsing these jobs into one bucket because all of them are “technical” and “customer-facing.” That is the wrong level of abstraction.
A Forward Deployed Engineer owns customer-specific technical delivery where code, systems integration, and production behavior are part of the job.
A Solutions Engineer owns technical pre-sales, evaluation design, and feasibility framing. Their main output is confidence, not shipped software.
Customer Success owns adoption, value realization, renewal health, and operational continuity. In technical products, that often includes a CSM paired with a Customer Success Engineer or Customer Engineer. Their main output is retention, not net-new implementation.
When one person does all three for too long, the role stops being leverage and starts being hidden organizational debt.
The dangerous part is that this debt initially looks like hustle.
Founders love the first field engineer who can close deals, write code, fix a deployment at 2 a.m., and calm down an angry buyer. But if that same person is still the answer six months later, you have not built a function. You have built a hero dependency.
Stripe’s engineering and infrastructure writing repeatedly emphasizes reducing bespoke operational work through internal platforms and standardized interfaces because operational complexity compounds faster than teams expect. The same logic applies here: if customer-facing technical work is not standardized into ownership boundaries, abstractions, and escalation paths, you accumulate exception handling as an operating model.
That is the core problem. Not title inflation. Not semantics. Ownership collapse.
02 WHY IT HAPPENS
This overlap happens because startups reach enterprise complexity before they build enterprise functions.
The product starts narrow and self-serve. Then a few larger customers arrive with real environments: SSO requirements, odd IAM policies, private networking, historical data migration, procurement security reviews, and workflows that do not fit your ideal path. Revenue pressure rises faster than operational maturity. So leaders route all exceptions to whoever can both talk to customers and understand the system.
That is usually the first Solutions Engineer, founding engineer, or implementation-minded PM.
From there, overlap becomes structural.
Sales is incentivized to maximize deal velocity and flexibility. Engineering is incentivized to preserve product coherence and roadmap focus. Customer Success is incentivized to protect renewals and customer sentiment. None of these incentives are wrong. The problem is that customer-specific technical work sits across all three.
This creates a classic boundary failure.
A Solutions Engineer can win a deal by proving feasibility with a clever demo path. An FDE then inherits the real work of making that path production-grade in the customer’s actual environment. Customer Success later inherits the operational consequences: brittle runbooks, undocumented assumptions, and support load from things that were “just for launch.”
The role overlap persists because the handoffs are invisible in standard dashboards.
Your CRM shows a closed deal.
Your product analytics show activation.
Your CS tooling may even show green health scores for 30 days.
What it does not show is whether the deployed solution is repeatable, supportable, secure, or one incident away from becoming roadmap debt.
This is especially common in AI-first companies.
The demo-to-production gap is much wider in AI products than in classic SaaS. A prototype can look excellent in a controlled environment and fail badly when exposed to customer data variability, latency constraints, hallucination tolerance, compliance review, or integration into existing systems. That pushes more work into the field. Not because the field team is doing something wrong, but because the product boundary is still moving.
Gergely Orosz has written in The Pragmatic Engineer about how modern engineering organizations increasingly create specialized roles at the edges of product and platform as systems become more integrated with customer-specific environments. The point is not to create bureaucracy. The point is to match role design to where complexity actually lives.
Another reason overlap happens: title borrowing.
Companies copy labels from Palantir, Stripe, Datadog, Snowflake, or Vercel without copying the operating model underneath. “Forward Deployed Engineer” sounds high-agency and technical. “Solutions Engineer” sounds commercially useful. “Customer Engineer” sounds implementation-friendly. Teams then map old work to a new title and assume clarity will follow.
It does not.
A title only works if it defines:
- What work the role says yes to
- What work it explicitly refuses
- What artifact it is expected to leave behind
- What metrics determine whether it is succeeding
- When ownership transfers to another function
Without those, every technical field role becomes “special projects with customer urgency.”
The last structural reason is product immaturity disguised as customer centricity.
Founders often say, “We stay close to the customer.” Good. But in practice that can mean “we have not decided what is core product versus paid exception work.” Until that line exists, FDEs, Solutions Engineers, and Customer Success Engineers become human patch layers over product gaps.
At small scale, this is adaptive.
At Series B scale, it is expensive.
At Series C scale, it starts damaging gross margin, roadmap quality, and customer trust all at once.
03 WHAT MOST GET WRONG
The most common mistake is treating these roles as a sequencing problem instead of an ownership problem.
Leaders think: first pre-sales, then implementation, then success. So they assign one person to cover the whole chain and assume continuity is the strength.
Continuity is not the strength.
Continuity without boundaries is how pre-sales optimism becomes post-sales liability.
The second mistake is writing role descriptions based on surface activity.
If the person joins customer calls, understands the product, and can explain integrations, teams assume the role is fungible. But the underlying work is very different.
A Solutions Engineer is optimizing for credibility, speed, and technical conviction during evaluation.
An FDE is optimizing for deployed reality under time pressure.
A Customer Success Engineer is optimizing for adoption, durability, and issue prevention over months or quarters.
Those are adjacent but not interchangeable operating modes.
The third mistake is assuming the answer is just “hire more senior people.”
Senior people absolutely help. They can tolerate ambiguity longer and make better tradeoffs in the field. But seniority does not fix a role with contradictory objectives.
If you tell one person to maximize win rate, accelerate onboarding, reduce custom work, preserve engineering bandwidth, and improve gross retention, you have not created a senior role. You have created an impossible one.
The fourth mistake is using “temporary” custom work as a permanent organizational loophole.
Every startup says the custom connector, migration script, or deployment workaround is temporary. Then six months later, it is running in production for a top-10 account, undocumented, with no clear owner.
HashiCorp’s public engineering culture has long emphasized codifying operational knowledge into products, patterns, and automation rather than sustaining institutional knowledge through individuals. That principle matters here. If field exceptions never get folded back into reusable product or platform capabilities, your field org becomes a shadow engineering team with none of engineering’s tooling, test discipline, or review structure.
The fifth mistake is failing to define exit criteria from the field.
The field should not be the final resting place for functionality that is broadly needed. The field is where demand gets discovered and de-risked. Product is where repeatability gets built.
Without a mechanism to move customer-specific work into the core stack, field roles become a sink for every edge case.
A concrete failure pattern shows up in outage and postmortem culture. The Google SRE book is explicit that toil grows when manual, repetitive, service-critical work is not engineered away. If your Customer Success Engineer manually reconfigures environments, rewrites mappings, or hand-holds every incident for the same class of customers month after month, that is not “high touch.” That is toil, and SRE guidance is clear: toil scales headcount, not reliability.
What does this cost?
It costs sales efficiency because technical scoping is trapped behind a few overloaded people.
It costs engineering throughput because field-originated requests arrive as urgent exceptions rather than structured patterns.
It costs retention because customers detect fragility fast. Enterprise buyers do not care that a workaround took heroics. They care whether it is documented, supportable, and survives turnover.
The hidden cost is hiring.
Strong field engineers burn out quickly when they spend half their week rescuing bad scoping and the other half begging product teams to adopt repeatable fixes. Paraform’s 2026 write-up on FDE versus Solutions and Customer Engineer roles makes the burnout point directly for hybrid technical customer success roles in early-stage startups: they can work for a small customer base, but once deployment complexity or volume increases, one person carrying the whole lifecycle becomes unsustainable.
That pattern tracks with operator experience. Burnout here is not about workload alone. It is about role contradiction.
04 THE FRAMEWORK
The model that works is not “pick the right title.” It is “design the ownership system around the lifecycle of customer-specific technical work.”
Use this six-part framework.
1. Define the unit of work before you define the role
Most teams start with job descriptions. Start instead with recurring work objects.
List the top 25 customer-facing technical tasks from the last 90 days. Not in abstract categories. In actual tasks:
- Security questionnaire support
- SSO and SCIM setup
- Data model mapping
- Sandbox proof-of-concept build
- Private VPC deployment
- Historical migration script
- Custom API connector
- Incident triage during launch
- Adoption instrumentation
- QBR technical roadmap review
Now classify each task on two axes:
- Is it pre-sale, implementation, or post-launch?
- Is the output persuasion, configuration, code, or operations?
This immediately reveals the real role boundaries.
If the output is persuasion and architecture framing, it belongs with Solutions.
If the output is customer-specific code or deployment behavior, it belongs with FDE or implementation engineering.
If the output is adoption health, ongoing optimization, and renewal risk mitigation, it belongs with Customer Success or Customer Engineering.
Without this task map, teams assign roles based on personality. That is how overlap metastasizes.
2. Create hard entry and exit criteria for each role
The field breaks when ownership is conversational instead of contractual.
Write the role boundaries like API contracts.
Solutions Engineer owns:
- Discovery of technical requirements
- Architecture options and constraints
- Proof-of-concept design
- Technical validation during evaluation
- Red/yellow/green feasibility judgment before close
Solutions Engineer does not own:
- Production-grade custom code
- Long-lived customer-specific integrations without product approval
- Post-launch incident response beyond transition period
Forward Deployed Engineer owns:
- Customer-specific implementation requiring code, infrastructure, or deep systems work
- Deployment into complex environments
- Time-boxed adaptation of product to real customer conditions
- Feedback loop into product for repeatable capability gaps
Forward Deployed Engineer does not own:
- Unlimited bespoke feature development
- Ongoing success management after stabilization
- Acting as default support for all complex accounts
Customer Success / Customer Success Engineer owns:
- Adoption milestones
- Business value tracking
- Stable operating runbooks
- Escalation routing
- Renewal-risk identification tied to technical friction
Customer Success does not own:
- Backfilling product gaps with permanent manual engineering
- Owning product roadmap commitments
- Accepting undefined technical debt from implementation
This sounds obvious. It is not. Most startups cannot write these lists cleanly because they have not chosen what kind of company they want to be: product company, services-heavy company, or a deliberate blend.
3. Use a “repeatability threshold” to decide what graduates into product
This is the single most important control.
Every field team needs a trigger for when customer-specific work stops being a field exception and becomes platform or product work.
Use a threshold like this:
- If the same capability is requested by 3 enterprise customers in 2 quarters, it enters product review.
- If a workaround requires more than 8 engineer-hours per month to sustain across customers, it is platform debt.
- If an implementation pattern appears in more than 20% of new enterprise deals, it must be templated, automated, or moved into the core product.
These are practitioner thresholds, not standards. The point is to make graduation explicit.
This mirrors what high-performing engineering teams do with toil and operational debt. The Google SRE framework uses a target of limiting toil so engineering effort remains focused on durable improvements. Different orgs use different exact thresholds, but the governing principle is stable: recurring manual work must become automation or product.
Cloudflare is a useful reference point here. Its public engineering writing often shows the same pattern: once a customer requirement appears often enough across traffic, security, or platform operations, the company turns operational necessity into productized infrastructure. That is how field reality strengthens the platform instead of fragmenting it.
4. Instrument the function with the right metrics
Most companies measure the wrong thing.
They track deal support volume, ticket counts, or vague customer happiness. Those matter, but they do not tell you whether your field role design is sound.
Use a balanced scorecard with four categories.
Commercial
- Time from technical validation start to close
- Proof-of-concept win rate
- % of deals requiring non-standard commitments
Delivery
- Time from contract signature to production launch
- % of launches using standard deployment path
- Number of customer-specific code branches or scripts still active after 90 days
Reliability
- Number of Sev 1/Sev 2 incidents in first 90 days post-launch
- Mean time to restore for launch-period incidents
- % of field-built components with monitoring, owner, and runbook
Productization
- % of field requests converted into reusable product/features/templates within 2 quarters
- Quarterly engineering hours spent on repeat implementations
- Number of top-10 blockers with no owner after postmortem review
DORA’s four key metrics—deployment frequency, lead time for changes, change failure rate, and time to restore service—remain useful here, especially for field-built components that enter production. If your FDE or implementation function is effectively shipping production systems, you should evaluate it with at least some software delivery and reliability metrics, not just customer-facing KPIs.
A practical benchmark: if more than 30% of enterprise launches in a quarter require custom code that is still manually maintained after 90 days, your product boundary is too porous or your field/product handoff is broken.
5. Build the handoff artifacts, not just the meetings
Most teams solve overlap with more syncs.
That is the wrong fix.
Meetings hide ambiguity. Artifacts expose it.
Every customer implementation that passes through Solutions, FDE, and Customer Success should produce four artifacts:
- Technical Scope Record
- Deployment Design
- Stabilization Exit Checklist
- Productization Review
GitHub’s engineering organization has publicly emphasized internal developer platforms and reusable workflows to reduce ad hoc operational complexity. The specific lesson here is not about GitHub’s exact field org. It is about how software teams scale work through standardized interfaces and documented pathways, not tribal memory. Your customer-facing technical function needs the same discipline.
Linear is another instructive reference. Linear’s product and engineering culture, discussed by CEO Karri Saarinen and observed by practitioners like Gergely Orosz, prizes tight scope, high-quality defaults, and resisting edge-case sprawl. That is the right mental model for deciding what belongs in product versus what should remain constrained implementation work. If every large customer exception gets first-class treatment, your product loses its shape.
6. Organize by dominant bottleneck, not by fashionable title
There are only three sane org patterns for early and mid-stage companies.
Pattern A: SE + Product Eng, no FDE yet
Use this when:- Fewer than 10 enterprise customers
- Launches are mostly configuration and APIs
- Engineering can absorb implementation work without roadmap collapse
Risk:
- Engineering gets dragged into pre-sales and launch support
- No clear owner for customer-specific code
Pattern B: SE + FDE + CS/CSE
Use this when:- 10–50 enterprise customers
- At least 25% of launches require deployment-specific adaptation
- Security, networking, data migration, or model behavior vary meaningfully by account
This is the most robust setup for AI infrastructure, data platforms, developer tools, and regulated B2B products.
Risk:
- FDE becomes shadow product team if graduation paths are weak
Pattern C: Customer Engineer / Technical Success hybrid, time-boxed
Use this only when:- Under 20 customers
- Moderate deployment complexity
- One person can cover onboarding and post-launch optimization without owning substantial bespoke code
This is the pattern Paraform explicitly notes can work temporarily, but should split once volume or complexity rises. That matches operator reality.
A practical split trigger:
- If one hybrid role supports more than 12 active implementations or more than 20 post-launch enterprise accounts with monthly technical escalations, split the role.
- If the same person is carrying both renewals context and production implementation incidents, split the role immediately.
The company examples worth watching are those that productized complexity rather than staffing around it.
Stripe built strong abstractions around payments, identity, and APIs, but it still uses customer-facing technical roles because real-world integrations are messy. The lesson is not “great products eliminate field roles.” The lesson is “great products let field roles spend less time on avoidable variability.”
Vercel’s platform decisions emphasize opinionated defaults and paved roads for deployment. That reduces implementation entropy. If your product lacks those paved roads, field roles are forced to invent them customer by customer.
Shopify’s platform evolution shows another version of the same thing. As ecosystems grow, partner and merchant variation explodes. The only way to scale is to turn recurrent edge cases into standardized interfaces, not to keep adding humans at the boundary.
Figma’s engineering culture has repeatedly centered multiplayer consistency, strong primitives, and constrained complexity. That philosophy matters here because field roles become manageable only when the product has reliable primitives that survive heterogeneous customer usage.
05 STRATEGIC TAKEAWAY
You should design FDE, Solutions, and Customer Success as a product boundary system, not a headcount plan. If you do this well, enterprise revenue scales without turning your engineering roadmap into custom delivery work. If you do it badly, the next two quarters fill with escalations: sales cycles lengthen, launches slip, and your best customer-facing engineers become full-time translators between promises and reality. For a CTO, this is a this-quarter decision because the cost curve bends early: once top accounts depend on undocumented field-built behavior, every org change becomes harder, not easier.
06 IMPLEMENTATION ANGLE
Start with a 30-day audit, not a reorg.
Pull every enterprise deal, implementation, and major renewal from the last two quarters. For each one, identify who owned technical scoping, who wrote or configured customer-specific logic, who handled the first post-launch incident, and whether the deployed solution had a documented long-term owner. You are looking for repeated ownership gaps, not isolated heroics.
Then create two control mechanisms immediately.
First, require a pre-close technical scope record for any deal that needs security review, non-standard integration work, private deployment, or custom data migration. Second, require a stabilization exit checklist before Customer Success inherits the account. These two artifacts alone will expose whether you really need an FDE function, whether your Solutions team is overcommitting, or whether your CS org is absorbing implementation debt.
If the audit shows the same field patterns repeating, stand up a small implementation engineering or FDE pod with an explicit productization review loop into core engineering every month. Keep it small on purpose. A large field team too early can mask product weaknesses instead of clarifying them. If you are scaling quickly, Amplify can help engineering teams scale the underlying delivery capacity, but that only works if ownership boundaries are already clear; more engineers do not fix a blurry operating model.
