Frontend Developer to Engineering Manager: How to Make the Move

Moving from frontend developer to engineering manager is often described as a promotion. The sources below describe something different: a change of profession that happens to share a building, a team and a vocabulary with the one you have. You stop being measured on the code you ship and start being measured on what a group of people ships, and the skills that made you a strong engineer carry over only in part. This guide covers what changes in the job, how to test the move before you commit to it, what the first months involve, what the pay data does and does not say, and what going back to engineering looks like.

Is engineering management the right move for you?

Start with the question people skip. Charity Majors, a longtime engineering leader, argues in her post on the engineer and manager pendulum that management is a change of profession, not a promotion. She quotes Sarah Mei describing the move as a lateral step onto a parallel track, one where you are back at junior level in many key skills, and she says to expect to be bad at it for a long time after you start.

Two more points from the same post are worth weighing, and both are her opinion from experience, not research findings. First, she argues you can only really improve at engineering or at management at any one time, because management is interruptive while the engineering that teaches you things needs blocked-out focus. Second, she says a hybrid of manager and hands-on tech lead is unstable, because engineering skills decay when they are practiced in leftover hours.

Her conclusion is not "never manage". She says to do it as long as it makes you happy, and then to stop and go back to building things if it does not. That framing, a stint and not a one-way door, comes up again in the section on testing the move.

What changes in the job

The clearest way to see the change is to look at what people who do the job say it contains.

Camille Fournier's book The Manager's Path is structured as a ladder, with chapters for mentoring, tech lead, managing people, managing a team, managing multiple teams and managing managers. Its tech lead chapter includes a section titled "Decision Point: Stay on the Technical Track or Become a Manager", according to the published contents list. I could read the contents list but not the chapters, so treat that as evidence of how the book frames the choice, not of what it concludes.

Will Larson offers one model of the skills. In Good engineering management is a fad, he lists eight, in two groups. The core skills needed in every management role are execution, team, ownership and alignment. The growth skills that decide how far you go are taste, clarity, navigating ambiguity and working across timescales. This is his own model, not research, and his larger point is that the expectations placed on managers shift with business conditions, so expect the emphasis to differ between employers.

Lara Hogan describes the human side in a post on manager levels, calling the switch from individual contributor to manager a huge shock to the system. The new skills she lists from her own first manager roles are working with recruiters, performance improvement plans, ending someone's employment, and tailoring your management style to each person who reports to you. A frontend engineering role does not ask for any of them.

One piece of advice to treat carefully is "managers should not code". Larson calls it a clunky preventative for micromanagement in his post on tech lead managers, not a rule about coding. The risk it guards against is real, though: he names micromanagement as the most common failure of new managers, who retreat towards work they find familiar.

What a frontend developer brings, and what is missing

What carries over is real. You can judge technical risk, you can tell when an estimate is optimistic, and you have credibility with engineers who want to know their manager understands the work. Google's published list of manager behaviours includes "have key technical skills" as one of ten, which is the clearest primary-source statement that technical depth matters, though the page does not say how much.

However, strong frontend engineering skills don't automatically prepare you for the other responsibilities of management. Coaching, performance management, career development, conflict resolution, and setting team direction require skills that may be less familiar to engineers who haven't managed people. The current re:Work guide on the research behind great managers says Project Oxygen identified 10 behaviours of highly effective Google managers:

Be a good coach.
Empower the team without micromanaging.
Create a team environment that values everyone.
Focus on productivity and results.
Communicate effectively.
Support career development and discuss performance.
Implement a clear vision and strategy.
Have key technical skills.
Collaborate across Google.
Make strong decisions.

Two cautions. The page does not rank the behaviours or give an effect size, and it does not say the list is specific to engineering managers. Older copies and many blog posts say there are eight behaviours; the current page says ten.

Gallup adds a vendor-sourced warning. Its research says there is no guarantee that someone who succeeded in a previous non-managerial role will be adept at managing others, and that managers it surveyed often cited prior success in such a role as the reason they were hired. Gallup's own wording on how common management talent is, about one in ten people with high talent to manage, comes from its own assessment instruments, which it sells, so weigh it as a vendor's claim. A separate Gallup finding is more careful and more useful: managers account for at least 70 percent of the variance in employee engagement scores across business units, per its analysis. That figure is about engagement scores, not about productivity or output, so do not quote it as "70 percent of team performance".

For a frontend-specific view, Vladimir Klepov, who spent seven years as a frontend developer before becoming an engineering manager, wrote about what he loves and hates about the switch. It is one person's account, and it is the closest thing to a frontend source I found. He argues that management methods such as one-on-ones, demos and planning change far more slowly than frontend frameworks, so the knowledge rots less. On the costs, he reports long feedback loops, with very few of your actions producing a visible result in under a month, and the work of handling tension between people. He also hedges: if you hate it, he says, you have plenty of time to go back into coding.

How to test the move before you commit

Because you often cannot know until you try, the practical question is how to try cheaply.

GitLab's public engineering careers handbook is the most concrete source I found. It has a section titled "Trying the Management Track" that recommends getting opportunities to try management before committing, with examples such as hosting a group conversation, acting as hiring manager for an intern, or running a series of demo meetings. It also describes two temporary roles:

An acting manager role is temporary, and the person moves back to their original role after a set time or other conditions.
An interim manager role is for someone pursuing management long term. GitLab generally sets a three-month timeline for interim management roles, with making one successful hire as the primary success criterion. When hiring isn't feasible, the interim manager and their manager can agree on alternative criteria, such as successful career development conversations or an assessment of management competencies. Moves between the individual contributor and manager paths go through an interim or acting role for four to six months before becoming permanent.

The handbook's line on risk is the most useful one: at worst, the person would return to their prior responsibilities, with the caveat that this does not protect against termination for other reasons such as a conduct breach. These are one company's rules, not industry norms, and I found no data on how many people return to individual contributor work or how they fare afterwards. But if your employer has no formal process, the structure is something you can propose: a time limit, a clear success measure, and an agreed way back.

On the question of doing a tech lead role first, the sources are more cautious than a simple "lead first, manage later" path. Larson's post on tech lead managers calls the combined role usually a trap for first-time managers, because the team is small, you stay deep in the technical details, and you are expected to make direct technical contributions. He recommends against starting a management career in that role, though he says it is not always a bad choice for people with experience in both. A tech lead stint can still teach you whether you enjoy coordinating others, as GreatFrontEnd's guide to frontend developer to tech lead covers, but none of the sources I read recommend it as a formal management trial. Only GitLab recommends trial tasks and acting or interim roles.

A Master.dev post on how to decide if engineering management is for you says it is common to try the role for a few months or a year and decide it is not for you, which fits the same picture.

The first months

Plan for the pitfalls that experienced managers name, because they are consistent.

Larson's older post on ways engineering managers get stuck lists patterns for managers in their first couple of years: only managing down, only managing up, not spending time building relationships, and defining your role too narrowly. For managers at any level he adds mistaking team size for impact and mistaking title for impact, and says that managing a larger team is not a better job, it is a different job.

Hogan's advice to spend the first 30 days in "sponge mode", listening and holding one-on-ones with everyone, comes from her post on the first 30 days in a new role. It is written for director-level and above hires, not first-time team managers, so adapt it rather than copy it. Listening before changing things is sound at any level, but the scale is different when you manage five engineers you already know.

A practical scenario from the Master.dev post is worth repeating, with the warning that it is a hypothetical and not data: a top engineer who becomes interim manager keeps saying yes to everything, cancels one-on-ones to catch up on code, and burns out the team. The lesson is the same as Majors': the time you spend on the people side is the job, not an interruption of it.

Pay and outlook

Check the numbers carefully, because they are easy to misread. The US Bureau of Labor Statistics publishes two relevant pages, both last modified on 27 August 2026.

For computer and information systems managers, the median annual pay was $175,140 in May 2025, and employment is projected to grow 16 percent from 2025 to 2035, against 3 percent for all occupations. The page lists a bachelor's degree plus five years or more of related work experience as the typical entry requirement.

For software developers, the median annual pay for software developers was $135,980 in May 2025, with 10 percent projected growth over the same period.

Three limits on reading those figures. The managers category is broad, and its examples include chief information officers and chief technology officers, so it is not the same as an engineering manager leading a product team. The gap between the two medians is a gap between two occupation groups, not what a developer earns after switching. And the pages break nothing down by company, level or frontend specialty. GitLab's handbook, for one company, says staff-level and engineering manager roles are equivalent in base compensation and prestige, while Klepov argues from his experience that managers are normally paid higher than team-level grades. Treat pay as something that varies by employer, and ask for the actual band for the role you are considering.

The alternative: staying on the technical track

Management is not the only way to keep advancing. Larson's staffeng.com says that, in his experience, you can reach senior software engineer in five to eight years and can then pursue engineering management or continue towards technical excellence as a staff engineer. That timeline is his own claim, not measured data. He also says the management route is better documented, while the transition into staff and beyond remains particularly challenging and undocumented.

GitLab's handbook treats technical leadership and professional leadership as two paths, and says engineers should self-select into management and not feel pressured. If you are weighing both, GreatFrontEnd's frontend developer career path guide maps the stages, and the frontend architect guide covers one technical option.

Going back

The sources say the move is reversible, with conditions. GitLab's handbook says a transition plan should allow a return to the individual contributor track if management is not for you. Majors goes further and argues that the best frontline engineering managers are never far from hands-on work, and that the best individual contributors have spent time managing, though she is explicit that this is her opinion and the "two to three years" she suggests has no data behind it.

If you go back, your technical skills need active maintenance in the meantime, and that is easier to arrange before you start than after. Keep a small area of code you still understand, read pull requests for context, and do not let your frontend knowledge freeze at the framework version you last shipped.

Frequently asked questions

Do I need to be a tech lead first? No source I read says so. Fournier's book treats tech lead as one rung of a ladder, and GitLab's handbook uses acting and interim manager roles as trials. Larson cautions that combining tech lead and manager duties tends to be hard for a first-time manager.

Will I earn more? It depends on the employer. BLS shows a higher median for the broad managers category than for software developers, but the categories differ, and GitLab says its staff and manager roles are equivalent in base pay. Ask for the band.

Can I still code as a manager? Larson argues the "managers do not code" rule is a clunky guard against micromanagement and not a requirement. Majors argues that doing both at once is unstable. Decide what you will actually protect time for, and be honest about how much of it is real.

Is engineering management harder for frontend developers? I found no data on frontend developers specifically. Klepov's account suggests the people skills transfer and the framework knowledge does not need to keep up with every release, but that is one manager's view.

Conclusion

Moving from frontend developer to engineering manager is a change of what you are responsible for: from the quality of your own output to the output and growth of a team. The most careful sources describe it as a change of profession, point out that technical depth is only one of Google's ten behaviours, and recommend trying it in a bounded way, through acting or interim roles with an agreed way back. The pay data is real but loosely connected to the job you would actually do. If you are curious, run a small, time-limited trial and measure how you feel after a quarter, not after a week. If it fits, you will know. If it does not, the same sources say returning to engineering is possible.