The CTO’s New Engineering Ladder

How to build a performance ladder that actually means something when everyone in the company writes code

I’m sitting across from a senior engineer named Priya on a Tuesday afternoon. Eight years in the industry. Runs the platform team. Every company I’ve ever worked in would have called her a senior engineer without hesitation. I’m doing a routine level review and I ask her, as casually as I can, “What does senior actually mean on your team right now?”

She looks at me for a long moment. Then: “I honestly don’t know anymore.”

Half her team is using Claude Code and GitHub Copilot to generate entire features in an afternoon. A junior who joined six months ago shipped three production-ready services last week. Another who’s been around for years is still barely functional without hand-holding. She can’t tell who’s performing and who isn’t because the outputs (features shipping and the pull requests closing) look about the same now. Maybe better for the newer people.

“So what do I measure?” she asks me.

That question has been sitting in my chest ever since.

When the Whole Company Writes Code

It’s not just Priya’s engineers using AI to generate code. It’s her product manager, who scaffolded a working prototype last week to win an argument with the CEO. The data analyst who built an internal tool without filing a single ticket. The operations lead who automated her own reporting pipeline in an afternoon.

Before the seasoned engineers in my audience roll their eyes. I know. A product manager’s prototype is not production software. The gap between a scaffolded feature and a maintainable, secure, observable system is exactly where engineering expertise still lives. The vibe-coded landing page doesn’t survive its first security audit.

But that’s the point. The things that make an engineer irreplaceable are not the things most performance ladders measure. They measure the stuff AI is getting good at. The irreplaceable stuff: judgment about what to build, instinct for what will break, the ability to reason about a system under pressure at 2am. This gets no column in the spreadsheet. No framework for rewarding it, retaining it, or developing it.

When your marketing team can ship a prototype and your engineering team can’t articulate what they do that the prototype can’t, you have a positioning problem inside your own organization. That’s the problem worth solving.

The World According to Dorsey

Jack Dorsey announced recently that Block would cut 4,000 employees, nearly half its workforce, in a move explicitly tied to AI reshaping labor productivity. In a letter to shareholders, Dorsey wrote that “intelligence tools have changed what it means to build and run a company” and that a significantly smaller team using AI can do more and do it better.

Block’s stock surged 24%.

His note to employees put it plainly: “100 people + AI = 1,000 people.”

Wharton professor Ethan Mollick pushed back, noting it’s “hard to imagine a firm-wide sudden 50%+ efficiency gain” given how new these tools are. He’s right to be skeptical. Dorsey admitted the company over-hired during COVID and built two separate organizational structures that had to be unwound. Block’s story is complicated.

The board reaction is not. A 24% stock pop gets read across every C-Suite in the industry. Your CEO saw it. Your board saw it. They are now wondering whether your team size can be justified by a formula that is no longer theoretical.

You need to be the one who reframes that conversation with a better framework than Dorsey’s, one that captures what your engineers actually do that AI cannot.

What We’ve Actually Been Rewarding

We have been rewarding output. We need to start rewarding judgment.

When code was slow and expensive, output was a reasonable proxy for judgment. The friction of development naturally filtered for people who understood what they were building. AI has removed most of that friction. Velocity, story points, deployment frequency. Those were the right measures when humans were the bottleneck. They are not the right measures now.

The fair objection: judgment can’t be measured either. Replace one unmeasurable thing with another and you haven’t built a better system. You’ve built a more opaque one where your manager’s subjective read of your “instincts” determines your promotion. The five rungs below are my attempt to solve that by making judgment observable. Not measured directly, but identified through specific, concrete behaviors that consistently produce it and specific, concrete behaviors that consistently undermine it. The goal is a set of signals a manager can actually point to in a conversation.

A 2025 LeadDev survey found that 54% of engineering leaders plan to hire fewer junior engineers because AI copilots are enabling seniors to handle more. On the surface this looks like efficiency. Underneath, it is the slow destruction of the talent pipeline that has produced every senior engineer alive today. A Stanford Digital Economy Study found that by July 2025, employment for software developers aged 22 to 25 had declined nearly 20% from its peak in late 2022. AWS CEO Matt Garman said it best when he heard proposals to replace junior engineers with AI: “That’s like, one of the dumbest things I’ve ever heard. How’s that going to work when ten years in the future you have no one that has learned anything?”

Your engineering ladder is your answer to all of this. If it still measures velocity, story points, and sprint completion (metrics that made sense when humans were the bottleneck) it’s optimizing for a world that no longer exists.

A Ladder Worth Climbing

What follows is the engineering ladder I would build for a team operating in 2026. It doesn’t discard the traditional levels. It reframes what earns each one. The axis shifts from what you produce to what you protect.

Five rungs. Three signals per rung: what excellence looks like, what struggle looks like, and when someone is ready to move up.

One note before we start. These rungs do not quietly push great engineers toward management. The Architect, Multiplier, and Strategist are all individual contributor paths. You do not need to manage people or attend CFO meetings to advance. What you need is to demonstrate that your presence raises the quality of work around you. Through code reviews, documentation, standards you set, systems you build. The path is wide. The requirement is impact that compounds beyond your own output.

Salary ranges reflect 2026 US market data from Glassdoor and the Bureau of Labor Statistics, blending base salary with total compensation. Each range carries a $30K–$40K spread because that spread is real. It’s the difference between someone who just crossed the threshold into a rung and someone who has owned it for three years. Where someone lands within a band should track how long they’ve been operating at that level and how consistently they show the signals below. Use these as calibration points, not contracts. FAANG bands run significantly higher at every level.

Rung One: The Apprentice (formerly Junior Engineer — $85K–$120K)

Their question: why might this output be wrong?

Not “can you ship it?”. AI can ship it. The Apprentice earns their place by interrogating output rather than accepting it.

Excels when

1. They flag inconsistencies before merging,

2. ask for context before shipping, and

3. escalate uncertainty rather than guess through it. Their pull requests include questions, not just solutions.

They build original features and write real code — the difference from the old junior role is that interrogating AI-assisted output, their own and others’, is now what signals genuine understanding. Prompting fluently and understanding deeply are not the same thing. The gap between them matters enormously by Rung Three.

Struggling when

1. they treat velocity as the goal

2. they ship generated code they cannot explain

3. they hide blockers because they don’t want to look like they don’t know something, which at this level is exactly what they should be saying out loud.

Ready to move up when

1. they can explain why a specific piece of AI-generated code will fail in a specific production scenario, not just that it might

2. they have shipped something end-to-end with minimal guidance and their postmortem was more insightful than their manager expected.

Rung Two: The Builder (formerly Mid-Level Engineer — $120K–$155K)

Their question: what is this feature protecting the company from?

The Builder owns a feature end-to-end. Not just shipping it, but the definition of done, the edge cases, the production monitoring, the customer impact. In a world where AI can scaffold a service in two hours, their value is in knowing which service is the right one to build and when to throw the generated output away and start again. They write specs before they prompt.

Excels when

1. they see around the feature they’re building — upstream dependencies, downstream consequences, what happens when it breaks

2. they know what matters to the business, not just the ticket

Struggling when

1. they are technically proficient but scoped too narrow

2. they deliver features in isolation

3. they need an explicit ticket to know what to work on next.

Ready to move up when

1. they have proactively identified and resolved a problem nobody assigned them

2. they have mentored an Apprentice visibly and successfully

3. their technical decisions reference company goals without being prompted.

Rung Three: The Architect (formerly Senior Engineer — $155K–$210K)

Their question: what does this decision cost us in six months?

This is where most performance ladders stop being interesting, which is a shame. It’s where the real leverage begins. The Architect sees downstream consequences before anyone else does. They translate technical debt into business cost without being asked. Not in a presentation. As a reflex.

Excels when

1. they walk into cross-functional conversations with answers before people have finished asking the question

2. the C-Suite understands them

3. their technical instincts show up as financial clarity

Struggling when

1. they are technically brilliant but organizationally invisible

2. they are right in the code review, wrong in the room

Being correct is not enough at this level. The AI era makes the gap between correct and heard more consequential than ever.

Ready to move up when

1. they have demonstrably improved the output quality of a team they don’t manage

2. they have translated a technical risk into a business risk and been understood by a non-technical executive

3. they have driven a consequential build-vs-buy decision and can show the math.

Rung Four: The Multiplier (formerly Staff Engineer — $210K–$300K)

Their question: how does the team make better decisions because of you?

Their output is not features. It is the quality of everyone else’s judgment. If a Multiplier leaves, the team doesn’t slow down by one; it slows down by the compounded capability they were adding to everyone around them. They define how AI-generated output gets evaluated, trusted, and deployed. They don’t just use the tools. They determine how the organization relates to them.

Excels when

1. engineers leave their code reviews smarter than when they arrived

2. their standards get adopted without being mandated

3. their departure would be felt across teams, not just their own.

Struggling when

1. they are still primarily an individual contributor

2. they produce excellent work that doesn’t compound

3. they hoard knowledge because it makes them feel essential rather than building systems that transfer it.

Ready for expanded scope when

1. they have changed how the engineering organization evaluates an entire category of work. Not just one team but the organization.

The bar is voluntary adoption. People following a standard because they were told to is compliance. People following it because it made their work better is influence.

Rung Five: The Strategist (formerly Principal Engineer — $280K–$450K+)

Their question: where do we need to be in two years and what does it cost to get there?

The Strategist’s domain is the future state of the business, not the current state of the codebase. They have opinions on build-vs-buy decisions that factor in organizational capacity, not just technical preference. They understand the Engineering Efficiency Ratio and know how their decisions move it. They are not waiting to be asked about the business. They are thinking about it before the business knows it has a question.

Excels when

1. they are in the room for business decisions before the technical implications surface

2. the CEO treats their input as commercial, not just technical

3. they can quantify the cost of standing still.

Struggling when

1. they have expert architecture instincts but no strategic patience

2. they want to solve the problem in front of them rather than the problem three years out

3. they can describe the vision but not the price tag.

Ready for more scope when

1. they can point to two decisions they made that the company is still benefiting from two years later.

Not decisions they recommended. Decisions they drove.

When You Let Someone Go

You let an engineer go when their judgment is not improving and their presence is actively degrading the judgment of others. Not when they write slow code. Not when they miss a sprint. Not when a feature ships with bugs. Those are correctable.

What is not correctable is an engineer who ships AI-generated code they cannot explain, who creates production surfaces that no one can reason about, and who trains the Apprentices around them to do the same. In the old world, that engineer was slower. In this world, they are a liability.

The inverse is more commonly overlooked. The engineer who makes your team smarter (who raises the quality of judgment around them even if they write less code than anyone else) is the person you build around. The Multiplier you can’t easily measure is often the one holding everything together.

If you’re not sure which kind you have, check what happens the week after they go on vacation.

What You Build This Week

If you run a team of twenty or more engineers without a written performance ladder that addresses AI-augmented work, you are measuring your team against a standard that exists nowhere but in your head. Promotions are political. Feedback is vague. Your best engineers are leaving because they can’t see a path forward.

Three things.

1. Put your current engineers against the five rungs

   Not to demote anyone — to understand where the gaps in judgment actually are. You will find Builders being paid like Architects. You will find Multipliers treated like Builders. That is information worth having before someone else delivers it to you with a resignation letter.

2. Ask every manager what Priya asked me: what does senior mean on your team right now?

   If they can answer it without mentioning years of experience or sprint velocity, great. If they can’t, that is where your work starts.

3. And before you cut Apprentices to protect headcount, read Garman’s line again.

   The engineers who will run your team in 2030 are learning how to think about code right now. Stop creating the conditions for that learning and you will not have a senior team in five years. You will have AI tools and no one who knows what they are doing.

Dorsey may be right that 100 people with AI can do what 1,000 once did. But someone still has to be smart enough to point the AI in the right direction, and wise enough to know when not to.

Here’s an example of how I do 1:1s against this new Engineering Ladder. Email me if you want a copy!

Build the ladder that finds those people. Reward them for their judgment. Keep them longer than two summers.

The rest will follow.

---

Etienne de Bruin is the founder of 7CTOs and coaches technology leaders through the complexity of scaling engineering organizations.