3 Steps To Demonstrate You Are Up For Staff Engineer Role

Act as the role you pursuit, and then the promotion will come

Jan 28, 2026

One of the biggest and most complex questions we all have is:

What can I do for getting promoted for the role I want?

If you are working in a tech product company, with around 800 or 1K employees, you have to know that you will not get a promotion just because “the time came”.

👉🏼 Instead, you have to demonstrate you can do the job before getting promoted.

I will not discuss here whether this is a good practice or not. It’s just the reality.

In today’s email, I will focus on the journey to the Staff Engineer role, and I will share with you 3 actions that are a must for you to get promoted to Staff Engineer.

The prerequisite here is to catch the opportunity to lead a project. In my experience, this can happen in two ways:

This opportunity can come to you from upper management. For example:

Silvia (you), there is a project for reducing costs in our obserbability system, and I want you to lead it.

Or you build the opportunity. For example:

Hey Barbara (your manager), I’ve validated a POC for feature teams own and deliver their own infrastructure, which will make them 2x faster to production with the same quality than today.

In the real world, this last one takes more time than just a sentence like that, but I hope you see the point.

Once the opportunity is on you, these are the 3 actions I found successful in many cases for the person get promoted to Staff Engineer.

Ownership end-to-end

You are THE person for a project, from the beginning to the end.

As simple as it sounds. You will be the person whom managers will ask in case they have questions or require information.

You clearly understand the problem and the expectations of the stakeholders.

You are responsible for everything on the project. If you have dependencies, you will have to manage them and coordinate the priorities across all of them.

To be able to get the full level of ownership, I start asking this 3 questions as many times as I need to really feel I have control of the project.

1️⃣ What is the problem we want to solve?

What are the use cases?
What is the pain?

2️⃣ What’s the benefit for the company?

Is it cost saving, efficiency, reducing incidents in production…?

You have to know the priorities at the company level, so you can align the solution in that direction.

3️⃣ Who is the customer and what are the dependencies?

This could be either the customers of the company or internal customers, like developers, marketing, etc.

If you are praying for not having dependencies, sorry. If the project is meant to be done by a Staff Engineer role, for sure, you will have dependencies… and most likely outside of your organization. But this is good in the sense that, once you succeed (because you will 😉), you demonstrate you can coordinate with external people and coordinate successfully.

Communication

Oh dear, this is the most important part of this framework; Bring visibility to your stakeholders and managers.

You can communicate at any time:

When progress
When blockers
…

☝🏼 Overcommunicating is better than a lack of communication.

Ensure you understand how your stakeholders like to get communication, such as:

When (daily, weekly, …). I would recommend you start weekly and, if your sta
The format. I usually like to be precise, using the framework:
- TL;TR
- Context
- Current status
- Next steps
Via email, Slack, meeting, Confluence page, …

🎁 At the end of this email, I give you a Pro Tip about communication. But, for the moment, let’s continue to the last point of this framework.

Plan

You most likely prepared a plan to deliver work for your team before reaching this big project. The idea here is the same, but on a wider scale, including your external dependencies.

1️⃣ Brainstorming / Kickoff

Join your team and your dependencies (if possible), and explain the project. Also, prepare a brainstorming session for the key problems of the project. This will bring ownership from all.

This part could sound easy, but it could become tricky because you may face some people that generates noise or hijack the session (most likely with no intent to). Polish your human skills to sail the brainstorming session to your north star and so achieve your goal:

Communicate.
And get feedback.

2️⃣ Technical Story Mapping

This is something that you will find very useful. I have pending an email for a deep dive into Technical Story Mapping. Until then, I can tell you this is an exercise on which:

Identify the categories of work.
The work to do on each category.
Prioritize the work.
Coordinate with your dependencies.

The previous brainstorming is really useful for this.

I like the tool Miro for Story Mapping, but you can use any other tool that allows you to print “boxes, stickers, and text”.

3️⃣ Continuous sync

For this, return to the part I wrote about communication, because it’s the same, but with a difference: here, you don’t need (or want) the stakeholders.

This is more for the Workforce or Virtual Team (however you call it) that will work on the project you lead.

The format I like the most is a Weekly Ops meeting for the project, where you:

Explain where we are.
Check the status of your dependencies.
Identify blockers, and the owner who can solve them.
Next steps

✨ Summary

Let’s wrap up for today.

Promotions to Staff Engineer are not about tenure, they are about demonstrating you can already do the job.
The journey starts by leading a meaningful project, either assigned by leadership or proactively created by you.
Success at this level requires three core actions.
Take full end-to-end ownership, from problem definition to delivery and dependency management.
Communicate early and often, giving visibility into progress, risks, and next steps.
Create and execute a clear plan that aligns teams, dependencies, and priorities.

The key idea is simple: act like a Staff Engineer before you get the title.

Don’t forget about the Pro Tip! 👇🏻

🎁 Pro Tip

For every single meeting you have during the development of the project, you should:

Prepare an agenda with the goal, context, and expected outcomes.
Once the meeting ends, reply with the meeting notes and action items (a meeting without action items is a waste of time, meaning that an email could solve it).
Record the meeting notes and action items in a place where you can get back to them in the future, in case you have to remember a decision.

This saved me a couple of times already, mainly when someone comes to challenge your plan when you are in the middle of its implementation.