The Senior Engineer Plateau

It was 6:47 PM on a Friday when I noticed Somchai hadn’t joined the usual beer session. Not like him — he was usually the first one cracking open a Singha after a long week. I found him at his desk, staring at his monitor like it owed him money, the office emptying out around him. “I’m thinking about leaving,” he said, not looking up. “I’m a tech lead. It’s the highest IC level here. I don’t want to manage people. So where exactly am I supposed to go?”

He was right. And that’s the part that kept me awake that night.

We’ve built an entire industry around hiring senior engineers. We obsess over technical assessments, whiteboard interviews, system design rounds — an elaborate courtship ritual to attract experienced talent. But ask most companies what happens to those engineers after year two, and you’ll get the corporate equivalent of a shrug.

As the economist John Kenneth Galbraith observed, “The conventional view serves to protect us from the painful job of thinking.” In engineering organisations, the conventional view takes two equally destructive forms.

The first is simple neglect: senior engineers have arrived. Development complete. Now they just… produce. Forever. At the same rate. With the same enthusiasm. Until they quietly start updating their LinkedIn.

The second is worse, because it looks like progress. We create ladders that are really just treadmills. Ship more sprint work. Pull off a bigger product project. Get promoted. Repeat. The titles change but the work doesn’t. There’s no expanding scope, no deeper mastery, no genuine autonomy over what problems to solve.

Daniel Pink, in his research on motivation, identified three things that drive people doing complex creative work: autonomy, mastery, and purpose. Most engineering career ladders deliver precisely none of these. You get a new title, maybe a raise, and the reward is… more of the same tickets, just with higher expectations. We’ve confused promotion with growth. They’re not the same thing.

The Invisible Ceiling

Here’s the uncomfortable truth nobody wants to discuss in sprint planning: most companies have accidentally designed a system where their best individual contributors hit an invisible ceiling around year two or three. They’re too expensive to ignore — their salaries demand justification — but too “senior” to develop. The implicit message becomes: you’re done growing. Now just keep shipping.

The career path in most organisations looks something like this: Junior → Mid → Senior → Maybe a few more levels → [awkward silence] → Management?

That question mark isn’t rhetorical. It’s the actual conversation happening in one-on-ones across the industry. “Have you thought about moving into management?” becomes code for “we’ve run out of ways to grow you here.” Or worse, you get promoted through those extra levels by doing more of exactly the same work — just faster, just bigger projects — until you wake up one day as a “Staff Engineer” who’s really just a senior engineer with a fancier title and heavier sprint load.

But what if they don’t want to manage people? What if they’re exceptional at solving complex technical problems and mediocre at performance reviews? What if they love code and hate Gantt charts? We respond to this by… making them managers anyway. Or watching them leave.

I was having a beer with an engineer leaving the company a few years back. When I asked why, he put it plainly: “I’m a Principle. It’s the highest IC level at this company. I don’t want to manage people. So I have no career path.” He wasn’t wrong. He wasn’t even particularly bitter about it. He’d simply done the maths on his future and found the answer was zero.

The Management Trap

The management track as the only path to advancement is what the basketball coach Phil Jackson might call “a beautiful system that produces ugly results.” We take our most technically gifted people — the ones who can see around corners in complex systems — and reward them by… removing them from technical work entirely.

At Atlassian, last I saw, they have six levels beyond what most companies would call “Principle.” Six. That might seem extreme, but if you have genuinely exceptional people, maybe you need it. The alternative is losing them to companies that have figured out that career progression for technical specialists isn’t optional — it’s infrastructure.

Recognition matters deeply to people. It’s not vanity; it’s validation that their growth is seen, that their trajectory has somewhere to go. A career ladder isn’t just HR bureaucracy — it’s a signal that says “we’ve thought about your future here, and it exists.”

You need a career ladder for individual contributors that extends beyond senior: Staff, Lead, Principal, Distinguished, Fellow — whatever naming convention fits your culture. Without it, you’re sending a clear message to your most experienced technical people: the path to success and money runs through management. And you will lose your best and brightest to companies that have built a path for highly skilled technical people who want to stay highly skilled technical people.

The Counter-Intuitive Growth Problem

So let’s say you’ve built the ladder. Tech Lead sits above Senior. Staff above that. Principal somewhere in the distance. You’ve got titles. But here’s the trap most organisations fall into: they create the levels, then define progression as “do more of what you’re already doing, but better.”

That’s not growth. That’s a treadmill with a nicer view.

This is where most tech leaders get stuck. And the answer is genuinely counter-intuitive.

You have an engineer. Namfon is amazing. Absolutely crushes her sprint work, delivers exceptional product results every cycle, writes code that makes reviewers weep with joy. The conventional approach says: promote her, give her a bigger project, expect even more output.

Here’s what actually works: ask her to do less sprint work.

I know. It sounds backwards. Your best performer, and you’re asking them to do less of what they’re best at?

Eugene, a former Principle engineer at Agoda, once framed it beautifully over coffee: “Joel, there are two types of work we can do as engineers. There’s the product work — that gives us more bonus at the end of the year. And there’s the tech work — that makes our lives easier. It’s up to us to choose the balance.”

That phrase — “makes our lives easier” — is doing a lot of work. Making engineers’ lives easier means making them more efficient. More efficient means more capacity. More capacity means more product work gets done anyway. It’s not a trade-off; it’s leverage.

This is where autonomy and mastery actually enter the picture. When you move beyond senior, you should be contributing to efforts that impact many teams, not just your own. The radius of influence expands. A senior engineer makes their team better. A staff engineer makes adjacent teams better. A principal engineer makes the engineering organisation better.

But — and this is critical — you have to actually give them the autonomy to choose what problems to solve and the space to develop mastery in solving them, along with guide them on the right metrics to prioritise that work. If you promote someone to Staff and then hand them a list of cross-team projects you’ve already defined, you’ve just given them a bigger cage. Real growth means trusting them to identify where they can have impact.

From Impact to Discovery

But here’s where it gets interesting. The step after expanding impact is something most organisations never explicitly develop: the ability to find the problems nobody knew existed.

I often tell my tech leads: “Go find me the problem I didn’t know I had. Then tell me how you’re going to fix it. Then tell me how much it’s going to save and cost me.”

That last part matters more than most engineers realise. I actively train my senior people on assessing the business value of technical endeavours. Not because I want them to become product managers, but because the ability to build a compelling case for change is what separates engineers who get to work on interesting problems from engineers who are told what to work on.

When you can link efficiency gains to your work, then multiply that by the number of teams affected, something magical happens. Suddenly you’re not competing with product features for prioritisation — you’re enabling them. The conversation shifts from “why should we let you do this instead of building features?” to “how quickly can you roll this out?”

As the management theorist Peter Drucker noted, “What gets measured gets managed.” But I’d add a corollary for engineering: what gets quantified gets funded. An engineer who can say “this will reduce manual deployment effort by 40% across 12 teams, saving roughly 200 engineer-hours per month” isn’t asking for permission. They’re presenting an investment opportunity.

Measuring What Matters

So how do you actually measure growth at these senior levels? You can’t exactly count story points anymore.

Start with DORA metrics — deployment frequency, lead time for changes, change failure rate, mean time to recovery. They’re imperfect, but they’re a foundation. The real work is figuring out what matters specifically for your organisation.

You need to measure how fast you can deliver with quality and performance. Cost reduction is another dimension — nice to have, not always primary — but these are the levers that technical improvements generally deliver on. When a staff engineer improves your CI pipeline and deployment frequency goes from weekly to daily, that’s measurable. When a principal engineer redesigns your service boundaries and mean time to recovery drops from hours to minutes, that’s measurable.

The point isn’t to reduce senior technical growth to a dashboard. It’s to give senior engineers the vocabulary and framework to demonstrate their impact in terms the business understands. They should be able to walk into a planning meeting and say “here’s the problem, here’s the fix, here’s the return on investment” without needing a product manager to translate for them.

The Quiet Rot

The reason I call this the “Senior Engineer Plateau” and not the “Senior Engineer Problem” is that plateaus are easy to ignore. Nobody rings an alarm when an engineer stops growing. There’s no deployment failure, no customer complaint, no production incident. Just a slow, quiet accumulation of disengagement.

Your best senior engineer starts doing exactly what’s asked — nothing more, nothing less. The ideas stop flowing. The architecture discussions lose their spark. Code reviews become perfunctory rather than educational. They’re still performing at a senior level, which is exactly the problem. They’re performing at the same level they were two years ago, and they’ll be performing at that level two years from now, assuming they’re still around.

The chef Anthony Bourdain, talking about a different kind of creative work, put it this way: “Skills can be taught. Character you either have or you don’t have.” I’d adapt that for our world: technical skills can be maintained. But hunger — that drive to solve bigger problems, to expand your reach, to grow — that atrophies if you don’t feed it.

Building the Path

So what actually works? Based on years of watching senior engineers flourish or fade across different organisations, here’s what I’ve learned:

Create explicit technical tracks — but make them meaningful. Staff, Principal, Distinguished — the titles matter less than what they represent. Each level should come with genuinely expanded autonomy: more freedom to choose problems, more scope to define solutions, more trust to operate independently. If your Staff Engineers are still being handed a backlog, you’ve just created expensive Senior Engineers.

Reduce sprint work for your most senior people. Thirty percent of their time or more should go toward problems that span teams. This isn’t a reward — it’s a job requirement at beyond senior levels. If they’re spending 100% of their time on sprint work, they’re in the wrong role. Or you’ve put them in a role that’s wrong.

Train business value assessment. Your senior engineers should be able to calculate and articulate the ROI of technical initiatives. Not because they’re becoming product managers, but because the ability to make the case for change is what gets change funded — and funded work is autonomous work.

Expand the radius of influence deliberately. A promotion from Senior to Staff should come with explicit expectations about cross-team impact. But here’s the key: tell them the expectation, not the solution. “Find ways to improve developer experience across the platform” is growth. “Implement this specific CI improvement we’ve already designed” is just a bigger ticket.

Measure the right things. DORA metrics are a start. What matters is capturing delivery speed, quality, and efficiency — the dimensions where technical improvements actually pay off. When engineers can point to metrics that moved because of their work, they’re building mastery that’s visible and valued.

Create discovery time. Senior engineers should have dedicated capacity to find problems nobody assigned them. The best technical initiatives often come from engineers who noticed friction nobody else was looking for. This is autonomy in its purest form: the freedom to notice, investigate, and propose.

The Bottom Line

We’ve built an industry that’s remarkably good at finding senior talent and remarkably bad at keeping it engaged. We recruit like our lives depend on it, then act surprised when experienced engineers drift toward the exits or settle into comfortable mediocrity.

The career path isn’t a perk — it’s plumbing. Without it, everything eventually backs up. But a ladder with empty rungs is almost worse than no ladder at all. Titles without autonomy are just participation trophies. Promotions without expanded mastery are just inflation.

Your best senior engineers are quietly asking themselves the same question Somchai asked me that Friday evening: “Where exactly am I supposed to go?” If you don’t have a good answer — a real answer, not just a title and a bigger sprint commitment — someone else will.

Now, if you’ll excuse me, I need to go review a career progression proposal. Apparently, having four levels between “engineer” and “management” isn’t enough anymore. Which is either a problem or a sign that we’re finally taking this seriously. I choose to believe it’s the latter.