Becoming a staff software developer is a significant milestone in a developer’s career. This role is often seen as the bridge between hands-on coding and higher-level strategic responsibilities. It’s a position that requires not only technical prowess but also the ability to influence, guide, and lead a team toward success.

If you're reading this, you might already be a staff developer looking to refine your approach, or a senior developer aspiring to level up. Either way, understanding the intricacies of this role is crucial. In this post, we'll delve into the role, breaking it down into three key areas: Expectations, Skills, and Pitfalls.

We'll discuss the often vague and variable expectations that come with the territory, and how to transform them into concrete actions that drive success. We'll explore the essential skills that differentiate great staff developers from the good ones, focusing on both technical abilities and soft skills like feedback and consensus-building. Finally, we'll highlight common pitfalls to avoid, so your journey goes more smoothly than my own.

In this post, we will focus on “Expectations.”

This article is the culmination of my thoughts on this role, informed by my 20+ years of professional software development experience. This is the article I wish I had read 10 years ago. Don’t be overwhelmed by all the ideas and possibilities. Feel free to take what makes sense for you and leave the rest.

Now, let’s dive into a list of expectations I have observed and see how this can make us better staff engineers.

Defining the Role

The role of a staff software developer is one of the most fluid and variable positions within a tech organization. Unlike more junior roles, where responsibilities are clearly defined and outcomes are straightforward, the expectations for a staff developer can often be nebulous. Each company has its unique culture, structure, and needs, which means that what is expected of a staff developer at one organization can be quite different from another.

A staff developer is often seen through idealized caricatures— the hero coder who can solve any problem single-handedly, the strategic thinker who can align technology with business goals, or the mentor who shapes the next generation of developers. While these images can be informative, they are also unrealistic and inaccurate in isolation. The true value a staff developer brings depends entirely on how well they adapt to their specific company’s context and needs.

Given the vague nature of this role, it’s crucial for a staff developer to take proactive steps to align their skills and contributions with specific company needs. This starts by turning nebulous expectations into concrete action. This is especially important for new staff developer hires, who are often faced with a completely new landscape, challenging their assumptions about the role and forcing them to level up their skills and influence. This process involves continuous dialogue with managers to ensure alignment on what success looks like.

Without this alignment, there is a risk of misunderstanding the role, leading to a breakdown in trust, or worse, dismissal for non-performance, despite strong performance in other areas. It is the full responsibility of the staff developer to bridge the gap between an ambiguously defined role and the behaviors and actions that define a successful staff engineer in those specific circumstances. Circumstances can even change within a company, depending on the specific team or division. Regular check-ins with managers can help clarify expectations and ensure that both parties are on the same page. Being proactive in seeking feedback can avoid problems later.

Proactively defining your role as a staff developer allows you to drive the conversation in a way that works for you, either towards your strengths or to building your skills. Don’t let the ambiguity deter you. Pretending those expectations don’t exist sets you up for surprises later on.

Seek Feedback, Not Validation

The need for a staff developer to seek feedback or help in any form can be seen in conflict with the unspoken expectation that staff developers should just intuitively know what they are supposed to do, needing help from no one. That a staff engineer should always know the answer and be self-sufficient is another unhelpful caricature. The truth is that not knowing is part of the job. Pretending to know, when you don't, leads to the equally unhelpful "impostor syndrome."

"Impostor syndrome" is a transition stage every developer goes through until they reach a point when they trust themselves and no longer require outside validation. When a staff engineer seeks validation from a manager who knows less about the role than they do, the advice they will receive will be close to useless. This can be extremely frustrating when you are the most senior member of a team, as you have no one to turn to or to get a signal on how you are doing. It feeds any sense of insecurity you may be nurturing.

Yet, insecurity as a feeling is an important signal. It simply means that you do not yet trust yourself or your judgments. Seeking validation from outside is futile and only erodes the trust of those who are leaning on your experience and judgment. Trusting yourself is not knowing everything or being able to do everything. This is impossible. Trusting yourself is knowing that no matter what is thrown your way, you can figure out a way to handle it.

I clearly remember as a teen learning how to drive, worrying about getting myself stuck in a situation where I could not get myself out. In particular, tight parallel parking situations made me very nervous. I remember practicing and getting pretty good at it, but it still made me nervous. Eventually, I realized that if it's a tight spot, it's usually best to just find another parking spot farther away and walk, rather than trying to squeeze into a difficult situation. Knowing what to avoid is perhaps more important than the skill itself. Just like in driving, a software engineer is faced with a new set of situations daily. Knowing you can navigate around and away, as well as through, any situation you face will help you start to relax.

When we indulge our "impostor," we act like we know when we don't. We act like we are capable when we are not. Pretending prevents us from getting the help we need and leads to bad judgments as we hide our insecurities. The way out of this is to focus on skills that can build your confidence that you can handle any situation you encounter. Here are some examples:

• Asking for help or requesting a second opinion. Remind yourself that no one has all the answers.
• Using data to drive decision-making and building your modeling skills. Human judgment is inherently suspect, so use data to check yourself.
• Admitting you don't know, then following up with a timely answer.
• Saying no to technical decisions you, or your team, are not yet comfortable with, then following up with what it might take to bridge the gap.
• Practicing asking for feedback on specific skills. Rather than asking how you are doing to compensate for your insecurity, focus on building skills that will shore up your inner confidence.
• Rather than blaming circumstances for the challenge you face, instead focus on what you have control over and notice what things you can do that would make a difference. You often underestimate how much control you actually have.
• Seeking feedback from peers or mentors on specific skills, such as mentoring, giving or receiving feedback, or learning new strategies for consensus-building; these are difficult to learn on your own, and a good mentor can help.

The caricature of the staff engineer who has all the answers and whose vast experience will help the team avoid all danger is neither realistic nor helpful. Only by admitting our limitations can we start to seek the answers to the situation at hand. By building these skills, we can build the confidence that we can handle anything that gets thrown at us. No staff developer has mastered every skill they need, so it’s important to not pretend. Take the initiative and get the information you need to improve.

Working Autonomously

A hallmark of the staff software developer role is the high degree of autonomy and responsibility it entails. Unlike more junior positions that often require close supervision and guidance, a staff developer is expected to operate independently, making significant decisions and driving initiatives without the need for constant oversight. The staff developer may actually be the one providing supervision and guidance. This level of autonomy is both a privilege and a critical aspect of the role, requiring a unique set of skills and a deep sense of accountability.

Being able to work autonomously can come as a shock if a developer assumes this role without preparation. Moving from a highly structured setting to one with seemingly no rules or limits is challenging and is best mastered with a supportive manager or mentor. If you were someone who struggled to create structure for yourself while working from home during the pandemic, then you can relate to the feeling of a new staff developer.

The caricature of the autonomous developer is the idea that they always know just what to do and seem to be in the right place at the right time without being asked to. Staff developers are the ones who step in to handle complex issues that don’t have a clear owner, ensuring that these problems are addressed before they escalate. While this describes a strong staff engineer, this caricature is unhelpful because it hides the actual behaviors that make these effects possible. You are expected to identify problems that fall through the cracks, prioritize them effectively, and take the initiative to resolve them. That is easier said than done. Working autonomously is actually a skill you can build.

If working autonomously and holding yourself accountable is a challenge, consider working on the following activities:

• Creating successful structures and routines, especially for things that always fall through the cracks.
• Being honest with yourself about your productivity and having an objective measure for keeping you honest.
• Using timers to provide focused blocks of time.
• Having rituals to start and end your day. For example: At the end of your day, write down three things you want to accomplish the next day. Review that list the next day.
• Having regular check-ins with a colleague or your manager to help with accountability.
• Creating visibility for the work you are doing. Nothing is more demoralizing than feeling like your work isn't seen, or doesn't matter.
• Reviewing your week by asking yourself probing questions such as:
  • “What is my team’s priority?”
  • “What is my division’s priority?”
  • “Did my week align with those priorities?”
  • “Did my team align with those priorities?”
  • “Am I aware of any balls getting dropped?”
  • “What structures can I put in place, or actions can I take to handle this ongoingly?”

Creating the accountability to be productive when no one is watching is a skill you can build. Without it, you will struggle to find the motivation to keep going.

Creating Structures

With all of the information, ideas and changes happening, it's easy to get lost in it all. Trying to juggle all of that in your head results in missed opportunities and a lack of focus. It's a constant challenge to keep up with priorities that seem to change constantly. Here are some ideas of structures that have worked for me.

One method I use for prioritization is a spreadsheet to track all my current, planned, and potential projects. This includes potential technical investments that require a business case before proceeding. I list these items and rank them using a simple formula. I use a modified RICE score to prioritize based on the following criteria:

• Reach: How many people are impacted by this investment?
• Impact: What is the potential impact? Is it trivial, or revolutionary? What is the ROI?
• Confidence: How confident am I that the project will be successful or completed on time?
• Effort: How many sprints will it take to achieve success?

Based on these criteria, the list is sorted from the highest score to the lowest. I have found this approach helpful in preventing distraction by new ideas and ensuring focus on initiatives with the highest likelihood of success.

Other ideas you can consider:

• Schedule regular 1:1s with colleagues to check in on goals and priorities. Discussing these openly can be a huge source of accountability, and can generate feedback and support.
• Schedule regular retrospectives on projects and major issues that arise. These are great ways to gather ideas on how to improve things. Assign and follow up on action items generated during the retro.
• Regularily groom and review your backlog and bug tracker. I'm always surprised by the patterns I see there. As circumstances change, these items need to be reprioritized.

The huge productivity of staff developers is more likely attributable to carefully crafted structures than to natural talents or gifts. Shying away from putting these structures in place is understandable, as it usually entails facing difficult realities and situations. But this is exactly where the opportunity lies. Don’t miss out!

Laying a Foundation of Trust

With autonomy comes the need to build and maintain a high level of trust with management. Trust is the foundation that allows staff developers to operate independently and make impactful decisions without being second-guessed. Without this trust, the benefits of autonomy can quickly erode, leading to micromanagement and a reduction in the effectiveness of the role.

The very existence of the role of staff engineer implies a high level of trust. This is taken for granted, and when it’s lost, you will find a lot of unwanted attention. This can happen for a variety of reasons, such as a project blowing up in scope or a catastrophic failure. It’s important in these situations to not panic or get defensive. Trust can be rebuilt, but only if you are willing to take responsibility for the situation as it is. From that place, you can work to improve the situation.

Communicate

Consistent communication and transparency build trust. Evasiveness and surprises break it down. Staff developers should regularly update their managers on progress, challenges, and successes. This not only keeps managers informed but also demonstrates accountability and reliability. This regular communication also helps to ensure that your team is aligned as priorities can frequently change.

Do What You Say, Say What You Do

If you say you’re going to do something, it’s expected you will do it, unless you communicate otherwise. Some people refer to this as “follow-through,” but I find that term vague and unhelpful. It’s easy to promise something in the moment, but those words can come back to haunt you later if you are loose with your word.

For example, your manager confronts you about the growing backlog of bugs, and you say you will get on it. Your manager appears satisfied, and you breathe a sigh of relief. This is a defining moment for you as a staff engineer. What happens to the words after you have said them will determine the level of trust your manager has with you.

Keeping track of everything you say is not the point. Prioritizing the many things you are responsible for is daunting, but it’s expected that you will. And if you don’t get to something, the minimum expected level of professionalism dictates that you communicate as soon as you know it’s not going to happen.

This was a hard lesson for me. At a certain point in my career, I had to face how difficult it was for me to balance all the competing priorities, and telling people what they want to hear in the moment and forgetting about it later did not work, to say the least. The number of things you need to balance and handle is overwhelming, and it takes time to build those structures. A good mentor or supportive manager can help. Having what you say and what you do match up is a solid foundation for building trust.

Make Informed Decisions

Another element of building trust is ensuring your decisions are well-informed. Checking with stakeholders to make sure their concerns are addressed. Backing up your decisions with clear reasoning and solid data can help your decision-making. Decisions aren’t about being right. It’s about making the best choice based on the best information you have available at the time. Even if your decision is a bomb, knowing that you made the best choice at the time can go a long way when answering to concerned stakeholders.

Documenting the decisions you make, when and how those conclusions came about helps you make better decisions in the future. It also builds trust. Covering your ass is just a nice side benefit.

Aligning Actions with Unspoken Expectations

Rookie mistake is to wait for your manager to clarify expectations. Don’t hold your breath, it won’t happen unless you take the initiative. The expectations are vague and nebulous, but you are nevertheless being evaluated on specific and mostly uncommunicated signals. It sounds unfair, but it’s the reality of the role. Most likely your manager has never been a staff engineer, which is why they are a manager instead. They likely have only the caricature of what a staff engineer does, and they are pattern matching you to see how you measure up. Don’t be surprised if your manager doesn’t seem to get it or has unrealistic expectations. It’s an unfortunate part of the dynamic. Either your manager just gets it, or they have unrealistic expectations, or they let you run amok, unable to challenge you on anything.

This is why you have to take the initiative. Otherwise, the odds are against you. There aren’t many managers that get it. If you drive the conversation, you can start to dispel the misconceptions of what a staff engineer does and start to build trust in the relationship. Find out what your manager needs and what they think is important. Communicate to them what you think the priorities are. Work together to make it happen.

Even with great communication, it’s possible that further unconscious layers of expectation exist. Even though they are unspoken, you are likely being evaluated based on those criteria. This shows up as a “gut feel” for managers, and if you try to get specific feedback from them, they won’t be able to give you anything helpful, and it may even make them uncomfortable. Do not let this deter you. And by this, I don’t mean to keep pestering your manager. They may lack the skills or experience to help you. Seek out a mentor. A well-phrased question to a peer can be a gold mine of insight.

Other things you can consider in these hidden realms are expectations regarding cultural fit, leadership style, and the ability to navigate organizational politics. Understanding and meeting these unspoken expectations requires keen observation and proactive engagement with your team, management, peers, and mentors. Pay attention to the company culture and the values that are implicitly promoted. Notice how decisions are made, how communication flows, and what behaviors are rewarded. Align your actions with these observations to ensure that you are not only meeting explicit goals but also fitting into the broader organizational fabric. If you can identify a pattern in your company that you think represents an expectation, bring that specific thing up with your manager. It will no doubt be helpful. Building strong relationships with your peers and other staff engineers at the company, they can help you uncover these unspoken expectations. Seek feedback from colleagues and mentors who understand the company’s dynamic. Their insights can help you make the necessary adjustments to lead in your role.

By aligning your actions with unspoken expectations, you build trust at a gut level. It seems like magic until you realize all of the hard work that goes into establishing yourself in a company culture.

Setting Objectives and Goals

As a staff engineer, you are expected to not only set your own objectives and goals, but for your team and division as well. This can be disorienting for someone who expects to be given specific objectives. This is made even more difficult because the business is constantly giving you new objectives and goals. It can seem like a contradiction, but these two things work very well together in practice.

Business objectives are always there, and you are expected to turn those objectives into results. This is easy to understand, and if you need clarity, you just ask your manager. Your manager and other executives in your company are very good at knowing what the business objectives should be. But what they aren’t good at is knowing what the “technical objectives” should be. That’s why they hired you, and you are expected to both define those objectives and execute them without needing to be asked or supervised.

This is very hard to grasp for anyone not in this role. It doesn’t seem clear which is more important. How do you decide what you should be working on? The truth is that the company is depending on you to execute both. The company knows what the business needs are, and they are relying on you to tell them what the technical needs are. And they want them both. That’s your job. And as with many aspects of this role, it’s easier said than done.

Developing the skill of prioritization is key. You likely have lots of ideas on potential technical objectives. You might even have a list of them. How do you decide which is the highest priority? How do you communicate that priority to your managers? How do you get your projects resourced? Each of these questions is a challenge in and of itself. It’s a skill to be able to build the consensus needed. And without trust, you will unlikely be successful. This balancing act is critical to your success as a staff engineer.

If you have ever had the thought that “someone should fix that,” this is the domain of the staff engineer. For less junior developers, it seems like magic! How did they get their initiative on the roadmap, while I continue to complain about mine? It’s not magic. The mysteriousness is part of the unhelpful caricature. The reality is that trust has been built with management, and the skills of consensus-building and prioritization are applied. With those ingredients, the magic happens.

Partner with Management to Build Team Competence

A staff developer is expected to work with management to ensure the technical competence of the team. This involves providing mentorship, offering constructive feedback, and helping team members grow in their roles. Your technical expertise should be leveraged to guide less experienced developers, guiding them as they solve complex problems and improve their skills.

You are also expected to identify skill gaps within the team and work proactively to address them. This might involve organizing training sessions, recommending relevant resources, or even leading by example through your own work. By fostering a culture of feedback and

continuous learning, you help elevate the overall technical competence of the team.

Other ways to build team competence:

• Share articles or blog posts related to topics of interest.
• Write a blog post on a topic not widely discussed and share it with the team. A personal blog post is more likely to be read, in my experience.

Additionally, staff developers often act as a bridge between the team and management. This means you need to communicate effectively with both sides, ensuring that the team’s efforts align with the strategic goals set by management. Regular updates and transparent communication with both managers and the team help keep everyone on the same page and prevent misunderstandings.

Happy Manager, Happy Staff Engineer

Your success as a staff developer is closely tied to the success of your manager and, by extension, the team. If your manager is struggling to meet their objectives, it doesn’t matter how well you achieve yours. They both matter, but if your manager is failing, you are failing as well. If you fail, your manager might be able to run cover. Unfortunately, it doesn’t work the other way around. For this reason, you need to make sure your manager succeeds by all means necessary.

Team motivation is often a struggle for managers. Disgruntled engineers and other downers can really make things difficult for everyone. It's a challenge for a manager, who is non-technical, to understand and relate to engineers at this level. This is where a staff engineer can really step in and make a difference. Also, because the staff engineer isn’t a manager, there may be some direct feedback you can give that can get an engineer to snap out of it. The secret to happy engineers is to make sure those engineers are productive. If they aren’t productive, no amount of incentive will make a difference. Using your experience, figure out what it takes to make your team productive. And don’t be shy about giving individuals reality about where they are on the scale of professionalism. Tolerating a lack of professionalism is the same as condoning it. Unprofessional employees have the same feeling as bad sportsmanship in sports. It’s a bad feeling, and it ruins it for everyone.

As a technical leader, you can help bridge the language gap between managers and developers and help them translate the demands of the job into specific goals they can work on. Building up a team of professional and capable engineers is easier for a staff engineer than for a manager. But it’s even better when you work together.

Unfortunately, you don’t always get to choose the managers you work with, and not all managers are great or easy to work with. This is a difficult situation, and there are no easy answers. But remember, if your manager isn’t successful, then it will be harder for you. So do what you can to work with what you have. I know, easier said than done.

Conclusion

Being a staff software developer is a challenging role that extends beyond technical expertise. It requires a blend of strategic thinking, autonomy, proactive communication, relationship-building, and a keen understanding of both explicit and implicit expectations within an organization.

This is just the start. Stay vigilant for unspoken expectations, and feel free to connect with me on LinkedIn if you think I missed something. I hope this post has been helpful for current staff engineers and those aspiring to the role. All the best in achieving your goals and building up your teams.