Should you dive deep into one front-end framework or try to learn all of them?
How do you know if you’re ready for a senior engineering position?
What should you even be working on learning?
These questions are extremely common in a field as rapidly changing as software engineering, and particularly front-end development, and answers are hard to find.
Luckily, there’s some great resources out there - a bunch of top companies have published their engineering career roadmaps that we can look to as guidelines for how careers progress.
But it’s still kind of overwhelming to dig through. There’s a TON of resources, and they’re all somewhat different. Someroadmaps have more levels than others, some use different names, some include management and some do not. Some focus on design, others on engineering.
But there’s enough commonalities that I think we can draw some big pictures together. This post is an attempt to dothis, to provide a roadmap for understanding how career advancement looks across the industry.
For each job title, I pull together a set of typical characteristics, a set of milestone-related questions to ask yourself to understand if you’re operating at that level, some items to focus on, and some recommended resources.
Note: This is slightly incomplete, but I found myself referencing it enough I want to make it public anyway. In particular, I do not currently include info on ‘what to focus on’ or recommended resources for the highest level of individual contributor, and drop both these and the ‘what to focus on’ or the upper levels of management. If you’re in one of those roles and would like to contribute guidance please leave a comment.
Some things to be aware of as you look through this article, and to understand how I’ve pulled these together from the underlying data
Many published engineering progressions separate out different categories of skills (technical skills, communication skills, leadership, making your team better…) and some map progressions in each. I have deliberately kept a single progression for simplicity, but you will see different types of skills, with the emphasis changing as you move through different positions.
Not every engineer is expected to go through all of these levels. Many will very happily get to senior engineer and not move up further levels. There is room for progression (both in skill and pay) within each level.
Smaller companies will tend to have fewer formal levels, sometimes with only one or two, while larger ones will have finer-grained progressions. Regardless of your current official title, you can use this progression as a way to identify where you’re at in your career and what would be helpful for you to focus on.
Management is a completely separate track from engineering (makers). It is emphatically not the “natural” step up, or even necessarily “above” higher levels of engineers. In most progressions, a low level manager is about equivalent to a “Lead” engineer or even “Senior” engineer in terms of pay grade.
The first step getting into the industry. Typically straight from university or a boot camp. Where we all started!
- Typically 0-2 years of experience.
- Typically working on well-defined tasks
- Often doing a lot of bugfixes
- Learning skills & processes
- Learning how to learn
- Are you able to apply most of the fundamentals of your area of focus? (backend dev => CS concepts, databases, servers, FE => HTML, CSS, accessibility, etc)
- Are you able to prioritize and complete well-defined programming tasks?
- Are you actively working to learn and improve your skills?
- You should be working on getting deep understanding of 1 specialization. E.g. Focus on frontend or backend, pick a framework, and go deep.
- You should be working on improving your habits. Get into habits of learning, being productive every day, and making lists of what you need to get done.
Note: Depending on what domain of software development you work in, there are a ton of domain-specific resources out there. I’m not going to try to detail them all, rather pointing to more generalized resources.
- JSParty #97 - learning how to learn
- Clean Code: A Handbook of Agile Software Craftsmanship (book)
The “in-between” between a junior and senior. At many companies they may just call this position “engineer”, though at many startups that’s the only title they ever give so the name isn’t super helpful.
- Typical 2-5 years of experience
- Able to design & architect implementation of features within area of expertise
- Follows established patterns and conventions without need for guidance
- Generally able to debug own code
- Involved in team-level technical discussions
- Can you take a small to medium sized feature from start to finish with minimal guidance?
- Are you able to unblock yourself when you run into problems?
- Do you participate in team discussions about technology choices and decisions?
- You should continue to specialize, and work on understanding how to build something front to back in your area of specialization.
- Work on communicating about your area of specialization. Participate in discussion, debate, and figuring out the right approach. Perhaps start writing blog posts focused on this area, or participating in tech talks.
- Start learning a bit about the systems your specialization interacts with. You probably don’t need to fully understand them yet, but you should be aware of what they are and how they interact with your domain.
This is when you first really start having to branch out beyond your “bread and butter” areas. This includes getting comfortable in other parts of the tech stack and may start touching on things that are not purely technical.
Many engineers stay at essentially this level, and that’s okay. Going up beyond this involves more and more of your job being outside the code.
- Typically 5+ years of development experience
- Starting to take on “tech lead” responsibilities of keeping things moving
- Typically own entire services or large tech components.
- Mentor junior engineers, give feedback in code reviews
- Work to set & maintain standards and processes
- Understand the relevance of their “owned” services/components to the business
- Communicates effectively with designers, product managers, etc.
- Communicates technical decisions & concepts internally and externally with documentation, blog posts, tech talks, etc.
- Do you own the development of an entire service or large component front to back?
- Are you regularly giving feedback to junior engineers, both in code reviews and outside of them?
- Are you involved in setting standards (e.g. code quality) and processes (e.g. scrum) for your team
- Practice your verbal and written communication skills. You should be able to clearly present your points of view in either prepared or impromptu scenarios.
- Learn about the way all of the different systems in your software work and interact. You should now not only be an expert in your specialty but have a solid understanding of how the entire system works.
- Get comfortable having 1 on 1 conversations with other engineers, giving helpful feedback, and guidance.
- Start understanding the business implications of technical decisions. How does your company actually benefit or make money from your software? What parts are important to the business and which parts don’t matter as much to them?
- Clean Architecture: A Craftsman’s Guide to Software Structure and Design (book)
- On Being a Senior Engineer (blog post)
Sometimes called “tech lead”, this one of the most challenging transition points in the industry because you’re still deeply involved in the tech stack, but your primary responsibilities and focus suddenly have to expand to include a ton of human questions.
- Typically 8+ years of development experience. Some orgs have this as “parallel” or “orthogonal” to pure dev track (e.g. https://docs.google.com/spreadsheets/d/1k4sO6pyCl\_YYnf0PAXSBcX776rNcTjSOqDxZ5SDty-4/edit#gid=0 from Rent the Runway) but even there expectation is to keep going on eng track you’ll work as lead sometimes.
- Engage in technical project management
- Delegates tasks and projects to others.
- Understand motivations & career goals of their team
- Give regular feedback to team members on growth, progression towards goals, areas for improvement, and praise
- Leads via influence rather than having direct reports
- Proactive in identifying and clearing roadblocks for the team.
- Typically coding much less. Some organizations just enough to keep familiar with codebase/hand in. Others only when it’s super high leverage to set example/clear roadblock.
- Anticipate technical issues, manage risk, and communicate with stakeholders about these.
- Fully understand the business value from your software & impact on customer.
- Do you help translate business and product needs into technical architecture for your team?
- Do you communicate updates and roadblocks to stakeholders outside of your team?
- Do you lead discussions and make decisions on standards and processes for your team?
- Do you give regular feedback and mentorship to your team members?
- Do you understand what types of tasks and projects are exciting for each of your team members?
- Do you help determine who on your team does what work, either by facilitating or directly delegating and assigning work?
- Learn to lead/manage a meeting.
- Learn how to work productively with stakeholders. Understand their goals and how to translate engineering concepts for them.
- Learn how architectural decisions impact business outcomes. Work to understand when technical debt can be useful to incur, and when it starts to become a problem.
- Learn how to lead others to learn, grow, and make good decisions by framing situations and asking questions.
- Measure your impact by the influence of your actions rather than the code you write.
- Learn to manage your own emotional state - when others look to you as a leader, your words & actions have an outsized impact.
These are industry leaders. Some companies create even more levels beyond this, “fellow”, etc, but however you break it down these are people who are movers and shakers in the industry as a whole. Many will never get here, and that’s okay!
- Typically 12-15+ years of experience
- Setting technical direction for the entire organization
- Identifying strategic technological growth opportunities
- Develop & communicate multi-year technical strategy
- Act as multiplier building systems, tools, and policies/patterns
- Wide industry recognition, participation in industry conversations & moving forward state of the art
- Has thorough understanding of the entire business and how different domains contribute to overall business strategy
- Facilitates organization-wide discussions
- Anticipates technical problems that will fall out of major projects, and designs solutions to overcome those problems
- Are you looking at technology trends and which are relevant and important to your business?
- Are you setting technology direction for your company or organization?
- Are you putting together multi-year technology roadmaps?
- Are you involved with industry state-of-the-art conversations via groups like standards bodies?
- Are you leading conversations about architectural and technology decision tradeoffs and their impact on business domains across the organization?
- Do you anticipate likely technical problems from major projects while those projects are still in the planning phase?
Okay, this is the lowest level on the management track, and often a point of bifurcation where you decide if you’re going to climb the management track or stay in the technical/individual contributor lane. For a thoughtful piece on thinking about / dealing with this “Multi-lane” approach check out Engineering Management: The Pendulum or the Ladder
- Typically 8+ years of experience
- Typically responsible for a team of up to 15 or 20 engineers
- Sets clear expectations for team members. Solicits, synthesizes, and delivers feedback.
- Focused on building relationships, both within the team and across teams
- Coaches their team members to help them continuously improve and do great work.
- Works with team members to resolve in-team disputes.
- Identify and work with team members to remedy problematic behavior
- Communicates timeline, scope, and technical concerns to stakeholders
- Often lead recruiting for their team, or work with HR & Staffing managers to handle recruiting
- Represent their reports during performance & compensation reviews & negotiations
- Works with product managers & their technical team to manage scope and deliverables
- Typically not writing code, but may occasionally contribute bug fixes to “keep hand in”, but not in mission or time-critical areas.
- Much of your schedule will be in “manager” mode - dominated by meetings, 1 on 1s, and planning sessions. You will have few large uninterrupted blocks of time.
- “Engineering how people will engineer products”
- Are you setting clear priorities and expectations for your team members?
- Do you have a clear idea of what each of your team members is trying to accomplish in their career?
- Are you keeping close track of your team’s deliverables and scope, communicating up when there are changes?
- Are you helping your team members achieve their learning, career, and salary goals?
- Are you pro-actively identifying and remedying problems and disputes before they get out of hand?
- Master conflict management and resolution.
- Work on your coaching skills. Learn to get comfortable asking questions instead of giving answers.
- Practice identifying and addressing bottlenecks in your team and companies process
- Continually improve your ability to set clear expectations and deliver actionable feedback.
- Improve your ability to communicate timelines, scopes, and risks “up” to higher level managers and “laterally” to other teams and stakeholders
- Mythical Man Month (book)
- Kate Matsudaira on Leadership
- The Manager’s Path(book)
- Coaching for Leaders podcast
At this level you’re well and truly into management, where much of your time is spent managing managers & balancing/coordinating resources across teams.
- Typically 12+ years of experience, with 4+ in management
- Typically responsible for multiple teams, or a team that is breaking new ground
- Collaborating with engineering leads and managers to facilitate and drive technical roadmaps & vision
- Responsible for identifying and cultivating leadership at all levels of their teams, particularly managers and senior engineers
- Ensures their organization has appropriately high technical competence
- Often driving staffing and budget planning for their area of ownership
- Work on how to structure teams and inter-team relationships to maximise for business priorities
- Owns priority setting and review process for teams under their oversight
- As needed manages vendor and external relationships for their organization
- Collaborates across teams and disciplines to solve problems and resolve technical debates
- Typically not writing any code.
- Essentially all of your schedule will be in “manager” mode - dominated by meetings, 1 on 1s, and planning sessions. You will rarely have any large uninterrupted blocks of time.
- Typically contributing to technical architecture by serving as technically savvy voice asking business & product questions to engineers.
- Are you continually working to delegate more and more things to your team, and building their skills to handle that delegation?
- Are your teams learning how to operate independently?
- Are you capable of setting realistic expectations for your managers while still maintaining positivity about their requests?
- Are you tracking ‘health signals’ appropriate to your team, such as frequency of releases, frequency of incidents, and related?
Often the top “People manager” in an engineering organization, collaborating with a CTO who is more technically focused
- Typically 15+ years of experience
- Focused on debugging organizations and processes
- Often responsible for determining technical priorities across the entire company
- Works with CTO, product leads, and other stakeholders to translate strategic vision into technology roadmap
- Coaches new directors and senior engineering managers
- Plans headcount for the entire engineering organization and works with directors to allocate across teams
The very top technical person in the company. Handled very differently across different companies but often focused on the future technology of the organization, not the day-to-day operations of the tech team (which is more the VP of Engineering’s responsibility).
- Typically focused on the technical strategy for the entire company
- Rarely has direct people-manager roles but often works with VP Eng and others to lead engineering organization
- Responsible for setting & communicating vision for company with regards to technology
- Identifies business growth opportunities enabled by technology and executes on those opportunities
- Ensures the architecture being implemented can support a multitude of future business possibilities.
If, on the other hand, you’re more interested in the leadership and communication skills that start to become relevant from Senior Engineer and up, you might like my latest project SpeakWriteListen.com where I help engineers become leaders by improving their communication skills. Check it out!