Full-stack Engineers Aren’t Myths — They’re Makers

In 2018, there were roughly 30% more full-stack engineering roles posted to AngelList than there were front-end or back-end positions. To many in the engineering community, this is a bad thing.

Over the last 10 years, think piece after think piece has been published questioning the legitimacy of full-stack engineering roles. The criticism can be bucketed into two claims:

• Full-stack engineering roles are unrealistic. With how complex the average stack is today, no one could possibly become an expert in every piece of it.
• Full-stack engineering roles are exploitative. Cash-strapped companies hire full-stack engineers to do the job of multiple engineers for one salary.

But does the data support either of these claims?

In short: No. The data doesn’t indicate the full-stack roles are exploitative in salary or unrealistic in scope. In fact, it suggests that if you’re interested in a cross-functional position, in learning new skills, or in working at an early-stage startup, a full-stack engineering role might be the perfect job — if you know what to look for.

All of this criticism really starts with a fundamental misunderstanding of full-stack roles.

Why “full-stack” really means “early-stage”

One of the chief criticisms of a full-stack role is that it pays a generalist less to handle an entire stack than it would pay a specialist to handle one piece of that stack. To the critics’ credit, there is some data to back this up:

Full-stack engineers in New York and San Francisco make less, on average, than front-end or back-end engineers in the same cities. But this is not the smoking gun critics make it out to be. If you look at the same data, you’ll see full-stack engineers in San Francisco and New York City also receive larger equity grants, on average, than engineers in specialist roles:

To understand why this is happening, we need to look at how different engineering roles are distributed by company stage. While the majority of front-end and back-end job listings on AngelList belonged to companies with more than 10 employees, the majority of full-stack job listings belonged to companies with fewer than 10 employees. To be clear, that’s fewer than 10 total employees, not just engineers.

Full-stack engineers are disproportionately distributed toward early-stage companies, where salaries are lower, but equity grants are higher. Comparing the average salary of a full-stack engineer to a front-end engineer’s is really a comparison of early-stage salaries to later-stage compensation. Full-stack engineers at seed-stage startups aren’t supposed to be experts at every piece of the stack. Full-stack engineers need to know enough — or be able to learn enough — to build and ship a product with a small team of contributors.

As a startup scales, specialist engineers will be necessary to handle the increasing complexity of the product, but at the seed stage, a startup needs makers — and that’s exactly what full-stack engineers are.

Why would engineers want to be full stack?

While the argument for why early-to-mid stage companies need full stack engineers is clear, why would you, as an engineer, want a full-stack role? What is your upside?

Majed Itani, head of engineering at SetSail, an early-stage AI-powered startup helping sales teams, exclusively hires full-stack engineers. He says he believes there are two groups of people who get the most out of full stack roles:

• Engineers early in their careers who want to learn as much as possible.
• Engineers later in their career who thrive on generalist work.

For junior engineers, “if you want to learn everything, go to a seed-stage startup,” Itani says. At a larger company, you’d likely be responsible solely for integrations or a database. At an early-stage company, you’ll be responsible for figuring out how to build a new product, which could mean learning the infrastructure, the back-end, and the front-end all in the same month.

By the same token, Itani says he believes senior engineers who like owning a product from idea to production, who want exposure to fundamental business problems, and who prefer generalist work, tend to be happiest in full-stack roles, where they are virtually guaranteed to never be pigeonholed into doing one thing.

If you fit either of these profiles, a full-stack engineering position may be the perfect role. Now you just need to know how to find a good one.

How to tell good full-stack engineering roles from bad

It’s not hard to find a job listing for a full-stack engineering role. The key is knowing how to vet them. Positive signals on a job listing include:

• The startup will be early-to-mid stage (fewer than 50 employees).
• The role will offer a larger equity stake than the industry average for specialist roles. You can check averages here.
• The role’s responsibilities should include some product-level decisions.

Ideally, all of this information will be listed on the job posting. Bonus points if the company has documented its philosophy on full-stack engineering.

While there are some obvious immediate red flags — if a company wants to severely underpay you, or expects five years of experience in 18 different technologies, run — what qualifies a “bad” full-stack engineering role is going to depend on your priorities.

Full-stack engineers aren’t myths — they’re makers

The debate over whether full stack engineers are myths or not has always been misguided. The critics are correct that there’s no giant pool of engineers who have mastered every piece of the stack and can ship beautiful enterprise software single-handedly. That definition, however, is not what a full-stack engineer is.

In practice, a full-stack engineer is one who is close to a product in its early stages, who has the generalist skills to jump from one piece of the stack to another, and who has the speed and agility to ship features and fix bugs as the product grows.

The task of a full-stack engineer isn’t to be a world-class specialist. It’s to be a maker — and early-stage startups need makers more than anything in the world.

Originally published at angel.co.