Engineering levels and progression

May 4, 2023 by Mark Rafn

Purpose of this document: This is a framework to think about engineer leveling and progression. It’s useful for employees to consider areas for their growth and for managers to discuss growth plans with employees. It’s intended to be a companion to the tabular-format ladder, with this providing explanation and reasoning, and the tabular ladder providing examples and behaviors that lead to it.

General

The career of an engineer is rarely linear. There’s no one path from starting out from proficient engineer to technical lead to an org-wide architect or systems visionary or industry-leading domain expert.

At higher levels, there is some similarity in responsibilities for a manager and an engineer (and in some companies, technical product or project managers). In fact, many engineers do become managers at some point, though some later return to Individual Contributor (IC) status. A fair bit of all of these jobs is influencing and implementing strategy through team and cross-team alignment. Leadership for ICs tends to be tech-focused, leading by example in actually delivering software, getting the details right in implementing strategy, and getting the strategy right in being actually implementable. Leadership for management tends to be people-focused, ensuring that the team’s capacity is being well-used and that individuals are efficiently moving forward on delivery that matters for customers.

There’s a wide range of ways that Staff and above (L5+) engineers can have great impact. Some are very deep thinkers and drivers of a technology or area – the company-wide (or industry-wide) expert in some critical system or topic for the company. Some are pure generalists, able to dive into almost any problem and make significant progress. Most are on a continuum between them, and often different points on that continuum at different times. The impact is the key, not the mechanism.

Levels

• 1-2 are entry levels, expected to last up to a few years in a career while learning how to work with others, how to think about products and features rather than purely code, operational and functional aspects of engineering, etc. Engineers are expected to grow beyond these levels in self-sufficiency, instincts, productivity, and impact over the course of 1-4 years.
• 3 (Software Engineer) is a professional engineer. Able to design and build modules, features, or relatively straightforward products. Often is the team expert on some aspects of a product and/or some technologies the team depends on. Very productive and valuable, especially around ambiguous solutions for well-understood problems. Starting to have some indirect impact in guidance and code reviews of newer or more junior team members.
• 4 (Senior) Team leader. Has a more complete view of product needs, able to constructively participate in longer-term planning and guidance of the team, and is designing large subsystems and making architectural changes to the team’s systems. Adds mentorship and indirect operation to the direct work they’re doing. Writing prose (not just code) becomes important at L4, and gets much more so at higher levels. Senior engineers should be writing and maintaining design documents, team-level onboarding guides, and collaborating on documents with a wider scope.
• 5 (Staff) multi-team or product leader. L5, to some extent, is a different job from L4, not just doing more and better. Staff engineers are setting technical direction and help to identify requirements for a product or system, in addition to leading the design and implementation. Should be working beyond the team a bit at this level – both internally to influence infra and dev-support mechanisms, and toward customers by developing human-level systems supported by tech for CSE, sales, or end-customers.

L3 – L5 are common points of career change, for someone who wants to try management or other roles, though it certainly happens at higher levels as well. Also, L4 and above are common “career levels”, where an employee might be satisfied for years or decades without seeking promotion, being happy with continuing to learn and grow within their current role. This is related to the idea that L5+ promotions feel like a different job, not just a bigger version of the same job. At L5 and beyond, it stops being just “do your job better”, and starts being “make others do their jobs better by figuring out how to do more jobs”.

Higher-level engineering roles are more about impact than about activities or capabilities. Not just what they did (though that tends to be a lot), but why they did it and how it actually improved things. Relatedly, starting at L5, and very much at higher levels, the impact is more about customer and product-visible impacts, rather than “just” improving internal processes (note: improving the process CAN improve customer-facing results, but it takes additional work to be sure of that). Very senior engineers should seek to improve their customer knowledge and intuitions and will have valuable input into product vision in addition to feature implementation.

• 6 (Sr Staff) Large team or product group leader. Looks around corners, very much setting technical product strategy over time in addition to shorter-term designs and implementations. Typically mentors and guides designs for multiple L4 and L5 engineers. Has visibility and impact across multiple orgs, not just their own, and/or impact across a large swath of business and customer improvements. Often involved in investment and team formation decisions, as well as major product launches or direction changes. At this level and above, there’s usually a significant impact on org effectiveness, product usability (and actual use) by customers, and agreement and understanding of how their org’s engineers are working toward a coherent medium/long-term vision.

• 7 (Principal) For PE (and Distinguished Engineer, DE), there’s not a great template for what they do. A depth-focused PE tends to be a true expert on one or more core technical functionalities for the company. Publishing academic research or commercial white-papers is common at the PE level. Broader-focused PE may not be an industry-leading expert but will be the expert on how the business leverages the core technologies, and how they should expand over time to make the product(s) more successful. In either case, a PE has a significant impact on the business. Where Staff and Sr. Staff engineers are contributing to engineering strategy, clarifying ambiguity, and ensuring visibility and alignment in the teams implementing it, a PE is defining and driving that strategy. Strategy discussions at the PE level will include long-term culture and team structure in addition to purely technical points.

• 8 (Distinguished) Setting engineering culture and tech/product direction for an entire business. Identifies (and often temporarily fills) holes in ownership/expertise in the L5-7 staff. Drives cross-org changes that significantly improve the business (both customer-facing improvements and indirect impact that noticeably improves the bottom line).

Practical considerations

• Who drives? At earlier levels (1-3), managers are mostly running the entire promotion, as they assign work, monitor progress, and initiate performance and growth discussions with the employee. Senior levels (4 and 5), the doc and process are still manager-driven, but the discussions are more of a joint discussion about how the employee wants to grow, what could challenge them on the right dimensions, and what should go into a promo doc to demonstrate the leadership and capabilities expected of the next level.
• At very senior levels, it’s often more collaborative – the manager is still building the final case for promotion (usually in the form of a document), including peer and customer feedback, but large sections about the activities and impact that show next-level impact and scope will be written by the employee or collaboratively between employee and manager. In addition, the skip-level and partner-leaders are often involved even before the submission of the promo request.
• It doesn’t always require formal mentoring, but it’s INCREDIBLY helpful to talk with people at the target level when considering how to increase your influence and what behaviors and impacts are indicative of the higher level.
• Opportunities sometimes seem (and occasionally are) scarce for higher-level promotion in one’s current team and position. If you’re in an area that only really needs one staff engineer, and you have one, it’s possible to feel stuck. Very often, some discussion with manager and mentor, and often with skip-level or other managers can identify needs for higher-level impact with some small changes to team structure. Very often there are product or systemic things that would be great benefit to the company, but need someone acting more senior to drive it.

In the rare case where the team really doesn’t have room to demonstrate next-level impact, work with management and HR – there are lots of teams at Foursquare that are actively seeking these capabilities, and we can find ways to transfer then grow to a new level, or to grow in place then promote+transfer (somewhat rare). Or just transfer to explore new domains and challenges, without a specific promotion goal.

• Keep in mind that at higher levels, there’s no set path or checklist for promotion. There can be no promises made about “do this for a year and we’ll promote you.” All discussions should be in the frame of growing and demonstrating impact on various dimensions, and how they add up to a given level.
• Public and internal writing (guides, philosophies, white-papers, academic papers, tech talks, wikis, etc.) is an important mechanism for influence. It’s also a great source of artifacts and demonstration of influence to be used in promo docs. The joke is that very senior engineers code mostly in MS Word, but the truth is that this is often the first step in turning your ideas into reality.
• Actual customer contact (directly working with larger customers or prospects, or indirectly paying attention to usage metrics, support tickets, etc., or even modeling out revenue and cost projections for a product or feature change) is a large part of knowing what impact your decisions are having, and to being correct in your direction-setting and your prioritization choices for your team(s).