One of the most challenging transitions in a software engineering career is the shift from Senior Engineer to Staff Engineer. It is not merely a promotion to the next level but a role change. The functions are different, and the scope of work tends to be broader. While levels beyond senior are not new in the industry, there is no consensus on the responsibilities of these roles.

To better understand the definition and expectations of this level at VTEX, refer to the Staff Engineer (L4) section of our career model, Becoming a Driver.

Typically, engineers promoted from Senior Engineer (L3) to Staff Engineer (L4) at VTEX have become indisputable references within their teams and have significantly contributed to cross-team initiatives. However, many of these cross-team efforts are driven by business necessity rather than by personal planning. Once promoted to staff engineer, tackling broad-scope challenges becomes part of the job description. If engineers do not intentionally allocate time for this, they will not meet the expectations of their role.

One of the primary challenges for a newly promoted staff engineer is stepping away from their team's day-to-day routine, where they are a key reference, to focus on broader-scope problems requiring their attention.

An unintuitive fact is that to have the freedom to perform this new role effectively, you need to become unnecessary to your team. However, unnecessary does not mean useless. It means you will keep contributing, but the team will be able to operate by itself. You will continue participating in technical discussions, implementing relevant features, and being involved in planning and critical decisions. However, most of the feature deliveries will no longer rely on your time, and the team will be capable of handling most issues and crises without involving you.

This transition is not simple.

In this article, I will share insights from my journey of stepping back from the Catalog Team at VTEX, highlighting key decisions and actions I took. This transition must be intentional and supported by the management.

If you have been promoted from Senior to Staff Engineer at VTEX, you are likely to be one of the main technical references in your team. This does not necessarily mean you are the most experienced person, but you likely have the most context about the product and the greatest ability to solve complex problems. In other words, you are the go-to person for questions and crises.

As long as you remain the sole reference, your team will always turn to you, leaving you with no time to focus on broader challenges. Your team needs new references, individuals capable of answering most of the questions you currently handle and implementing most of the solutions you used to develop.

You must trust in the potential and capabilities of others. Just as you became a reference after someone else, others can follow in your footsteps. Improving your delegation skills is an important step in your Staff+ journey.

However, you cannot wait for these references to emerge organically. You need to actively foster them by sharing as much knowledge as possible and deliberately developing your team members. This benefits them, the company, your career, and your mental health.

There are several ways to achieve this, but I will highlight a few that worked well for me:

Training Sessions

Over several months, I conducted weekly training sessions for the Catalog Team. These sessions covered the team’s modules, their interconnections, interactions with the platform, system architecture, key configurations, common problems, and solutions. These sessions included hands-on examples, accessing infrastructure, navigating code, and exploring dashboards and logs. The sessions were recorded for later viewing. Attending the live session allows you to join the Q&A.

A key strategy was inviting team members with deep knowledge of specific topics to lead some of these sessions instead of me. This helped them develop communication and knowledge-sharing skills while allowing the entire team (including myself) to learn from one another.

Reverse Shadowing for On-Call Support

When VTEX introduced on-call rotations for engineering, most Catalog Team engineers relied on me during incidents. I realized that I was, in practice, on-call every week becoming a bottleneck in the process. This was happening because people were afraid of making mistakes in high-pressure situations.

To help new on-call engineers build confidence, I started acting as a reverse shadow. This meant I was available to provide guidance but would never directly intervene. The engineer handled the situation with my supervision. As a result, the team quickly gained context and experience. Soon, those who had gone through this process with me began mentoring newer team members in the same way.

Avoid Answering Every Question

It is instinctive to answer questions on topics you know well or to handle incidents you can quickly resolve. However, it is essential to reduce your response rate over time. If you answer every question quickly, the team members do not grow, do not seek to learn, and will always expect you to take responsibility.

Let the team handle questions and issues. Get involved only when explicitly requested.

If someone asks for help privately to answer a question or handle an emergency, assist them, but let them take ownership of the response or resolution. This approach fosters independence and increases the team’s visibility within the company.

Do Not Be the First to Speak in Technical Discussions

In technical discussions, when the primary reference person states an opinion first, only a few people will challenge or propose alternative solutions. Allow others to share their perspectives before you contribute.

This does not mean you should withhold your opinions; rather, wait for others to express theirs first. This process might be frustrating, especially when someone suggests exactly what you were thinking. In such cases, acknowledge your agreement. No one will doubt you. You have already earned your status as a reference.

Let others shine and develop independent thinking. Healthy debates often bring out the best solutions, something that might not happen if you speak first.

Do Not Get Involved in Every Topic

Once your team has exercised its ability to solve problems, you will feel much more confident in their capabilities. Not every issue requires your attention.

This does not mean that some problems are beneath you. You can engage with any challenge, regardless of complexity. However, you must find the relevant issues and recognize that your team can handle many issues without your direct involvement.

Ideally, your time should not be considered in regular sprint deliveries. While this is challenging, it is achievable. A more practical approach is to commit only 50% of your time or avoid tasks with strict deadlines. This allows flexibility to address broader-scope challenges.

To achieve this, align with management. Managers and senior leaders must support this shift, understanding that broader-scope work is part of your role and the best use of your time.

This transition can be gradual but should have a timeline. Managers excel at planning. Ask for their support, especially since team delivery expectations must be adjusted to account for your reduced involvement in daily tasks.

That said, do not take this approach to the extreme. There will always be moments when your team needs 100% of your attention, and you should be available in such cases. Even with new references, you remain a key leader. As a Staff Engineer, you are a role model for those aspiring to this position, and your team must feel they can rely on you when needed.

Working on broad-scope problems is a core responsibility of a Staff Engineer, and making time for it requires intentional effort. It is essential to develop people to take on your responsibilities and align with management to position yourself where you will have the most impact.

Your journey will be unique, whether at VTEX or another company, but I hope this article helps you navigate this new and uncertain role.

I would like to thank Rafael Bacelar, Isaque Lima, and Rodrigo Zaccara for their valuable contributions to this article’s review.