Breaking the Staff Engineer Ceiling pt. 1
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.
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?
As you move up on the ladder, you go from knowing what you will do in the next few hours to knowing what to do in the next few weeks to eventually the next few years.
For example, at the Principal and Director Level, you're expected to be a year or more ahead planning the roadmap, removing risks, etc.
At every level I see a lot of people who don't understand how to cascade things from the day to the week to the quarter in how the organization dynamic actually works.
The graphic below outlines how we go from Offsites → OKRs → Planning Meetings → Monthly OKR reviews → Weekly Team Syncs → Daily Work & Meetings.
Multi-scale planning was an idea I first encountered in David Allen's "Getting Things Done," where it's described as the Horizons of Focus. I later came across a similar concept, the Horizons of Perspective, in the fantastic "Building a Second Brain" course by Tiago Forte (@fortelabs).
Highly effective staff engineers excel in multi-scale planning, even though this skill is often not explicitly outlined in career ladders.
These engineers understand how to anticipate project needs, such as foreseeing the necessity for additional resources or preparing pitches for the CEO. They adeptly navigate different time horizons, ensuring that visionary ideas are grounded in reality and aligned with organizational structures.
They are not only thinking about the next few years of visionary ideas, but also how they will work with/within the organizational structure to make those ideas a reality.
A common mistake made by seniors
One common mistake among senior engineers is over-reliance on short-term solutions. That often looks like an intense two-week projects to solve some of the biggest organizational problems single-handedly.
This approach is unsustainable, and can lead to burnout.
Instead, most of the time, our focus as staff-plus engineering leaders should be on sustainable planning, balancing immediate tasks with long-term goals, and integrating these plans within the organization's framework to achieve lasting success.
3/ Ownership: Autonomy Level / Deliver Results
The third key staff-plus expectation is Ownership. Ownership is another organizational expectation that, again, is not usually clear on a career ladder or matrix.
Where I see a lot of people get this wrong comes back to the idea of implementers, solvers, and finders.
The canonical article called "Implementers, Solvers, and Finders" outlined the differences between these types. Here’s an excerpt:
Do you find that most of your time is simply closing tickets, and your team rarely considers your input? Your title is Solution Implementer.
Are you given general problems and left to your own devices on how they’re fixed? When brainstorming, is your input considered by your teammates? You’re working as a Problem Solver.
Are you given near-total autonomy in choosing what you work on? Can you tell your boss “That’s an interesting idea but my time would be better spent elsewhere” (and not get fired on the spot)? You’re a Problem Finder.
At the start of one's career, you are an Implementer, tasked with executing specific instructions and replicating given solutions, examples or patterns. You are given a TASK and "the HOW" to do it.
As you advance to a senior level, you become a Solver. Someone gives you a problem, and you go and you figure out how to solve it. There is not clear HOW.
The next critical level is the Finder. Not only do you solve problems but also anticipate and identify future priorities and challenges for the organization.
This is someone that is not only solving different shapes of problems, but is someone that's thinking ahead of time, and is finding the next priorities, the next things, the next set of problems that the organization needs to focus on.
Common ownership mistakes
A common mistake I see is that some professionals stop at being Solvers. They never transition into the Finder role, perpetually remaining a solver.
The other common mistake I see is that some Finders become untethered to the reality of actually resolving problems. They move into 100% finding problems mode, throwing them over the fence to others: "There is this problem here… We're going to get blocked here. etc." And they don't help any further. That is not true Finder.
In reality, you never entirely stop being a Solver or Implementer.
The most effective Staff Engineers are not only able to go back and forth on the different horizons of time, but also roles and levels of ownership.
They move back and forth between implementing, solving, and finding as needed. If there is no one to delegate tasks to, they take on the solver role. When implementation is necessary, they step in to execute on tasks.
Mastery in these dynamics ensures your effectiveness and value within an organization.
Driver: The missing ownership level
A staff-plus engineer it is not only someone that implements, solves or finds new and existing problems, but someone that is able to drive key projects to conclusion.
A driver is someone that knows when to step in and dive deep, vs just watching from the outside. It is someone that is there as a safety net for the organization making sure the priorities are still being reflected or slightly adapted as reality sets in.
A driver is the person that might prioritize that incomplete database migration while slow rolling a big project because they know that once the migration is complete everything will be easier.
As a driver, you aren’t doing project management quite in the same way an engineering manager is doing, but you're almost an executive that is trying to make sure all the important things are getting done.
Action Items:
If you feel stuck in your career, or just overwhelmed with all the theories around how to move to the Staff-Plus level, these action items are for you.
Let’s dive into some really practical ideas for Blast Radius, Multi-Scale Influence, and Ownership that should help you unlock that staff-plus level in your career. 🚀
Also – stay tuned for part 2 next week where we are going to be discussing critical behaviors that distinguish high-performing Staff-Plus Engineers from their peers that help them scale their impact and influence in a sustainable way
You won’t want to miss it!
1. High Blast Radius Impact
Here are some questions to ask yourself:
Are you working on projects that are actually going to move the needle and create a huge blast radius of impact across the org, or you're working on "feels-good snack-tasks"?
What was the last initiative you worked on that extended beyond your team or your codebase? What was your most impactful deliverable in terms of blast radius?
Side-note: Will Larson has a fantastic article on this topic called Work on What Matters where he talks about among many things avoiding snacks, and stop preening & chasing ghosts.
Snack tasks may offer quick wins and a sense of accomplishment, but they often lack significant, long-term impact. To make a meaningful contribution, you need to intentionally steer toward projects that cascade across the org, affecting not just your immediate team, but other parts of the business.
Now, reflect on your recent projects.
What was the last initiative you worked on that extended beyond your team or your codebase?
What was your most impactful deliverable in terms of blast radius?
These are the kinds of endeavors that have a deep or broad impact on the business or product. They might take longer to materialize, but when they do, their effects are far-reaching. This level of impact often requires stepping back, thoroughly evaluating the scope, and resisting the urge to jump straight into solving smaller, less impactful problems.
Continually ask yourself whether your current work aligns with high blast radius outcomes.
While smaller tasks are sometimes necessary to keep things moving, your long-term focus should be on finding and executing on projects with substantial influence. Look for gaps in your current approach where you might be prioritizing easy wins over transformative results, and adjust accordingly to ensure you're contributing at the highest possible level.
2. Multi-Scale Planning Influence
Here are some questions you should be asking yourself:
Can I work ahead of time to add things to the annual roadmap, influence stakeholders, or negotiate dependencies?
How am I influencing my department with my vision?
Can you work ahead of time, like planning dependencies, helping to shape the roadmap for the year?
Can you work a quarter or like a half (6 months) ahead of time? When have you done that?
How are you influencing the department and your group beyond your squad with your vision?
To operate effectively at a staff-plus level, it's essential to build your ability to influence long-term planning and vision. This requires working ahead of time, anticipating dependencies and helping to shape the annual roadmap.
This requires more than just executing tasks; it means aligning your projects with the organization’s broader goals, influencing stakeholders, and negotiating across teams.
If you can successfully work a quarter or more in advance, shaping not only your team’s focus but also contributing to the overall strategic direction, you’re functioning as a high-impact engineer.
To do this, you need to influence both your department and stakeholders with your vision. Ask yourself, how often do you proactively add items to the roadmap or ensure your dependencies are addressed in other teams' backlogs?
It’s not just about technical solutions but about aligning initiatives with business priorities and helping guide the future direction of the organization. This ability to see the bigger picture and bring others on board with your ideas is what sets a staff engineer apart.
As a staff engineer, you need to understand how the next year's priorities for your company don't come out of the blue out of the CEO's mind on Dec 31th. They are extremely predictable if you are paying attention to the right rituals and to the right people.
Learn how company-wide priorities are set and how they cascade from leadership down to your team.
Your ability to influence this process can greatly impact the organization’s direction. Whether it's advocating for a re-architecture or pitching a new technology, the skill of shaping discussions and building alignment around your vision is critical.
If you are not doing it yet, start to use your one-on-ones, write proposals, and continuously influence peers and leadership to ensure your vision is part of the roadmap for the coming year and beyond.
3. Ownership & Autonomy Levels
Here are a few helpful questions to think through:
What is the percentage of my time I'm working as an Implementer vs. Solver vs. Finder vs. Driver?
Is this the ideal allocation for my next level? If not, how can I get closer to that?
You need to be careful with that ratio. Because if you are 100% as an Implementer, or 100% as a Solver, you're not going to get through staff-plus impact and influence.
Staff engineers need to spend more time as finders and drivers—proactively identifying issues, risks, and opportunities that others may not see.
Really stop and ask yourself: What percentage of your time is allocated to each of these roles? Be honest, if you're spending most of your time as an implementer or solver, it's unlikely you’re reaching the level of impact necessary for staff-plus.
Consider whether your current role-ratio allocation is aligned with the expectations of the next level. At higher levels, you need to take ownership of finding and driving initiatives that shape the roadmap, influence cross-functional teams, and unlock new opportunities for the organization.
Sometimes, short-term priorities require a heavy focus on implementation, but over the long term, the ideal balance shifts toward finder and driver activities should be there.
To move closer to that next level, you must deliberately shift your focus with an intentional calendar to cultivate the skills necessary to take on more ownership and autonomy.
Focus on building the skills and behaviors associated with higher levels of ownership and influence. Regularly ask yourself: What is the highest-leverage thing I can do this week or month to maximize my impact across the organization?
The key to achieving staff-plus is mastering the balance between solving problems and proactively driving initiatives, all while developing the autonomy to shape the future of the organization.
Well that’s all for this week.
Thanks so much Thiago for diving deep and sharing your insights on staff-plus expectations. I personally learned a lot! 🙌🏼
As always, you don’t have to wait until next week to hear from me. You can catch me daily on LinkedIn where I talk about everything software engineering, startups, and growing in your engineering soft skills.
– Caleb
 | A guest post by
|