Many engineers become focused on the Staff-plus career path because the engineering manager path has too many meetings or requires too much collaboration with other coworkers… and woah are you going to be surprised if you begin a Staff-plus with that mindset. Although Staff Engineer roles are generally positioned as the sequential step beyond Senior Engineer, it’s genuinely a different role and you’ll increasingly spend your time doing sorts of work that you previously did infrequently or not-at-all.
The role’s work also has a much slower feedback cycle. The delayed feedback can initially feel quite demoralizing as you replace the visceral coding REPL with the uneven progress of mentorship, relationship building, and strategy. This chapter discusses the work you’ll be doing instead.
In the interviews for this book, as well as my own experience leading and coaching Staff-plus engineers, a handful of topics kept coming up as keystones of personal development. They aren’t everything you’ll do in the role, but they are the places where you’re most likely to have an outsized impact or accidentally commit a career-limiting move.
- Stay aligned with authority to remain an effective leader over time.
- To lead, you have to follow. Having a vivid sense of how things ought to work is a powerful leadership tool, but it's also essential to learn to blend your vision with the visions from your peers and leadership.
- Learn to never be wrong and you can spend less time cleaning up mistakes and more time having an impact. Comes with the added benefit of fewer folks complaining about you to your manager.
- Create space for others so that your team grows stronger than your contribution.
- Build a network of peers to vete difficult decisions, and to give you honest feedback when your role's authority starts to temper feedback.
- Work on what matters to make the most of the working hours you have, particularly as you get further along in your career and life's commitments expand.
- Writing an engineering strategy [WIP] to guide your organization’s approach to supporting your company’s business objectives with its architecture, technology selection, and organizational structure.
- Curating technical quality [WIP] to maintain the quality of your company’s architecture and software as it grows and tacks over time.
As you deliberately practice in each of these areas, you’ll slowly progress from the newly minted Staff Engineer towards the trusted organizational leadership. That said, these won’t cover everything you do. At times you’ll find your role surprisingly similar to that of an Engineering Director, and at other times strangely familiar to previous work in your career.
That extraordinarily broad remit is part of what makes describing these roles challenging, and if there’s a particular topic you’re focused on that’s missing, check out the Additional resources for learning appendix.
But will you still write software?
It would be impolite to end this introduction with addressing the very first question that Staff Engineers ask each other when they congregate into a room: “Do you still find time to write software?” The answer is, of course, it depends!
Ras Kasa Williams said,
I still contributed code regularly—certainly less than the rest of the engineers on my team; but it was important that I sustained "hand to keyboard" work to ensure that my technical strategy (and other macro–level decision–making) was informed by the on–the–ground experiences of the rest of my team.
Katie Sylor-Miller said,
I’m a frontend architect, but by far the main thing I've been writing lately is SQL, because I'm doing a lot of data analysis. I’ve been looking at our performance metrics to figure out where the areas for improvement are, and what would be the most impactful issues to fix to improve performance and business metrics. I will write little bits of JS or PHP here and there, but it's mostly to help unblock teams or to run small performance-related experiments, or if there is something important that needs to be done but other folks don’t have time for.
Dmitry Petrashko said,
On a perfect week I’d spend Monday, Wednesday and Friday in meetings or working groups: either 1:1’s or team meetings, collaborating on plans & strategy, both short term and long term. Tuesday and Thursday of my perfect week would be spent coding alone. In reality, depending on team needs at the time, I may end up having more meetings or more time coding.
Silvia Botros said,
I don’t do coding for the business anymore. I think the last time I had to pull up my terminal it was to refactor my dot files. This is an intentional decision by my boss, the Chief Architect. He’ll check in with us every quarter to make sure we didn’t contribute any code that goes into production.
Bert Fan said,
I might spend time prototyping concepts that will almost certainly be thrown away or gathering usage metrics around a particular user flow to better understand how to improve the system. I will often build apps on top of the Slack Platform to keep myself honest about what the developer experience is actually like and actively try to build on other people’s platforms to see what works and what doesn’t. A lot less of the code that I write makes it into production than other engineers at the company and I’m completely fine with that.
Joy Ebertz said,
The more senior you get, the less your job is about code. Sure, unlike a people manager, you still have a very technical slant and even through principal, you’ll likely be doing at least some coding. However, the higher you get, the more your job becomes about mentoring and growing the people around you (and more broadly), building your team through building your company’s public tech brand, noticing larger technical trends that can be improved upon or corrected, helping to set the tech vision for your team or the company and advocating for resourcing for tech debt projects.
Stephen Wan said,
Notably, it's hard for me to guarantee anything longer than a day at a time spent writing code. I don't get counted when we consider engineering roadmap bandwidth, though I do try to reserve at least a day a week for writing some code.
So, we’re back where this section started: it really depends on both you and your company.