Everyone wants to be a senior software engineer. Sure, there may be the odd exception, but typically speaking, software engineers intend to progress. Nothing unusual. In fact, I think that’s quite natural. Part of being human is wanting to progress. Part of being human is also getting appreciation, recognition for one’s hard work. Staring out with a “hello world” already dreaming of the day you’ll be given the badge of honour and called a senior software engineer is very common and a great goal to have in mind. Yet, many struggle reaching that goal, getting increasingly frustrated by their seemingly slow career trajectory.

In this article, I’m hoping to address that frustration, and give actionable advice based on both first-hand and second-hand experience gathered over the years. If you aren’t already a senior software engineer, you need to read this. If you’re just thinking of becoming a software engineer, you still need to read this, and if you’re working towards your staff engineer level, you might still find valuable advice here. As always, I also welcome additional ideas in the comments, so please, don’t hold back. 🙂

The nuances of progression and levels

Progression in software engineering, just like in most other professions — especially white-collar — is multi-faceted. The general expectation is that every day or week you become a bit better at what you do. You learn something new, you understand new perspectives, you become faster, more pragmatic, etc. There is a near-infinite number of muscles you can train over time in software development, and that training is a progression of some of your skills — and this is already bringing up something worth highlighting.

Skills progression doesn’t necessarily equate to career progression. In fact, in software engineering, it often doesn’t.

Take, for instance, a web developer who loves JavaScript to the moon and back, and can’t shut up about it. Their love of the language pushes them to become an expert. They’ll know it inside-out. They’ll be up-to-date with all the latest ECMA specifications and a wizard at clever one-liners, yet when it comes to writing well-structured HTML templates or styling with CSS, they’ll struggle, their code in the pull-requests will always require cleanup. Such an engineer will struggle to see career progression in many environments. Unless of course they join a team or company building a new JS library or framework.

Another example is that of the engineer who keeps doing the same type of work over and over again for a decade or two. I have met developers with 5 years’ experience over twenty years. Not to diss WordPress — it has its place — but once you have hand-coded 100 sites, you have just about done them all. Having excellent WordPress development skills doesn’t transfer well to most other development jobs, and a senior engineer might even find themselves demoted when moving to a new development job unrelated to WordPress. The takeaway here is that becoming perfect at just one thing — while a great goal to have — is unlikely to bag you a promotion.

Build your skills in a stack or an environment. Not just a language or a framework. And for the love of code, please don’t become a “React Engineer”.

While getting better at certain skills is quantifiable and measurable at your end-of-year review or self-assessment, career progression from the outside is really measured in moving from one individual contributor (IC) level to another. While pivoting into say management is also an option, it’s rarely a good idea.

What levels actually mean, however, can unfortunately vary from company to company. In my first development job at a startup, within three months I was promoted to “senior junior developer”, which felt good as a recognition of my progression as an engineer, but was also something I couldn’t really put on my CV. Over a decade later, I see engineers posting on LinkedIn that they have been promoted to “senior associate engineer”. At the same time, looking at Indeed’s definition of levels, you’ll get a very different impression and no sign of a “senior associate” level.

When I started working for companies, I started as a junior, simply because all my previous experience was somewhere between hobbyist and freelancer. That however was enough to move within a year to engineer level and another year later to senior engineer. But it wasn’t simply because I spent x amount of time doing development, but rather at what level I was doing the work and owning the projects I got assigned or volunteered for. I was very visibly better than the role I was in, and hence the quick progression, which finally brings me to visibility and why it matters so much — far more than many engineers think.

As a software engineer, you are very much in control of your career progression, but it can only happen if you take active control over your career. IC levels may not be a universally reliable metric of where you are, but are nevertheless milestones you can aim for.

Visibility matters more than anything

Truth be told, I can’t quite take full credit for the title of this article. That is the abridged version of a response I received years ago from one of my managers as I was listing out all my achievements, arguing for a promotion from senior to staff engineer. You see, once I became a senior, my skills, and the role I was in, caught up with each other. I may have had the advantage of having coded a lot before my first software engineering job, but that could only accelerate my first two major milestones. Once I was a senior, I was on-par with all of my peers, so my visibility wasn’t granted anymore, I had to work for it.

When you start out as a graduate or junior engineer, good work, quantifiable skills progression, are easily noticeable, and luckily for you, they only have to be visible within the team, and most importantly to your manager. In most companies, managers need little or no justification to higher management when wanting to promote at lower levels. In fact, if a junior engineer doesn’t progress to engineer level within a couple of years, it’s a troubling sign that either the manager is not doing their job, or the engineer is struggling and needs placed on a performance improvement plan.

Once you hit senior level, however, things change quite a bit. It’s suddenly a lot less about perfecting your existing skills, but piling on many more, half of which are actually soft skills that you might have had very little exposure to in the past. Many software engineers assume — wrongly — that just doing more work, picking up more Jira tickets, working faster is the key to their progression. Others — the more sneaky or lazy ones — will just lean back and hope that if they stay in the role long enough, someone will notice and promote them based on years spent in the role. While every so often those strategies do pay off, they do so in unhealthy environments.

Noteworthy are also those engineers who consciously decide to stop at senior level. Contrary to general belief, for the most part, career progression isn’t forced upon engineers, it’s rather that some don’t quite see the benefits of moving from one level to another. There are those who are right in stopping at a certain level, and then there are those who misunderstand IC levels, and see them as merely a formality that happens to come with a small pay bump. That couldn’t be further from the truth and those deciding to stop at senior level know that all too well.

From senior onward, it’s not “just another IC level”. It’s a new role entirely. And not everyone wants that role. Those who do, however, need great visibility to reach the next step.

As a senior software engineer, your manager needs to have a solid case to promote you to staff level. The same goes for staff engineers getting promoted to senior staff or principal engineers. Managers cannot simply make the case that you’ve delivered more code than your teammates, that you refactored half the application or always had 90%+ code coverage in your tests. This is the expected baseline for all engineers alongside other responsibilities like mentoring, proactive problem-solving, big-picture thinking and the likes. This is why many senior engineers are disappointed when they keep getting a “meets expectations” rating at their annual review. Because none of that gives an engineer strong visibility to appear as having exceeded expectations and be on their way towards a promotion.

What perhaps isn’t immediately obvious to many software engineers is that framing one’s entire career around visibility can only have positive consequences. A quick note, though:

Increased visibility does not require burning yourself out. Work smarter, not harder.

When you keep your visibility as your career’s “North Star”, you approach everything differently. A little over a year ago, I was working on an application that I increasingly felt needing an architectural diagram. I whipped one up and posted it in one of our Slack channels with a wide reach. The response was overwhelmingly positive. From engineers to senior leaders and C-level executives, everyone was very excited to see how the application worked and understand some of the complexities we were dealing with in the team. For the most part, I did what all senior/staff engineers should do — documented the inner workings of an application. The added extra was making it visible by posting it in a relevant Slack channel with wide reach. This is just one example of “working smart” and with visibility in mind, but it’s a great segue to my next point.

How to increase your visibility

As I am not here to merely dissect the theoretical value of visibility in software engineering, I can’t but leave you with an actionable set of ideas on how to work your way towards staff, senior staff or principal engineer and do so very effectively. This list is just things that I have done or seen others do successfully, so I would love to see other suggestions as well in the comments.

The reason engineers’ careers tend to progress faster if they switch jobs more often isn’t because they switch, but rather because switching inevitably makes you adopt a high visibility mindset.

When you want to get a new job in a higher level role than the one you have been before, you have no choice but to stand out. You’re simply trying harder and start punching above your weight. The advice here isn’t necessarily to switch jobs, but it is most certainly a viable avenue, and it proves that visibility does get you from one level to another.

Think outside the box. Think different — as Apple would say. A few years ago, my team and I were tasked with rearchitecting the UI of the most visited section of an LMS (learning management system). It had to be done on an old Angular.js v.1 codebase while ensuring it integrated well with the rest of the application written in React, inside a microfrontends architecture, all delivered in no more than two months. Several ideas were put forward by the team. Looking at the suggested theoretical solutions, I proposed to my delivery lead (Scrum master with extra superpowers) that I try one more thing — something that looked unorthodox at first, but with a 1-day spike was possible to validate.

Needless to say, the idea turned out to be successful, and the UI was rearchitected and delivered — naturally, with some help from the team — within 7 weeks. This, being a very high-profile request, made me highly visible in front of the VP of Engineering and the VP of Product. This ensured not just my promotion for the upcoming cycle, but also put the entire team in a very positive light, which brings me to my next point.

Fill a gap. Some teams desperately need someone with the right mix of expertise and attitude. In my case, I was encouraged to move into a team that recently lost their senior engineer to another company. My manager was very transparent with me, and explained that this team wasn’t performing well compared to all the other teams, and it required a fresh infusion of energy and experience. I saw the opportunity again to gain visibility and joined the team. Within just a couple of months, our team doubled its performance and was rivalling other high-performing teams in the engineering organisation. Find a team that you can take to the next level and ask to join them. You don’t just make yourself visible, but also an entire team.

Found or join a working group. Ideally, a small one tackling something important to the wider engineering organisation. In a previous job of mine, I was one of the initial members of the frontend working group. Some of us realised there was too much technological chaos around us, and it was time to standardise across our three engineering locations — Boston, Dublin and Montreal. This worked out so well, that the company even paid us to meet in person in Boston, where we spent a very productive week together. Being a strong voice in a group that sets the standards across engineering is bound to make you visible to those above your immediate manager. Look for areas of chaos, lack of standardisation, inefficient processes and gather people around you to solve it. These don’t even have to be long-running work groups. It can just as well be a tiger team that achieves its goal and gets dissolved after a month or two.

Visibility translates to impact. And measurable impact is tougher to dismiss when asking for a promotion.

Get yourself on a high-visibility, high-stakes team. Look, it’s an unavoidable reality that sometimes you find yourself working on a team that does things more in the background, behind the curtains, keeps the lights on — so to speak. It’s tough getting visibility there, and you might not be the type of engineer that decided to stop at senior level and live a cushy life, more or less stagnating. That’s when you need to find a team that gives you the opportunity to shine. For instance, a few years ago, I joined the small team that was migrating our entire frontend from an Angular monolith to a React microfrontends architecture. There were just three engineers on the team, myself included, but the entire platform’s future depended on us — for scale, a platform serving many millions of students and teachers in public schools on a daily basis. Find out what the next big thing your company is looking to solve, what is the big engineering challenge that most of your colleagues are trying to avoid getting their hands dirty with. Being on a high-visibility, high-stakes team is risky, I’ll give you that, but when successful, it will be remembered and the rewards can get you closer to your next promotion.

Do the scut work. Most engineers will choose the exciting work every time over maintenance, debugging, migration work and the likes, but someone has to do it. Currently, I am involved in migrating our Cucumber E2Es to our own internal test framework. There are basically zero Ruby skills left in the company and over the years we have heavily invested in our own test automation framework as it provides features nothing else out there does. Turns out this migration was attempted several times and never succeeded. There just wasn’t enough willpower behind it to make it happen. Yet, at the same time, it kept slowing us down, like a ball and chain, hanging around year after year. This time, the migration is happening. It’s not what you’d call visible work in itself, but it’s a high-visibility effort because it was abandoned so many times it became notorious for not getting done. Every engineering organisation has something that desperately needs cleaned up. It may not be very exciting, but it can be very rewarding — like looking at a freshly mowed field.

You may be doing your work behind a screen, but don’t let its shadow hinder your career.

Be the voice of reason. We have all been there. Meeting rooms, Zoom meetings or Slack channels where the tension is so high, it’s palpable. God knows, we’re an opinionated bunch. These conversations — let’s just call them what they are: fights — always need a voice of reason. Over the years, I have tried to position myself as a pragmatic engineer, and it has been working quite well, but I have met other engineers who go even beyond that. They sit back, listen to everyone, then explain the pros and cons of every strong opinion in the room and bring the conversation to a point where it has at least a chance of a conclusion or an outcome. One of my best friends is an engineer like that. The downside is that he’ll be brought into virtually every meeting on the calendar. The upshot, however, is that he’s visible, and he is reaping the benefits of that high visibility.

Have a voice. As you are reading this on a blogging platform, I can’t not mention how powerful having an online presence can be. In 2016, I published an article on setting up PHP7 on a Raspberry Pi. Nobody cared. In 9 years, 110 people read it. 9 years later, however, my article on installing CocoaPods on Apple Silicon machines has been read by over 23,000 people in just 2 years and my software developer review of the M2 MacBook Air has been read by over 44,000 readers! If you’re at all interested in writing and sharing your technical expertise, by all means do so as visibly as possible. Start a public engineering blog in your company if there isn’t one already or contribute to one if there is. Use LinkedIn, use Twitter, Mastodon, Reddit, whatever makes sense to you, but don’t hide your light.

Tough pill to swallow?

Perhaps. You may be thinking, “Why can’t I just do my job and get promoted?” Well, partly because beyond a certain point in your software engineering career, your job isn’t to just “do your job”. Also, because it’s been tried and tested. Progression is always about doing something more, something that stretches you, and unfortunately, in software engineering from senior onward that means standing out in some way or another.

I will reiterate, though, it’s perfectly fine not to want that. It’s perfectly fine to stay a senior software engineer and never ask for another promotion, or even refuse one if it’s offered to you. Steve Wozniak — Apple’s co-founder has repeatedly said that he never wanted to climb the ranks of management, he very consciously decided to stay an engineer, it’s what he believed in.

If, however, you do want to be called a principal or distinguished software engineer one day, you need visibility, you need to stand out. There is simply no way around it. Is it scary? It can be. I have heard engineers say, “I do not want the limelight, I would rather not be noticed.” But it’s well worth it if your career is important to you. It will improve not jut your chances for a promotion, it will make you a better engineer.

Use visibility as a tool to make yourself a better engineer, and your career progression will take care of itself.

Attila Vago — Software Engineer improving the world one line of code at a time. Cool nerd since forever, writer of codes, blogs and books. Author. Web accessibility advocate, LEGO fan, vinyl record collector. Loves craft beer! Read my Hello story here! Subscribe for more stories about LEGO, tech, coding and accessibility! For my less regular readers, I also write about random bits and writing.