Article originally published on my blog at ieftimov.com.

---

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 have been asking myself: what is one high leverage change I could have 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 have 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 you would like to join one of those companies and spend years (or decades) there, you'd likely be forced to make the step up.

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

Interdell

Interdell is a fine place to chill. The tools are familiar. No Git rebasing is too hard, with a few exceptions. Reviewing the team's pull requests goes smoothly. Being the onboarding buddy of the latest addition to the team went smoothly. A senior engineer pulled you in for a deep dive into a particular performance bottleneck that you observed in the monitoring tooling, and you could contribute. How awesome is that?

While we are at it, remember when you had no idea how to navigate DataDog? Hah, those were the times!

As you can see, the valley is a sunny place where rain rarely pours. From the north and south side lie the Frontend and Backend Senior's Ranges protecting Interdell, while from the east lies the coast of the EMs. In the distance, you can see the PM's Archipelago. It feels like one can easily swim to the islands, but you've heard stories about people trying but struggling with the currents of the sea.

At this point, I will stop torturing you with the valley metaphor and come back to my narrative. Senior colleagues and leadership shield intermediate developers while expected to ship and continue learning on the job. As I said before, this is fine if that's what you are looking for.

But one of the main drawbacks of staying intermediate is lack of autonomy. They 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.

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 have 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 have 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.