Compare engineering roles by actual ownership, not the title

This is lesson two of Foundations of Forward Deployed Engineering. Role titles overlap across companies. So compare what each team implements, decides, operates and hands over. Then check what the job you're looking at really asks of you.

In the last-mile exercise, you found data, workflow and operating dependencies. Now you'll work out who owns each of them, without assuming that an FDE is the only engineer who builds customer-facing production software.

Start with the work you can see. Solutions engineers, professional services engineers, technical account managers, product engineers and FDEs can all work with customers.

Many of them can code. Several can own production systems, or contribute reusable product work. So a universal rule that every adjacent role stops before production is incorrect.

The useful comparison is the center of responsibility and the agreed scope. A job title is a clue. Its actual deliverables, decision rights, incentives and support obligations determine the work.

Why do titles overlap? Because each company draws the line where its own sales motion, delivery contracts and support obligations happen to fall, so the same word lands on different work in different organizations.

Each role has a common emphasis, and it's where the role tends to put its time. A solutions or sales engineer leans toward technical discovery, demonstrations, proof of fit and pre-sales decisions, professional services or delivery toward implementations, migrations and outcomes under an engagement agreement, a technical account manager toward the technical relationship, operational guidance and coordination, a product engineer toward shared product capabilities and their reliability, and a forward deployed engineer toward customer-context implementation, discovery and deployment outcomes.

Each emphasis comes with a question that reveals the actual boundary. Does the solutions team build production integrations, or stay involved after signature? For services: what's in scope, who approves changes, and what support follows delivery? Does the account manager write code, lead incidents, or provide advisory escalation? How directly does the product team work with customers and own deployed behavior? And for the FDE, how much is bespoke code, platform work, production support and product feedback?

These are tendencies, not exclusion rules. AWS Professional Services explicitly describes implementation and deployment work. That's a direct counterexample to the claim that services can't build what runs in production. And a services agreement can also include discovery and changing requirements, when its terms provide for them.

Next, read the lesson's timeline as one possible allocation. It runs across four phases: pre-sales, pilot, production and daily use.

In this illustration, the solutions engineer helps establish technical fit in pre-sales. The services team has a defined delivery scope, across pilot and production, bounded by the statement of work. And the FDE stays involved from the pilot through daily use, building and following workflow outcomes.

Another organization may assign the same work differently. Product engineering can participate at any of these stages. And customer contact need not be mediated only by a product manager. Confirm each team's actual duties and support scope.

An FDE may start before a contract, and may transition operation to a customer or managed-service team after an agreed acceptance point. "Own the outcome" doesn't mean unlimited scope, indefinite support, or authority to bypass a contract. Make the actual handoff explicit.

Now map a supplied engagement. This synthetic freight allocation deliberately puts several adjacent roles in production, so you have to read responsibilities rather than sort by stereotype.

Six facts. Technical fit and demo limitations are documented before purchase: that's the solutions engineer. A contracted identity migration includes production rollout, and that one's with services. A platform query defect affects several customers. That's the product engineer. The exception workflow needs a customer-specific adapter and evaluation, and that's the FDE. Production escalation and service review follow the support agreement: the account manager coordinates, and a named engineering team resolves defects. And extra scope changes cost and timing, so it goes to the commercial and delivery owners who are authorized to decide it.

Every row still needs coordination. The FDE and customer validate the real source assumptions behind the fit. The customer's identity owner approves mappings and access. The FDE supplies a minimized reproduction of the defect, and its deployment impact. The data owner confirms semantics, and operators review outcomes. Incident ownership and response commitments stay explicit. And the FDE and services provide estimates and dependencies for extra scope.

Now a customer asks the FDE to take over the identity migration, "because you own the outcome." The packet already gives implementation responsibility to services, and approval to the identity owner. The FDE can help diagnose a dependency and coordinate a repair, without silently taking over the migration or granting permissions.

Then the adapter exposes a platform defect. Filing a vague ticket and walking away would leave the workflow unresolved. Patching the shared product without its review process is also inappropriate. Instead, supply the smallest permitted reproduction, explain the affected scope, agree a mitigation and track the responsible product fix. End-to-end concern and bounded authority can coexist.

Next, tell custom work apart from reusable learning. Work done for one customer can be useful, and it can be worth what it costs.

It isn't automatically lower quality, or evidence that the engineer is merely a contractor. But its costs, its maintenance burden and its strategic value should be visible.

Repeated needs may justify something shared: a connector, a template, a deployment check, or a product capability. An FDE can contribute the field evidence and the implementation, while product and platform teams help decide the right reusable boundary and the long-term owner. This feedback is valuable, but it isn't exclusive to FDEs.

Don't copy one customer's code or data into a shared product unless you have the rights, and it's been through review. Generalization means identifying the reusable behavior and its variation, not publishing a private configuration with different variable names. The next lesson calculates when reuse pays for its additional work.

Finally, ask the questions that a title can't answer. When evaluating a role, ask for a recent engagement example, and follow it through its lifecycle.

Who wrote the production code? Who approved access? Who handled the first incident? What changed in the shared product afterward? And who remained responsible after handover? Where an answer is missing, keep "not stated" apart from "not part of the role."

Clarify the practical terms too: travel frequency, duration and notice, working hours, on-call expectations, the number of simultaneous accounts, and the balance between customer code and platform work. Verify these with the specific team and the current posting. Don't infer a company's present travel model from an old employee account, or another office's role.

Ask how they judge how well you're doing: delivery quality, customer outcomes, commercial results, reuse, operational reliability, or some combination. No title guarantees that a person controls all those outcomes. Look for an operating model in which responsibility is matched with resources and decision paths.

Teaching, explaining and negotiation experience can provide relevant evidence, when it's connected to the role's work. Avoid unsupported claims that a particular background guarantees a hiring advantage. In an interview, explain a real trade you understand, and an example you can honestly discuss. And don't diminish adjacent roles to make your motivation sound stronger.

Your turn. Pause the video here. Draw a responsibility map for the six-row freight packet. For each row, distinguish the person implementing, the decision-maker and the team supporting the result. Where the packet doesn't say, mark it unknown, and write the question needed to resolve it. Then compare two current job descriptions, saving their sources and dates. Record explicit evidence for customer discovery, production coding, incident responsibility, reusable product work and travel. Keep "not stated" separate from "not part of the role." Finally, write a short answer to "Why this role?" that names the mix of work you want and a tradeoff you accept. It passes when it's grounded in the job and your experience, not in saying other engineers avoid customers or production.

To recap. Role boundaries vary, so look at the actual deliverables, authority and support duties. Adjacent roles can build production systems and contribute product learning. Caring about the whole outcome doesn't remove contracts, approvals or ownership boundaries. Custom work and reusable product work need explicit value and maintenance decisions. And check how the specific team really works before you draw any career conclusions.

That's lesson two. Next in the series, run the engagement as a learning loop, with explicit release gates. The full lesson, with its exercise and drill, is on fdeinterviews.com.