As a Senior Software Engineer, the next progression step isn't always obvious. You're shipping good work and trusted by your team, but the leap to Staff or Principal can feel unclear, with role definitions and responsibilities looking different at every company.
Progression no longer just means stepping into people management. Staff and Principal roles offer a genuine path for individual contributors who want to grow their technical depth and leadership without managing people, and we're seeing more of these roles appearing across our clients.
Over a series of group discussions with Senior Engineers and experienced Staff Engineers who've navigated this path themselves, we've gathered some of their most consistent advice on the real challenges, lessons and mindset shifts involved in making the move.
Growing into Staff+ positions
Moving into Staff+ isn't about writing better code. The role can look very different depending on the company, so it's worth being clear about what you're actually looking for: learning, influence, compensation, recognition. Your motivation shapes your next move and helps you work out whether the step up is achievable where you are now, or whether you'd be better served looking elsewhere.
One thing that comes up repeatedly is that the title tends to lag behind the behaviour. Shadow or reverse-shadow senior leaders to understand how they make decisions. Build cross-functional influence by demonstrating technical leadership, even on smaller projects. And accept that every company defines "Staff" and "Principal" differently; part of your job in any process is figuring out whether their version aligns with yours.
Moving from features to business impact
At Senior level, success looks like shipping. At Staff level, the question becomes: what actually matters to the business right now, and where can I have the most impact? That requires you to zoom out. It means understanding where teams are misaligned, where cross-team friction is slowing things down, and what the organisation needs beyond what's in the current sprint.
Leading through influence
You won't have direct authority over most of the people you need to work with, so building trust matters more than being the most technical person in the room. That also means getting comfortable with organisational dynamics: understanding where decisions get made, and learning to navigate that without playing politics.
Senior ICs evolve from problem solvers to influencers. Progression at this level depends far more on your ability to align, communicate and persuade than to control. Build relationships outside your team with PMs, design and leadership. Aim to be an accelerant rather than a barrier, building on other people's ideas rather than redirecting conversations back to your own. Learn to connect engineering goals to commercial outcomes, and be patient: influence grows over time through consistent input, curiosity and collaboration.
On imposter syndrome: for many engineers, it's something you'll carry for most of your career. You don't need to have all the answers. At Staff level, impact comes from judgement, context and asking the right questions.
Creating growth opportunities in flat or small organisations
Don't wait for the title to start acting at Staff level. Recognition tends to follow demonstrated behaviour, so spot problems, drive initiatives and show ownership before anyone asks you to. Look for impact beyond your immediate team, whether that's driving engineering standards, mentoring peers, or connecting teams who are working on the same problem in different ways.
The shift that matters here is moving from independence (doing the work well) to entrepreneurship (finding the work that needs doing). The role boundary at Staff level is often unclear by design, and figuring out where you can create the most value is part of the job.
The importance of advocates, sponsors and mentors
One of the most common reasons engineers stall at Senior level is visibility rather than performance. If you feel like you're already operating at Staff level but not getting the recognition, the missing piece could be that you don't have the right people in your corner.
- A sponsor advocates for you and opens doors.
- A coach builds your skills through feedback and challenge.
- A mentor offers perspective and a sounding board.
Internal progression tends to move faster when you have two or three of these relationships in place. When leaning on your network, you'll get the most from people when you're clear about what you're actually asking for. They're different roles, and the best thing you can do is be specific about which one you're asking someone to play. If you're struggling to identify anyone who fits these roles internally, it could be a signal that the environment around you may not be set up to support that next step for you.
Know your archetype
Take time to understand the kind of IC you want to be and where your strengths lie. Will Larson's Staff Engineer archetypes, laid out in his book Staff Engineer: Leadership Beyond the Management Track, are a useful framework for this. Some people gravitate toward shaping system architecture, others toward solving the hardest problems, others toward enabling leadership or driving complex cross-team delivery. Most engineers find they're a blend of two or three. Knowing which archetypes fit you helps you focus your energy where you'll have the most impact, and makes it easier to identify the kind of environment where you're likely to thrive.
Interview tips
If you're interviewing for a Staff Engineer role, be clear on what the role means to you and make sure you understand what it means to that specific company - alignment matters on both sides.
Show depth and introspection. Go beyond what you built and explain why you made certain choices, what alternatives you considered, and how your decisions drove outcomes. Where you can, anchor those outcomes in metrics. Improving latency is a good story, but improving latency that reduced churn or cut support load tells a much better one. Business and customer context is what separates a strong Staff-level example from a purely technical one.
Own your risk profile. Whether you've spent a long time at one company or moved through several, be ready to articulate what you've learned from those choices, the strengths they give you, and the gaps they might create.
It's also worth remembering that at this level, strong examples don't have to be purely technical. Managing relationships through a period of friction, unblocking a team that had been stuck, improving team structures, or finally resolving that long-standing low-priority problem are all legitimate demonstrations of Staff-level impact.
One practical habit worth building now is to keep a running record of your wins and update it as you go. Trying to reconstruct two years of impact the week before an interview is hard. A living document gives you a richer resource to draw from and makes it much easier to recall specifics when it matters.
If you're trying to get a sense of where salaries sit at this level and what the market is currently paying, our latest Salary Guide is a good place to start.
At Burns Sheehan, we spend a lot of time talking to engineers at exactly this stage of their careers, and working with the technology companies who are looking to hire them. If you're thinking about what a Staff or Principal role could look like for you, or you're already in a process and want a sounding board, we're always happy to talk it through.
We also run regular roundtables and discussions for software engineers at various stages of their careers. If you'd like to be part of a future session like the one that inspired this post, drop Tom a note at [email protected].
