Career Ladders for Software Professionals - and How to Make Salary Structures More Transparent

In this episode of The Agile Software Engineering Deep Dive, Alessandro Guida explores why professional software engineering requires professional career structures.

Career ladders are often perceived as rigid or bureaucratic. In reality, they provide clarity about expectations, scope of impact, and sustained behavior at each stage of an engineering career. Without that clarity, progression becomes ambiguous and growth conversations lose focus.

Alessandro discusses how to define meaningful levels based on responsibility and influence rather than seniority alone, why roles such as Technical Lead should not automatically imply promotion, and how Individual Contributor and Management paths must remain structurally distinct yet equally senior.

The episode also examines two unhealthy leadership extremes - the purely administrative manager who loses technical depth, and the over-involved “super engineer manager” who never truly transitions into leadership. Healthy engineering management requires technical credibility, product awareness, and organizational responsibility in balance.

Finally, the conversation connects career ladders to salary transparency. When expectations are explicit and levels are well defined, compensation discussions move from negotiation to structural alignment.

If you care about clarity, fairness, and long-term engineering professionalism, this episode is for you.

Please subscribe to the podcast - it is the best way to support it.

If you are interested in the full written article behind this episode, you can find it in the Agile Software Engineering newsletter on LinkedIn.

Transcript

SPEAKER_00 0:30

Welcome to the Agile Software Engineering Deep Dive. My name is Alessandro Guita, and in this episode, I want to explore something that many engineering organizations underestimate. Structured career development. Professional software engineering requires professional growth paths, not vague encouragement, not improvised titles, but clearly defined expectations for what mastery looks like at different stages. What does it actually mean to be a senior engineer? When does someone operate at principal level? What distinguishes technical influence from organizational authority? In this episode, I explore why career ladders are not bureaucratic artifacts but essential instruments for clarity, growth, and fairness. I also discuss the difference between levels and roles. For example, why technical lead is a responsibility, not automatically a promotion. And why engineering management is not a step away from engineering, but a shift toward shaping the system that delivers results. Only once that structure is in place does salary transparency start to make sense. Because without clear levels and expectations, compensation discussions inevitably become emotional and arbitrary. This is not an HR episode. It is about engineering as a profession. Let's dive in.

SPEAKER_01 1:58

You know, there's this um there's a very specific fantasy that lives in the heart of almost every startup founder.

SPEAKER_02 2:04

Oh, yeah.

SPEAKER_01 2:06

And honestly, uh a lot of us who just work in tech buy into it too. It's that it's the garage band fantasy. Trevor Burrus, Jr.

SPEAKER_03 2:12

Right. The idea that we're just this uh this group of scrappy rebels fighting the corporate machine.

SPEAKER_01 2:18

Exactly. We tell ourselves that structure is just, you know, a dirty word. It's a relic.

SPEAKER_03 2:23

Something for IBM in the 1980s. Yeah.

SPEAKER_01 2:26

Or like government bureaucrats. We want the flat organization. We want a room full of brilliant makers where titles absolutely do not matter, nobody has a boss, and we just organically solve problems through pure, unfiltered genius.

SPEAKER_03 2:39

Aaron Powell It's the halacracy dream, really. Right. The romantic notion that if you just strip away the hierarchy, a perfect meritocracy is going to naturally emerge from the chaos.

SPEAKER_01 2:49

But today we're actually going to take a sledgehammer to that fantasy. We're doing a deep dive into a really compelling piece of writing from the Agile Software Engineering newsletter. This is specifically issue number 22, focusing on career ladders for software professionals.

SPEAKER_03 3:03

And what I love about this source material is that the author isn't um they aren't preaching from a mountaintop.

SPEAKER_01 3:09

No, not all.

SPEAKER_03 3:09

They're down in the mud with us. They are actively confessing to their own past management disasters. It's part of a series they frame as a user manual for the young engineering manager. Trevor Burrus, Jr.

SPEAKER_01 3:20

But it reads way more like a warning label.

SPEAKER_03 3:21

Completely.

SPEAKER_01 3:22

And the warning is loud and clear. The central confession here is that by avoiding structure, by thinking career ladders were these oppressive tools of the man, the author wasn't actually liberating their team.

SPEAKER_03 3:36

They were failing them.

SPEAKER_01 3:37

Failing them deeply. Because the absence of structure isn't freedom.

SPEAKER_03 3:41

It's ambiguity.

SPEAKER_01 3:42

Yes. And ambiguity is exactly where bias, unfair pay, and stagnation just thrive.

SPEAKER_03 3:48

So our mission today is to really unpack this. We need to understand why structure isn't the enemy of an agile culture, and how implementing a rigid definition of levels is ironically the only real way to protect your team from burnout.

SPEAKER_01 4:00

And from getting totally ripped off.

SPEAKER_03 4:02

Exactly. We need to reframe the whole concept for you. We have to stop looking at career ladders as a cage that limits you and start seeing them as a scaffold.

SPEAKER_01 4:11

Because you can't build a skyscraper without a scaffold.

SPEAKER_03 4:14

You really can't.

SPEAKER_01 4:15

So let's start with the first major pivot in the text. The author actually lists this as mistake number 13, which is believing that career ladders were obsolete.

SPEAKER_03 4:25

Why is this such a common trap? I mean, I've definitely felt that anti-title vibe before myself.

SPEAKER_01 4:30

Well, think about the pressure on a new leader in a modern tech company. You're obsessed with flexibility. Right. You've read the Agile Manifesto. You want cross-functionality. You want a team where everyone can do everything. Yeah. The author admits they started their own journey believing that specialization was inherently bad. They wanted a team of generalists.

SPEAKER_03 4:49

Aaron Powell The famous Swiss Army Knife employer.

SPEAKER_01 4:52

Yep.

SPEAKER_03 4:52

The full stack ninja who can, you know, configure the server, write the API, design the front end, and maybe even draft up the marketing copy on a Friday. Right. And in the very early days, when you're just three people in a basement, that actually might work. But as you scale up, that generalist mindset becomes a massive trap.

SPEAKER_01 5:10

Aaron Powell The source uses a really fantastic analogy to dismantle this generalist myth, actually.

SPEAKER_03 5:14

Oh, the professional comparison?

SPEAKER_01 5:16

Yes, I loved this part.

SPEAKER_03 5:17

It's so good. They ask you to look at other serious high-stakes professions. If you have a complex, life-threatening medical issue, do you go looking for a doctor who is, quote, generally interested in medicine?

SPEAKER_01 5:31

Absolutely not. If my hormones are completely wrecking my life, I'm not going to a general practitioner. I am finding the best endocrinologist I can possibly afford.

SPEAKER_03 5:40

Exactly. Or look at the legal field. If you're buying a commercial building, you don't want a lawyer who just knows a bit about the law.

SPEAKER_01 5:47

Right. You want a specialist in real estate contracts.

SPEAKER_03 5:49

The author's insight here is a heavy hitter. They write, breadth is valuable, but depth builds authority.

SPEAKER_01 5:56

Depth builds authority. That is such a sticky phrase.

SPEAKER_03 6:00

It really is. And the author connects this directly to Steve McConnell. For those who might not know, McConnell wrote Code Complete, which is basically the Bible of software construction.

SPEAKER_01 6:13

Oh yeah. Legendary.

SPEAKER_03 6:14

The influence there is the core idea that professional software engineering deserves professional career structures. A career ladder isn't there to box you in, it's there to define what mastery actually looks like.

SPEAKER_01 6:29

Because without that definition, growth is just a vibe. It's just a manager saying, hey, do better.

SPEAKER_03 6:35

Precisely. Like a And this is the real purpose behind the ladder. It isn't primarily about money, though we will definitely get to the money because that part is huge. It's about the learning journey. Right. If you are a manager and your version of professional development is just saying, here's a$1,000 budget, go pick a random course on Udemy you aren't managing. You're just spending cash.

SPEAKER_01 6:52

You're completely abdicating responsibility. You're just hoping they figure it out on their own so you don't have to guide them.

SPEAKER_03 6:58

Right. A manager's duty is to support a journey. A well-constructed ladder gives you a map for that. It creates a shared language so the manager and the engineer can sit down together and say, okay, you are here.

SPEAKER_01 7:10

And to get there.

SPEAKER_03 7:11

Exactly. To get to that next level of mastery, you need to conquer these specific technical or leadership challenges. Without the ladder, that conversation is just pure guesswork.

SPEAKER_01 7:22

Aaron Powell So let's get into the nuts and bolts of this map. Because I think when a lot of us hear the phrase career ladder, we immediately revert to that old corporate thinking.

SPEAKER_03 7:31

Oh, sure.

SPEAKER_01 7:31

We think of seniority, you know, I've been here three years, I haven't been fired yet, so I guess I'm a senior now.

SPEAKER_03 7:36

The participation trophy model.

SPEAKER_01 7:38

Exactly. But the source shuts that down hard.

SPEAKER_03 7:41

Completely shuts it down. A real professional ladder is not a list of titles based on years served. It's based on, and this is the key phrase from the text, consistent reproducible capability.

SPEAKER_01 7:53

Consistent reproducible capability.

SPEAKER_03 7:56

That sounds very engineering focused. It is very deliberate. It means can you do this level of work reliably? Not just once by accident or once because you panicked during a deadline, but every single day. The text outlines a specific hierarchy for an individual contributor. I think it's really worth walking through this because a lot of listeners might suddenly realize they're stuck between levels.

SPEAKER_01 8:21

Let's do it. Let's start right at the bottom. Level one.

SPEAKER_03 8:29

Okay, level one is the junior engineer. The defining characteristic here is guidance. They are contributing, they're writing code, but they are primarily absorbing.

SPEAKER_01 8:39

They're learning the stack, the practices, the culture of the team.

SPEAKER_03 8:42

Right. They need a safety net.

SPEAKER_01 8:44

Then we graduate to level two, which is the software engineer. This is usually the bulk of the team, right?

SPEAKER_03 8:48

Yes, the mid-level. The major shift here is independence. A level two can take a scoped feature, run with it, and deliver reliable, maintainable code without someone holding their hand the whole time.

SPEAKER_01 8:59

They understand how their specific piece fits into the immediate system. This is your solid, everyday contributor.

SPEAKER_03 9:05

Exactly. And then comes the big jump, level three, the senior engineer.

SPEAKER_01 9:09

I feel like this is where the most friction happens in the entire industry. Everyone wants that senior title, but the definition is often incredibly fuzzy.

SPEAKER_03 9:18

It really is. And this source clarifies it perfectly. The jump from level two to level three is not just doing level two work, but faster. Right.

SPEAKER_01 9:27

It's not about typing speed.

SPEAKER_03 9:28

No, or closing more Gira tickets. It is a fundamental change in scope. A senior engineer owns entire subsystems, but more importantly, they make architectural trade-offs and they actively mentor the level ones.

SPEAKER_01 9:42

So if you're just sitting in the corner with your headphones on, writing brilliant code all by yourself, but you aren't lifting up the juniors or thinking about how your code is going to affect the database costs next year.

SPEAKER_03 9:53

You aren't a senior.

SPEAKER_01 9:54

Wow.

SPEAKER_03 9:55

You might be a highly paid level two or very specialized coder, but you aren't a senior engineer in this structure. You have to influence the team. The mindset shifts from my code to our code.

SPEAKER_01 10:05

That is such a crucial distinction. Okay, then we have level four, the principal engineer.

SPEAKER_03 10:09

Now the scope zooms out even further. Level four defines the architectural direction. They aren't just solving problems as they come up, they are anticipating risks before they even happen.

SPEAKER_01 10:20

They're guiding cross-team initiatives.

SPEAKER_03 10:22

Right. They elevate the standards of the whole organization, not just their specific squad.

SPEAKER_01 10:28

And finally, the top of the mountain, level five. The distinguished engineer.

SPEAKER_03 10:32

The unicorn.

SPEAKER_01 10:33

Yeah.

SPEAKER_03 10:34

This person is a true visionary. They shape the long-term technical vision. They represent the company externally at conferences. They are likely influencing industry-wide standards, not just internal company policies.

SPEAKER_01 10:47

Aaron Powell, What I really love about this breakdown is that it introduces what the author calls the consistency rule. It's the idea that the title is actually a trailing indicator.

SPEAKER_03 10:56

Yes. This is vital. You have to demonstrate the behavior of the next level consistently before you get the promotion.

SPEAKER_01 11:02

Aaron Powell, you don't get the title to help you grow into the job.

SPEAKER_03 11:04

Exactly. You grow into the job to get the title. This is how you prevent the Peter principle.

SPEAKER_01 11:08

Where people just keep getting promoted to their level of incompetence.

SPEAKER_03 11:12

Right. And while we're talking about roles, the text also notes that while one ladder is often enough for smaller company, eventually organizations might need separate tracks for QA, DevOps, or UX.

SPEAKER_01 11:23

Because backend excellence doesn't look the same as testing excellence.

SPEAKER_03 11:27

Precisely. The capability markers change depending on the discipline.

SPEAKER_01 11:31

Which brings us to a scenario that I think literally every single listener has seen, or maybe even lived through. The author calls it mistake number 14. I call it the hero trap.

SPEAKER_03 11:41

Oh man, the hero trap is so painful because it usually comes from a really good place.

SPEAKER_01 11:45

Okay, so here is the scene. The deadline is looming, it looks totally impossible, the project is weeks behind. But then one engineer, let's just call him Dave, decides to go completely rogue.

SPEAKER_02 11:57

We all know a Dave.

SPEAKER_01 11:58

He pulls an all-nighter, then another one, he worked the entire weekend. He drinks enough energy drinks to power a small city. And on Monday morning, bleary-eyed and exhausted, he ships the code. He literally saved the company.

SPEAKER_03 12:10

And the manager's natural instinct, just filled with relief and sheer gratitude, is to say, Dave, you are an absolute rock star. I am promoting you to senior engineer immediately.

SPEAKER_01 12:22

And the author says, Stop. Do not do that.

SPEAKER_03 12:25

It feels harsh, right? I mean, Dave saved the day. Why shouldn't he get the promotion?

SPEAKER_01 12:29

Yeah, walk us through the logic there. Why is promoting the hero such a massive mistake?

SPEAKER_03 12:34

There are two major reasons. First is the competence trap. Remember, the levels are about consistent capability. Dave proved he can crunch. He proved he has incredible stamina. Right. He did not prove he can mentor juniors, design sustainable architecture, or lead a team without burning them out. By promoting him, you might be taking a great coder and turning him into a terrible, exhausted leader.

SPEAKER_01 12:57

You're just setting him up to fail.

SPEAKER_03 12:58

Exactly. And the second reason is the math. This is a very cold financial reality check. A promotion comes with a salary increase that compounds forever.

SPEAKER_01 13:07

Yeah, that's true.

SPEAKER_03 13:08

You are paying that extra money every single month for the rest of his tenure at the company. But the heroic act, that weekend crunch, was a one-time event. You are creating a permanent financial liability for a temporary gain.

SPEAKER_01 13:23

That is a very stark way to look at it, but you're totally right. You're basically paying a mortgage for a weekend hotel stay.

SPEAKER_03 13:30

Exactly.

SPEAKER_01 13:31

So what is the cheat code here? How do we keep Dave happy and feeling valued without ruining the org chart?

SPEAKER_03 13:37

You pay him, you give him a spot bonus, you give him extra paid vacation days, you throw a party in his honor and give him public praise. You reward the one-time act with a one-time reward.

SPEAKER_01 13:48

But you hold off on the title.

SPEAKER_03 13:49

You absolutely reserve the promotion for when he actually shows he can consistently operate at the next level of capability.

SPEAKER_01 13:56

Promotion is for capability, not crunch time. I feel like that needs to be on a bumper sticker for every engineering manager.

SPEAKER_03 14:02

It really does. Because it also changes the entire culture of your team. Think about the signal you send. If you promote based on crunch, you are telling everyone else the only way to get ahead here is to work yourself to death on weekends. But if you bonus the crunch and promote the consistency, you signal that you value sustainable, high-level professional engineering.

SPEAKER_01 14:25

Okay, so we've built a ladder. We know exactly who sits where. We know Dave gets a bonus, not a new title. Now we have to talk about the part everyone absolutely dreads. The elephant in the room, the winners and losers lottery.

SPEAKER_03 14:37

Uh, yes. Transitioning into part two of the source material, the annual salary regulation season.

SPEAKER_01 14:49

The author describes this with such vivid, relatable frustration. The manager gets a pot of money, say, a three percent increased budget for the whole department, but they aren't allowed to just give everyone three percent. Right. They have to redistribute it, rob Peter to pay Paul, and often they aren't even allowed to explain why to the team.

SPEAKER_03 15:07

It's a complete transparency black hole, and it erodes trust faster than almost anything else. And employee sits there thinking, why did I get two percent and she eat four percent? Does the boss just like her better?

SPEAKER_01 15:19

And without a real system, the answer might actually be yes.

SPEAKER_03 15:22

Or it might be that she just negotiated harder when she was hired. Or it might be that the manager was just having a bad day. It's completely arbitrary.

SPEAKER_01 15:29

So the author drops a really heavy philosophy bomb right here. They write, as engineering managers, your loyalty must first and foremost lie with your team.

SPEAKER_03 15:38

That is the core of the ethical argument in this whole piece. The author is saying that if you cannot openly and rationally defend a salary decision to an employee's face, something is structurally broken in your management style.

SPEAKER_01 15:51

You shouldn't be hiding behind HR said so.

SPEAKER_03 15:54

Or the budget is just tight this quarter. You need a defensible system.

SPEAKER_01 15:58

And this is where the career ladder meets the market. They introduced this transparency mechanism. How does this actually work in practice?

SPEAKER_03 16:06

It turns salary from a dark art into a simple calculation. You create a matrix. On the y-axis, you have the career level, so junior, senior, principal, based on the ladder we just talked about. Okay. On the x-axis, you have market data. These are salary bands provided by industry reports or unions. And then you factor in seniority or experience within that level.

SPEAKER_01 16:25

So it's basically just a grid.

SPEAKER_03 16:26

Exactly. The example given in the text is quite specific. Let's say you have a level two software engineer. That defines the band. Then you look at their experience, say, 10 years. The matrix might say the range for that exact combination is between 7100 and 7,600 euros.

SPEAKER_01 16:43

So there is zero mystery, no backroom deals.

SPEAKER_03 16:46

None. You can literally show the employee the graph. You put it on the screen and say, you are a level two, you sit right here on the seniority curve. This is the current market rate. That is exactly why your salary is X.

SPEAKER_01 16:58

That completely changes the tone of the conversation. It isn't I feel I deserve more because my rent went up. It becomes, what do I need to do to get to level three where the band is higher?

SPEAKER_03 17:08

Precisely. It shifts the entire focus from negotiation to progression. It aligns the employees' ambition with the company's structure. And honestly, it removes the begging aspect of asking for a raise, which is frankly humiliating for everyone involved.

SPEAKER_01 17:20

But this system heavily relies on the manager actually being honest about performance throughout the year. Which perfectly leads us to mistake number 15. The author talks about using salary as a weapon, the passive aggressive raise.

SPEAKER_03 17:34

This is so toxic, and sadly, it is rampant in the industry. This is when a manager is unhappy with an employee's performance, but instead of having a difficult direct conversation, they just give them a 0% raise.

SPEAKER_01 17:47

Or like a tiny insulting increase during the annual review.

SPEAKER_03 17:50

Right. They use the paycheck to send a message that they are too cowardly to say out loud. Deferring feedback until the annual salary review is not just unfair, it's corrosive to the culture.

SPEAKER_01 18:00

The author warns performance is not a negotiation.

SPEAKER_03 18:04

Exactly. The correct approach is to address underperformance immediately. Today, you clarify expectations again using that ladder we built. You say to be a level two, you need to be doing X. You aren't doing X. Here's the support and the corrective action plan to fix it. And if they still fail after that support, then you have to face the hard truth that they might just not be fit for the job. But this is critical, you do not use the salary review as a punishment mechanism. Salary adjustments are strictly for market alignment and progression on the ladder. They are not a disciplinary whip.

SPEAKER_01 18:34

That is such a vital boundary to set. If you mix those two things up, you just totally confuse the employee. Just sitting there thinking, wait, did I not get a raise because the market is down or because my code actually sucks?

SPEAKER_02 18:47

Exactly. Clarity is kindness. Even when the news is bad, people deserve to know why.

SPEAKER_01 18:53

We have really gone on quite a journey here today. We started with the idea that structure is this boring, bureaucratic enemy of agile culture. But when you really deep dive into it, it turns out structure is actually just fairness.

SPEAKER_03 19:06

I would go even further than that. Structure is respect. It is respecting your team enough to be crystal clear about what you expect from them. It's respecting them enough to pay them fairly based on data, not on who yells the loudest or negotiates the hardest. And it's respecting their ambition by giving them a real map, not a maze.

SPEAKER_01 19:24

And it protects them from the hero trap we talked about. It ensures that the person working sustainable hours, but delivering massive architectural value gets recognized just as much, if not more, than the person burning themselves out on a weekend crunch.

SPEAKER_03 19:40

It professionalizes the craft. It says we take engineering seriously, so we take your career seriously.

SPEAKER_01 19:45

The author suggests actually visualizing this entire system for the team.

SPEAKER_03 19:49

Yeah.

SPEAKER_01 19:50

Like putting that matrix up on a screen for everyone to see. Here is exactly where you stand.

SPEAKER_03 19:54

It sounds terrifying to a manager who is used to hiding the numbers.

SPEAKER_01 19:58

Oh, for sure.

SPEAKER_03 19:59

But it sounds incredibly liberating for the team. It creates structured reasoning instead of favoritism. It removes the cognitive load of constantly guessing. Am I doing a good job? Does the boss like me? Is the new guy making more than me? When you have a ladder and a transparent matrix, you don't have to guess, you just know.

SPEAKER_01 20:16

So as we wrap up this deep dive, I want to leave you, our listeners, with a challenge. We've seen the logic, but actually putting it into practice is the hard part.

SPEAKER_03 20:25

I have a question for the managers listening right now. If your team walked into your office today, like right this second, and asked you to mathematically justify their salaries, could you do it? Could you show them the graph? Or would you have to rely on vibes and vague promises?

SPEAKER_01 20:41

That is a terrifying thought for a lot of people. And if you are an individual contributor listening to this, do you know exactly what excellence looks like in your current role? Or are you just guessing and hoping someone eventually notices your hard work?

SPEAKER_03 20:55

Clarity does not reduce ambition, it directs it.

SPEAKER_01 20:58

That is the perfect takeaway right there. Structure isn't the cage, it's the ladder. Thank you for joining us on this deep dive. Go check your levels, ask the hard questions, and we will catch you next time.

SPEAKER_00 21:19

Thank you for listening to the Agile Engineering Deep Dive Podcast. If you found this episode valuable, feel free to share it with someone who might benefit. A colleague, your team, or your network. You can access all episodes by subscribing to the podcast and find their written counterparts in the Agile Software Engineering newsletter on LinkedIn. And if you have thoughts, ideas, or stories from your own engineering journey, I'd love to hear from you. Your input helps shape what we explore next. Thanks again for tuning in, and see you in the next episode.