This is Part 2 of a two-part series.
My last post was about actionable steps mid-level software engineers can take to become senior software engineers. This time around, I’ll share some steps you can take to go from senior to staff.
I didn’t say it explicitly before, but I think being a senior engineer is about being a leader within the engineering organization; staff engineers, by contrast, bring that same focus and attention to all organizations throughout the company. They act as expert-level liaisons between engineering and design, product, and other teams. With that said…
Become a technical expert
The primary expectation of a staff-level engineer is deep technical proficiency. One of the steps I mentioned for becoming senior was to “share the knowledge”. That should continue to include small things—various learnings, brief posts about “why I’d like to make these changes”—but staff engineers also need to tackle issues of ever-increasing size and scope. Architectural changes, large refactors, introducing patterns or dependencies.
Your company may or may not have a formal culture around these things, but even if it’s not explicitly required, I strongly recommend writing things down and putting them out there.
Communication skills become increasingly important as you move up the engineering ladder, and writing is one of the main ways you’ll communicate. Writing helps you think through complex problems and serves as invaluable documentation. I once wrote up a spec on how we should reorganize the file and folder structure of our codebase. It explained the benefits of the proposed approach, why I chose one pattern over another, and the steps needed to get us from A to B. The team was able to review it, weigh in, and once I had buy-in, I completed the work through a few focused PRs.
Make yourself available
Mentorship is a key component of being senior/staff. It’s common for people to continue spinning their wheels rather than ask for help, but you can be proactive. When a team member says they’re blocked or struggling during standup, try asking, “Want to jump on a call after this meeting?”
One way to bring junior engineers into the fold is to involve them in areas where you’re the domain expert. Did you recently refactor your codebase’s state management and now a bug has popped up? Offer it up to another engineer and let them know you’d be happy to pair. As the more senior engineer, who’s most familiar with that bit of work, you could likely fix it faster on your own, but that doesn’t help your team grow.
As an aside, this approach avoids information silos. When only one person understands a critical piece of code, it becomes a black box, and that’s risky if that person moves to another project—or another company altogether.
Find ways to collaborate
Regardless of what department they’re listed under on the org chart, staff-level employees effectively belong to the whole company. They’re expert engineers/designers/project managers who can interface with other departments on behalf of their own.
Working on a design system—if you have one, or creating one if you don’t—is the ideal way to collaborate with designers. Think about your company’s product the same way your product team does by asking thoughtful questions during requirements gathering and refinement. When non-engineers think of “someone from engineering”, you want that someone to be you.
If you’re in the middle of your engineering journey and looking ahead, I hope these guides offer some practical steps you can take to level up your career.
Top comments (0)