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.

Compare responsibilities that can be observed

Solutions engineers, professional services engineers, technical account managers, product engineers and FDEs can all work with customers. Many can code; several can own production systems or contribute reusable product work. 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.

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.

Read the timeline as 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 assign the same work differently. Product engineering can participate 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. Make the actual handoff explicit.

Map a supplied engagement

Use this synthetic freight allocation. It 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. Patching the shared product without its review process is also inappropriate. 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.

Distinguish custom work from reusable learning

Customer-specific work can be useful and economically justified. It is not automatically lower quality or evidence that the engineer is merely a contractor. 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. This feedback is valuable but not exclusive to FDEs.

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

Ask questions that a title cannot 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? 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 current posting. 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 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 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; do not diminish adjacent roles to make your motivation sound stronger.

The spine below 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