The “front end” is pretty nebulous. What makes a good front end developer? Its definitions, and so its answers, are all over the place. It’s not just the introduction of new front end frameworks that have changed how we talk about it, but in terms of the discipline of designing websites we have begun to think differently: in components, in services. We can see front end in flux in Ernie Hsiung’s “A fictitious, somewhat farcical conversation between me and the JavaScript programming language,” where Ernie as a front end developer — a successful front ender, look at his resume — imagines having an existential crisis because the front end changed while he was busy being a boss (a good one).

Our understanding of the front end as a place no longer holds up to scrutiny. We cannot define it by a specific suite of tools, a kind of user expertise, or even that — if anything — front end development requires a browser.

If we talk about the front end in terms of distance from a user, the “front” specifically being the interface between the user and the service provided, then we ought to accept that voice user interfaces (among other examples) challenge the notion that the front end has any tangible component at all.

Even here, we are cherry-picking a particular kind of user, one that is at the tail-end of a complex service provision - presumably outside the “provision” circle of the Venn Diagram altogether. We’ll call this person “end user.” But again, using “front end” as a descriptor of that distance from a user — while accepting there are no constraints on technology or medium (like a browser) — should be applicable to the RESTful API that I design for consumption by a variety of user interfaces. The consumer is my end user. When I design the interface for that user, am I performing “front end development?”

What I am trying to illustrate is that when we are thinking about user experience and service design, paradigms like “front end” and “back end” no longer align with an understanding of service clusters, ecosystems, or - frankly - users. These kind of identifiers are ephemeral and, as such, pose a problem to companies who organize themselves around these concepts.

You long time Metric readers and listeners — “Metricians?” — might find this latter concern familiar. The practice of thinking in services reveals that same ephemeral nature around the product itself, given that the product is just a tool in a larger service provision, it is thus — like a tool — replaceable. Choosing to design organizations around products will shape the way in which said organizations develop, which is probably against the grain of good service design. Hot take, I know.

So, practically, as service providers who make products that require engineers, how do we hire after we thought-spiral ourselves away from terms like “front end developer?”

I think there is an implied solution. In 2017, Rob Schade at Strategyn suggested a new kind of role called the “Job Manager” in “Product Managers are Obsolete; focus on the Job-to-be-Done.” As an alternative to a Product Manager, the Job Manager focused on the design and development of solutions for a given job-to-be-done.

If you need a refresher, a job-to-be-done describes a task where the user has a demonstrable need for the solution you provide. That is, if I need talk shop and further develop my own thinking about service design, a company like Substack provides a solution for my shop-talking need. The product — the newsletter editor and mailer that Substack provides — is a means to an end, not the end, and not necessarily crucial to my job to be done.

In this example, rather than there being a Product Manager in charge of the newsletter editor, there would be a Job Manager overseeing the entire service Substack provides that connects me to you. These circles overlap, but the lens is very different.

I think there is room then for “Job Designers” and “Job Developers.” These are the design workers who, alongside the Job Manager, provide the company’s solution for a specific job to be done.

A huge benefit, you argue, for “front end” is that even if the definition is super loose it implies some kind of big umbrella of skills around which people can identify. Maybe that is, regardless of which framework compiles them, something to do with HTML, CSS, and JavaScript. There is nothing about “Job Developer” that implies what that person does.

I agree. While I think it’s liberating to disassociate the technology from the service provided, it makes this shit hard in a different way.

Rather, I think there’s room for specialization, in the way that “front end” and “back end” are technically specializations of just “developer.” This specialization is also implied by jobs to be done.

A job to be done is composed of jobs to be done. In the job that is “understand the civic role I have in my community,” there is a subsequent job that is “see the agenda for upcoming city council meetings in my email.” There are jobs that imply the interface, so there is a role in the service provision to provide that service to that interface. Make up a title that works. Surely “interface developer” — or, even, “civic interface developer” — has more semantic meaning that “front end.”

That’s sort of about the point where I stop caring and let you all figure it out. Titles. Some projects need only one developer, others need one hundred. Few job titles really hold up to the scrutiny — I’m looking at you, Business Analyst 1 — and “front end” or “back end” won’t solve that.

More importantly, a jobs-to-be-done approach to role-making is still fundamentally about spatial relationship to the user. These kinds of roles are user centric - all of them. Whereas “front end” and “back end” might describe distance from a user, all job-to-be-done style roles imply the user in their very description. Each job solution has a userbase, and so fundamental skills like empathy, data-driven decision making, and user advocacy (privacy, accessibility, usability) are part of each job - regardless of where they are in the stack.

Liking (❤) this issue of Metric is a super way to brighten my day. It helps signal to the great algorithms in the sky that this writeup is worth a few minutes of your time.

Metric is a podcast, too, which includes audio versions of these writeups and other chats. Look for “Metric UX” in your favorite podcatcher.

Remember that the user experience is a metric.

Michael Schofield