Following up on my post about writing personal weekly summaries, this post explains how you can scale the process to your entire organization. In doing so, you create a “pyramid of radical candor” that directly combats insular communication.
But wait, there’s more! If you have reasons to share your org roll-up externally, the leader of that org can filter the document to make an external version. Pyramids within pyramids…
This is especially valuable if you are in a remote environment or in an organization where different roles report to different leaders. This mechanism maximizes communication flow and minimizes your time spent in status update meetings.
After my last two-part series about creating ladder guides, I finally have one for TPM! To my knowledge, this is the first ladder guide for TPMs available for use in an open and free way.
Read the post for the links to freely use the ladder guide yourself!
Here we are – this is it! Drumroll please 🥁…the post where I debut a framework to make a ladder guide for any role in the tech industry! But when I say “I,” I don’t mean just mean myself. I want to introduce and heap praise upon my former coworker and now coauthor of this post, Bryan Zug. It is only thanks to him that we have this open source framework that you are free to use!
Read more for templates to use and instructions on how to use them
In the tech industry, if you really want a role to exist at a company, you cannot avoid what is likely the most ubiquitous and simultaneously most hated tool in the entire industry: the ladder guide.
What is a ladder guide? Whether you have people in a role already or are looking to hire your first, you want to be sure that those in the role are setup for success. You want to be sure that you are hiring the right people for what you need. You want to be sure that the people hired will be happy and worth the expense of hiring them. And as per my last post about pay bands, you want to be sure you are paying people the right amount.
Do you now see why we all have a love-hate relationship with ladder guides? We hate them, but we need them. The list of questions goes on, but a ladder guide is a tool to help answer these questions.
Click in to learn more about how to create a ladder guide!
After my last post, 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 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.
This past year has been a tough one for the tech industry at large. Still in 2024, more and more layoffs are happening daily. Last week alone (the second week of January), we saw Twitch, Discord, Google and more have layoffs; it’s no wonder that thousands of Software Engineers say the job market is getting worse! I want to talk about a different angle, one that isn’t as broadly covered in the mainstream media: how this impacts the Product and Program Management job functions. As there was another layoff last week that hits close to home: Instagram laid off all Technical Program Managers (TPM), consolidating them into the Product Management (PM) function.
If you’ve been reading with me for the past year, you’ll know that I am about to say something controversial: kudos on following my advice, Meta. Before you come at me with pitchforks 🔱, allow me to explain myself!
As tech layoffs continue, including Return to Office (RTO) mandates which cause attrition by design, there has been a very real pressure to focus on “efficiency” in 2023 that I am starting to see carry into 2024 plans. Meta went so far as to dub 2023 “the year of efficiency.” This focus makes sense given the macro economic state and a pace of rising interest rates not seen in 40 years. *But how?*
Coupled with the focus on efficiency, the general industry sentiment is that engineering teams are getting slower. And to that I would say: they are right. We seem to have forgotten what we know from Mythical Man Month, which I will summarize as “the fastest way to slow down a project is to add more people to it.” Despite this, the software industry has grown immensely. For example, Meta’s employee count has an exponential growth shape. While rounds of layoffs will cut this number for 2023, the shape is still exponential and the size of organizations have increased tremendously; it is due to this size increase that the sentiment of slower engineering teams arises. *So, what are we going to do about it?*
Read the post and find out!
Now that I have laid out my thoughts enough about TPM to “open to floodgates” so to speak, I want to discuss a topic that immediately comes up: what’s your recommended organizational (org) structure? I have lived both the integrated team structure at Amazon, where TPMs, Software Development Engineers (SDEs), and Software Development Engineers in Test (SDETs) all report to Engineering Managers (EMs/SDMs). But I have also lived the functional team structure at the company formerly known as Facebook, where TPMs report to TPM managers (Group TPMs) and SDEs report separately to EMs. The org overlaps at the Chief Technology Officer (CTO) level, but not before; from the TPM perspective, I sometimes call this model a Technical Program Management Office (TPMO).
So, which is better? Or is there a hybrid in between the two models you recommend? Let’s dig in!
