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!
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 TPMs, we are often asked to provide regular status reports on ongoing projects and programs. While sharing personal weekly summaries may avoid the need for formal status reports, there are differences between the two that different situations may call for. That said, one should not assume that a recurring status report is necessary for every project! Rather, think through the overall communication strategy for a project and consider if status reports make sense within that – they often do!
This post defines a best practice around status reporting, starting with first evaluating if status reports are a good fit for your situation before then sharing how to source the content and format your report.
When I last wrote about what to do instead of quarterly planning, I did not mention the word “budgeting” once. While everything said in that post is true, to dismiss budgeting leaves a huge gap that has to be addressed. The US Securities and Exchange Commission (SEC) requires that publicly traded companies file both quarterly and annual reports on an ongoing basis. While financial forecasts are not a part of these requirements, it has become the norm to do so. In order to provide more accurate financial forecasts, most publicly traded companies adopt a budgeting process. However, budgeting only tells one half of the story: spend. To get the other half – revenue – you want to understand projected product and feature releases with associated revenue forecasts. This gives you both sides of the coin for your overall financial forecasts. However, it leads to the conflation of budgeting and planning, and creates a game to be exploited no matter how you slice it.
As Technical Program Managers (TPMs), we often end up as meeting note takers. While TPMs are not just stenographers, note taking is a valuable exercise, and thus taking notes is something to be encouraged. It is OK for note taking to be TPM led, as we often are the best suited to distill down complex, cross-functional, and cross-organizational topics. However, the reality is note taking is meant to serve a purpose, and all meeting attendees should be encouraged to partake in their own way to ensure maximal value of the exercise.
This lightweight post simply defines a best practice around collaborative note taking, where the note taking responsibility is shared across all members of a meeting.
When I shared my post about the value of writing weekly summaries months ago, I wasn’t sure how long it would be before I had a follow-up on it. Well, here’s the first follow-up on it!
An article that I was reading the other day triggered the inspiration for this post. While I struggle with many articles written by people without direct experience, I want to highlight a particular part of this article: “[Atlassian VP] Dean pushes Atlassian employees to keep 50% of their day open for individual-focused productivity.”
This quote spoke to me, as 50% is exactly the target I held myself to in my first two years at Zillow. Why this target? I made it up; it felt right for me as a TPM. While you are free to adjust the target, perhaps for other roles or levels – just don’t let picking a target get in the way of you getting started.
And what medium did I use to track this? Well, my weekly summary, of course!
So…how does one get started? If you look at your calendar, it might make you feel sick right now 🤢. Well, there’s good news! We all start here, and this is why this post is necessary. Even better news: you already did step 1.
As a follow-up to a previous post “Please, Stop Quarterly Planning: It’s Just Waterfall in Disguise,” I want to share what to do instead. I touch on this at the end of that post, but it felt worthy of its own, more detailed post. For details about why I don’t like quarterly planning, see that first post. But if you want solutions to replace it with, well, this post is for you.
So, what should we do instead? Two things:
1. Embrace a more flexible planning process, such as Kanban (just-in-time), and
2. Drive accountability through recurring business reviews every 2-6 weeks.
With these two things, you transparently cover the desired feedback cycle that quarterly planning provides while remaining truly agile. In other words, you create a simple, sustainable two-step flywheel. Let’s break these two components down.
Open LinkedIn – seriously, do it. I bet it’ll take no longer than five seconds to stumble upon a post with the word “strategy” in it. And I bet you’ll read it and go – “huh?” The example I found was along the lines of “just do these 10 easy steps and you’ll define everything you need for your entire company.”
I admit, this line from Good Strategy/Bad Strategy hits home: “A hallmark of true expertise and insight is making a complex subject understandable. A hallmark of mediocrity and bad strategy is unnecessary complexity—a flurry of fluff masking an absence of substance.”
Here’s a good rule of thumb: if you need more than one sentence to describe what a strategy is, you’re doing it wrong. This post will help you do it right!
Throughout my career, I have seen this process called quarterly planning become more and more popular across multiple companies for reasons I don’t understand. At a high level, quarterly planning could not be a better example of the now-antiquated waterfall methodology. What’s the issue with that? Well, keep reading.
© 2021-2024 — Straker Carryer