Frontend engineer is the wrong title for the work

When I tell people I am a frontend engineer, half of them assume I mean someone who builds beautiful interfaces and hands them off to someone who handles the data. That picture has been wrong for at least a decade. I want to use one feature I built recently to explain why.

The feature is called the Trips Workspace. It is the screen at our company where a travel concierge actually executes a trip plan. The concierge sees the client, the itinerary, the open tasks, the supplier interactions, the budget state, the documents, the timeline, and the next action they should take. It looks like a productivity tool, which it is. It is also the surface where the company’s commercial intent meets the daily work.

I owned the feature. Here is what that meant in practice.

I shaped the model. The Trips Workspace is not a screen on top of an existing data model. The data model was incomplete when I started. The fields that mattered did not have a clean home. The relationships were ambiguous. I worked with the backend engineers and the product team to decide what the right primitives were, what a trip actually contains, what state transitions are legal, what counts as a task, what counts as a milestone, what fields a supplier interaction needs. The screen could not be designed until those decisions were made, and the decisions were not going to make themselves.

I wrote the queries. Once the model was right, the question was how to fetch the data the workspace needs without overfetching, without underfetching, and without surprising the user with loading states that fragment the experience. That involves understanding the database, the index strategy, the caching layer, and the network shape. It is not pure frontend.

I shaped the API contracts. The endpoints the workspace calls were not pre-built. I co-designed them with the backend team. We talked about pagination strategy, sorting defaults, partial updates, optimistic concurrency, error envelope shape, status codes, idempotency. Most of those are normally categorized as backend work.

I built the interactions. This is the part that fits the title. The components, the states, the transitions, the keyboard handling, the accessibility, the responsive behavior, the loading and error and empty states. Real frontend work, done with care.

I owned the rollout. Feature flags, percentage rollout, regression watching, error monitoring, user feedback collection. This is operational work.

I sat with the users. Concierges using the workspace, in person and over video, watching them work, asking what felt wrong, watching what they ignored, noticing where they paused before clicking. This is product work.

The title “frontend engineer” captures one of those activities. It misses six others.

I do not actually mind the title. The thing I mind is the assumption that comes with it, which is that someone with that title is somewhere downstream of the more important work. That picture is wrong. The frontend layer is where the rest of the system becomes legible to a real human. The work of making it legible reaches backward into the data model, sideways into the API design, downward into the database, outward into the supplier integrations, and forward into the operations of the people who use it. A frontend engineer who is doing the work well is touching all of those.

When an engineer takes the wider view of what their work is, the visible outputs change. The tickets close faster, because fewer of them require back-and-forth across teams to resolve. The feature ships with fewer surprises in production, because the engineer has already met the failure modes in their head. The users complain less, because the screen was shaped to the work and not to an abstraction of the work. The team’s velocity goes up. None of that shows up as frontend work. All of it depends on the frontend engineer treating frontend as the place where the system has to become legible, not as the place where styling happens.

The argument I want to leave you with is not that the title should be different. Other titles have the same problem. The argument is that ownership in product engineering is not a layer thing. The layer you live in is where you spend the most of your time. The work you own runs from the database to the user and back. If you cannot see the work that direction, you are not owning the feature. You are decorating it.