In this Guide you will learn:
How you can advance your technical career without becoming a manager
What non-technical skills you need to foster to help your team thrive
How to grow as a leader in staff+ roles
Management isn’t the only path you can take as you grow your software development career beyond the role of senior engineer. If you want to remain a technical individual contributor (IC), you can pursue a role as a staff engineer, principal engineer, distinguished engineer, or similar—roles that are often referred to as “staff+” level. But even though these aren’t management roles, you’ll still be expected to be a leader.
As a staff+ engineer, or a senior engineer looking to advance, you should be a force multiplier both within your team and in the larger organization. At this level, it’s not enough to just write great code. You need to level up the people around you by enabling them to work more effectively, both on their own and with others. One important way to do this is to help foster a collaborative culture at your organization.
In recent years, more and more organizations have realized that a culture of collaboration is much more efficient than one full of silos. Movements like DevOps and site reliability engineering (SRE) have brought in different lenses for encouraging collaboration between developers, operations and infrastructure engineers, security personnel, and even the product and business side of things. Organizations must find ways to make their engineering environments more collaborative or risk losing both market share and employees to competitors.
A collaborative culture can’t be created by a mandate from the executive team. Culture is created by what individual people do day to day: The IC engineers’ practices will determine if a culture is collaborative or not. To that end, staff+ engineers can be instrumental in creating this type of culture by guiding team and organizational behavior in terms of goal setting, decision making, feedback gathering, and organizational learning.
Support organizational goals
If you don’t know what you’re aiming for, you’re probably not going to achieve it. Making sure everyone has a clear picture of their individual, team, and organizational goals is key to reaching them, and leaders should ensure that those different levels of goals don’t conflict with each other. As a staff+ engineer, you need to understand the big picture of what your organization is trying to accomplish over the next six to 12 months in order to ensure your team’s work supports these goals.
For more product-centric development teams, this might be fairly straightforward: Someone makes a decision about new products or features that they want to release to customers, and those teams execute on building and releasing those features. For teams that are in supporting roles throughout the organization, such as operations and security teams, their work may not align so directly. Ops teams who manage infrastructure—regardless of what customer-facing features are deployed on that infrastructure—can often feel like they exist outside their organization’s larger goals.
If you’re a leader on one of those supporting teams, you need to make sure your team understands how their work can support the overall organization and product goals. For example, if a company sets a goal of growing their customer base, an ops or database team can make sure that the infrastructure is set up to handle increased load, proactively working to address potential bottlenecks or scaling issues before they become customer-facing problems. Or, if the development teams are trying to cut down on the number of bugs that get released into production, the infrastructure team can find ways to help support those efforts such as adding test infrastructure, creating a more usable pre-production environment, and so forth.
This type of work means talking with adjacent teams to figure out what their goals are and how you can help them reach those goals—which may mean defining what they actually need and not just what they say they want. While more junior engineers might be in the habit of fulfilling requests exactly as they come in, those at a higher level should be thinking critically about the requests your team receives, how various requests interact with each other, and how those requests relate to the larger goals. For example, if you’re getting multiple requests from various people or teams to spin up VMs or test environments for them, maybe there’s some shared test environment or self-service VM provisioning process that would make life easier for everyone.
Make decisions effectively
At any reasonably-sized organization, you’re going to have lots of different people with lots of different ideas about how things should be done. A staff+ engineer can help their team and organization find ways to make decisions that strike the right balance between arriving at a conclusion quickly and making sure they’ve considered all the possibilities.
There are two extreme ends of the decision-making spectrum, and organizations of any size can fall into either of those traps. On the one hand, the process can be too top-down, hasty, or overbearing. This might look like a small startup where the technical cofounder makes every single decision themself with no room for argument, or an enterprise where everything is mandated by the C-suite. Decisions might be quick, but this method risks option bias, and often leaves the rest of the company feeling like their voices don’t matter. On the other hand, you can end up with consensus-style decision-making that drags on and on forever, leading to debates that never end, or people who are afraid of speaking up if their opinion is in the minority. Neither process is good for making decisions effectively.
There’s no magic wand that can make all these problems go away, but there are some things that can help make the decision-making process less painful. First, document your current process. Try and define which decisions can be made by one individual, and which require some sort of buy-in or approval from others. Create templates for RFCs or design documents that can help standardize how your team thinks through large-scale technical decisions. Set deadlines for when and how a decision will be made in advance. This might look like: “I will leave this RFC open for comments until X date; if nobody has objected to the proposed solution by then I will begin implementing it.” This way, you know how and when you’ll move forward instead of languishing in uncertainty forever.
The “disagree and commit” principle is sometimes used by organizations that want to look like they’re giving everyone’s voice a chance to be heard, but in reality they’re falling into more authoritarian decision-making processes. However, the principle is worth keeping in mind: You do want to have an organization where people have enough psychological safety to speak up when they disagree with something. A staff+ engineer can help foster this by facilitating group discussions, shutting down harmful disagreement styles such as personal attacks, and making sure that the loudest members of a group don’t dominate.
An organization without disagreement is either a hive-mind or one where some people have given up on trying to participate. You also want an organization that gets things done (not one where you discover that all your competitors have passed you by while you were still picking colors for your bikeshed). Staff+ engineers should be empowered to move a team forward if they’re getting stuck, while still making sure that there’s room to course-correct if necessary.
Iterate on feedback
With few exceptions, organizations don’t end up with ineffective decision-making processes because they love arguing. They are motivated by an often-reasonable fear of making the wrong decision, of wasting time working on something that turns out to be the wrong thing. While I’m not recommending that you start making decisions by throwing darts at a Gantt chart or yolo-ing everyone’s first ideas into production, it’s crucial to be able to make decisions knowing that you will be able to evaluate sooner rather than later and then pivot if necessary. To do that, you need to collect and act on feedback.
It is well known that long feedback loops and slow development cycle times don’t work in modern engineering environments. There is a reason that we’ve moved away from the waterfall method and towards more agile development methods. Being able to effectively collect, process, and act on feedback in a timely manner is key to having an organization that can keep up with the pace of the world. This includes getting feedback not just on development progress and customer satisfaction, but how your internal processes are working and how employee happiness.
As a staff+ engineer, you will need to plan and organize project work in a way that builds in feedback loops at every step. This starts with identifying owners and stakeholders and including them throughout the process—you can’t know that you’re building the right thing if you don’t know who you’re building it for and why. Then, make sure you don’t paint yourself into a corner as the work progresses. Start with a proof of concept or MVP that can be evaluated at the early stages of work. Have regular development milestones and check-ins with stakeholders to make sure everything is on track; if requirements change on either end, you’ll want to know that sooner rather than later. Be sure to architect your work in forward-looking ways. For example, write your software so that logs and metrics are modularized rather than hard-coded. This way, if your team changes how they handle logging and observability in the future, you can change the contents of just that module—rather than unpicking the details out of the entire codebase.
Leaders within the team, including both ICs and managers, should help their teammates work this way as well. Have regular 1:1s with the more junior members of your team and help them think through asking for and receiving feedback on their own work. While a staff+ engineer might have regular meetings with leaders on other teams to keep up with changing goals and requirements, engineers with smaller scopes of work should be doing the same thing, perhaps with stakeholders within their own team. This is all in addition to the basics like having regular standups (whether synchronously or not) and performing reviews of code and planning docs.
As with making decisions, there is an element of psychological safety at play when it comes to soliciting and acting on feedback. If people don’t feel safe in their work environment, they aren’t going to speak up if they think something is wrong. Developing ongoing relationships with team members, making sure to call out and discourage counterproductive behavior, and creating an environment where mistakes are not punitively punished can help create an atmosphere where people are more comfortable taking risks—whether that means speaking up or testing a new solution.
Learn as you go
Soliciting feedback won’t do you any good if you don’t ever act on that feedback. If you create an MVP of a product and get early feedback from customers, find out they don’t like it, and keep going with your original designs, you’re still going to end up with a product that customers don’t like. You must change course when needed, which can be tricky because changing direction often means admitting that your initial direction was at least a little bit wrong—and in a culture without psychological safety, people don’t want to be wrong about anything.
Staff+ engineers can lead by example. Perhaps the most straightforward way of doing this is admitting when you’re wrong. Ask questions in public Slack channels rather than DMs. Speak up when you don’t know something. Respond to questions that others ask in channel, and make sure to respond in a way that’s helpful rather than condescending. For starters, follow the “No Feigning Surprise” rule. As a staff+ engineer, you aren’t expected to know everything, but you should be expected to build a culture where learning is encouraged.
In addition to learning at an individual level, it’s also important to facilitate learning at team and organizational levels. One great way to do this is through post-mortems or retrospectives. The key here is to not punish people for making honest mistakes or speaking out about them. If people are punished for admitting they made a mistake, you aren’t going to create a culture where nobody makes mistakes. Instead,nobody will ever own up to anything, and you’ll be in the dark about how to avoid said mistake in the future.
Instead, practice blameless post-mortems where people are free to explain their experiences without fear of punishment or retribution. The thing to look for is an understanding of why people acted the way they did. Start with the assumption that nobody comes to work with the goal of causing problems on purpose, and go from there. Staff+ engineers can help with post-mortem facilitation, engaging in dialogue to find out the reasoning behind various actions or decisions. You might find out that your documentation is incorrect, or that some default CLI option is destructive, or that you have different goals working in conflict with one another—but if you don’t find out why things happened, you have very little hope of fixing them next time.
Balance is key when it comes to learning from and responding to feedback. On the one hand, you don’t want to never change course: That way lies the stagnant ruts of “but we’ve always done things this way,” which are blockers of organizational learning and progress. On the other hand, you don’t want to turn into the organizational equivalent of a chicken with its head cut off, changing major goals and initiatives so often that you never actually complete any meaningful amount of work. It can help to set regular cadences for reviews to try and help strike that balance, like weekly team sprints and quarterly reviews for organizational goals.
Parting thoughts
Collaboration is a key part of any modern engineering culture, and as a staff+ engineer, it is your responsibility to help shape the culture of your team and larger organization to be a healthy and collaborative one. Stay on top of team and organizational goals to ensure you’re all moving in the right direction. Work towards decision-making processes that give people a chance to be heard without needing to get 100% consensus on everything. Foster an environment of psychological safety where team members are comfortable giving and receiving feedback, and where people can talk about and learn from their mistakes. All of these elements combine to create a culture where individuals and teams can work and learn together in order to move towards their shared organizational goals.
