To reach the Senior level, you need to increase your scope, impact, and ownership.
One of the best ways to do that is to become a “go-to” person or an expert.
You could be the “database expert”, “Python expert”, “caching expert”, “frontend expert”, “Typescript expert”, etc.
You can also be an expert in specific product domains, like the “onboarding flow expert”, “payment portal expert”, “home timeline expert”, etc.
Don’t believe me on the importance of this?
Check out these promotion criteria from top tech companies.
Google’s criteria mentions “being a trusted authority on something”
Square Senior Engineer Guidelines
Technical Execution: Is highly proficient in one or more technical areas.
Etsy Senior Engineer Guidelines
Engineers at this level will generally be Advanced in at least one competency or will display some Advanced level skills across competencies.
To clarify, by being an “expert” or “owner” I don’t mean you are the person who has the final say on decisions in a particular technical or domain area.
I mean that people seek out your advice. You are seen as a leader within that area.
📣 JetBrains free learning resources
JetBrains has kindly sponsored the newsletter and is offering free resources for you.
They have learning tracks to make you a pro at nearly any language—Python, Rust, Java, SQL, data structures, machine learning, NLP, and plenty more.
Outside of these learning tracks, I’d highly recommend their Code IDEs. I’ve been using them since I started programming and can say they’ve been a huge source of my productivity. Things just work, without installing 100 plugins.
The IDEs are also free with a student email.
⭐️ Main takeaways
Why being an expert will help you get to the senior level
How to find the best thing for you to become an expert in
How to become an expert in that area
🚀 Why you need to be an expert
If the promotion criteria above wasn’t enough, check this story from
.She highlights a junior eng even becoming an expert in a particular area, and senior people going to her for advice and opportunities.
This was the case for me in my journey to Senior at Gusto too.
Even as an Eng 1, I was the driver of a few important projects early on that allowed me to expand my scope and knowledge within the team. People would come to me for advice on how to modify those parts of the app, or for code reviews. PMs would also look to me for taking on the next project in that area since the first couple went well.
No matter your level, you can start becoming an expert in a technical or domain area, especially if you’re put on a project for that domain area.
💡 How to find your expertise area
Your expertise area can be a technical area or product domain.
Here are some examples across frontend and backend.
Remember you can always start as small as possible.
For example: Within databases, you could start incredibly small like being an expert on databases within a particular subset of tables or patterns.
You can also become an expert in a product domain.
Your company’s product domains will look different than the ones below. These were some of the ones I had back at Gusto.
Note: The above images are not comprehensive. There’s plenty more you can think of to become an expert in.
Now, to assess what you should become an expert in, use this Venn diagram.
The 3 dimensions are:
Team or company impact
What you’re good at
What you’re passionate about
If you can get all 3, double down. Invest more in that area, maintain your expertise and expand your scope. Learn more about that area and keep making impact.
If you are passionate, are good at the expertise area, but are missing “Team or company impact”, you can try to find impact in that area. Maybe you need to start a new initiative that will create impact. Or you could find a different expertise area.
If you are passionate, have impact, but are missing “Good at”, focus on growth. Find a mentor, read a book, take a course, or take on a project in that area.
If you are good at the expertise area, have impact, but are not passionate about it, try to find something else to start becoming known as the expert for. A classic example of this is people who are great at on-call. It has impact, you’re good at it, but you don’t want to be known for this and take on all the on-call work. Start investing in a new area to become known for that rather than the “on-call person.”
Here’s a table you can use as well:
I also have a full template for determining your expertise area. Become a paid subscriber to get full access to it and tons of other goodies.
🔬 How to become known as an expert
Be visible. That’s it. Or at least all you need to remember.
I know it is tough to hear, especially because it would be amazing if our work could speak for itself.
But it’s less about that. It’s more about using your knowledge to level up the team and give value to those around you.
BEING VISIBLE IS NOT BRAGGING!
For example, one of the best ways to be visible is to run a presentation teaching about your expertise area.
I gave presentations on all of these in the past:
CSS Best Practices
Accessibility Best Practices
React Testing Library vs Enzyme
Migrating to a data access layer
Why we need to use GraphQL Batching
All of them are giving some form of value. It’s either giving others tools to do their job better or convincing the team to do something that will benefit all of us.
Here’s a list of other ways you can be visible along with a few examples from my past:
Lead projects reliably and successfully. Even just by yourself.
For my first few projects at Gusto, I made sure to go the extra mile. I stayed in close sync with my manager and made sure I was meeting and going above the expectations where I could.
Say you’ll do the thing. Do the thing. Say you did it. Follow this framework to keep people in the loop of the request they made and the progress.
Only doing “do the thing” is allowing your work to speak for itself, which unfortunately is not what will get you the most value in the business world. It also doesn’t help your team either since they’re not up to date.
Be visible in Slack. Answer questions. Make announcements.
There are often eng-help channels you can try to answer questions in. If you often answer questions in a particular domain or technological area, over time people will start seeing you as the expert.
Solve unowned problems in a domain or technological area.
I set up patterns for handling GraphQL N+1 queries then I ran a presentation explaining how to use those patterns to improve our performance.
Writing documentation and sharing about it
I set up documentation on how to debug performance issues in tests. This offloads responsibility from me but still points me as the expert.
Creating a cool tool that solves a problem for the team
I saw our team doing a bunch of manual work when importing translations from our translation service. I set up a CLI tool to allow them to run a single command to do the importing process.
Lead an initiative that brings together teams
I got together a few teams to align on API consistency patterns since our GraphQL schema was getting complicated for our primary consumer, the Mobile team.
Create a guild or working group
I didn’t create, but led the Frontend guild for a short period. This positioned me as an expert within the org, or at least someone who was resourceful and could point you to the right place for what you need.
Lead a recurring meeting across teams
I set up a bi-weekly sync between our team and our primary API consumer, the Mobile team to prevent surprises and keep a good relationship between us.
📖 TL;DR
Why you need to be an expert
Becoming an expert gets you opportunities. Opportunities get you promoted.
You increase your perceived value. Your manager might think, “I need them. They’re my database person.” This also leads to faster promotions.
How to find your expertise area
Evaluate expertise areas on 3 dimensions: What you’re good at, what you’re passionate about, and what is impactful to the company. Getting all 3 is the sweet spot.
How to become known as an expert
Be visible. But add value while you’re doing it.
Give presentations, lead projects reliably, do what you say you’ll do, write documentation and share about it, solve challenging technical problems for the team, lead a recurring meeting, lead an unowned initiative that brings teams together, create a working group like a guild.
I hope you enjoyed this article. Fun fact, this was the first topic I ever wrote about because of how important it is. Check my first article, “Make yourself known at work.”
📣 Shoutouts
Starting my career again as a junior engineer by
onEngineers Guide to Feedback by
on- (Former Amazon Director) writing at moved to Substack and shares his highest ROI action at Amazon. The story also is in line well with the lessons here of adding value while being visible.
What I wish I knew as a Mid-level Engineer by
on —a story about focusing on impact rather than output.
As always, thank you for reading and the growth to 33k+ subscribers.
- Jordan
P.S. If you’re interested, I’m accepting the following:
Waitlist spots for the next Mid-level to Senior cohort (this particular newsletter topic is 1 of the 5 modules we cover in more depth).
Monthly coaching discovery calls. Learn if coaching is right for you. See what others say
Newsletter sponsorships: Feel free to reply to this email or check the Sponsorship packages
Did you find this issue valuable? If so, there are two ways you can help:
You can also hit the like ❤️ button at the bottom of this email to help support me. It really helps!
Great article, Jordan.
Just sharing some of the things that worked for me:
About deciding what work is important, a mentor of mine talked to me about finding the critical path of the org. If there are layoffs, if the work is re-prioritized... which parts are more likely to stay as they are? They are usually profitable parts that still have a big potential. The parts that enable many other people to function properly.
About doing stuff to increase your value, I love engineering groups. There are some roles you can have outside your team (I guess in all companies there's something like this). I started being part of a design review group in my org. Around me, I find roles like this for operations, infrastructure, postmortems, and even document reviewers. Whenever the topic arises, people will ask the closest person to them who is part of these groups. They have a magnet effect, you can become the go-to person for design reviews :)
Or, it will permanently solidify in your current positions, because that is where you are needed. 😅