Ever since I started learning to code, I have dreamed of becoming a senior engineer. Some may think this a bit odd. Shouldn’t my main goal be to get a job first and worry about a promotion later?

Generally, yes. But, as someone who has changed careers four times in as many years, I didn’t want to simply change my career. I wanted to thrive in it. And there was no better example of thriving in the tech field than being a senior engineer.

Senior engineers are the masters of their craft. They are rockstar developers who churn their code at breakneck speeds. They are the pinnacle. Right?

Well, after years of working and learning, I happy to proclaim that I’ve made it. I am now among those with the coveted senior title. But you know what the craziest thing is? I’m none of the things I described above.

Rockstar code-smith producing code at 10X speed? Not quite. I’m your average 1x engineer who has Stack Overflow bookmarked. How does someone like me end up a senior?

That’s what this article is going to focus on.

Over the years, I’ve come to realize how propped-up my image of a senior was. Many articles define the characteristics of a senior developer. Fewer discuss how to become one. I want to address that gap.

This post will show the steps I took to arrive at this point in my career and dispel some myths that I’ve seen newer engineers, including myself, fall prey to. Keep in mind, this was just my path and is in no way prescriptive, although I do hope it provides some insight.

So, how did I become a senior software engineer?

I Asked

Photo by Scott Graham on Unsplash

Seriously, I just asked.

After my one-year anniversary at the company, I approached my manager. I recapped my accomplishments and expressed my interest in getting to the next level in my career.

I followed up with a simple question: “How can we make that happen?”

After that meeting, my manager and I came up with a development plan and within that year, I earned my promotion.

A trap I see many new developers fall into is believing that our industry is a meritocracy. They believe that they will get what they deserve if they work hard enough. Once they’ve proven their worth, their employer will reward them with a raise or promotion.

While the tech industry may be more of a meritocracy than other industries, there are countless undervalued developers. I know several myself.

There are many reasons why engineers may be underpaid and under-leveled. I don’t pretend to understand anyone else’s situation. However, the reason I became a senior is that I pushed for it.

Photo by Tim Mossholder on Unsplash

But how do you know when to ask?

This is a great question and is also highly subjective. The problem I have with defining “senior engineer” is that each company has its own definition. Taking a blog post to your manager and saying, “according to this, I should be a senior engineer” isn’t going to work.

The criteria for becoming a senior engineer at a ten-person startup will be different from a FAANG company.

Luckily, many companies provide detailed criteria for the senior role. This was the case for me. Whenever I made an achievement of note — shipping a new feature, refactoring old code, or handling an incident — I kept a record of it. After a while, my accomplishments began to look like those of a senior engineer. That’s when I knew to ask.

If your company doesn’t have a clear benchmark, I would suggest talking to your coworkers. Ask other senior engineers what they’re working on, review their code contributions, and/or ask them, “how did you become a senior engineer?” I’m sure you’ll find at least one person willing to talk your ear off about their accomplishments. I’m doing it right now.

Speaking up for myself and pushing for my own goals was crucial. But, it would’ve been for naught if I didn’t have the proof to back up my value. Which brings me to my second point.

I Utilized My (Non-Coding) Strengths

Photo by Clark Tibbs on Unsplash

Another misconception I see about senior engineers is that they are all masterful programmers. I’ll be the first to admit that I’m a pretty average coder. I know a thing or two about a thing or two, but I won’t be winning any awards any time soon.

But being a senior isn’t about being a code-smith. As Patrick McKenzine wrote in Don't Call Yourself A Programmer, And Other Career Advice:

“Engineers are hired to create business value, not to program things.”

It’s all about providing value to the business. As an engineer, a lot of the value you bring will be a direct result of the code you write, but there are other ways, too. Each of us has different strengths other than coding. Utilizing those other skills can help you stand out.

For me, it came in the form of writing, speaking, and teaching.

During my first year at the company, I had difficulty understanding how the system worked. Hundreds of moving parts, combined with halfway-refactored services, made for an opaque structure. While our code base wasn’t old by any means, it had its fair share of tech debt with which we were still grappling.

Many of my coworkers felt this same struggle, though not all. There was a mental fissure in the engineering organization. Several engineers dated back to the company’s founding and knew it’s historical baggage. However, there were even more engineers that didn’t. The knowledge gap was a divide that was widening with every new hire.

So, unable to piece things together myself, I began talking with my tenured coworkers. I asked them how the technology worked and how it had evolved. What trade-offs were made, and what role did each team play in the system? Some of these conversations lasted for hours.

Through these discussions, my mental model formed and solidified. I had obtained the coveted knowledge that so many of my coworkers sought. The trouble was that it was all trapped in my head, which didn’t benefit anyone except me.

That’s when I realized what value I could provide! I was in a unique position to fill the knowledge gap. By putting pen to paper, I recorded the company’s technical history. From it’s founding to the present day, covering the technical decisions, trade-offs made, and tech debt accumulated.

While I’ve never won an award for my coding, my writing is a different story.

Photo by Pereanu Sebastian on Unsplash

I interviewed senior and staff engineers past and present, and one of the founders. What started as an internal document blossomed into a public article and a tech talk. It has aided in onboarding newer engineers, as well as giving back to the developer community.

I received accolades from many of those who viewed it, including the VP of Engineering, the Head of Product, and CTO. For a mid-level engineer, that level of attention was foreign but exhilarating. It also played a key factor in my future promotion.

This is not to say that everyone has to write a blog post, that’s just what I did. There are always ways to stand out and add value. If you’re a coding savant, then let your code speak. But if you’re a mortal like the rest of us, then play to your other strengths.

I Became Essential to My Team

Photo by Marvin Meyer on Unsplash

I had always thought of senior engineers as code machines. They were the ones finishing the most tickets, shipping the most features, and writing the most code. Imagine my disappointment when I realized that, along with being an average coder, I’m also a remarkably average producer.

However, I’ve come to learn an important lesson. While speed is nice, consistency is just as important. And what I lack in speed, I make up for in consistency. The tickets to which I commit myself, I finish. I don’t shy away from giving estimates. And if I get blocked, I update my manager and stakeholders and let them know how long I’ll be delayed.

In other words, I’m a reliable team member. I’m honest about what I can accomplish, and even more important, with what I can’t. I do my best to support my team and make their lives easier. This extends to emergencies as well.

Last year, my tech lead messaged me out of the blue to let me know that our metering service wasn’t working properly. A bug was merged into production that was preventing usage from being recorded. When I asked when the bug had been introduced, my heart sank when my lead responded with “over a week ago.”

This was a major problem. The system that we relied on for accurate billing had been down for over a week. No one knew why and how we hadn’t detected it earlier. To make things worse, the engineer who had built the service, and knew all its ins and outs, had left the company.

We needed to get the service back up and running as soon as possible. Not only that, but we also needed to backfill multiple weeks worth of usage data. With my tech lead in emergency meetings and the only senior engineer on my team unavailable, the task fell to me.

Photo by Tonik on Unsplash

Even though I didn’t cause the bug nor did I write the impacted service, I took ownership of the situation. I identified the bug, made the patch, and, crafted a solution for fetching the missing data. I also kept in constant communication with stakeholders, letting them know of updates, and assisting in the postmortem. When my team was in trouble, I stepped up.

But, I didn’t stop there. The experience had been so stressful that I vowed it wouldn’t happen again. I improved the tests, health checks, and added more substantial alerting. If something were to go wrong again, we would know about it immediately.

These added measures are what caught the attention of my director. He told me that mistakes happen — even mistakes that result in lost revenue. Ensuring those mistakes never happen again improves the team as a whole. And sure enough, my team has not had an issue with that service since.

Becoming a senior engineer, for me, was realizing that reliability is essential. The more dependable I am, the more my manager and the team will trust me. The added authority and responsibility that comes with a senior title can only be earned through trust. And trust can only be built over time through consistency.

A meaningless sign — Photo by Micaela Parente on Unsplash

A parting thought: Titles are meaningless.

However, they do signify growth and progress, which is what many of us seek in our careers. The money doesn’t hurt either.

Don’t seek the senior role just for the sake of a new title. Trust me, it won’t change anything. You might have some extra responsibilities and a slight uptick in recruiter emails, but you’ll be the same engineer you were before.

Growth and self-improvement should be your real goal. If you focus on mastery, the titles and accolades will come along the way. But don’t forget to trust your worth and advocate for yourself — don’t wait for someone else to do it for you.