How to Make the Step up From Intermediate to Senior Engineer

We live in a world where we like to get fast (or even instant) gratification from our things. While I try not to subscribe to that type of thinking, I often try to think of high leverage changes that bring significant benefits.

Following that same thinking, while reflecting on my career so far, I’ve been asking myself: what is one high leverage change I could’ve made five years ago to get faster to where I am right now?

Before we continue, I am curious: what would be your answer to that question?

My answer? Step up more often. Let’s unpack.

Plateauing #

Career plateaus have been long documented. One of them that I’ve observed occurs when an engineer becomes comfortable at the intermediate level. They have a good command of the tools, know how to work well within the boundaries of their team, and can provide value at a predictable pace.

At many companies, this is considered a ‘career-level’ or ‘terminal-level’, as in you can spend the rest of your career operating at this level without being pushed out for not being promoted. Being an intermediate engineer is a great place to be at if this is what you want out of a career, but I’m assuming you’re reading this because you want to grow and take the leap.

Also, many well-known tech companies (think FAANG and the tier “below”) set the career level at senior. So, if an engineer would like to join one of those companies and spend years (or decades) there, they’d likely be forced to make the step up.

In addtion, one of the main drawbacks of staying intermediate is lack of autonomy. Intermediate engineers require the cover from more senior folks, even on smaller tasks. The weak (or, lack of) agency on the situation and the outcomes is why larger companies do not consider the intermediate level a career-level.

Therefore, the question remains: what does one need to get over the intermediates’ valley and walk in the woods of seniority?

Taking the bat #

At the risk of offending a bunch of (all?) senior engineers out there, I believe that an entry-level senior has comparable technical skills to a solid intermediate engineer. In other words, my claim is that the distance between the technical skills of the two is negligible.

If we accept this presumption, then the natural question is, what is, in fact, the gap between the two? Or, to put it in a more actionable form, what skills should one acquire to bridge the gap?

For one to truly leap to become a senior, in my view, one has to be comfortable to step up and take the bat.

What stepping-up means is very contextual. But we can bucket it into technical and organizational work. You should always prefer to step up on technical tasks. Stepping up on technical tasks is preferred because your role is to ship and maintain code before everything else as an engineer.

But there are other, non-technical ways to step up. During planning, do the “dirty” work and update all of the JIRA cards as you close the sprint. Your team will love you for it. If you cannot technically aid the mitigation efforts during an incident, make sure to capture a paper trail, communicate to internal stakeholders, or bring in the necessary people who have the know-how. Or volunteer to be the onboarding buddy for the newcomers on the team. Or write documentation. Or improve the test coverage on the module that shipped the last sprint. You get the point.

Tanya Reilly called this being glue. But, as she mentions in her article, glue work is expected from senior engineers. And it can be dangerous when done by non-seniors. That’s why I believe you should default to technical tasks when stepping up.

I recommend you watch Tanya’s talk above. But, no worries, I’ll stand by.

If you realize the dangers of doing only glue, it’s is a powerful weapon to wield.

Don’t just jump in on the first idea #

Before you begin, I would like you to think about thoughtfully approaching this. Do not just jump in the water unprepared.

Here are a few things you can do as a prep:

1. Source ideas. Your teammates or leader(s) are probably experiencing various paper cuts every day. Have a hot beverage with them and see where their pain points are. If you are on a product team, talk with your product manager or UX researcher – they indeed have some exciting user problems to share.
2. Communicate with your leader (manager, tech lead, etc.) before you leap. You’re an engineer that is expected to ship code. When you decide to write documentation, make sure it’s trackable, time-constrained, and aligned with the team’s, and by extension, the company’s goals.
3. Don’t just do it. Approach this like any other coding problem: discover what it means to do it, set goals, scope the breadth and depth, break it down into smaller chunks, list them out in a document or tickets. You need a structural and measurable way to tackle these tasks so you, your manager, and your team can understand the deliverables and the progress.

Ideas to step-up on #

When it comes to technical tasks, I think that there are two buckets here:

1. code: writing, debugging, maintenance, refactoring, profiling
2. technical organization: improving the scaffolding that the technical organization relies on

Below are a few ideas for both buckets:

Coding tasks #

Write tests for a under-tested module #

Sometimes during crunch, engineering teams are known to cut some corners. While frowned upon, it’s often easy to skip tests, especially if the team is under pressure to ship.

Take stock of where you can improve the code coverage, and take a shot at it—use code coverage tools to give you a measure of where you should start. Also, suppose there are problematic areas of the newly added code (think: lots of errors reported). In that case, that’s a hotspot you can start testing, covering edge cases, and ultimately decreasing the error rates.

Improve instrumentation in team-owned code #

While we are cutting corners, instrumentation is another aspect I am sure of saving time/energy on. Adding more data points that can highlight the health of the product or service is a valuable effort, especially when accompanied by a dashboard that is easy to digest.

Investigate/resolve performance pain-points #

Every codebase has performance issues. Use your company’s application performance monitoring (APM) tooling and find such hotspots. Always start with the hot paths because that’s where you can make the most significant difference. For example, if you shave 50ms off a critical code path that runs millions of times per day, you’ll end up saving a lot of time for all users on the product.

I’ve spent a lot of time with Rails, and Rails makes it quite effortless to inadvertently add N+1 queries. APM tooling, like Datadog, makes it easy to spot code paths that produce N+1 queries. Do not shy away from relying on them.

Pair-program with a newcomer on the team #

As the company grows, new people will start joining your team. Onboarding them is also a high-leverage activity: not only do you gain a productive colleague to help the team with the workload, but also you will learn from them.

The most-effective onboarding, from my experience, is when the newcomer pairs on well-defined tasks with an engineer from the team. They rub off domain and stack knowledge and cultural values and principles that the company appreciates.

Technical Organization #

Lend a hand to your tech lead #

Your tech lead is pulling a lot of weight, and there are undoubtedly some interesting bits on their TODO list that you could take over. However, keep in mind that it’s unlikely that they will ask you to hand over a task. After all, it’s your job to focus on shipping code, so they might be hesitant if you ask for it. But, again, if you are mindful of how you approach them and explain how you will systematically tackle the challenge, their concerns will slowly melt away.

Prepare the next newcomer’s onboarding program #

While I firmly believe this is highly technical work, I decided to put it in the “technical organization” section because it doesn’t involve shipping code. Still, as I mentioned above in “Pair-program with a newcomer on the team”, preparing the team and tasks so the newcomer can hit the ground running is also very valuable.

Depending on the organization’s maturity, there might be onboarding programs in place. Onboarding teams commonly lead these programs and put the newcomers through a week (or weeks) of various classes, meetings, and Q&A sessions. They absorb the company’s history, culture, processes, and technology choices in these first couple of weeks.

Once done, the onboarding within the team is crucial, and this is where you can shine. Make sure to line up well-defined tickets, some of them tailored to be done in pairs (by you and the newcomer), and others that are small enough to be done by the newcomer alone. The split of the tasks will give the newbie ample opportunity to rub off knowledge from his onboarding buddy while also having alone time to code and learn at their own pace. Also, make a list of must-read documentation, that would give the newcomer the most value by reading it.

Once you do this a few times, you can take the learnings from the past onboardings, get feedback from the newcomers on what could’ve gone better, and use all that to establish the team’s onboarding program.

For example, source ideas from the team on simple projects that the new folks can work on have them scoped and prepared well in advance. Then, when the new person joins, have a kick-off meeting, explain the project, and set some ground rules on how you will approach it together. Then, create an operating system of the program: stand-ups, office hours, pairing sessions, Q&A with the rest of the team, and all other scaffolding required to succeed in the onboarding project. In the end, make sure you do a demo to the team, and maybe send an announcement email to the rest of the organization about the newly delivered project.

Create or improve dashboards #

Another area where there’s always room to improve is dashboards. Some can be outdated, and others can be nonexistent. However, any team worth its salt will have a dashboard in place to see the health of the system(s) or product(s) owned at a glance. Frequently these are shown on big displays in the offices.

After some exposure to the dashboards, you will notice their shortcomings. For example, some dashboard metrics might not be as relevant now as they were when the team created the dashboard. Or maybe the widgets arrangement is flawed, and you believe that you can improve it.

One thing that I always mind about dashboards is entropy. What I mean by that is no standardization between the widgets and metrics displayed on the team’s dashboards. While I am all for self-expression, I am lazy and hate to adjust my brain depending on the dashboard I am looking at. I believe that all unified dashboards are best because you can instantly know if something terrible is happening in a single glance.

If you share my sentiment, there’s an excellent project to spearhead for your team and organization.

Improve (or establish) the incident response protocol #

If you are in a young organization that does not have well-established incident response protocols, this is a great way to shine. Even in small organizations like yours, incidents happen, and they will be business-disrupting events. You have users/customers to answer to, regardless of whether you’re a small company or a FAANG-like behemoth.

To create a problem statement, review how the company has handled recent incidents and look for shortcomings. It can be as simple as “rely on Zoom call instead of Slack if the severity is high”. There are no severity designations? Perfect. Try to codify that first before everything else.

As I said before, you will need an approach to doing it – don’t just jump in writing the documentation. First, begin by interviewing a few folks in the org and understanding their IR protocols view. Then, once you get enough insight, write a proposal document and share it with the technical leadership. But, again, keep it concise and to the point.

After the proposal is approved, dive into writing an elaborate RFC document through which you will define the protocol. Even though you would be driving the writing, make sure to request (and incorporate!) feedback from other folks.

The bottom line #

The list of examples that we covered is not exhaustive. Every organization is its own intricate living organism, with its own needs and shortcomings where you can find your opportunity to step up. Things always need improvement, and stakeholders will have ideas on the flaws and opportunities.

For example, your organization might already have a well-established incident response protocol, but cross-department communication during an incident needs work. Your opportunity is to develop ways to efficiently broadcast the incident response communication to the other departments. For example, think about Slack automation (bots/workflows) or having the incident scribe push their updates to other channels.

The bottom line is: you’ve to begin thinking and acting like a senior before you leap. The promotion is not an invitation to start behaving like a senior engineer but rather an affirmation of your current and past behavior as one.