Frontend Engineering: SFIA levels and developer seniority
Fennec team · 26 Jan 2026 · 5 min read
Frontend stopped being "the styling job" a while ago. These days it's component architecture, state management, performance budgets, accessibility, and increasingly the server-rendering calls that used to belong entirely to the backend. There's a huge gap between someone who can tweak a stylesheet and someone whose design system twenty other engineers build on, and job titles almost never say which side of that gap a person is on.
That's the gap SFIA is actually good at closing. A "Senior Frontend Engineer" at one company and a "Senior Frontend Engineer" at another can sit a full level apart, same words, different job. What separates them isn't the title, it's the stuff below: what you built, how much of it you did without being asked, and how far your calls actually reached past your own code.
1
Level 1: Follow
“I can make basic HTML/CSS changes following clear instructions. I need guidance on most JavaScript tasks and haven't shipped a production feature independently.”
Right now you're learning by doing, and your evidence should look like it: a pull request where you followed an existing component pattern and a reviewer walked you through what you missed, before-and-after notes from a small bug fix someone checked over your shoulder, a certificate from a React, Vue, or CSS fundamentals course. None of it needs to be impressive. It just needs to show the muscle memory is forming.
Getting past this is mostly repetition with feedback attached. Take one well-scoped ticket a sprint and actually ask your reviewer why they left the comments they did, not just what to change. Build a couple of throwaway apps purely to get fluent in your framework's fundamentals, and ask to pair with a mid-level engineer on something real instead of just watching.
2
Level 2: Assist
“I build simple UI components following existing patterns, and I can fix most straightforward bugs without help. I'm learning a framework but still need guidance on complex problems.”
The shift now is independence on the easy stuff. Pull requests for components you built solo from an existing pattern, with review comments only landing on the tricky edge cases. A bug you tracked down and fixed end to end, nobody walking you through the cause, counts for a lot here, and so does writing your own component tests without being told to.
Make testing a habit, not a request, that's the single biggest lever. Pick one ticket a sprint that sits slightly outside your comfort zone, an awkward layout or a new API integration, and go past the tutorial level of your framework's docs, React's own guidance on rendering and effects is a good place to actually dig in.
3
Level 3: Apply
“I build and ship features independently without supervision. I can take a design and turn it into working code, write component tests, and give useful feedback in code reviews. I've been doing this for a few years and the work feels natural.”
Somewhere around here, supervision stops. Your evidence is a feature you carried from ticket or design straight to shipped production code, code review comments that genuinely changed how something shipped, a performance, accessibility, or UX issue you caught and fixed before anyone flagged it.
What tends to unlock the next level is picking one whole feature, scoping through rollout, and owning every inch of it yourself. Start reviewing other people's pull requests as a matter of routine, not just receiving reviews on your own, and go deep on one area, performance, accessibility, testing, until people start asking you about it specifically.
4
Level 4: Enable
“I'm the person other developers ask when they're stuck. I set standards, make the hard technical calls, actively help junior engineers grow, and take ownership of an entire area, not just individual tickets.”
The evidence stops being about your own code and starts being about its reach: a frontend standard or shared component that other engineers actually use, a thread where people waited for your call on a disagreement, a junior engineer you mentored who visibly leveled up because of it.
Write the RFC instead of waiting for someone else to. Pair with and unblock other engineers even on tickets that aren't yours. Taking ownership of something cross-cutting, a design system, a build pipeline, a performance budget, is usually what makes the next level obvious to everyone else before you've even said anything.
5
Level 5: Ensure & Advise
“I set technical strategy across multiple teams. My decisions shape how the whole engineering organisation builds frontend, and I'm brought in when there are cross-team or long-term technology choices to make.”
Now the evidence spans teams you're not even on: a cross-team architecture call you drove, a micro-frontend split or framework migration with a rationale people actually read, getting pulled in as the outside expert on someone else's frontend decision, a talk or RFC that traveled well past your own team.
This level usually starts with writing an architecture decision record for something more than one team depends on. Build relationships with other tech leads deliberately, so you're the first person they think of, and track a frontend-wide metric, Core Web Vitals or bundle size, across teams rather than just your own patch.
6
Level 6: Initiate & Influence
“I define frontend engineering direction and culture at an organisational level, and the industry pays attention to what I ship or write.”
This level looks like direction people follow without being told to: a frontend strategy adopted org-wide with your name on the document, a post, open-source project, or keynote that traveled outside the company, organisation-level metrics that moved because of a call you made.
From here it's mostly reach beyond your own company: publish your thinking externally, set the hiring bar and career ladder for frontend at your org, and expect to spend real time in the leadership and strategy conversations that decide where the discipline goes next.
Go deeper
Google's guidance on performance, Core Web Vitals, and modern browser APIs.
Practical, example-driven CSS and layout patterns.
Long-form articles on UX, performance, and accessibility.
A weekly podcast on the day-to-day frontend ecosystem.
Knowing where you sit is one thing, proving it later is another. Fennec lets you log frontend engineering evidence as you go, a shipped feature, a decision, a review, tagged to the level it demonstrates, so the case for your next step is already made when you need it.