The Perils of being a siloed frontend engineer on a team


I'm not sure if this is a hot take, but one piece of career advice I often give to frontend engineers/developers, particularly those in the early stages of their career, is to try to avoid joining a team where you are the only frontend engineer and the rest of the team works on other areas such as backend/infrastructure/ML systems.

exceptions exist…

Of course if this is the only job opportunity you've got, you don't even have other options.

Or maybe the team is working on a problem space that you really care about, or simply it pays an ridiculous amount of money, by all means, go for it.

Here are the reasons why:

Bad for career growth as a frontend engineer#

If you want to continuously develop your frontend skills and grow as a frontend engineer, such a team will not likely set you up for long term success: being the only frontend engineer on a team means the team generally prioritizes backend tasks and leave little capacity for frontend tasks, and being the solo contributor to the frontend projects means your decisions and works go unchecked by your peers. All lead to a lower career ceiling for you as a frontend engineer, when there is already a lower ceiling for frontend engineers in general.

The problem is exacerbated when you are in the early stage of your career. As a junior engineer, there is a lot more to learn outside of the official documents of your favorite framework and ins and outs of the JavaScript language. Architecture, bundling, testing and releasing practices, these skills can only be acquired by joining a team with strong frontend engineering rigor.

Managers of teams that hire for a siloed frontend role often tout the ownership and autonomy that you will have as the only frontend person on their team. However, the reality is often that your project starts with no design review, your code gets deployed without proper checks, and there is no place for healthy discussions on frontend topics, all because either they trust you as the frontend domain expert, or their bandwidths are taken up by all the backend work.

The other term they tend to throw at you is "impact". Yes, you do make a unique impact by being the only person doing the frontend work. You get to demo the UI you implemented to the stakeholders. However, this kind of impact is superficial and short-lived. It may get you promoted to an intermediate level (e.g. Software Engineer 2), but then you will likely plateau at that level (without moving to another team), because all the work that would give you the impact necessary for a promotion to the senior level is on the backend.

Bad for career growth as a software engineer in general#

I also think it's sub-optimal to join such a team for your growth as a software engineer in general.

As a sole frontend engineer, there are likely no opportunities for you to lead projects. And this can seriously limit your career growth: you need to practice leadership skills in order to level-up and get promoted to a senior level.

Would joining such a team help me transition into a backend/fullstack engineer if I don't want to continue to be a frontend engineer?

It is possible, but it could be harder than you expect. Let's say your team has nine backend engineers and one frontend engineer. Do you think at least 90% of what the team owns is backend services? If not, then transitioning the only frontend engineer on the team into a backend or fullstack role can cause a bottleneck in the team's ability to ship frontend features, unless some of the backend engineers are willing to transition into frontend roles. Chances are the manager may not be very motivated to help you make the transition. And I have seen that lead to attribution to another team or company.

What if you are already in one of those teams#

If you are already part of a team and have difficulty getting your perspective heard by your manager or peers, and you believe it would be an uphill battle to educate them on the importance of frontend work and fix that dynamics, then you should consider internal mobility.

Reach out beyond your immediate team and connect with the larger frontend community at your company (if one exists). Seek mentorship from other senior frontend engineers and include them in important meetings.

If you choose to stay with your team, work with your manager and colleagues to create a long-term vision (e.g. a three-year plan) for the frontend work your team owns. This exercise could provide more clarity on your career progress as a frontend engineer on that team.

Closing thoughts: frontend career path#

I've been thinking a lot about career progression as a frontend engineer. It's also been a running theme in my blog. If you ask me, what could be an ideal team to join as a frontend engineer? My answer would be a product team with a 50/50 split between frontend and backend devs, a healthy mix of disciplines that you can learn from. I was fortunate enough to be part of such a team at AWS and Instacart, where I was able to lead challenging frontend projects, as well as gain some backend experience. And because it is an even split, if you want to transition from one side to the other, you will have more leeway to do so.

Moreover, if the team is growing quickly, with the right team dynamics, there might also be an opportunity to transition into an engineering manager role. The transition would be almost impossible if you are the frontend person on a backend/infra team. I encourage frontend folks to take bigger responsibilities, have more agency at work, and see if a transition into an engineering manager role is possible. Aim high; If you fall short, it's not a big deal. I talked about frontend career ceiling in my previous blog post where I said part of it is due to the long-standing power structure in tech industry. I want to diversify it, so I'd love to see more frontend folks moving into the management roles.