How to Get Promoted as a Software Engineer (Even During Tough Times)

“Congratulations,” my manager smiled. “You’ve been promoted.” Despite the toughest job market since the Great Depression, coronavirus, working from home, two reorgs, and two different managers, I finally succeeded at getting a promotion (and a raise).

Many people assume, “I’ll work hard, keep my head down, and eventually The Company will recognize me.” Other people believe getting a raise is impossible. They blame anything and everything, repeat the same anecdotes, but never ask “What if I…?”.

When you work hard but get a 0% raise

I did not get promoted for working 80 hours a week or for being a yes-man. I was promoted for prioritizing the right projects and making them succeed.

I wish I had a nice little story that goes from point A to point B.  Instead, promo was a compilation of many behaviors and small accomplishments over the years. I hope that engineers can learn from my good behaviors, and senior engineers can correct me when I focused on the wrong thing. I recommend these behaviors in both easy times and tough times.

Standard disclaimer: don’t take my advice.

My Strategy

My promo journey began two years ago. Google has a rubric about the behaviors and accomplishments it expects from its engineers. I looked at the rubric and thought to myself, “What would it take for me to do those things at the next level, L5? And how do I prove that I did them?”

Every week, I had a 1:1 with my manager. I told him that I wanted to work towards promo. And every week, I would ask questions like:

What things should I keep doing?

What should I do differently?

How can I help the team?

How can I help you?

How can I help our product area in general?

What would it take to get to the next rating?

In other words, I was saying both directly and indirectly, “If I did X, would that give me a promotion/raise?” Then I got my manager’s commitment to proceed, and I aimed to make those things happen.

Make It Happen

I use the phrase make it happen deliberately.  It doesn’t have to be me that works on a specific project. Ramit Sethi says you have two options. “You can do it, or you can cause it to get done.”

For example, the Snapshot page has 65 engineers that have contributed a small amount of code. All their features need tests. Most did not have any. Over time, the bug list grew longer, and I realized we were driving down the road to disaster.

Since it’s infeasible for me to manually fix everyone’s bugs, I built a framework and provided guidance. I followed up by asking everyone to take responsibility for their own code (and their own tests). Thanks to the framework, the system began to scale without any single engineer being the bottleneck.

Sometimes, this “glue” work involved working outside my main codebase. Sometimes it meant non-coding tasks like documentation, attending meetings, and writing emails. A beginner programmer would think, “That’s not my job.” In contrast, I thought, “This is necessary for the ecosystem.”

With extreme ownership and a “make it happen” philosophy, I became an engineer that others trust to handle important projects. Managers love being able to hand off an important project and trust that the engineer independently makes progress.

In general, a good engineer can unblock themselves and get things done without needing constant micromanagement.

A good manager notices this behavior.

In case the manager doesn’t recognize this, a good engineer makes sure their manager understands the truthful difficulty and impact of their work.

Communication is a Superpower

I believe communication is a superpower. I can’t be the most knowledgeable person on every topic. But, if I could convince the smartest people in the room to be on my team, we would be unstoppable.

Not all superheroes wear capes.

Despite my start as an ordinary, computer-loving programmer, I became known as a strong communicator. If a project involved talking with many people outside the immediate team, I was the go-to guy. I felt surprised when my manager complimented me on my communication skills. I simply used Dale Carnegie’s “How To Win Friends And Influence People” to guide my interactions.

Thanks to Carnegie, I have good relationships with my colleagues. When we had disagreements, they were always resolved amicably. I made positive impressions on other teams. Instead of criticizing, I suggested ways they could improve. I aimed to make life easier for my client teams and I genuinely wanted them to succeed.

Finally, I put a 30-minute weekly block on my calendar.  I devoted that time to thinking about perf and the bigger picture. I compiled a little bit of evidence every week in the 6 months leading up to promo. When it was time to write performance reviews, I was ready to go.

The Outcome

I was not nervous when waiting for my promo result. The result was uncertain, but I had done everything necessary, and I did not worry about the outcome. Worst case, I apply again in six months with a stronger review packet–or even appeal immediately.

When my manager told me I was promoted, I felt more relief than excitement. I had planned to take a nice vacation after promo, but Coronavirus held off a big celebration.

But it’s a pandemic? What did you do differently?

Tough times make getting promoted harder. However, the core principles remain the same. Understand what your team and organization needs. Tell you manager what you plan to do (and confirm it’s the right path). Then hit a home run.

Who will your manager promote when budget is limited? The person that proves they have helped the organization.

If you continue to think about the bigger picture, remain a trustworthy person, bring projects to completion, and make the people around you happy, you’ll be a level above everyone who keeps their head down and wishes for a raise.

The Downside

One of the worst parts about working at Google is “perf driven development”. You can get rewarded for solving a problem, but it’s harder to prove that you prevented a problem from happening in the first place.  A focus on metrics means activities that are hard to measure won’t get rewarded.

In my case, I chose projects that would look better for perf. There were some cleanup tasks that I wanted to do, but they kept getting de-prioritized.

Additionally, I could have bit off more than I could chew. I learned an effective tactic to avoid overcommitting. When my manager asked me to take on a new task, I would check my notes and reply, “That will require me to push X to next week. Is that OK?” We understood prioritization. Not all work has the same urgency and importance.

Promo is Easy (For Some)

Another engineer didn’t think much about promo. One day, his manager asked, “Do you want to go up for promotion?”

Engineer: “No”

Manager: “You are doing valuable work. I think you should apply.”

Engineer: “Okay.”

A few weeks later, the engineer was promoted to the same level as me without doing much differently.

So who knows if my intentionality and focus were necessary.

This entry was posted in Software and tagged , , , , , , . Bookmark the permalink.

8 Responses to How to Get Promoted as a Software Engineer (Even During Tough Times)

  1. Pingback: How to Structure Your Presentation to be Clear and Convincing | Sheldon's Software

  2. Pingback: The Best Part About Working at Google | Sheldon's Software

  3. Pingback: 8 Good Communication Habits for Early Career Software Engineers | Sheldon's Software

  4. Pingback: 6 Ways to Negotiate Like a Pro Board Gamer | Sheldon's Software

  5. Pingback: Stop Having Sucky 1:1s with Your Manager | Sheldon's Software

  6. Pingback: 100 Things I’ve Learned as a Software Engineer at Google | Sheldon's Software

  7. Pingback: How to NOT worry about layoffs | Sheldon's Software

  8. Pingback: Get the top rating in your next performance review with this one weird trick | Sheldon's Software

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s