A useful task in a software engineer’s career, notably when looking towards a promotion, is outlining what steps in a career look like. How can you be ready to grow into a new position or take a bigger lead in work if you’re unsure what that means? Similarly, when guiding folks who are up and coming, what better way than to highlight your successes (and failures!) to guide them?
I’ve put together a well rounded outline of career maturity and expectations within each step level, offering direction on how to grow and what to emphasize as engineers progress their skills. Just as I’ve sourced from lots of folks, feel free to take from it what you think works and toss out anything that doesn’t for you or those you’re advising.
General Expectations
Some guidance on how to approach career growth using this model. Note: while listing ideals, it is not a checklist and it’s more than ticking all the boxes.
- Influence – As an engineer matures, their impact becomes more pronounced, both in breadth and depth of influence
- Multifaceted – Growth is more than committing more lines of code or pushing out projects at a faster rate
- Humility – Failure still exists as we go up the ladder, often more deeply felt. Knowing how to handle that failure is the important part
- Communication – Developing skills to communicate, notably challenging idea and often when to let others speak, is essential
- Direction – Less explicit guidance is needed as one grows and more trust is earned, though feedback is still sought after to include the vantage point of others
- Vision – An increase in clarity and at what distance into the future planning can be done
- Compromise – Better understanding of trade offs with decision making and that choices are not always clear
- Mentorship – Greater availability to guide others, and an understanding that it should apply upwards as well
- Sponsorship – Making room for others to grow themselves and developing opportunities for them
- Cheerleading & Recruiting – Developing an ability to “recruit” folks to ideas and to build consensus, even when those ideas are not your own
- People Problems – All work, IC and Manager, reduces down to people problems. Developing a sense for this as an engineer matures
- Intangibility – Challenges become bigger and more amorphous in scope, which means that boundaries and definitions of the role also have less defined, soft boundaries
Levels
Software Engineer
Early career Software Engineers have foundational knowledge of what it takes to develop software. This includes how to edit files locally, work with version control software, and communicate progress of ongoing and completed work. Tasks are typically assigned and require the ability to best complete them based on those parameters. Lateral movement within tasks is required, though, as priorities change and understanding of a problem takes shape once work is started. A Software Engineer is proficient enough in at least one core language such that they can update a service in their domain as needed.
A Software Engineer’s focus is at the task level and communicating with members of the project.
Includes:
- A fundamental knowledge of how to write code including but not limited to use of functions, variables, typing, and fetching data from other sources in at least one language used in the domain hired into
- An understanding of basic tooling to help accomplish engineering tasks:
- Fluency in an editor of their choice
- Skillfulness with version control
- Observability and debugging tools
- A development of communication skills, such that they are looking for guidance from more senior members of the team
- Frequent updates on tasks to advance insights into success and failures along the way
- Sourcing from more experienced members of your team as they develop strategies to work through challenges. Searching for answers is a sign of growth, not weakness.
Senior Engineer
Senior Engineers have an understanding of their scope of work at the project level. They have the ability to lead epics, a collection of related tasks, from the beginning, organizing the work by breaking it down into smaller tasks as part of the roadmap. They understand that developing software is more than writing code, but organizing ideas and developing shared understanding of issues at hand for members of the project and those outside it. They frequently search outside of their team and the company for new ideas that can help problem solve for future work.
Senior Engineers look towards working as a project lead, communicating in both directions information between members of the team and leadership on project direction.
Includes:
- Strong knowledge of at least one core language and fundamental knowledge of others used in day to day work as to advise others on industry standard practices
- Regularly building of new tooling, adding to existing, and sourcing of third party tools/libraries as needed, but not unnecessarily – sometimes this includes deprecating tooling!
- Knowing how to deprecate and sunset projects/code
- Ability to define the scope of a project as first hand knowledge, including the ability to plan accordingly at the start of a project and when unexpected situations arise, to cut scope and prioritize other projects
- Coordinating meetings on projects, seeking input for specifics and reaching out beyond their team to make sure other stakeholders are informed early and often
- Working with customers on problems, with patience and efforts made to make sure they are taken care of
- Alternatively to being assigned work, issues are readily sought out and resolved
- Setting aside time to mentor others, which can include slowly working through an approach, sharing expertise in their domain, and debugging code out of their domain
- A comfort level with proposing new ideas for code paths and design, introducing RFDs (Requests For Discussion) where needed
- Regularly introducing spikes, MVPs (Minimum Viable Product), and steel threads to provide momentum to projects
- A track record of successfully completed projects within given constraints set out early at the start of the planning process
Staff Engineer
Staff Engineers understand that projects are critical, but are able to navigate the work in between projects as well. You see beyond the work in the current quarter.
A Staff Engineer serves as a team lead, leveling up adjacent coworkers and accomplishing work as a group, even if they are not directly contributing to a project, with communication work on how to level up members of the team.
Includes:
- Relieving pressure on potential issues before they become a problem, having insights into issues that will affect customers or end users
- Developing a balance between performant and legible code
- Scalability, reliability, and performance at the systems level becomes core to their work
- An understanding of development at scale – what it means for the organization to grow code, develop new projects, add customers, and take on new work while still maintaining existing services
- Comfort in ownership of a service, being responsible but not solely responsible
- Seeking out constructive criticism when proposing changes to other team members before those changes become problematic
- Mentorship includes leveling up others on the team as a core function
- Readily, openly, and fully acknowledging failures to increase transparency and psychological safety for your team
- Sponsorship is a requirement as regular work. Questions regularly asked are “Who on the team is unable to speak up or unable to progress in their career and how can I help?”
- Design begins to take shape at the systems level, where the interactivity of individual systems becomes a focus
- Developing ideas that extend beyond the org, including but not limited to blog posts, podcasts, and conference speaking
- RFDs source ideas they have generated and proven in production
- Being a source of consultation to inform the RFDs, spikes, steel threads, and MVP work of others
- Advising Senior Engineers on constraints in the planning process early on and being available to guide skill building in planning
Senior Staff Engineer
A Senior Staff Engineer’s scope extends beyond their team to the entire organization. They are developing a greater understanding of business needs and how that drives the Product/Engineering team. They’re involved with prioritization for roadmap work, having developed a strong sense of the calculus between the business and engineering constraints that make work successful.
A Senior Staff Engineer’s work focuses on company wide or org level work, with the ability to widely communicate challenging ideas through multiple teams. They look to see how current work in the quarter will extend and affect the next.
Includes:
- Mastery of at least one language in use with strong proficiency in several others
- Further development on distributed systems and how individual systems are linked, building off of Staff Engineer
- Ability to solve problems that exist outside your team, potentially with encouraging others to develop the skills to execute on those solutions
- Communication through the org means being readily available often without being a blocker to information, requiring facilitation not gatekeeping
- Likewise, communication on challenging topics – saying no or not now, bringing up topics that make for difficult but necessary conversations
- Mentorship includes reaching out to folks on other teams and developing a sense of inclusivity for the issues between teams
- Sponsorship of projects to help champion others’ work with the knowledge that others’ wins are your wins as well
- Sponsorship in advocating for others who might not have privilege to speak up on topics
Principal Engineer
A Principal Engineer works through team boundaries and even between those at the company level to achieve engineering concepts furthering the goals of the company, often beyond. They’re seen as leadership within the org and an external representative of the org to the tech community at large. Communication skills become critical in day to day work that includes precision and clarity being core functions. Paradoxically, they do less coding to make software engineering more viable. A Principal Engineer looks at a calendar year, including seasonality and expected trends, to coordinate with planning, knowing well that things can and will likely change, but the planning for that is invaluable all the same.
Their focus is on the interaction between the company and those outside it.
Includes:
- Software Development has less time in an editor and more time solving problems on coordination to getting code worked out – designing the systems and answering questions for folks so your expertise helps them move faster
- Involves finding “the messy inbetweens”, “Glue Work”, and undefineables that come with work that is either hard or impossible to predict
- Highlights early the pathological cases not just in code but in systems design
- Can extrapolate from existing data issues that will come about not in a few months but potentially in years
- Understands the decision making process of the past brought the org to its current position and can prioritize work knowing when the cost can and should be paid down
- Generates team collaboration of the Engineering org with that of other Engineering teams in the industry
- Mentorship includes developing Engineering as a force outside of the org and encouraging culture that allows the company to be an example to other orgs
- Sponsorship includes serving the tech community at large and building the skillsets of internal engineers at the company to share ideas that shape tech
- Defining the culture, not just of their team or org, but of the company as a whole
- Likewise, developing work that extends beyond the company to influence other companies, particularly ones that are adjacent to the work here
Distinguished Engineer
A Distinguished Engineer is an exceptional role that very few people in the world achieve as a career milestone. Your influence in the tech industry is not relegated to changing how folks do day to day work – it’s a fundamental restructuring of technology or assumptions. Almost nothing is typical about this level, as it requires bringing forth previously unknown standards, tools, concepts, and guidance that shapes how the industry runs.
The list of ideals includes all of the above and beyond, not limited to any particulars. It is intentionally open ended and rare. I’ve seen Distinguished Engineers who champion CI/CD deployments and containerization, develop entire frontend frameworks, and coordinate widely used strategies in managing security vulnerabilities shared by the largest companies in the world. Those are all enormous lifts in the industry and so rarely is it one person who is the outright founder or sole inspiration for it.
A challenge here – I’ve never achieved this role and in all likelihood won’t as part of my career. It’s groundbreaking in such a way that it’s hard for me to understand what incredible insights we’re missing or developing a new technology that would change thousands or possibly millions of roles out there. Even folks who have stepped into this role can find it difficult to articulate how others can similarly achieve this level of expertise and significance. There’s reluctance in including such a well regarded person if it’s so far a reach, but having goals that continually stretch you to exceed are what keep engineers sharp and continuing to improve.
Their input is foundational to new impactful ways the industry as a whole functions now and far into the future.
Challenges in creating an engineering ladder
Models are imperfect, this included. What may fit one company will do poorly at another. Larger organizations may need more granular leveling (I’ve seen roman numeral I’s and II’s suffixed to titles, for example, to give folks steps in between or to delineate salary ranges further). I encourage anyone reading to pick what you like and throw away the rest, as the practice of developing a ladder that makes sense to you helps in strategizing where to improve yourself or teams you lead. Some of the challenges in putting this framework include questions such as:
- How do we increase visibility/clarity as folks go up the ladder to know what is required of the next level?
- How do we make sure DEI (Diversity, Equity, and Inclusion) is a core function of this grouping, both in leveling evenly and encouraging folks to grow this as a skill?
- Leveling is not at the same pace in all vectors – how do you measure something that is intangible or often invisible in the day to day work?
- How do we go about reducing bias, giving folks ability to be seen as opportunity for promotion?
- When there’s a lack of agreement in leveling between employee and company/manager, how do you square that circle?
References
Etsy Engineering Career Ladder
Etsy Code as Craft: Engineering Career Development at Etsy
Open Source Framework for Career Ladders (Github)
On Being A Senior Engineer
On Being A Principal Engineer
The Staff Engineer’s Path
Defining a Distinguished Engineer