Switching fields

FDE ⇄ GTM Engineering

Forward Deployed Engineering and GTM Engineering look different on the surface: one embeds with customers to ship production software and AI, the other builds the data and automation systems behind a company's own sales and marketing. Underneath, both are engineers judged on business results rather than code alone, both work closely with non-engineers, and both now lean heavily on applied AI. That overlap makes switching realistic in either direction, as long as you're honest about the gaps.

What both fields share

  • Finding the real problem

    An FDE reframes a customer's vague request; a GTM engineer reframes "we need more leads". Both start from the workflow and the number that should move, not the tool.

  • APIs, integration and data plumbing

    Both spend much of their time connecting systems they don't control: auth, pagination, rate limits, retries and idempotency matter equally.

  • Applied AI with evaluation

    Structured outputs, hand-labelled test sets, an explicit "unknown" and humans in the loop for risky actions apply whether the model triages tickets or researches accounts.

  • SQL and practical coding

    Both roles write pragmatic code and queries to clean, join and report on messy business data, rather than building large codebases.

  • Stakeholder communication

    FDEs work with customer executives and end users; GTM engineers with reps, marketers and revenue leaders. Answer-first updates and saying no with reasons work for both.

  • Measuring business impact

    Both must show a baseline, a target and a result in business terms, whether that's hours saved for a customer or pipeline created for sales.

  • Rollout and adoption

    Systems nobody uses are failures in both jobs. Pilot with a small group, gather feedback, then widen.

Where they differ

AspectFDEGTM Eng
Who the customer isExternal customers: their teams, systems and executives.Internal teams: sales, marketing, RevOps and leadership, and indirectly the prospects they reach.
Success metricThe customer's workflow measurably improves, the deployment is adopted, and the account renews or expands.Meetings, pipeline and revenue created, cost per meeting or opportunity, and time saved for sellers.
Typical stackPython or TypeScript, cloud services, the customer's enterprise systems, LLM APIs, RAG and eval tooling.Clay-style data tables, data providers, CRM (HubSpot or Salesforce), sequencers, n8n/Make/Zapier, a warehouse, LLM APIs.
Day to dayDiscovery calls, building inside a customer's environment, debugging integrations, security reviews and presenting results.Building tables and workflows, tuning signals and copy, watching deliverability and data quality, and reviewing results with sales.
Risk profileMistakes can affect a customer's production systems, data and compliance, so reliability and security dominate.Mistakes burn sending domains, damage the brand with prospects or corrupt CRM data, so deliverability and data hygiene dominate.
Pace and feedback loopEngagements run weeks to months, with feedback through pilots and adoption metrics.Campaigns and experiments run in days to weeks, with fast but noisy feedback from replies and meetings.
Interview stylePractical coding, debugging, decomposition of customer scenarios, GenAI system design and client role-plays.Take-home table or workflow builds, live automation builds, design-a-motion cases, SQL, and stakeholder role-plays.
Career path and payToward senior or lead FDE, solutions architecture, engineering management or product. Pay usually tracks software engineering bands.Toward senior or lead GTM engineer, head of GTM engineering or RevOps, or growth leadership. Pay varies more widely, from operations bands to engineering bands at AI-heavy companies.

FDE → GTM Eng

From FDE to GTM Engineering

You already have the hard engineering half: integration, applied AI, evals and customer-facing communication. What you need is the go-to-market half: how B2B buyers are found and reached, and the tools and rules of outbound.

What transfers

  • API integration, retries and idempotency carry over directly to workflow automation.
  • Your eval habits make you better than most at proving AI research steps are accurate.
  • Discovery skills translate into understanding what reps really need.
  • Experience presenting to executives helps when reporting pipeline results to sales leaders.

Gaps to close

  • ICP definition, buying committees and how sales cycles actually work.
  • Data providers, enrichment waterfalls and the economics of credits per record.
  • Email deliverability: domains, authentication, warmup and sending limits.
  • Cold copywriting and what makes a busy stranger reply.
  • CRM data models and RevOps conventions in HubSpot or Salesforce.

First steps

  1. Read the ICP, enrichment and deliverability guides first; they're the least familiar.
  2. Build one signal-triggered account list end to end with real costs and accuracy checks.
  3. Shadow a sales rep or SDR for a day, or interview two about their workflow.
  4. Set up a test sending domain with SPF, DKIM and DMARC and read the headers.

Realistic timeline: About 2–3 months part-time to be credible, mostly on GTM fundamentals and one portfolio build.

Open the GTM Eng roadmap

GTM Eng → FDE

From GTM Engineering to FDE

You already turn messy business requests into working systems and measure their impact. The gap is production engineering depth: writing, testing and operating code inside someone else's environment, with security and reliability held to a higher bar.

What transfers

  • Working directly with non-technical stakeholders and turning requests into systems.
  • API and automation experience, especially if you've moved workflows from no-code into code.
  • Applied AI for research and classification, including prompt structure and cost control.
  • Thinking in business outcomes rather than technical output.

Gaps to close

  • Production software practices: tests, version control, code review, CI and deployment.
  • System design for reliability: failure handling, observability and incident response.
  • Security and data governance: identity, permissions, compliance reviews.
  • Deeper GenAI engineering: retrieval (RAG), agents with tool limits, and formal eval suites.
  • Coding interviews in a shared editor without no-code tools to lean on.

First steps

  1. Move one of your automations into tested, version-controlled code with logging and retries.
  2. Work through the FDE practical-coding and applied GenAI guides and their drills.
  3. Build a permission-aware RAG assistant with an eval set and deploy it to a live URL.
  4. Practise customer-scenario decomposition out loud using the FDE answer framework.

Realistic timeline: About 4–6 months part-time, most of it on engineering depth and coding-interview practice.

Open the FDE roadmap