Staff Engineer

The four common archetypes of Staff-plus roles I encountered are:

Most importantly, an organization needs roughly one Tech Lead for every eight engineers, making it far more common than other archetypes.

The most effective Staff engineers pair a moderate amount of mentorship with considerably more sponsorship: putting your thumb directly on the scale to help advance and support those around you.

The first place to look for work that matters is exploring whether your company is experiencing an existential risk. Companies operate in an eternal iterative elimination tournament, balancing future success against surviving until that future becomes the present. If you’re about to lose one of those rounds, then always focus there. Running out of money, like my experience at Digg, can be the most obvious issue, but not every existential issue is financial, like Twitter’s fail whale stability challenges or adapting to the shifts caused by the Covid-19 pandemic. If something dire is happening at your company, then that’s the place to be engaged. Nothing else will matter if it doesn’t get addressed.

There is almost always a great deal of room to do this sort of work that no one is paying attention to, so you’ll be able to make rapid initial progress on it, which feels like a good opportunity to invest. At some point, though, you’ll find that the work needs support, and it’s quite challenging to get support for work that a company is built to ignore or devalue. Your early wins will slowly get eroded by indifference and misalignment, and your initial impact will be reclaimed by the sands of time.

Hiring has a lot of folks involved in it, usually in terms of optimizing the hiring funnel, but onboarding, mentoring, and coaching are wholly neglected at many companies despite being at least as impactful as hiring to your company’s engineering velocity. If you start dedicating even a couple of hours a week to developing the team around you, it’s quite likely that will become your legacy long after your tech specs and pull requests are forgotten.

You realize that you’ve rehashed the same discussion three or four times, it’s time to write a strategy. When the future’s too hazy to identify investments worth making, it’s time to write another vision.

A few recommendations as you write:

Best advice for writing a strategy document is:

For a useful vision, a few things to focus on are:

Just as your company’s technical quality bar will shift over time, your approach to managing technical quality will evolve in tandem: fix the hot spots that are causing immediate problems adopt best practices that are known to improve quality prioritize leverage points that preserve quality as your software changes align technical vectors in how your organization changes software measure technical quality to guide deeper investment spin up a technical quality team to create systems and tools for quality run a quality program to measure, track and create accountability

When you’re rolling out a new practice, remember that a good process is evolved rather than mandated.

However, as you look at how software changes over time, there are a small handful of places where extra investment preserves quality over time, both by preventing gross quality failures and reducing the cost of future quality investments. I call those quality leverage points, and the three most impactful points are interfaces, stateful systems, and data models.

Your fundamental tools for aligning technical vectors are:

Some representative components to consider including in your quality definition:

Along with the shift in mindset, there are a few techniques that I’ve found helpful in creating more space in discussions:

On the other hand, it’s hard to transfer your judgment to someone else, particularly around complex decisions. Fortunately, it’s possible to take an incremental approach to shift increasingly complex and important decisions to your wider team.

I’ll share what’s worked for me as an introvert who struggled to craft an authentic approach. Find someone you respect and send them a short 1-2 paragraph email or DM with a specific question asking for advice. If they reply, thank them and send another question in six to twelve months. If they subsequently ask you for a favor or question, do what you can to help. If they don’t reply, don’t worry about it; just move on without comment. This works surprisingly well, and the worst thing that can happen is totally fine: they’ll just never reply.

The foundation of communicating effectively with executives is to get a clear understanding of why you’re communicating with them in the first place.

Controlling the sequence in which you present your ideas is the single most important act necessary to clear writing. The clearest sequence is always to give the summarizing idea before you give the individual ideas being summarized. I cannot emphasize this point too much.

I’d particularly recommend every document’s opening paragraph follow the SCQA format:

Anyone who tells you that you must complete a Staff project to reach a Staff-plus title is wrong: there are many avenues to reach Staff-plus titles without doing a Staff project, with a stint in engineering management prominent among them.

Each of these projects is different, there are a few typical characteristics that capture why they’re so effective at stretching you as an engineer:

To get into the room, you need:

Sometimes the easiest way to increase your value to the room is by decreasing the cost of including you. Some of the approaches that work well are:

There are a few patterns that will consistently get you kicked out of the room:

Sometimes that isn’t enough, though, and some other strategies are: