Why You're STUCK at Senior Software Engineer
Dev Leader Weekly 101
TL; DR:
It's not about more complexity.
It's about scaling your impact beyond the team.
Check out the livestream (or watch the recording) on Monday, July 7th at 7:00 PM Pacific!
Why You're STUCK at Senior Software Engineer
Let’s be honest -- lots of engineers are chasing the next title. I noticed this when moving into Big Tech after spending years at a startup.
But sometimes the real pursuit isn’t the title at all. It’s the type of work, the impact, and the sense that what you do actually matters beyond your Jira board.
On Code Commute, I was discussing a topic from a LinkedIn message where an engineer was effectively saying:
“I’m doing repetitive work. I’m not growing. I want to have broader impact -- not just crank out the same features. I want to operate like a principal engineer.”
While we can't control if someone gives us the title or not, we can control if we start operating at that next level. And we'll dig into what that looks like in terms of differentiating senior and principal (or staff, depending who or where you are).
If you're interested, you can check out the Code Commute episode where I break this down:
The Real Difference Between Senior and Principal
A lot of people assume it’s a matter of skill.
“Principal” must mean:
You’re more technical.
You're a better architect.
You're a smarter engineer.
Not quite. Here’s the big difference:
Senior engineers deliver meaningful work at the team level. Principal engineers deliver impact at the organizational level.
This distinction makes a big difference, even though in both cases you're leading complex projects and will have others working alongside you to deliver that impact.
To contrast:
Seniors lead team-level projects, support junior developers, guide designs within their domain.
Principals identify problems that affect multiple teams and solve them in a way that scales.
It’s not about being the best coder, but more about becoming a force multiplier ACROSS the organization you're in.
Actionable Tip:
Pull up your last few months of work. For each item, ask:
Who did this impact?
Did it help only our team, or other teams too?
Was the benefit local, or does it scale?
You may be doing great work. The next level requires greater reach. And you know what? Maybe you can kick off an initiative to do it at a broader scope now that it's been proven for your team!
Visibility Isn’t Bragging
One of the biggest challenges for principal-level growth is that impact without visibility doesn’t move careers. This has been my single biggest challenge in my own career while at Microsoft.
If your skip-level’s peers have no idea what you’re doing, it doesn’t matter how good it is. If your work only helps your manager, it’s not enough. How can it be impacting the organization significantly enough if the leaders of the organization aren't even aware of it?
This isn’t about chasing credit or ego. It’s about making your contributions unignorable.
Think of it this way with this example:
If your process change, tool, or system improvement is valuable enough, other teams should want to adopt it -- even if you never ask.
That’s what real visibility looks like.
Don't Wait for Opportunities -- Create Them
In an ideal world, your manager gives you meaty challenges that grow your career. They know what's coming down the pipe with respect to challenges and opportunities across the organization, and they tee them up for you.
But many of us don’t live in that world. And many of us shouldn't rely on the stars to align that way either.
Sometimes your day is full of bug fixes, debugging, tweaking configurations, or “quick wins” that don't stretch you. Sometimes the only way to do principal-level work is to go find it yourself.
That might mean:
Talking to peer teams and asking about shared pain
Offering to pilot a solution your team can own and extend
Identifying duplicative work across orgs and proposing a unification effort
You can’t rely on a formal initiative. The work isn’t assigned -- it’s discovered.
Actionable Tip:
Pick one recurring problem or inefficiency your team deals with. It could be related to a process or some part of your product or service. Then:
Talk to two other teams and ask if they face the same issue.
If yes, write a short doc ("one pager") describing the common thread and a possible solution.
Share it with your manager and those teams -- see who’s interested in co-owning.
Even if it doesn’t get adopted immediately, you’re starting to build the principal-level muscle of org-scale thinking.
Remember: You don't want to be chasing these things if you're not already doing what's expected of you in your role. That would just be dropping the ball.
Build the Org You Want
Here’s a shift that matters more than most people realize:
Senior engineers build great features.
Principal engineers build great systems for the greater team.
This includes:
Processes that scale
Technical decisions with long-term consequences
Frameworks for other teams to adopt, not just tools for yourself
One example that I shared in the Code Commute episode was a process change I led that wasn’t especially complicated -- but it solved a cross-org pain point. It gained attention because it made sense to formalize and spread.
That’s the kind of work that signals leadership, not just execution. And in my case, it didn't have to be a fancy new architecture or a complex coded solution.
Actionable Tip:
Look at one internal process you rely on. Ask:
Could this be templated?
Could it reduce friction for 3+ teams?
Is the process ad-hoc when it should be documented?
If the answer is yes, start by writing a one-pager or proposal. You don’t need buy-in to get started -- that's what comes after when you have a proposal you hope solves a large problem.
Beware the “Complexity Trap”
Going back to the LinkedIn message that kicked off this entire discussion, the software engineer was considering:
“My projects must not be complex enough.”
Maybe you failed an interview where someone said your projects lacked complexity.
Maybe you compared yourself to a friend building a compiler in their spare time.
But the truth is that complexity is the wrong metric.
No one wants to build complex systems. Nobody wants more complexity than we have to deal with.
The better metric is: Are you solving important problems? At scale? For real people?
A beautifully simple solution to a hard problem is 10x more impressive than a convoluted mess.
Actionable Tip:
Reframe “complexity” in your portfolio. For your next project, document:
The problem you solved (why it mattered)
The impact it had (who benefited and how)
The approach you used (why it was effective)
Show how you think, not how many layers you can add.
Don’t Wait for Mentorship
Many engineers are stuck waiting for mentorship. They want someone to guide them, to help shape their path, to show them what “principal” really means.
Mentorship is great -- when it’s available.
But if it’s not? Don’t wait. Lead anyway.
In my own career, I didn’t have a consistent technical mentor. I learned by observing, experimenting, and most importantly leaning into uncomfortable new opportunities.
I will say that I was extremely fortunate to have an amazing HR leader early in my career who helped push me on the management side of things. But when it came to areas for technical growth or trying to deliver impact? I didn't wait on a mentor to get me there.
You can even start being the support that others need on their journey.
Actionable Tip:
Start mentoring others, even informally.
Host a brown-bag session on something you’ve mastered
Review someone’s design doc and ask strong questions
Share your thought process in writing after solving a tricky bug
Mentorship is a great way to teach yourself by teaching others. And you'll refine your strong points and learn about the areas you need to improve for yourself too.
You May Need a Different Environment
Sometimes, no matter how hard you try, the environment just doesn’t allow for growth.
Your team might not need org-scale solutions.
Your day might be packed with tactical, repetitive tasks.
Your manager might not be interested in career progression.
There’s no shame in that. But there’s also no future in staying stuck if you know you’ve outgrown it.
You simply can’t demonstrate principal-level work if the sandbox is too small, or if you're permanently confined to work that doesn't have enough impact.
Actionable Tip:
Audit your environment. Ask:
Are there any org-wide problems you could feasibly tackle here?
Is your manager supportive of growth outside the current scope?
Could switching to a different team internally create space for principal-level work?
If the answer is consistently “no,” it may be time to make a move. It's not an easy decision to make, but if you're even remotely considering this already, then you know this already.
Final Thoughts
Becoming principal isn’t about being anointed, and it's certainly not going to be someone "taking a chance" on you to give you a title and hope you grow into it.
It’s about doing the work before anyone gives you the badge. It’s about solving bigger problems. Building bridges. Creating systems that last.
You don’t need permission to start, but you do need the intention.
And if you’re reading this far, then odds are you already have it. Now go build something that outlasts you.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!