Compare engineering roles by actual ownership, not the title

TL;DR: Role titles overlap across companies. Compare what each team implements, decides, operates and hands over, then verify the actual responsibilities of the job you are considering.

Where you are. The last-mile exercise exposed data, workflow and operating dependencies. Now identify who owns them without assuming that an FDE is the only engineer who builds customer-facing production software.

Responsibilities you can observe

Solutions engineers, professional services engineers, technical account managers, product engineers and FDEs can all work with customers. Many of them code, and several own production systems or contribute reusable product work, so any rule that every adjacent role stops before production is simply wrong.

The useful comparison is the center of responsibility and the agreed scope. A job title is only a clue; the deliverables, decision rights, incentives and support obligations behind it determine the work. 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.

These are tendencies, not exclusion rules. AWS Professional Services explicitly describes implementation and deployment work, providing a direct counterexample to the claim that professional services cannot build production solutions. A services agreement can also include discovery and changing requirements when its terms provide for them.

The timeline is one possible allocation

In this illustration, the solutions engineer helps establish technical fit, the services team has a defined delivery scope, and the FDE remains involved through daily use. Another organization may split the same work differently, and product engineering can take part at any of these stages; customer contact need not be mediated only by a product manager.

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” does not mean unlimited scope, indefinite support or authority to bypass a contract, so make the actual handoff explicit.

Mapping a supplied engagement

Use this synthetic freight allocation, which deliberately puts several adjacent roles in production so that you must read responsibilities rather than sort by stereotype.

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.

Now the adapter exposes a platform defect. Filing a vague ticket and walking away would leave the workflow unresolved, and patching the shared product outside its review process is no better. Supply the smallest permitted reproduction, explain affected scope, agree mitigation and track the responsible product fix. End-to-end concern and bounded authority can coexist.

Custom work and reusable learning

Customer-specific work can be useful and economically justified. It is not automatically lower quality, nor a sign that the engineer is merely a contractor, but its costs, maintenance burden and strategic value should be visible.

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

Do not copy customer-specific code or data into a shared product without the appropriate rights and review. Generalizing means identifying the reusable behavior and the variation around it, not publishing a private configuration with the variable names changed. The next lesson calculates when reuse pays for its additional work.

Questions a title cannot answer

When you evaluate 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? Who remained responsible after handover?

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

Ask how performance is evaluated: delivery quality, customer outcomes, commercial results, reuse, operational reliability or some combination. No title guarantees that one person controls all those outcomes, so look for an operating model in which responsibility is matched with resources and decision paths.

Teaching, explaining and negotiation experience can count as relevant evidence when you connect it 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; do not diminish adjacent roles to make your motivation sound stronger.

The spine above is the set of questions a title cannot answer, asked in the order one real engagement answers them.

Do this before moving on

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 does not specify one, 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.”

Write a short answer to “Why this role?” that names the actual mix of work you want and a tradeoff you accept. It passes when the claims are grounded in the job and your experience, not in saying other engineers avoid customers or production.

Go deeper

• FDE vs other engineering roles sets the same comparison against pay and career path, which this lesson leaves out.
• Explaining trade-offs is the skill that makes owning past the handoff survivable in a room full of stakeholders.
• Stakeholder management covers the people who can stop your deployment even when the code is finished.
• Travel and living at customer sites is the practical question behind whether this trade suits your life.
• OpenAI interview prep shows an AI-native version of the loop, where the boundary is drawn slightly differently.

Key takeaways

• Role boundaries vary; inspect actual deliverables, authority and support duties.
• Adjacent roles can build production systems and contribute product learning.
• End-to-end concern does not remove contracts, approvals or ownership boundaries.
• Custom work and reusable product work need explicit value and maintenance decisions.
• Verify the specific team's operating model before drawing career conclusions.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1A services engineer owns the contracted production identity migration. Does the FDE title automatically transfer that ownership?

   Yes, FDEs own everything after the demoNo; coordinate the dependency and follow the agreed responsibilitiesYes, if the customer asks informally

2. 2A job posting does not mention on-call. What should your comparison record say?

   No on-call dutiesNot stated; verify with the teamAll FDE jobs require on-call

3. 3Why can customer-specific engineering still be worthwhile?

   Answer it, then reveal