Navigating your career
To Senior and Beyond
Career ladders list job title hierarchies and describe expectations at each level. Together, the titles in a ladder form a career progression at a company. The number of levels vary from company to company, but there are usually two transitions that indicate significant shifts in seniority:
from junior or software engineer to senior engineer,
and from senior to staff or principal engineer.
Note
There’s a nice summary of the Engineering levels created by CircleCI: https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo
In the “How to navigate and learn at job” section we enumerated the technical, execution, communication, and leadership skills expected of a senior engineer. Importantly, after reaching seniority engineer’s scope and focus also change.
Junior engineers implement features and complete tasks.
Senior engineers deal with more uncertainty and ambiguity; they help determine what to work on, tackle larger or more critical projects, and need less direction.
Staff engineers take on even broader responsibilities that extend beyond their team.
They contribute to engineering strategy, quarterly planning, system architecture, and run engineering processes and policies.
They still code (and they code a lot), but to get to this level, just being a good coder isn’t enough: you have to understand the big picture and make decisions with far-reaching consequences.
Career ladders usually split into management and “individual contributor” tracks at the staff level.
Advancing in your career does not require managing people, and management is a wholly different skillset.
Career Advice
Be T-Shaped: Software engineering has many specialties: frontend, backend, operations, data warehousing, machine learning, and so on.
“T-shaped” engineers work effectively in most areas and are experts in at least one. Being a T-shaped engineer will keep you from making decisions in a vacuum, allow you to make changes that touch multiple codebases, and simplify troubleshooting. You’ll be able to solve hard problems that stump others by combining your expertise with the ability to understand disparate systems.
Start by building your base. Base-building will expose you to different subfields so you can find your passion. Look for projects that involve other teams such as data science, operations, frontend, and so on.
A good team will have a solid mix of T-shaped people. Product development teams are likely to have varied areas of depth among teammates, while infrastructure teams are more likely to have a shared expertise.
Participate in Engineering Programs: Many companies have engineering programs that encourage learning, development, and a shared culture. Hiring, interviewing, brown bags, conferences, meetups, reading groups, open-source projects, and apprenticeship and mentoring programs are all opportunities to get involved. Participating in and contributing to engineering programs will help your career. You’ll build relationships, increase your visibility across the organization, learn new skills, and help influence company culture.
Steer Your Promotion: Ideally, your manager would promote you at the exact right and fair time. But the world is rarely ideal, so you’ll probably need to steer your promotion. Learn the promotion process, make sure your work is valuable and visible, and speak up when you think you’re nearing the next level.
To get promoted, you’ll need to know how you’re evaluated and what the promotion process looks like. Find your company’s career ladder to determine the skills you need for the next level. Talk with your manager about the promotion process.
Are promotions done annually?
Who evaluates potential promotions?
Do you need a mentor, sponsor, or promotion packet?
Once you understand the evaluation criteria and promotion process, do a self-assessment and get feedback from others.
When it comes to promotion conversations, timing matters. Start these conversations before you think you are ready for a promotion— about when you’ve hit the halfway point. Engaging early gives you and your manager time to align and address gaps.
Stop doing glue work—even if it hurts the team in the short term—if your manager does not see your contributions as a path to promotion.
Change Jobs Carefully: Changing jobs can expand your skillset and your network, but frequent job changes can stunt your growth and look bad to hiring managers. Don’t change jobs without a good reason.
There are, of course, good reasons to change jobs even after a short tenure. Some companies or teams are a bad fit, and it’s better to get out of a bad situation quickly rather than letting it drag on. But stick with your job if you’re still properly compensated, growing, and learning. There is great value in seeing teams, companies, and software evolve over time.
Conversely, don’t stay too long. Job ossification—becoming stagnant—is a legitimate reason to change things up. Longtime engineers at a company naturally become historians who educate engineers about how things work, who knows what, and why things were done the way they were. Such knowledge is valuable—it’s even part of being a staff engineer—but it can stunt your growth if your value comes more from past work than current contributions.
Pace Yourself: Work can be hectic, competition is fierce, technology evolves quickly, and there’s always more to learn. It might feel like there’s too much happening too fast. New engineers often react by pushing harder and working longer hours, but that’s a recipe for burnout. Take breaks to disconnect, and don’t overwork yourself.
Researchers studying the effect of sleep on developer performance found that “a single night of sleep deprivation leads to a reduction of 50% in the quality of the implementations” Even with a healthy work schedule, the monthly grind of work can burn you out. Take vacations and sabbaticals to disconnect.
Your career is a marathon, not a sprint; you have decades ahead of you. Pace yourself and enjoy the journey!
Note
Sources:
The Missing README: A Guide for the New Software Engineer © 2021 by Chris Riccomini and Dmitriy Ryaboy, Chapter 14.