The shape of a web team has changed more in the last five years than in the ten before. The frameworks changed, the tooling changed, the server came back, and now the tools write code. I have been thinking about what that does to the roles on a team, and here is where I have landed.
The platform engineer
Every web team now sits on a platform: the component library, the build pipeline, the rendering setup, the conventions and lint rules that make a codebase feel like one codebase. Someone has to own that, and I think it is the most important role on the team and the hardest to fill.
The job is to make the other engineers faster by making the right thing the easy thing. It needs someone who likes building for other engineers, who can say no to a feature request from a colleague, and who can measure their success in work that other people did. That combination is rare. When a team has it, everything else gets cheaper.
The quality and accessibility owner
This is not a tester. It is an engineer who holds the line on how the product behaves for everyone: accessible, fast, correct on the devices people actually use. I think this role has grown because the cost of getting it wrong has grown, with regulation on one side and a public that notices on the other, and because the tools that generate interface code generate inaccessible interface code unless something stops them.
The owner builds that something. Checks in the pipeline, rules in the library, a review habit on the team. It is a role that pays for itself in audits that find nothing.
The product-minded engineer
When code is cheap to produce, deciding what not to build becomes the scarce skill. I think every web team now needs at least one engineer who thinks about the product as a product: who the users are, what they are trying to do, which of the twenty things the team could build will matter. Not a product manager. An engineer who can take a vague ask, find the small version that answers it, and ship that.
Generalists who can move
The rest of the team, and most of it, should be people who can work across the stack: a page, the layer that feeds it, the component it needs, the test. The narrow front-end specialist who only did the view layer is a role I think has been absorbed. The frameworks now expect the same person to render on the server and hydrate on the client, and the tools make the unfamiliar parts approachable. What a generalist needs is judgment, not breadth of syntax, and judgment is what I hire for.
The role I would not hire for anymore
I would not hire a dedicated build or tooling specialist as a separate role. That work is real, but it belongs to the platform engineer, and splitting it off produces a person who maintains the pipeline without owning what runs through it.
What this means for hiring
Each of these roles asks for something different in an interview. The platform engineer should talk about a time they made other people faster. The quality owner should be able to explain what a screen reader does with a page. The product-minded engineer should have a story about something they chose not to build. The generalist should be able to reason about a problem outside their comfort zone.
I think the team of 2026 is smaller than the team of 2020 and more senior, with less specialization and more judgment per person. That is a harder team to hire and a better one to work on. It also means the entry-level question gets sharper, because a team that only hires judgment has to decide how judgment gets made.
Photo source: https://photos.robertstowe.com/san-diego