Pay Bands: What They Are and Why They’re Usually Wrong8 min read

After my last post It’s Happening: the Consolidation of PM Roles, I’ve had multiple conversations that got into the weeds of how these moves work at larger tech companies. I quickly realized I needed to address a particular gap – that of pay bands – when I saw this comment on Joshua Teeter’s post about the Instagram consolidation of PM and TPM:

To be fair, if a TPM at Meta moves into a PM role, they’d be getting significantly more in compensation.

This comment hit close to home, as I worked at Meta for ~3 years and experienced this truth first hand. But I’ll get into my personal experience shortly – first, allow me to explain some context.

Most tech companies work such that every role has their own pay bands. This means that no matter how similar roles are, people in two different roles at the same level may be paid different amounts on average. While this maximizes flexibility to pay what the market demands for each role, it also comes with a host of problems.

Before we continue, I’d like to add a disclaimer: this LinkedIn comment is a good one, and this post is in no way meant to shame this person.

Let’s take a step back: what is a pay band?

Most tech companies follow a formula to calculate how much to pay new hires:

Role x Level = Pay Band

Now, this isn’t a strictly mathematical formula, as “role” is just a string of text, such as “Technical Program Manager (TPM)” or “Software Development Engineer (SDE).” Additionally, each level does not bump the pay band by a fixed linear amount. For example, if you start at level 1 in a role, level 2 is not necessarily 2x the pay. Instead, pay bands are manually decided, and then everyone in that role at that level is supposed to fit inside the band.

So what’s the problem?

Typically, every role has their own pay band, no matter how similar the roles are. Thus, it is no surprise to see PMs exhibit this behavior:

For example, at Amazon, I saw multiple friends go from Financial Analyst → Program Manager (PgM) → Technical Program Manager (TPM) → Product Manager (PM) → Product Manager-Technical (PM-T), often within a ~4 year span.¹ While I am a staunch believer in horizontal mobility, this type of movement had one reason and one reason only: $ave dat money.

If you zoom out, you see broader problems outside of just the PM community. Tenure in the tech industry is not rewarded and we tend to change companies every few years.² Even during our (relatively short) average tenure at a company, we are fixated on promotions to increase our pay. Alternatively, we change roles to those with higher pay bands – but when we do it for this reason, we dilute the role’s meaning, eventually demonstrating that roles shouldn’t be separate and should instead be consolidated.

Let’s break these problems down and explain why they occur.

Problem #1: Obsession with promotions

Pay bands tend to not be wide enough, which forces a promotion to occur for a raise. The average raise at a tech company tends to be ~3%, and performance only increases/decreases this by 1-2%. In recent years, where inflation exceeded 5%, this means that even your best employees are getting paid less year over year (YoY) unless they get promoted. And if you’re already at the top of your pay band, you can perform well and receive a 0% raise or even a pay decrease – I know this because I lived it.

Years ago, at Amazon, I earned a prestigious “top tier” award in my annual review. This was a mechanism to give a more significant raise without requiring a promotion to the top performers at the company. However, because Amazon’s stock had risen “too much,” I was already at the top of my pay band. So much so that I got a “pat on the back” and no raise despite being a top employee in my role and level.

Wait, Straker – are you complaining about being overpaid? Hah – busted! Joking aside, I am not writing this to complain. Rather, I am writing to explain how this system works and the flaws it has, with my personal anecdotes adding to this story. I am comfortable sharing numbers, but whether they were high or low is relative. My numbers were significantly less than what you see on levels.fyi today, and let’s just say I had a non-insignificant amount of student debt. No, sadly, I was not living high on the hog. Which leads me to the next problem…

Problem #2: Selective usage leads to new hires being paid more than tenured employees

Pay bands are ever-evolving, usually pushed higher by recent employees negotiating higher amounts.³ This leads to situations where an employee hired last year is often paid thousands less than an employee hired this year. This is avoided if equity prices rise, but is even worse if equity prices fall.

Wait, equity? Yes, most tech employees are paid significantly in equity instead of cash. This is not always the case, but it is the norm, with equity sometimes pushing up to a third or more of one’s total compensation.

Now do you see why tech employees don’t stick around one company? Stock went down? Change companies. Stock stayed flat? Change companies. Stock only went up a little bit? I bet that new hire at your same level that you’re mentoring is getting paid more than you;⁴ change companies. There are more reasons to change companies than there are to stick around!

But wait – if the pay band goes up, can’t employees just get raises to match the new pay band? Technically yes; however, that doesn’t happen at most companies. This is not pay bands’ fault, but process’ fault. The typical HR process in tech is to do a single annual review where you receive a minimal salary raise and equity refreshers to keep you at about the same pay from an equity perspective. This usually assumes some amount of growth in the equity that isn’t shared publicly, and if that internal growth target isn’t hit, your pay may decrease.

Problem #3: Horizontal mobility is discouraged

Given every role has their own pay bands, you now have people chasing roles with higher pay bands instead of playing to their strengths and maximizing their value to the company. To elaborate, let me continue my anecdote from earlier.

The year after my “top tier” review, I had an intentional pay decrease despite getting promoted. Why? Amazon’s significant initial vesting cliff didn’t help, but my promotion largely offset that issue. No, my issue was that I transitioned from an SDE to a TPM which had a lower pay band.⁵ It did not matter that as a TPM I brought in a billion dollars in revenue in 24 hours during Amazon’s first-ever Prime Day, something I wouldn’t have achieved in 10 years as an SDE. TPMs were paid less, and that was that.

Again – cry into your paycheck, Straker. Agreed – I am not writing this to complain. Rather, this anecdote helps make the point that this system is flawed. I obviously no longer work at Amazon, and I wasn’t the only one to leave. Amazon’s “brain drain” at the Senior level was so significant that a formal program had to be spun up to help encourage retention. Surprise: they made promotions easier to address the problem, but this was just a band-aid and did not address the root cause.

However, Amazon is not alone in having these types of problems. When I joined Meta as a TPM, it was a relatively new role for the company at the time. A year or two later, PMs were introduced to the mix as well. Interestingly, TPMs reported to TPMs in a TPMO, and PMs reported directly into the engineering organization (typically at the director level) in a hybrid approach.

As a TPM, I was doing product design and mock UIs for engineering teams while PMs owned broad “big bets” that spanned across the organization. In other words, PMs were TPMs and TPMs were PMs 🙃. While I appreciated my time learning how to be a PM, I wanted to be a TPM, so I sought to transition to PM 🤯.⁶ However, this was not permitted (for me or others who felt the same). Why? Because the PM pay band was higher, and folk assumed this was why we wanted to transfer. This story has the same end as the Amazon anecdote: I (and others) left the company as a result.⁷

Both anecdotes share a common theme. In both, I sought to maximize my value to the company. In both, I was not thinking about pay bands when seeking to transition roles. However in both, pay band differences reared their ugly head. I was able to transition from SDE to TPM at Amazon easily because the pay band was lower, but I didn’t find this out until years after I made the switch. And then when the pay band was higher, I wasn’t able to transition at all despite being extremely qualified for the role.

I am not saying that horizontal mobility should be granted simply because I asked for it. However, pay bands should not be a part of the conversation or a blocker to such movement!

So what should be done instead?

While this post may feel like I am building towards eliminating pay bands, the reality is they are but a tool, and tools are only as effective (or ineffective) insofar as they are wielded. If you have pay bands at your company, you do not have to make drastic changes. Rather, PM, TPM, and SDE pay bands should be the same. What this enables is horizontal mobility irrespective of pay.

But wait – these roles aren’t worth the same, Straker! I have worked at three large tech companies, and each one had the three roles mentioned: TPM, PM, and SDE. Yet not a one of them agrees on which role should have the highest pay band vs the lowest. Given this industry inconsistency, I do not agree that each role needs its own unique pay band.⁸ When combining pay bands, it is OK to make them broader. This simple change alleviates the third problem statement in its entirety.

There is an equally simple solution to address the first two problems: allow for higher employee raises with your regular review process to keep them competitive within their pay band. Pay bands should be a two-way street and benefit new hires and tenured employees alike rather than selectively applied!

If you don’t have pay bands today, I would love to caution against implementing them, but pay transparency state laws make them tough to avoid. That said, if you implement the simple fixes outlined here, the tool can be just that – an effective tool to help with a host of goals. From answering what to pay new employees to helping retain your valued tenured employees, pay bands can be setup to achieve multiple goals – they just need to be approached with intention!

How does this relate to Instagram’s consolidation of PM and TPM?

While news of Instagram’s role consolidation reads as the elimination of the TPM role, I view it as the reverse given how PM and TPM are approached at Meta. Furthermore, the empirical evidence that TPM and PM role definition is so inconsistent across companies that they can be completely swapped from one company to the next cannot be ignored.

My last post It’s Happening: the Consolidation of PM Roles was not saying that you only need one person to do two jobs; I’m not quite ready to recommend Linear’s solo head of product role. Rather, the roles’ differences are too nuanced to be separate roles. You should still have multiple PMs or TPMs on a project when needed, and they can work together to split up the work as needed. The most successful projects of my career, including Amazon’s first Prime Day that I referenced earlier, were certainly not solo efforts.

But if you are going to have separate roles, align the pay bands. In doing so, you enable specialization and the rewarding of different archetypes regardless of what you call them.

---

Footnotes

1. I hear the TPM pay band may be higher than the PM pay band at Amazon now, but the point remains the same. ↩︎
2. My data is old, but last I had formal data Amazon’s average tenure was just under 2 years per employee, whereas Meta’s was around 4. Perhaps that has changed more recently, but it’s hard to find data that excludes layoffs. You can read about the tech industry’s struggles with this in general here.  ↩︎
3. I’ve also seen pay bands be adjusted lower for reasons such as one person being a bad negotiator or a remote company avoiding location-based pay (a good thing) but then bringing pay down to Low Cost of Living (LCOL) rates. ↩︎
4. If this reads a little…specific, it’s because it’s yet another anecdote that I experienced. I was the mentor in this scenario. ↩︎
5. If you’re at Zillow, now you know why I aligned the TPM pay band with SDE so that transition between the roles could be about success and not short-term financial differences. ↩︎
6. While I don’t love having the two separate roles, if both exist, I prefer the TPM role to a PM one. ↩︎
7. I suppose this worked out given the layoffs that have hit Meta and drastically affected the TPM function there. ↩︎
8. To be clear, if TPM and PM both exist and they follow the differences outlined in So, What is a Technical Program Manager (TPM), Anyway? Part 2: The Four P’s, then the PM pay band would be expected to be lower. But SDE and TPM pay bands should remain the same. ↩︎