Breaking the Staff Engineer Ceiling
Going from Senior to a Staff-Plus marks a pivotal evolution in an engineer's career, requiring a fundamental shift in how we influence, lead, and drive outcomes across the organization.
The transition from Senior to a Staff-Plus Engineer marks a pivotal evolution in an engineer's career, requiring not necessarily more technical excellence but, more importantly, a fundamental shift in how they influence, lead, and drive outcomes across their organization.
When it comes to staff engineering, the old management saying, "What Got You Here Won't Get You There," couldn't be more accurate.
This article is part 1 of a series on staff-plus engineering. In this series, you will learn:
What defines the Staff-Plus level, common expectations across companies, and the key gaps that often cause Senior Engineers to get stuck.
Critical behaviors that distinguish high-performing Staff-Plus Engineers from their peers that help them scale their impact and influence in a sustainable way.
"The Staff-Plus Flywheel" – Practical strategies for scaling personal impact through mentorship, sponsorship, and strategic involvement in projects.
This series is really a peak behind the curtain of what it takes to really be get promoted, and be impactful at the staff-plus level.
Today we’ll be jumping deep into part 1.
About the author
Thiago Ghisi is the Director of Engineering for the Mobile Platform team at Nubank. He has nearly 20 years of experience in the software industry, having worked at companies like Apple, ThoughtWorks, and Amex. He also hosts a podcast called "Engineering Advice You Didn't Ask For" and writes extensively about Career Growth & Leadership on both the IC & the Management track on LinkedIn & Twitter.
Thiago has helped over 30 people get promoted, including 10 engineers to staff-plus levels through coaching and mentoring. He’s also done more than 350 interviews as a hiring manager and seen first hand how top performers get hired, onboarded, and become a top-performer. He’s also spent hundreds of hours on promotion committees and performance calibrations.
It‘s clear he knows his stuff.
What does it mean to be a Staff-Plus Engineer?
These are the top questions I hear often as an engineering director.
What does it mean to be a staff-plus engineer?
What are the expectations to get to Staff Level?
What do Staffs do for their practical day to day work?
What is a good Staff Engineer? What is a bad Staff Engineer?
How do I get there? I heard about all the different archetypes..."
The first thing that we really need to understand is not necessarily what's directly written on a companies ladder, but, actually, what is around it and the expectations everyone has in their head when they see someone that has a Staff title.
In order to understand that disconnect, I need to go back in time.
History of engineering career ladders
If we go back 10 to 15 years ago, most companies had a career ladder where you grow from junior to senior, and then you were effectively stuck, unless you became a manager.
That was a pattern that we saw for decades before we finally got the creation of the dual-track career ladder. This new dual-track ladder is a win-win for everybody.
Senior ICs that were unable to grow after a certain level now had a path, and motivation to keep sharpening their skills and their craft.
For companies it was also a win, as it gave them a powerful retention and performance calibration tool. Now “super star seniors” that were impacting more areas, projects and teams across the company could be fairly compensated for their impact and scope, instead of getting frustrated and leaving the company.
The creation of this actually revolutionized not only the IC track, but also the management track: it provided more clarity in terms of progression, scope of responsibility and the equivalence of impact across the tracks.
With that history understood, in my experience, what clearly defines what a staff is:
Someone that's not sitting on a single project or on a single team.
Someone that's overseeing an area that's bigger than a particular project or team.
Someone that is working directly or indirectly on and with multiple projects/teams at the same time, usually reporting to a leader that has a broad scope.
The main thing that matters in most companies to get and to stay at the staff-level is not how deep you know a piece of technology or a layer of the stack, it is your SCOPE of impact and influence on the organizational surface.
I'm not saying that your technical, architectural and decades of intuition in software engineering aren't relevant, they are. But, they aren't what really moves the needle.
Yes, in some core platform teams you might have a handful of staff engineers working on really hard problems that have super broad implications company-wide as part of a single team such as databases, networking, security, provisioning… but those cases are super rare.
Even in the cases a Staff-Plus is part of a single team, their day to day involves a lot of work and coordination to impact and influence many teams across the organization.
In order to be effective, they still need to be managing and influencing stakeholders, talking to the customers, planning ahead what they are going to prioritize to build and why over the next year, etc…
To this point, Staff, Senior Staff & Principal Engineers often report to someone that is at least one level higher than them in the org chart. Staffs tend to report to Senior Engineering Managers, Senior Staff tend to report to Directors and Principal Engineers tend to report to either Senior Director or VPs.
Staff engineers are part of the engineering leadership team and have cross-team responsibilities beyond their direct scope. They are responsible for building bridges and paving paths between the tech teams and the business, even if they are a true expert on a single topic.
There is only one problem with that definition…
Variations of titles/expectations across Companies:
What is the main problem with my definition above? Title, Levels and Expectations vary a lot across companies as you can see below.
Titles are almost always meaningless. The same title could be a completely different level and have completely different expectations in different companies.
This is especially true in periods of hyper growth in the industry (as we have seen recently from 2020 to 2022) when “Title Inflation” tends to happen a lot more, especially when moving from a big/mid-size company to a small/startup.
Here is an example, using the fantastic website levels.fyi. See how a Staff Engineer (IC7) at Nubank, the company I worked for, maps to Principal at Microsoft and even to Senior in other companies.
Levels FYI tries to help answer the question “what level would I transfer into if I were switching companies?” They use leveling rubrics, and map similar scopes and responsibilities based on the information across hundreds/thousands of companies.
What are the core expectations for achieving & maintaining the staff-plus level?
Let’s get into the main focus of this article.
There are the 3 things I found again and again that if you do consistency will make a top Staff-Plus Engineer at pretty much any company.
Interestingly, these are also the 3 things I've seen struggling Senior Engineers completely neglecting or being unaware of.
Do them well, and it's going to be almost unavoidable to be promoted to Staff-Plus level at some point.
Staff-plus expectations across all companies:
Blast Radius
Multi-Scale Planning
Ownership Level
1/ Blast radius: Scope & Shape of Impact
There’s this idea that you need to have a wide impact. As a staff engineer, your impact should go beyond a single group or beyond a single project.
There is, on the other side, this idea that you should be technically excellent. You should go deep, and you're the person that knows the most about the topic.
I actually believe the mistake a lot of people make is that they go so deep on the technical expertise that they forget the organizational surface expectation – eg. the blast radius of impact of what they are doing.
In my view, yes, technical depth is important. But I see a lot of people dropping the ball on blast radius by not impacting the broader organization.
The reason why I chose blast radius, and not only high impact, is because there are different shapes of blast radius.
You can have an impact on something that's deep, that almost changes how a product line works. Or, you can create a new platform, a new library or something that is going to make everybody else more productive, all the engineers are going to know who you are or the tool, the innovation you made.
Blast radius is the thing that you have to keep in mind in this first expectation for staff-plus. Again, it’s usually a red flag if you are only working on projects that only involves a single team or repo, and never expanding beyond that.
’s fantastic article called "Beyond Staff Engineer"For having a High-Blast Radius, I honestly don't care how technical you are; I care about the blast radius impact of what you work on.
It can be a blast radius that is super wide and affects the whole company, or it can be super deep in one area that almost revolutionizes how the product operates and has profound implications on that particular business area.
On both angles, you impacted the company as a whole if you were able to fundamentally change how things were done in a product or product line; or improve the revenue or cost structure or the customer experience of the broader company.
Look for ways to make a high-blast radius impact from a business perspective.
2/ Multi-Scale Planning: Ability to Influence
Many people talk about the importance of Big-Picture Thinking, emphasizing that staff engineers should focus on the next two to three quarters. I agree with that.
Where I see a lot of people dropping the ball on is understanding how those long term plans and visions come into play. How do they translate into actionable steps?
Keep reading with a 7-day free trial
Subscribe to Level Up Software Engineering 🚀 to keep reading this post and get 7 days of free access to the full post archives.