When I first started on the software engineer career path, I thought I knew where I wanted to go (become a Senior Software Engineer) and how to get there (write better code faster). I was wrong on both accounts.
First, by focusing on a generic career ladder instead of my individual career path, I was losing sight of my own development as an engineer. I was like a student who is focused on getting an A instead of on their education: the former is only a symbol of the latter. Career ladders are useful tools, and can be instrumental in ensuring equity of promotions across an organization. But they are a poor substitute for a person’s career path. Or to put it another way, titles are metrics, not targets.
Second, I was wrong about how to get that Senior title. At the time, I measured myself by the things I understood: how quickly I could implement features, the performance of my code, and how few bugs it had. I thought that my career progression would be about me improving those metrics. Write faster code faster, and with fewer bugs, and then I’d be recognized as a Senior Software Engineer.
What I ultimately came to realize was that the real measure of my career growth was in having an ever-increasing impact. My focus at that time was very much on my personal performance, which was only one part of my impact.
Impact is the north star for a software engineer career path
You can increase your impact, and thus grow in your career, in a number of different ways. You could expand the depth and breadth of your skills, to have a greater direct impact in more areas. You could increase the scope of your concerns to encompass the performance of your team, and eventually of your entire organization. You could work with, influence, and support a broader range of people. Each of these software engineer career paths will come with a different set of titles, but chasing those titles is putting the cart before the horse.
I’m not saying titles don’t matter. They do, depending on where you work. Having a title starting with Senior or Lead can affect how deeply people consider your input, or what projects and opportunities are available to you. If you are doing the same kind/quality/quantity of work as someone else, of course you will care if you don’t have the same title. But it is still a mistake to treat a string of titles as being identical to your software engineer career path.
(One thing I love about working at Sourcegraph is that we don’t have those title prefixes. I “lost†my Senior title when I came here, and I wasn’t sure how I would feel about that. But right away I could see how it put early career engineers on a more equal footing with more experienced engineers, which raises the quality of conversations and designs. That’s definitely worth more to me than a title.)
Every career is unique; there’s no one right way to do this. The trick is to find the path that most resonates with you. When you are the most engaged, you will be most effective in expanding your own impact. Here are a few anonymized examples of real software engineers and their career paths.
Maria, Engineer (technical breadth) Maria moved into tech after first working in another industry, but deciding it wasn’t for her. Her superpower was fearlessly asking questions: she never left a meeting or conversation without knowing everything that was going on. She built her knowledge and skill-set rapidly, first in depth and then in breadth. Her personal performance increased. By becoming an expert in one codebase, and then in several, Maria became a trusted advisor and mentor. Her impact expanded to other engineers, on and off her team. Maria’s curiosity uncovered technical needs that were not being met, things that didn’t fall cleanly to any one team to solve. By that point, she had the technical skills to formulate solutions, and the connections and communication skills to get buy-in from stakeholders. In time, she was recognized as the primary technical leader in her group. In one particular instance, Maria started poking at a feature that was unreliable and impractical to use. It was poorly designed and hadn’t scaled well, but changing it would require the coordination of at least a dozen teams (and their roadmaps!). Many others had run into this broken feature before, but never fixed it because “you just can’t push a change through that many teams.†Maria showed them how. She led the effort to phase it out and replace it with something much better, something that didn’t feel like it was made for the web of 2010, something customers would use and love. A year later, Maria was providing technical guidance and proofs-of-concept for multiple stages of the project to some 60 engineers, working closely with numerous product managers and engineering managers. Maria’s initiatives prepared the company for a major industry shift, and delivered the revamped feature well before their competitors could catch up. For her outstanding work, Maria was eventually promoted to the title of… but that’s not really the point, is it? Theo, Engineer (technical depth) Theo loved taking things apart and understanding how they worked. His superpower was an ability to understand the inner workings of complex systems, especially software/hardware systems. In addition to a standard computer science curriculum, Theo studied real-world software construction and maintenance, and had a special talent for taking a “performance optimized†system and making it significantly faster. In any complex system, in the many layers of abstraction, from hardware to firmware to drivers to operating systems to libraries to applications, there’s always something somewhere that is going much slower than it should. He would find what others missed. As Theo’s reputation grew, he was given larger and more interesting opportunities. Eventually, he was tasked with building a system that would power the future of the company. It would need to ingest millions of complex, multi-dimensional data points per second. It would need to allow queries over all of the data, and a query must return in milliseconds. Going forward, it would need to scale not at the rate of their customers, but of their customers’ customers. Theo was there from the beginning: building prototypes, redesigning key components, and refining implementations. The project would ultimately last years and grow to several teams of engineers, with Theo leading through all of it. It’s hard to imagine what it would have looked like without him. After that, he had the pick of projects to work on. He was given the freedom to work with any team on any project. He would gravitate toward the most complex problems the company was facing, pair with the engineers on that team to turn “intractable†to “performantâ€, and then move on to the next big problem. Jan, Engineering Manager (growing engineers) Jan began their career as a software engineer. Their superpower was empathy: they cared deeply about the success and well-being of their teammates. This naturally led to an interest in career mentorship and whole-team success. As a mentor, Jan worked with early career engineers to help them navigate through interpersonal conflicts, communicate better with peers and managers, and advocate for their own career development and goals. As they progressed in their career, Jan began to pay increased attention to non-technical issues that impacted engineers: psychological safety, equitable hiring, conflict resolution, implicit bias, representation, etc. When a management opportunity came up, Jan was a natural choice. It was made clear that moving into management was not a promotion: it was starting a new career at the bottom of another career track. But just as clear was that this was a move toward having a broader impact in the organization, and in the careers of everyone on the team. Jan eagerly accepted this new challenge. As an engineering manager, Jan had the influence and authority to enhance the day-to-day experiences of engineers on and off their team. They also collaborated with other engineering managers to improve hiring practices. As a result, their company gained a reputation for being an excellent place to work, and they were better able to hire and retain top talent. You, gentle reader Maria, Theo, and Jan followed different software engineer career paths. But they all succeeded by increasing the magnitude and scope of their impact. So what will your path look like? Think about what brought you to tech and what drives you. Identify your superpower. Then use these to guide your professional growth and steer you on your own path toward ever increasing impact. More posts like these How we built our software engineering career frameworkAsync, remote, and flexible: How 7 engineers rethought their work calendarsImproving code display: A look at 17 developer workspaces
Get Cody, the AI coding assistant
Cody makes it easy to write, fix, and maintain code.
