This isn't a skill issue in the traditional sense. It's a *learning* issue. The gap between what these tools can do and what most engineers extract from them has never been wider. And that gap is growing faster than knowledge can spread.
Season 2
We’re rebooting the Staff Engineer podcast with a specific focus: practitioners using AI to deliver valuable outcomes with specific examples
This season is in production, episodes are coming soon!
Season 1
Conversations with software engineers who have progressed beyond the career level, into Staff levels and beyond. We discuss the areas of work that set Staff-plus level engineers apart from other individual contributors; things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. Hosted by David Noël-Romas (@davidnoelromas) and Alex Kessinger (@voidfiles).
Episodes
One of the things that I've learned from the show and that I've tried to take away and try to sort of model in my behavior is like, take a step back, make more space, let more people talk, listen a lot more and just be humble.
The difference between context and control is not in the first sentence. The difference is in the paragraph that comes afterwards and in the fact that there's often a question at the end of that paragraph that draws the other person into the journey.
Oftentimes the biggest dysfunctions in a team are a lack of alignment around a clear strategy and lack of values alignment.
The role to me is really about ensuring that everyone around me is successful, to try to make sure that the work that we are doing is aligned with what the rest of the organization needs. And really just to be out in front of things to try to think six to 12 months ahead of where we're going and make sure that that work is going to line up with what the rest of the Org needs from us.
As you go up higher, the idea of that's not my responsibility, like goes away. It's like in theory anything can be your responsibility. Like even if it's not in my domain of front end development, like it can still be my responsibility to try to at least get the right people in the room or what have you to get this problem solved.
I think a lot of this is just about talking to people. That's it. And when I say talking to people, I mean listening to people.
The thing that makes me a staff engineer is not that I have any particular knowledge, it's that I have a really wide breadth of knowledge.
I use the skills [of a manager] every day... as a staff engineer, you might not be managing people, but you're influencing people and working very closely with people.
There's three key words to always say when it feels like someone is objecting to what you're proposing: Tell me more.
The highest leverage stuff here is communicating. Because if you make if make it really clear to people why we decided X or why we want to keep this in mind, then we basically kind of empowered them to understand where the business is coming from and where the technical leadership is coming from, but still make the right decisions on their own.
Leading without authority. Ideally, having everyone step back and reminding them of the goals of the project is the best first step.
No one ever made a decision based on a number. They need a story.
I am a doer and I like to do things and I have to get used to not doing things but asking other people to do things. And so delegating and then helping them through that because you don't just want to drop a bunch of stuff on their plate and it actually, you know, that helps you scale and then you can rely on that person to kind of pick that up the next time.
Fear can prevent good things from happening, but fear can't prevent bad things from happening.
Engineering is a means to an end, not the end. So focus on what you're doing.
If you ignore the product direction, if you ignore what's making money, if you can't find some way to align the work you're doing or help frame the work that other engineers are doing in the context of what is delivering value, I think you're going to be less effective.
30 years of experience tells you a lot about, like when you're not ready to code something, right? And a lot of folks, especially younger folks, are going to. You're going to get the requirements, doc, whatever the design thing looks like, and you're just going to plow right into it and start coding. And it's important to know when you're not ready, it's important to be able to step back and say, you know what, I'm not exactly sure how I'm going to do this.
Mentoring people is probably the best thing you can do. If you want to have great senior staff and staff engineers in your org, protect your time to mentor.
The main idea about being staff engineer is scale yourself. It's not something that there is you, you cannot be replaced. You just some unique diamond in the team. If you are scale yourself, make other people diamonds as well.
One of the things I'm having to get used to now, especially growing into my role, is that some of the stuff I just have to delegate and not everything is up to me to take on to fix.
What I try to do is solve problems that have maximal impact, that can only be done by me. Every pull request, commit whatever I make, if I was to create an issue for this instead, would this get done in a reasonable time frame by someone else?
The higher impact you have at the company... the higher you will usually go. It's not about necessarily how technically awesome you are... It's more what you are enabling, how you're enabling others, what kind of multiplicator effect you're having in the company.
