Becoming a go-to person gets you promoted

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.

• 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

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.

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.

I want the template

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:

1. Lead projects reliably and successfully. Even just by yourself.

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

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

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

3. Be visible in Slack. Answer questions. Make announcements.

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

4. Solve unowned problems in a domain or technological area.

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

5. Writing documentation and sharing about it

   1. I set up documentation on how to debug performance issues in tests. This offloads responsibility from me but still points me as the expert.

6. Creating a cool tool that solves a problem for the team

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

7. Lead an initiative that brings together teams

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

8. Create a guild or working group

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

9. Lead a recurring meeting across teams

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

• 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.”

• Starting my career again as a junior engineer by

  on

• Engineers 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:

1. 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).

2. Monthly coaching discovery calls. Learn if coaching is right for you. See what others say

3. 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!