The Staff Engineer Difference

So many engineers struggle with the transition from Senior to Staff. What is the difference? and how can you get there? Spoiler alert: It's not about lines of code.

The Staff Engineer role is a significant milestone in any engineer's career. Although I have written previously about the entire Software Career Ladder, this post will focus on the transition from Software Engineer to Staff Engineer. I struggled with this transition, and often see engineers on my team (and even managers) grappling with it.

Expectations for all Engineers

Before we talk about Staff, let’s level-set what’s expected of any engineer. As an individual contributor, you write code, solve problems, deliver features, maintain operational excellence, and triage issues in production. Those are the expectations and they should be things you discuss with your lead on a regular basis. That’s the bar.

I programmed for years and still do to this day. Should a VP of Eng code? It’s complicated but I’ll cover this in a future post.

As your experience grows and your track record of delivery grows you’ll be entrusted with larger tasks, more ambiguous problems where the solution is not quite obvious. You’ll have to make tough decisions between bad and less bad outcomes. And some of the expectations on you will be less obvious. I’m going to talk about these in detail as these ambiguous expectations and how you rise to them are what will distinguish you as a Staff engineer.

Some engineers you “just know” they have something different. What is it? People often use the overloaded term “Leadership” but what does it mean in practice? Let’s compare a Staff Engineer with a Senior Engineer for a given situation.

Example #1: Architecture Improvements

A Senior Engineer on a service or API team might advocate for an architecture change like bringing in GraphQL. That’s a great idea! They might bring this idea to their manager and articulate it’s advantages and even prototype how it might be used. This puts the burden of carrying it forward on their manager, who may be dealing with other issues. As a result progress from here on might be slow, or the idea may stall altogether.

With the best intentions they might drive on, thinking that’s the right thing to do. They contact the vendor, arrange a demo, and maybe even stand up a proof of concept. This all sounds great, look at all the strong initiative this person has displayed right? There’s danger here - without bringing people along with the solution and considering all the implications of this choice it can become a huge problem to unwind. The result is the engineer thinks they did great work and it’s the organization’s fault for not supporting it.

It’s not about lines of code. It’s about the right lines of code and in many cases…it’s not about the code at all.

A Staff Engineer takes a proactive approach to promoting GraphQL (in this example) within the organization. They might arrange a Tech Talk to discuss the technology with the team and then reach out to other teams to get their input. From there they would facilitate a deep dive to weigh the pros and cons, they would drive the team to a consensus decision and then present findings to their leadership in the form of a end to end proposal. In the proposal they would articulate the problem, the options and the recommended solution holistically and project a few years out to show how GraphQL aligns with the larger engineering direction (e.g. moving to micro-services) and explain how it would impact the developer workflow at a team level. They would also ensure that it aligns with Ownership and Operational Excellence, and consider how it might be managed in production over the long term, highlighting any negatives with the choice, such as vendor lock-in or service discovery and how these could be mitigated. They'd also consider how it might impact authentication, network ingress, the standard service caching patterns, and how these could be solved. They would consider the compute costs. Are there skillset mismatches? They’d include the impact on client development teams and even involve them in the decision-making process. They’d include an open and frank point of view on “reasons not to do this” and be transparent about any drawbacks. These are just a few examples of the broader multi-dimensional thinking an experienced engineer might bring into the equation.

Finally, they'd socialize all of this throughout the organization and ensure that all stakeholders, including financial stakeholders, are considered in the decision to adopt GraphQL.

Same idea, two different approaches with two very different outcomes.

Example #2: Risk Management

Let's consider a different example; A team faces a scalability challenge, where surges in traffic often overload their service. A Senior Engineer might work with the team to address the issue by implementing better service alarms for timely notifications. They would proactively analyze the infrastructure and consider moving to a different instance type in AWS or GCP. They might initiate load tests and collaborate with the team to ensure all changes are reviewed during design. They might even implement a distributed cache to minimize traffic to the origin. These are all excellent ideas and actions that have a significant positive impact on the team. They distinguish the Senior Engineer from an Engineer.

The Staff engineer may consider any of the aforementioned solutions, but a Staff engineer should also take a large step back and re-evaluate the situation. Will any of the solutions truly address the scalability issues of the service if the traffic grows 10x or 100x? Even if the service can be scaled, this may create negative downstream effects that shift the scaling problem from the API to the datastore. Perhaps the synchronous requests involved in this flow are the wrong approach altogether? Maybe the ideal long term solution is to handle requests asynchronously, in a queue. That’s thinking laterally. How can we achieve this with minimal impact and ensure that this is the correct solution before investing in it? Finally, how can we socialize this idea and gain momentum in a collaborative way that aligns with the team's delivery schedule?

Again same problem, two different approaches, two different levels of effort (acknowledged) and of course two different outcomes.

I hope these examples illustrate or hint at some of the differences between Staff and Senior Engineer in terms of how they approach a problem, how they manage risk, how they collaborate and how they up-level the team over the long term. It’s a nuance but an important one. I hope it also illustrates the dramatic differences in value that each approach brings with it.

In these examples you may notice the Staff Engineer is consistently taking a broader view, considering the organization as a whole, bringing people together, and taking their input. Macro-level direction changes need to be collaborative and can rarely be achieved by fiat. When the Staff drives the conversation (and when the conversation is the right one) three things happen:

1. First, the best solution is arrived at by taking everyone’s input.

2. Next, the team feels heard, included, and bought into the solution, allowing its smooth execution. Momentum for the choice grows across the larger group and this is usually essential to large-scale changes like the ones mentioned above.

3. Lastly, the reputation, personal brand and influence of the Staff Engineer grows. This last is an important point that cannot be overlooked. When you act like a Staff…people know you as a Staff, whether you have the title or not and when it comes time for the leadership to review your Promotion it’s over in 60 seconds.

What can you do today?

Ok, so how can you change your thinking, pull it up a level, and start exercising some of these “Staff Engineering” level muscles? Here are a few ideas to point you in the right direction.

1. Organizational awareness: Look across your team. If you don’t know what everyone’s working on, that’s a red flag. Start building your network. Talk to people in other teams, maybe they’re working on things your team can utilize. Think about your place in the org. Are you the last to know about something? and if so why is that?

2. Problems: Where is your team struggling? Are there issues in production? Are developers wasting time on boiler plate activities? Are deployments failing or constantly being rolled back? Is the team using the right tooling? Are you bringing in ideas from the industry or are they reinventing what’s available in the Open Source world?

3. Productivity: Is your team’s velocity and efficiency growing quarter over quarter or are you perpetually adding to technical debt? What can be done? Have you spoken to your manager about it? Have you brought not just problems but ideas and solutions to the table for discussion? (a junior person highlights problems, a senior person highlights problems AND offers solutions and an outstanding person …just takes care of it ;) )

4. Team: How is the team dynamic? Are people talking to one another? Does everyone understand the bar? Culture - is your team inclusive? Does everyone have a mentor?

5. The Future: Are you thinking two or three quarters out? Are there risks waiting to turn into huge fires? (we called these “dogs waiting to bark”). When’s your team’s seasonal spike? What are the new things your business will need but hasn’t asked for yet? What’s the industry doing? Are there open standards emerging related to your field? Are you being left behind?

Each area offers an opportunity to lead, take ownership and model the way. Staff engineers don’t wait, they take initiative and are self-directed but in a way that is inclusive and up-levels the whole team.

The Ideas Anti-pattern:

When you start down this path there’s something critical to keep in mind. Everyone has ideas. Ideas are easy. Not everyone delivers. Delivery takes influence, grit and ownership to see it through. Don’t be the ideas person who constantly offers criticism of what the team should or should not be doing. Joel Spolsky calls these people Architecture Astronauts - they’re out there in space, waving their hands around. It takes Ownership and Leadership to deliver on the ideas. Ideas are the easy part. Delivery is hard.

In this post I’ve purposefully avoided this notion of the 10x engineer - that’s a confusing term and much has been written about it. It might be a nice headline but personally I don’t think helps.

Stay on the Path

Maybe you’ve read this as a Senior Engineer and said “yeah I am doing ALL of that, why aren’t I a Staff by now???”. Take heart, if you’re on the path it will happen for you and when it does it will feel amazing. Stay on the path. Nothing will kill a career quicker than being promoted too early.

If I don’t get there have I failed? Hell no! A team needs a blend of skills to be successful. In no way do you need to attain Staff level in order to have a successful career. The worst thing that could happen to you would be achieving the Staff level title without truly understanding the expectations of the role. I’ll write more on the Dangers of Early Promotion in a future post.

If you’ve read this far I hope the delta between a Staff Engineer and a Senior Engineer is starting to become clearer. I hope the examples I’ve given however simplistic will give you some ideas to help you pick up on the nuances in your own team.

Caveat; this post is based on what I’ve experienced personally and what I’ve seen in the industry. Your experience may differ and if so I’d love to hear about it in the comments. Have I missed something fundamental? Are my expectations too high? too low?

I get to work with amazing people at every level who I reach out to for ideas and help every day. Some are Staff but not all. That’s ok. Everyone has a contribution to be made and it takes everyone pitching in to make ideas come to life. It’s not about lines of code. It never was. It’s about the right lines of code and in many cases…it’s not about the code at all.