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.
Amazingly, there aren’t public ladder guides for most roles, including Technical Program Managers (TPMs). I will correct that in a follow-up post to this one, but first I need to introduce the concept and explain how to make a ladder guide.
Step 1: Define Your Levels
Most tech companies have levels that adjust your title and pay. For example, “Senior TPM” is different from “Staff TPM.” If you want to compare these levels across companies, check out levels.fyi. Most companies already have these defined, so if you are creating a guide under such circumstances, you don’t need to do anything for this step – use what you already have. To use Software Development Engineer (SDE)1 as an example, this typically looks like one of two models:
- The Amazon Model (6 levels): SDE → SDE II → Senior SDE → Principal SDE → Senior Principal SDE → Distinguished Engineer
- The Google Model (8 levels): SDE → SDE II → Senior SDE → Staff SDE → Senior Staff SDE → Principal Engineer → Distinguished Engineer → Fellow
Yes, there are other options, such as Microsoft having 13 levels, but these two models are among the most common. If you are in a position of influence, it is important that you think through your levels that exist and if they meet the needs of your role. I mention this as the Google model that introduces the Staff Engineering concept has become the norm for good reason; consider adoption of this model (or a similar one) if possible.
The Google model has become popular because the extra level balances long-term career growth that rewards tenured employees with the difficulty of leadership positions starting at the senior level. You also have the book Staff Engineer to leverage for role definition and expectations of the level, creating the closest thing to an industry standard. To give an example of its popularity, Uber adjusted their levels and titles to mirror this model back in 2022.
I mentioned in my last post that when I left Amazon back in 2017, they were having such a “brain drain” at the senior level that they spun up a formal retention program. Comically, I recently learned that the informal-yet-very-real level 6.5 is still alive and thriving. So, even Amazon doesn’t follow the Amazon model. Why should you? 😜
Admittedly, I don’t think most companies need the Fellow level, but it is easy to add levels later at the beginning or end of a ladder guide. It is much harder to add levels in the middle, so you will appreciate thinking through your levels early in this process to avoid this scenario!
Step 2: Determine Which Levels You Need for Your Role
Just because levels exist at a company doesn’t mean every role needs to support individuals at that level. TPMs are the best example of this – some companies, such as Microsoft and Meta, support college hire TPMs (ie, TPM I).2 However, others such as Amazon and Zillow, do not have this level of TPM. Instead, TPMs are expected to have at least a small amount of existing experience (perhaps as another role, such as an SDE) and start their ladder guides at TPM II.
There are pros and cons to any choice of what levels to support for a role, but this choice should be approached with intention to avoid the following scenario:
Step 3: Determine Your Format
And here is where things get surprisingly complicated: what does a ladder guide look like? A matrix? A document? Do I use a tool? OK, slow down – let’s tackle these!
First, we need to lay out our use cases to work backwards from. Remember from our introduction here that we have multiple questions we seek to answer. These can be broken down as follows:
- Clarity for Individuals in the Role of in-level Expectations: This is the most important use case to consider. Regardless of level, individuals should have clear in-role expectations that they can use for career conversations with their manager, reviews, and horizontal mobility purposes.
- Promotions: Ladder guides enable equitable promotions across the company, regardless of organization, as they set the same definitions for all levels of a role across the company.
- Recruiting: Ladder guides are used by recruiting when it comes to Job Description (JD) writing as well as ensuring that roles are opened at the right level based on the scope defined for the role.
- Cross-Role Understanding: You can’t be an effective team if you don’t know what position your teammates are playing. Ladder guides serve as role definitions for folk outside of the role so they understand what to expect from their peers in the role.
Admittedly, this list of use cases makes it hard to follow the “do one thing well” Unix philosophy. However, if we go back to the question that got us here – what does a ladder guide look like? – we can start to realize that the answer for these different use cases may be different.
Let’s start by laying out the pros and cons of different formatting choices.
Matrix Pros and Cons
Matrix guides’ superpower is their level of detail that optimizes the Individual Role Clarity and Promotion use cases. By giving clear expectations of every level of a role, an individual’s reasons to promote can be clearly tied back to the ladder guide to justify any promotion.
Matrix guides also enable easy interoperability. If certain skills are meant to be shared across roles and/or levels, you can easily use the same text without copying and pasting across different matrices. You can move data to a shared “backend” gSheet and then use this for lookups in various “frontend” gSheets that serve as the customer-facing level guides.3 This makes matrix guides useful if you need to not just define a single role, but multiple. Examples of overlap across multiple roles are expectations around communication, collaboration, mentoring, leadership, and more – there are plenty of examples of shared expectations at a level, agnostic of your role/function!
Like many things, matrix guides’ superpower is also their potential weakness: their level of detail means there is subjectivity in how deep to go. If one isn’t careful, a matrix guide can end up like a long checklist. It may not be the intent that all items are demonstrated at the same time, but the desire to cover work that is reasonable within the role can lead to a long list of expectations of a role. This risk is especially acute more senior levels. This issue compounds to create readability issues, which are particularly harmful for the Recruiting and Cross-Role Understanding use cases.
Narrative Pros and Cons
To combat the weakness of matrix guides, one might propose a narrative guide. Narrative guides’ superpower is their flexibility, which enables handling of all of the use cases above to varying degrees. They especially prioritize the Recruiting and Cross-Role Understanding use cases, which were mentioned above as not being handled well by matrix guides.
Narrative guides’ flexibility also enable significant changes across levels. For example, the software engineering role has a significant shift at the Staff level based off the Staff Engineer book mentioned earlier; matrices’ rigidity in rows make this shift at a particular level a challenge to describe.4
But like matrix guides, narrative guides’ superpower is also their potential weakness: their flexibility means there is subjectivity inherent in striking the right depth to explain a role. For example, a narrative guide can accidentally be too high level and not serve the Individual Role Clarity use case well enough, greatly harming the guide’s effectiveness. Narrative guides usually require multiple iterations to find that Goldilocks sweet spot of just right. This iteration means that narrative guides tend to be a higher level of effort than matrix guides.
So what about a tool?
Given the tradeoffs of matrix vs narrative guides, you might be thinking “surely there’s a tool for this!” And while perhaps there is, I have yet to experience the use of one in my career.
The important thing to remember is that accessibility to all employees is key; there’s no point to ladder guides without this. With this assumption in mind, most tools charge fees per licensed user. In other words, the larger your organization, the more expensive the cost 💰. This leads to a disincentive to use a new tool for ladder guides besides ones you already pay for, such as your online document solution.
So, what do we do?
At the end of the day, I find the debate of matrix vs narrative guides a false dichotomy; they are not mutually exclusive. Like any product that fails at trying to be good at too many things, it’s OK to split the use cases listed above and serve them differently.
You can have a matrix ladder guide and a narrative cover letter to serve all of the use cases more optimally than trying to do it all in one go. It’s almost too good to be true that the narrative and matrix guides optimize for different use cases from one another! While this is more work upfront, I argue it is less work overall when you try and serve the use cases with a tool that doesn’t match the problem being solved.
But wait – are we duplicating the guide across two different formats? No! If you’ve worked with me, you know that I don’t find Segal’s Law to be very ironic. I am not advocating for two watches, but rather two artifacts that complement and relate to one another as a package deal to make up the ladder guide.
Step 4: Write the Guide (and Have it Reviewed)
It’s funny that it’s taken this long just to get to the writing step, but it is important to move with intention for this kind of work. Assuming you are writing both narrative and matrix components for your ladder guide, I recommend you start with the narrative component. The narrative component is easiest to review to ensure you are thinking about the role correctly. This is especially important if your leadership is reviewing the guide and/or you are introducing a new role to your company.
For example, this is why my first posts my TPM series are so important – when I eventually share my TPM ladder guide, you will see this content reflected in the guide. In effect, they serve as the narrative cover letter.5
Once you go through whatever reviews are necessary with your narrative guide, you should first take feedback into account before switching gears to the more detailed matrix component. However, once both of these are ready, then go through one more round of reviews with the complete guide.
Step 5: Share the Guide in a Discoverable Manner
While you are close to done once you’ve written your guide, remember that a ladder guide is simply a tool, and a tool is only as effective as its use. Make sure your guide is discoverable for said use! This means that sending an email is not enough, although notification of a new ladder guide should exist. Just be sure to also add a link to the guide in some searchable location, such as your company’s wiki, intranet website, or both. Ideally, your company’s ladder guides are compiled in one place, and that place is the same as where other HR policies live!
Step 6: Don’t Forget to Iterate
Like all things, one must not forget to improve the ladder guide over time. Sometimes this will be based on feedback of its use, but others may be due to changes to the role. A common example of where iteration is valuable is improving clarity between levels of a role.
It is important not to change the role too much, as you need time to actually try the ladder guide before passing judgement. Additionally, you want to avoid any sentiment of a “rug pull,” where the ladder guide changes right before a review period.
For example, if your company does annual reviews, it is OK to make changes after the annual review, but consider locking all changes a 3-4 months before the annual review period starts.
Additionally, while improvements are encouraged, all changes to ladder guides should go through a change management process. This is usually the review component of step 4 and then the communication of the changes in step 5.
Conclusion
So I have made it all the way to the end, and I haven’t shared templates or examples of ladder guides. But fear not! I am working on these now. However, I realize that is going to need to be its own dedicated post, perhaps even with video instructions featuring a special guest. The reason for this is that this post is already a long one, but any templates need detailed instruction that will rival this length.
I will be sharing these templates as soon as I have this magical societal construct called time 🕑. If I am being honest, creating open sourced ladder guides has been one of my main inspirations for starting this blog. So fear not – we will get there! But in the meantime, have fun reading about the debate if time is real or not.
Appendix: Good External Resources
These are other relevant articles I found after writing this post. I will update this in the future as I find more, so you may notice this change:
- Using a Tech Career Ladder to Map Growth – This post is a similar detailed one about all of the reasons why one should make a ladder guide, as well as what it entails to do so!
Footnotes
- Yes, I know Google uses the Software Engineer (SWE) acronym instead of SDE, but until Software is spelled SoftWare, I refuse to comply 😅. ↩︎
- Associate TPM is another common title of an “undergraduate college hire” equivalent TPM. ↩︎
- All online spreadsheet options provide this type of functionality, not just gSheets. ↩︎
- Yes, you can create a second matrix for Staff+ levels, or even switch to a narrative guide at these levels, but this shift has to be properly managed and communicated. ↩︎
- Of course not everyone is expected to make a blog post for such a cover letter; a shareable document like a Google document works fine for most use cases. You can then link to/reference this content from the gSheet. Even at Zillow, this is what I did when I defined the TPM role there (before I had a blog). And no, most narrative components don’t need to be as long as mine 🤣. ↩︎
1 Comment
Leave your reply.