Mailbag: Evolving your engineer career beyond the career level.

career (37), staff-eng (14), mailbag (12)

Recently I got an email asking about evolving your engineering career after you’ve hit the career level, but before you feel like you’ve accomplished what’s important to you. Here’s the lightly edited email:

I’m a mid-career engineer with experience in the technical, management, and leadership tracks. I find it challenging to continue leveling up. I’m working on it, reading articles and books, but it’s hard, sometimes, to know what to do next. My network in the Bay Area is small because I moved from Mexico, how do you recommend finding people that can act as role models for Staff/Principal engineering roles, and do you have any frameworks/books/resources you recommend for building technical roadmaps?

This email came at a good time for me, because I’ve been spending more time time reflecting on the lack of support and structure for folks in what I’m calling “staff-plus” engineering roles. There are books like The Manager’s Path that explain the engineering manager’s career, but few high-quality resources for engineers.

There are a few different topics in the note, that I’ll approach in order. First, what are resources for continued development? Second, how do you find (and ideally meet) staff engineer role models? Finally, any resources for developing technical roadmaps in particular?

Resources for continued development

Each job is going to develop your career in different ways, sometimes with deep technical learning, sometimes by developing your network, sometimes by accumulating the universal lubricant known as “prestige.” The most effective way to develop yourself is to align your current role with the dimension you’re looking to build on.

If your focus is on developing your technical and technical leadership capabilities, then your best bet is to find a company which needs this sort of work, typically a company that doesn’t yet have senior engineering leadership in place or whose rapid growth is creating frequent new gaps to address.

As each of those gaps widen, they turn into “staff projects.” These are projects that are considered complex and important enough that the person who completes them should be considered a staff engineer. Most folks become staff engineers through the completion of at least one staff project. The best way to continue developing yourself is to successfully deliver staff projects, this is true even if you’re part of the project rather than the project leader.

The other angle of developing yourself through doing is to take on broad responsibilies. This might be designing and leading an architecture group, defining the organization’s development process, or formalizing mentorship for engineers earlier in their career at your company.

Continue to take on staff projects and broad responsibilities, get them to a steady state over a one to two year period, and then transition them to someone else who can learn from them. This will foster development across the organization, and allow you to move on to learn new things yourself. (I don’t think you can move on sooner than 1-2 years, because maintaining and operating the thing you built is a key part of the learning.)

I do believe it helps to supplement this learning-through-operating with learning from the outside, and some recommended readings are:

For more, check out my favorite books and papers.

Finding role models

The easiest way to meet these folks is joining a company that’s large enough to have an existing community of staff-plus engineers. You don’t have to work there forever, but working at an Airbnb, Facebook, Google, Netflix or Stripe will leave you with a permanent network of these folks. Similarly, it takes a certain scale to routinely generate staff-level projects (all companies have some staff-level projects), which means that the rate of staff engineer creation is also higher at these sorts of large companies. This makes you more likely to meet folks making the same transitions that you’re working on.

If joining such a company is practical, don’t dispair, you can still organically develop your network. I’ve previously written up my approach to meeting people, and I’ve found that it basically works if you put in the required work.

In terms of being a bit more concrete, I brainstormed a list of some folks who I think are great role models for this sort of work. The best known folks are generally the least productive to reach out to, because they’re already getting a bunch of inbound requests, but hopefully they’ll serve as inspiration for the sort of roles and folks you might want to reach out to:

There are, without a doubt, bunch more amazing folks out there, these are just a few examples!

Developing technical roadmaps

The final question was around developing technical roadmaps, which I find a somewhat challenging question to answer because “technical roadmap” means such different things across companies. I’ve rarely seen any company write an explicit technical roadmap, which is a shame because I think they’d be very helpful.

My best advice is to write an engineering strategy (Magnitudes of exploration is one example), combine it with a protected project budget reserved technical investment (talk, blog), and build your roadmap by resourcing the projects identified by your strategy with that protected budget.

This is definitely a topic that folks frequently ask about, so I will brainstorm if I have something more useful to say.