This post is my own personal view of a software developer’s career path. While biased to my own career path, I’ve noticed that it aligns to several organization’s explicit job levels to make me think that it may be more universal than just me as a full-stack web application developer. I hope you find it helpful.
Before going over the stepping stones, or levels/roles, here are a few points to help set context.
The audience for this career path is a software engineer who wants to spend a nonzero amount of time coding, while still expanding her scope and impact. It therefore excludes most organization’s definitions of Engineering Manager, Architect, or other Post-Technical (but still important) roles. To use a popular term I don’t really like, it is aimed at the Individual Contributor.
- I have intentionally not used the traditional role titles common in the industry (Senior, Lead, Staff, Principal) because these carry connotations with them that vary across orgs. The traditional titles also seem more related to tenure and org-chart power/prestige than helping clarify what each actually does.
- By presenting these in a linear sequence, you may get the impression that these are incremental steps where you get slowly better and better at one level and then are ready for the next. But actually, that’s not really true. Changing levels often involves a major and disorienting shift in focus. You usually have to dip your toe in the next role to see if it’s something you even want to do. Deciding which one best fits your personality, skills, and interest is highly dependent on you as an individual. And none of those decisions are static. What you absolutely love today may seem confining a few years later. Talented folks sometimes miss coding and “go back” a level to stay closer to what gives them satisfaction. I don’t think this should be seen as a career misstep.
- Aside from you as an individual, a lot of the specifics are also tightly coupled to the organization. One org’s culture of bureacratic meetings might make you want to retreat to comfortable coding, while another’s more collaborative environment might inspire you to influence far beyond the codebase. And of course there’s all the expected politics of how opportunities are distributed and the promo process itself, whether informal or highly standardized. Some orgs might promote too quickly with insufficient evidence, while others might do everything they can to retain and develop high achievers. There’s no single best place for everyone and so you have to make sure it’s a good match for where you want to go in an acceptable timeframe. An advisor with significant tenure in the organization is invaluable here.
- Despite the above caveat, these are in a particular sequence for a reason. You need to become highly proficient in one before considering the next. This is obvious. How can you influence a team if you haven’t practiced influencing one other engineer? How can you influence an org if you can’t build consensus on your own team?
- You’re always growing, even if it doesn’t mean a level change. The key differentiator of each level is the breadth of influence rather than depth of technical expertise. I’m just taking for granted that all levels will be growing in depth over time. In other words, you can stay in one level and become more and more of an expert of a particular toolset and learn additional techniques and toolsets. In fact, all developers need to do this ceaselessly to avoid their own obsolescence. Not to mention that technical learning is what makes the job a continued source of delight for many of us.
The Stepping Stones
Without further ado…
One Line Job Description
Your top focus is on transforming yourself from someone with potential into a self-sufficient engineer; code delivery is secondary.
Success starts with…
Delivering a meaty story without needing help with an uneventful pull request.
Success eventually becomes…
Owning a relatively simple epic from start to finish, where most of your own ideas end up as the final implementation.
The code you add/modify. You seek to follow code review discussions but mostly observe, ask questions, and make suggestions more rarely.
Primarily just yourself. You help the team by asking good questions and improving the onboarding experience for future newcomers.
- Struggling alone too long. Everyone has their own threshold before giving up. Often named “Grit” in psychology research, some claim it’s predictive of success in many facets of life. However, much of the research deals with things you can solve on your own and are intrinsically self-teachable. With this in mind, you should definitely struggle longer on your own for how to implement something in Rails, an open-source framework with literally thousands of examples on StackOverflow, rather than on an internal framework for which you may not even know where to find tips to get yourself unstuck.
- Leaving the training wheels on too long. This is common if you’re on a very experienced team with dominant personalities. This antipattern won’t actually hurt you too much at this level, but you should try to ratchet up the time you struggle alone over time, as you learn more. When senior folks go on vacation, it’s a great time to stretch your solo skills a bit or go talk directly with a different role where you normally rely on your tech lead or manager as an intermediary.
- Prioritizing what to learn. At this stage, everything is new so it can be overwhelming with where to start. Seeking a little guidance for what to start with is extremely helpful. What did the most recent person to join the team focus on? What was helpful for her and what turned out to be a waste of time? Not all learning will be directly applicable to your current team/project and at this stage you really need to be tightly focused before thinking about more distant subjects.
You are proud of something you shipped that feels wholly yours.
One Line Job Description
You are given a solution to build and deliver it to production in a way that engineers admire and business stakeholders appreciate.
Success starts with…
Thriving in the weeds. You own meaty epics from start to finish, communicating the design to your team but typically running fast on your own.
Success eventually becomes…
Living for the weeds. Shifting from a correct implementation to one that is optimized across multiple dimensions. You invent standards and patterns. Other engineers follow your lead and ask for your opinions before code review time.
Your team’s codebase(s), top to bottom.
Still primarily yourself but also your peer engineers. When relating to senior engineers, you will often be convincing them that Your Way is better. For peers and junior engineers, it will be helping them become another you on the team.
Signals of Struggle
If you shy away from tough challenges, this may be a sign you’re not confident in your abilities. This may or may not be accurate and you’ll need to check in with others to get objective measures (see also: Impostor Syndrome). Your estimates vary wildly from reality. This usually means you are being too optimistic and are thinking of Ideal Dev Days that never happen. More seasoned engineers can help here. Shadow them for their estimation thought process. Sometimes it can help to estimate the time for someone else to do the work (especially a less-experienced developer), rather than yourself.
Signals of Success
- You are technically unstoppable. If your first solution doesn’t work, you will adapt your way around the obstacle and plow ahead anyway. Delivering results above and beyond will soon be taken for granted by your manager and team.
- The deepest technical expert on the team is almost certainly an Implementer. It takes battle scars from multiple wars to get to this point and any time away from code adds little to these skills.
- (Feels like struggle). Instead of focusing only on the best/fastest/cheapest way to implement Solution X, you begin to look upstream to ask, “What problem is X is meant to solve?” Here you may be bump up against the constraints of spending the maximum possible percent of your time coding.
- (Also feels like struggle). When you feel that nobody on the team seems to listen to your great ideas, especially those that seem to be right in hindsight, you might be waking up to the need to influence the right person at the right time.
- Chasing Shiny Things. At this stage you might lament doing legacy maintenance and be drawn toward Greenfield Reboots or Silver Bullet Framework X.
- Perfectionism. If you deliver good solutions but they take a long time or are complicated, you may need help in being more pragmatic about what “Good Enough” means for your context. If this is only surfaces as a problem after you already have a proven track record of delivering quickly, it instead may be a signal that you need new challenges that can let you express your hunger for complexity in a constructive way.
- Leaving to find a more receptive audience. When first trying to influence, which usually does not come naturally for engineers (especially introverted ones), you may blame your audience for not listening and seek a new audiences elsewhere in a different part of your org or another org entirely. Maybe you think if you had a more important title, folks would have to listen to you. To be clear, sometimes it is a good idea to find a better fit. However, it’s very helpful to have a senior mentor who can help you discern the difference between a team where you could influence with some effort on your part to be a better influencer vs. the wrong team/project for you.
You stare down the scoping/estimating of a new and unfamiliar project or escalated support ticket and feel no fear.
One line job description
You draw on your hard-won experience to continuously nudge the team to make good choices.
While you still write code, it’s rarely the “Critical Path” code. You’re more likely to cast a larger shadow on the architecture via design (and code) reviews than with the lines you write yourself. You contribute to many technical deliverables that are about code, but are not the code itself.
Primarily the members of your team and secondarily any folks that the team regularly interacts with. This includes the developers of course but also the project manager, the designer, and any QAs or business stakeholders.
Success starts with…
Finding your voice and using it to help the team take the best actions for the user and your team’s architecture.
Success eventually becomes…
Actively staying out of the weeds and instead looking ahead and even moving ahead, e.g. to do a proof-of-concept on an idea. This is why I chose the name “Scout” since to me the role often feels like you are running ahead to see the terrain of where you want to go and then running back to communicate with your team on how to get there.
Signals of struggle
- Superficial consensus. You thought you built consensus among the developers for a controversial decision (e.g. Node vs. Java for a new service) but notice passive aggressive grumblings and other signs that the consensus was merely superficial. “I told you so”’s are the clearest example of this.
- Healthy dose of humble pie. As an Implementer you likely had endless ideas and since they existed in your own brain and never went to prod, you assumed they all would have worked out flawlessly had they been battle-tested. Now that your ideas are acted on, you may be dismayed to see that you weren’t as clever as you imagined. This is an inevitable growing pain. It just means you need to learn how to fail cheaply and have a better decision-making process in the future, often involving hearing more from others, especially non-engineers.
Signals of success
- People ask what you think about things. These may be developers from other teams and they may be business people thinking about opportunities. They want your perspective. This is not a bothersome distraction. It is one of your position’s unique values.
- Real consensus. You encounter a technical disagreement on the team and build consensus on a way forward diplomatically. Once resolved, the teams move on and the decision is not revisited.
- You successfully advocate for not building something. This could mean using a third-party solution or achieving the same business goal with human effort rather than automation. This role starts to focus more on the overall goal and questioning assumptions rather than accepting existing thinking.
- Time management (universally the most common challenge for new practitioners of this role). As a developer, you probably took for granted having long stretches of uninterrupted time to code and think. Without explicit effort by you, this time will surely be swallowed up by other obligations, leaving you feeling unproductive at the end of the day. (If not doing any real coding for an entire week doesn’t actually bother you, that may be a clue you might even excel as an engineering manager.) But for most individuals new to this role, they will lament not coding and desperately find ways to do it, which sometimes means long hours and burnout. Luckily, there are whole books about managing your time and senior engineers who can share their own tricks for getting over this hurdle.
- Not delegating enough. Your wits got you this far, but like any good caretaker, your goal isn’t to heroically solve all problems but instead to make your team self-sufficient and able to happily chug along without you. This includes finding the strong Implementers on your team who may be interested in following you to this track by sacrificing some of their coding time in service of activities that help the team overall. You should facilitate them trying out their skills in a safe environment (No sink or swim deliverables!) If you go on extended holiday and come back to a mess, you’re not doing well here. (Note: this shouldn’t be read as meaning you want the actions taken in your absence to be identical to what you would have done, but they should be sound and sustainable).
- Not shutting up. You finally have a voice that is listened to and so the temptation is there to use it when possible to optimize anything and everything. Counterintuitively, you actually must learn to give space for others to be heard, in a way that perhaps no one did for you. Know the personalities of your team and the kind of support each likes: one-on-one candid discussions, specific pairing, written design feedback, etc. Focus more on helping other engineers refine the design that they have chosen, not on saying how you would have solved the problem.
You’ll be in a meeting and a teammate jumps in before you and says what you were thinking, or even something better than what you were thinking. You helped them find their voice!
The Cat Herder
Disclaimer: As I’ve never been a Principal Engineer or any role like this, this is purely from the outside and YMMV.
One line job description
You look far ahead for where your organization’s technical projects should go and help make that vision a reality.
You’re more likely to be directly responsible for system architecture and helping others make good decisions for their code rather than contribute any production code. You may go weeks without writing any code.
Several software teams linked by common management, product ownership, or shared code (or a combination of these). Your scope also includes business people, often with titles that would have been unapproachable and distant when you were focused on code.
Signals of struggle
You miss the immediate feedback of delivering code. It might just be impatience or unrealistic expectations, but it’s helpful to have the mentorship of experienced practitioners to see how they measure their success. Vision is nebulous and can take years to become real. Everyone must find their own way to make it more concrete.
Signals of success
- Others reference your ideas to make decisions. The thinking you communicate in writing, in-person, and through your actions lead to more cohesion across teams. Concepts you reference work their way into the organization’s vocabulary.
- You dive head first into “unsolvable” problems. You start seeing even the most painful legacy integration project to be full of opportunities rather than just a slog. You build trust so that you can transform vague gripes into actionable improvements.
- Previously you looked further upstream. Now it’s likely you are actually the headwater for others, including your org’s senior management. Instead of just asking “Why are we doing X?” you find yourself saying, “Is there a hidden opportunity for us if we invest in Z?” that no one else is thinking about yet.
- Ivory Tower Architect. You create a vision in a document but it fails to connect to team’s day-to-day. It seems too distant. It doesn’t help them make decisions. They either don’t understand it or don’t see it as a realistic endpoint.
- Gatekeeper. The inverse of the above is someone who remains too involved in an individual team’s delivery. If you want to review the design of every feature on every team, you will likely become overwhelmed and be seen as a drag on delivery instead of an accelerator. You instead want to lean on the Scouts on each team to come to you with the toughest issues, not for the Right Answer but for additional data about how Design A vs. Design B either aligns more closely with or goes against the organization’s technical vision.
Your prose is mightier than your code.
Final Thoughts: Finding Your Own Path
One truism I’ve discovered in my career is that if the question being asked is should we do A or B, the best answer is almost always later discovered to obviously be C, the option no one had articulated when the decision was made. I think this is true for your own career development too. Maybe we need less of “Should I be an IC or become a manager?” and more of “What kind of technical contributor would make me happy, draw on my strengths, and help me build new ones?”
Software engineering is young enough to have many paths available to us and we can forge our own way, to build hybrid roles or move to people management and back again in a way that others may not have. Try to take advantage of that. You can learn a lot by not writing code for awhile. What do you miss? What did you gain?
I wish you best of luck in finding your own path.
Special thanks to Sadique Ali Koothumadan for his valuable feedback on this post.