Full Scale Career Ladder: How We Level Developers
In this article
- Four dimensions decide the level
- Five of the fourteen are judgment, and three of those are Matt’s Three C’s
- Five more are technical, and one of them can end a client relationship
- The scale is 1 to 4, and a score without an example does not count
- Mentorship is where most strong seniors stall
- The test that settles it: hand them something with no spec
- What this actually changes
- Frequently asked questions
- Ask how your vendor levels people
Two developers hand you a pull request. Both used AI to write most of it. Both pass the tests.
One of them shipped what the model suggested. The other one noticed the model had misread the requirement, rewrote that part, and can tell you in one sentence why the original approach would have broken in production.
Nothing on their résumés separates those two people. The diff sizes match, the languages are equally hard, and one of them has been doing this longer than the other in a way that turns out to predict nothing. The signal we used to rank developers by was output, and AI flattened it.
So we stopped ranking on output. At Full Scale we score fourteen things across three layers, and this is the whole list.
Four dimensions decide the level
These four are not ours. Most public engineering ladders landed on the same four independently, Kickstarter and Medium and Spotify and Rent the Runway among them, and Camille Fournier’s The Manager’s Path walks through the same logic. We did not need to invent a new one. We needed to make it usable for engineers embedded on somebody else’s team.
| Level | Scope | Autonomy | Ownership | Mentorship |
|---|---|---|---|---|
| Junior | A well-defined task | Work is reviewed before it ships | Builds what they are told to build | None expected yet |
| Mid | A feature, including the edge cases nobody spec’d | Reviewed on architecture, not every line | Accountable for their feature working in production | Helps onboard someone when asked |
| Senior | A system, or a client relationship end to end | Trusted to carry our judgment to a client directly | Theirs to fix at 2am, not just theirs to build | Reviews code in a way that teaches |
| Staff | A whole engagement, or several workstreams | Answerable for outcomes, not deliverables | Accountable for the engagement’s health | Develops other people’s careers on purpose |
That table is the actual promotion decision. The ten items below exist to answer the question sitting underneath it, which is the only question that matters in a leveling conversation: what do you point at as proof?
If you want the longer version of how each of those levels behaves day to day, it lives in junior, mid-level, and senior developers in the age of AI. The title taxonomy underneath them, all nine of the ones you will see on a résumé, is in the software engineer levels.
Five of the fourteen are judgment, and three of those are Matt’s Three C’s
Communication, curiosity, and courage are what I have argued for years are the things that separate engineers who grow from engineers who plateau, and they are the spine of Product Driven. They are the first three here. The other two are newer.
1. Product thinking
Product thinking means understanding the purpose behind the ticket. It shows up as somebody pushing back on a spec that is aimed at the wrong problem.
*Proof:* they caught a requirement that would have solved the wrong problem. They can explain the business impact of something they shipped without being asked.
2. Communication
This one is about whether a technical decision survives contact with a non-technical person, and whether risk gets raised early instead of going quiet and hoping it resolves itself.
*Proof:* they flagged a blocker before it became a missed deadline rather than after. Their written updates do not require a follow-up question to be useful.
3. Curiosity
The tell is what somebody does when something breaks. Curious developers go find out why. The rest patch the symptom and move on.
*Proof:* they picked up a tool or technique on their own and taught it to the team. They ask why in code review, not just what.
4. Courage
Will they say “this is wrong” to a lead, to a client, or to me?
*Proof:* they disagreed with somebody senior and turned out to be right. They reported their own bug before anyone else found it.
5. AI judgment
This one did not need to exist five years ago. Can they move faster with AI without lowering the bar, and more importantly, can they tell when the model is wrong? Do they review generated code with the same suspicion they would apply to a junior teammate’s PR, or do they rubber-stamp it?
*Proof:* they caught a subtly wrong suggestion before it shipped. They can explain generated code line by line instead of saying it worked.
That fifth one is the difference between a developer who got faster and a developer who got more dangerous.
Five more are technical, and one of them can end a client relationship
Judgment alone does not prove somebody can carry a bigger piece of the world. A developer can be a wonderful communicator and still not be ready to own a system at 2am.
6. Architecture and system design
From working inside a structure somebody else designed, to setting the architectural direction a team lives with for years.
7. DevOps and infrastructure
From following a deploy runbook, to owning observability so problems get caught before the client notices them.
8. Project and delivery management
From estimating one ticket badly, to scoping a multi-sprint initiative and flagging timeline risk before it surprises anybody.
9. Quality and technical debt
The real test is whether somebody can say “we should ship this now and pay it down in March” out loud, in advance, to a client, rather than quietly taking on debt nobody agreed to.
10. Security awareness
From not introducing an obvious vulnerability, to designing the data and access model with a threat in mind and being able to explain it.
Security carries more weight for us than it would inside a product company. A security incident on a client’s system is one of the very few things that ends the relationship outright rather than costing a sprint. We wrote about the rest of that risk surface in how we background check every developer we hire.
The scale is 1 to 4, and a score without an example does not count
| Score | What it means |
|---|---|
| 1 | Not yet observed. No evidence this period. |
| 2 | Emerging. One or two real instances, inconsistent. |
| 3 | Consistent. Shows up repeatedly, across different projects. |
| 4 | Multiplies others. Raises the bar for teammates, not just themselves. |
The rule that makes this work is boring and non-negotiable: a manager has to point at a concrete instance. Not an impression. Not “they seem senior.” A specific thing that happened, that somebody can name.
Drop that rule and you have rebuilt the thing we were trying to replace, which is gut feel wearing a spreadsheet.
One more guardrail. A single 4 does not promote anybody. Leveling reads the whole profile against the four-dimension table, because one tall spike does not carry a whole level.
Mentorship is where most strong seniors stall
Mentorship is a dimension in its own right, and it is the one people are most surprised to be scored on. Three things carry it: whether somebody’s code review teaches instead of just gatekeeping, whether other developers bring them judgment calls without being told to, and whether a teammate got measurably faster because of them.
Somebody technically excellent who reviews pull requests with a thumbs-up and nothing else scores low here regardless of how good the other thirteen look.
That is usually the exact thing keeping a strong senior from being staff. It is also the most fixable, which makes it a good thing to find.
The test that settles it: hand them something with no spec
Every rubric needs a gut check you can run in one conversation, and this is ours.
Hand a developer an ambiguous problem with no spec and watch what they do with it.
A junior asks for the spec. A mid-level developer makes reasonable assumptions and tells you what they assumed. A senior developer tells you what the spec should have been, and why, and you would have shipped the wrong thing without them.
Years of experience will not predict which of those you get. I have met eight-year developers who ask for the spec and three-year developers who rewrite it.
What this actually changes
When somebody asks how to get promoted and make more money, “keep doing good work” just ends the conversation without answering it.
With fourteen scored items you can do something better:
- Show them the four-dimension table and where they sit today.
- Name the one or two items holding them there. It is usually a mix, one judgment trait and one technical item, because people over-invest in the work they already enjoy.
- Give them one concrete thing to do this quarter that would produce evidence for the gap.
- Revisit with the same rubric next quarter.
Progression stops being a negotiation and becomes a paper trail. That is better for the developer, and it is better for the client who wants to know the person on their account is getting better instead of just getting older.
The same fourteen items are what we are looking for in the first place, which is why how we interview developers reads like a shorter version of this list.
It also tells our training program where to aim. When the scores show a pattern of weakness, that is what the next course gets built about, which is how we train in the first place.
Frequently asked questions
Why not just rank developers by years of experience?
Because years measure exposure, not judgment, and the correlation was always weaker than people assumed. AI made it worse by collapsing the output gap between an experienced developer and an inexperienced one. Two people can now produce similar-looking work while understanding it very differently, and only one of them can tell you what the code does when it breaks.
Is this the same as a competency matrix?
It is a competency matrix with two additions most of them are missing. The first is a scored trait for AI judgment, meaning whether somebody can tell when a model is wrong. The second is a hard evidence rule, so no score can be given without pointing at a specific thing that happened.
How is a client’s engineer scored when the client runs the daily work?
The four dimensions are deliberately written to be observable from the work itself rather than from being in the room. Scope, autonomy, ownership, and mentorship all leave visible traces: what someone is trusted with, how much review they need, who is accountable when it breaks, and whether teammates come to them.
Does a higher level mean a higher rate?
Level and rate are related but not automatic. A developer moving from mid to senior is the business case for a rate conversation, because they are now doing senior work, but the timing depends on the engagement. What the rubric changes is that the conversation starts from dated evidence instead of an assertion.
What if a developer is strong on judgment but weak technically?
They are a mid-level developer worth investing in, not a senior. The reverse also holds. Somebody who can architect a system alone but cannot explain the tradeoffs to a client, or will not push back when the spec is wrong, is a strong technical mid-level who needs the judgment traits to catch up before more scope is safe to hand them.
Ask how your vendor levels people
Most staffing companies rank developers by years and bill rate, because those two numbers are easy to put in a spreadsheet and neither one requires anybody to have an opinion.
If you are paying senior rates, it is worth asking what the vendor thinks makes somebody senior, and whether they can point at anything specific. We can, and the list is above.
If you are considering staff augmentation and want to talk about what your team actually needs, and how we would score somebody against it, schedule a call.
