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
As a follow-up to my post about the Chase ecosystem, I wanted to follow-up about the AmEx ecosystem. While it is more work to redeem points for high value, AmEx offers simplicity over Chase in other ways.
And if you travel internationally a lot, AmEx points – called Membership Rewards (MRs) – transfer directly to airline partners that make for some incredible deals.
Read more to find out how to add these cards to your quiver!
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 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.
After reading about ScarletInk’s dissatisfaction with Ghost and migration to Substack and a former colleague’s dissatisfaction with Medium, I figured it was time for me to do another update on Wordpress (.org, not .com) and how it’s going.
My honest summary is I love WordPress and can’t imagine me changing to another platform. Ghost was the one platform I had some FOMO (Fear of Missing Out) about, but after reading the ScarletInk’s post, that FOMO has been replaced with JOMO (Joy Of Missing Out).
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.
