I was a new team lead, and I still remember this career progression conversation as intensely uncomfortable. This was back in the early 1990s; Boss Logic was young, and so was the software industry.
The conversation lasted about four minutes.
An engineer on my team wanted to talk about promotion. His code was always solid, and he always delivered. When the team had to work extra hard, he was right there with everyone else. He helped his teammates and collaborated well. He was right — he’d done everything he was asked to do. So, what about a promotion?
The problem was, we’d never asked him what he wanted to be doing. We’d never told him what a promotion would require. Nobody had explained that the gap between his level and the next one wasn’t code quality. It was whether he could walk into a room with a customer and hold his ground. It was putting more time into mentoring and leading. It was starting to act like a team lead, not a team member.
So I didn’t have a good answer. In fact, back then Boss Logic didn’t have a good answer. We hadn’t thought enough about career progression. I could feel myself reaching for a phrase every manager reaches for in that moment — keep doing what you’re doing and we’ll revisit next cycle.
Eight months later, he left to work at another company.
If you’re new, welcome to Customer Obsessed Engineering! I write about an article a week. Free subscribers can read roughly half of most articles, plus my free articles. Learn more.
That failure was mine, not his. And it wasn’t a failure of intention — I liked the guy, I wanted him to succeed, I’d have signed the promotion paperwork happily. It was a failure of specification. There was nothing written down. No map. No description of the terrain between where he stood and where he wanted to be. Just a vague sense that he wanted to do more.
A career progression plan fixes that. Not perfectly, and not by itself. But it’s the difference between a promotion process you can argue with... and a vague idea of what happens next.
So what is a “career progression plan?”
Let’s get the definitions straight so we’re talking about the same thing:
It is not a performance review. A review looks backward at the last six or twelve months and asks how you did against what you were assigned. Useful, but it’s a rear-view mirror. They are related, because performance is measured against clear goals. That’s where the plan comes in.
It is not a job description. That’s a recruiting artifact. It describes the role you’re in now, in language calibrated for job boards and HR systems. That’s an entry point. Your progression plan is the path out of that initial role.
It is not a promotion, and it is not a promise of one. A promotion is an event. That’s where the career progression plan really lands: it’s the map that makes the event predictable instead of mysterious.
So your career progression plan is a specification.
Let that sink in a bit, because it’s what makes the whole thing tractable for engineers. We know how to write a spec. A good spec describes observable behavior. It’s testable. Two competent people reading it should arrive at the same conclusion about whether the thing passes. It says what “done” looks like without dictating the implementation.
A career progression plan is exactly that, applied to a person’s growth. It describes the behavior expected at each level, in terms concrete enough that you and your manager can look at the same evidence and agree on what it shows. Specific inputs equal specific outputs.
There are three components, then:
The map. A set of levels, each described by behavior, arranged so you can see the whole path from entry to senior. This is the piece most people call a career ladder, and that’s the word I’ll use for it.
Your position on it. An honest read of where you actually stand today, not where you’d like to stand.
The route. The specific gaps between here and the next level, and what closing them looks like.
Most organizations, in my experience, have a fuzzy version of the first, no version of the second, and treat the third as something you’ll figure out on your own. That’s why promotion conversations so often go badly.
What it’s worth, and to whom
I want to approach this from two sides — once for the team member and once for the team lead — because the two cases are different even though we’re talking about the same thing.
For you as a team member
Without the map, you optimize for the wrong things.
This is the tragedy of the engineer in my opening story. He wasn’t lazy and he wasn’t coasting. He was pouring everything into the dimension he could see: the code. Code quality was legible to him; it was measurable, and he’d been rewarded for it before. So that’s where his effort went. Meanwhile, the real threshold — customer-facing authority and mentoring his team — sat entirely outside his field of view.
Effort without direction is just motion — a career progression plan gives that effort a target.
It also changes the character of the promotion conversation. Without a written standard, you’re asking your manager for a favor, and they’re left rendering a verdict without clear guidelines. With one, you’re both looking at the same document and comparing it against evidence. That’s a contract based on specific objectives.
And if your company doesn’t have one, the good news is they’re portable. You can adopt somebody else’s. Read a published ladder, find the level that matches what you do now, and work the one above it. Bring that plan to your employer, and set the expectation that you want clear outcomes. Your employer’s failure to write things down doesn’t have to become your failure to grow. (And implicit in that conversation: you borrowed the plan from someone else, presumably someone who might steal away an engineer who shows initiative.)
For you as a team lead
The business case is blunt and it’s been measured empirically.
LinkedIn analyzed 32 million member profiles at companies with more than 500 employees, tracking what happened to people over time. Employees who were promoted within three years had a 70% chance of still being there. Employees who made a lateral internal move (no promotion, just a change of role) came in at 62%. Employees who did neither: 45%.1
That’s a twenty-five-point spread on retention, and it’s behavioral data rather than a survey of what people say they’d do. Figure the cost of replacing a senior engineer — recruiting fees, years of ramp, the knowledge that leaves with them — and it looks like a high price to pay.
The reasons people give for leaving support the same point: when McKinsey surveyed 5,774 workers across five countries about why they’d quit, the top three answers weren’t about money. They were about not feeling valued by the organization (54%), not feeling valued by their manager (52%), and not feeling a sense of belonging (51%).2
People walk because they don’t feel valued.
A written ladder is one of the very few mechanisms a company has that says, here is what we value, and here is what happens when you demonstrate it. It’s no substitute for a manager who pays attention, but it is the scaffolding that makes paying attention possible at scale.
There are second-order benefits that compound, too:
Hiring becomes calibrated. When you know what a CL2 is, you can tell whether the candidate in front of you is one. Leveling stops being an on-the-spot negotiation, and it stops meaning different things to different people.
Capability gaps become visible. Map your whole team against your ladder and the holes show up clearly. You’ll see that nobody can run customer engagement solo, which is a very different problem from “we’re a bit short-handed.”
Standards scale across the organization. Every manager applying their own private standard produces chaos the moment you have more than one team. You need your teams to function at compatible levels to run larger programs.
Bias gets constrained. Not eliminated — written standards can encode bias just fine. But a written standard can be examined, challenged and revised. A gut feeling, a friendship or nepotism can’t.
This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.
What a good progression plan needs
I check for seven things. I’ll put my own company’s ladder through this test in the next section, and it won’t come out clean.
These criteria serve both sides of the table. If you’re a team lead, this is your build checklist. If you’re a team member, it’s your audit tool — for the ladder you’ve been handed, or the one you’re about to borrow.
1. Levels described by behavior, not by tenure or title. “Three to five years of experience” is not a level, it’s a proxy for one, and it’s a bad proxy. The question is how the person behaves. If your ladder can be satisfied by waiting, it isn’t a ladder.
2. Each level includes the one below it. A CL3 still does everything a CL2 does. Levels accumulate; they don’t swap. Without this you get promoted-out-of-competence situations, where the team quietly loses a capability it thought it had.
3. Named roles, and no dead ends. Every level in your career progression plan needs a path forward. This sounds obvious. It’s routinely violated, as you’ll see shortly. Run your finger across your own chart and find the career dead-end nobody can leave. Nobody wants to land there.
