Increasing Your Sphere of Influence as a Staff Engineer

All right. My name is Ian Schwartz. Welcome to my talk at React Advanced 2024, How to Increase Your Impact as a Staff Engineer.

This is so let me talk a little about who I am. I work at a company called CarGurus. We make a marketplace for, you know, we don't sell cars, but you might sell your car on CarGurus. And although my title is Principal, we don't have a staff title, but Principal is the title that has a lot of the same responsibilities you would typically see in staff and other roles. I've been writing JavaScript in some form or another since 2015. I love TypeScript and functional programming. In fact, most of the talks I've given at other conferences have been about functional programming in TypeScript.

And really, you know, the goal of this presentation, this actually came out of another presentation that I went to where I was kind of hoping for this kind of content. And when it wasn't there, I said this is the talk I have to give. So, you know, we're going to basically give you some actionable tips on increasing your influence as a staff developer. This mainly focuses, you know, this is not going to focus on any relationship where you have direct reports or one-on-ones with people. You know, if anything, the challenge of this role is that we usually don't. So let's talk a little bit about what a staff engineer is. You can see my AI generated memes that I did. So you know, when I think of a staff engineer, it's a really broad definition, and I'm going to fly through a lot of these. But you know, at a very high level, you're supposed to focus on strategic projects of value for the company and level up the team. You want to set the technical direction. You know, what does this mean? You know, it could mean that you want to institute a higher quality of, you know, testing or code review or process. There's a lot of ways that you can go with it, but it's your job as a staff engineer to be the advocate for the company's technology needs, right? In a world where every developer is trying to meet their targets and their deadlines, you know, it's your job to think about, well, how can we make the system more efficient? How can I help them to thrive in this setting without them actually, like, being my underlings that report to me? So there's a lot of mentorship involved. You know, a junior developer who comes on or somebody new to the company, they're going to come to you and you should be able to support them. So you really, it's your job to help people grow. You know, we do a lot of planning. So participating in higher level discussions, you know, making decisions that are time-sensitive decisions in engineering context. What can we commit to? What can't we commit to? These are things I would look to staff engineers for. Prototyping and problem solving and ambiguous high impact challenges. This is a big part of what I do. You know, most of the time you come in on a code base and there's these sort of patterns that have gotten entrenched into the code base.

And I expect the staff engineers to look and see where the inefficiencies are, see where the repeated challenges that people are running into, but not necessarily voicing. This is a staff engineer job to me.

Being the glue. I love this graphic. AI is getting really good. Being glue. A lot of times the staff engineers are the ones to perform the background tasks, like, you know, upgrading dependencies or taking care of technical debt or performing refactors, which are often invisible to the company. You know, ensuring that work is done in the right speed. A big part of what I do at work is about, you know, writing tickets and making sure you write the tickets the right way and the work can be done much faster than if you write them a different way. Right. We think about those things.

A lot of times when you come into a company as a staff engineer, you are expected to write code. And, you know, I asked on Reddit and I got the opinions of the community and almost unanimously they said, oh, if you're a staff engineer, you shouldn't be doing day-to-day sprint work. But the truth is that at a lot of companies you're expected to balance day-to-day sprint work with more, you know, staff-eng type of tasks. And this is really challenging to do. And it's not always obvious how to find the time or make the space to do the more staff-eng jobs when you have day-to-day targets.

But that said, I think it's important to keep your hands dirty and in the code base because, you know, there's one thing to solve high-level problems. But to be able to see those problems, I think it's really important to, you know, know what everybody else is going through. And so a job that had a staff engineer that didn't do any sprint work, I would question how in touch they were with the problems that the rest of the team were facing.

You always have to be learning and doing skill development. I actually think this is how you get to be a staff engineer is if you're doing this already anyway. So a lot of you probably have this checked off. But especially the last point about seeking regular feedback, I truly believe that feedback is something that should be happening from everybody on the team. The most junior developer is just as qualified to do code review as the most senior developer. And you never know what people know or what insight they'll bring or what questions they ask will cause you to see things in a different way. So, you know, lead by example on receiving code review. Be gracious about comments. Be, you know, be willing to really hear people's feedback because that helps them grow. And that's a big part of your job as well, too.

And that's a big part of your job as well, too. Sharing knowledge, staff engineers do a lot of documentation. They do. They tend to do presentations at my company. We have company-specific tech talks that other companies have seen Lunch and Learns and those sort of things. Mentorship and internal training sessions. You know, if you're not doing these things, it doesn't mean that you're not being a staff engineer. But this is just sort of the way the role has presented itself for me. And I think actually helping junior developers grow is is it's just it's so important. Right. Because the seeds that you sow with with people today are going to affect the way the code is written six months or a year from now. So I truly believe that.

Building and leading high-impact projects, you know, big part of being a staff engineer, even though you may be doing sprint work, is also like having projects that you yourself are spearheading. And it's one thing to have technical goals and things that you want to research. But it's really important to make sure that those things are high impact and have value for the company. And based on how well you do this, it's going to really help to help you with the other aspects of being a staff engineer. You know, you need people besides other engineers to notice you and you need other engineers to notice you. So I think that's very important.

Leading design and architecture discussions within your team. Here's a question. Does your team have conversations about, you know, design and architecture? Are you guys thinking about how to structure your code in a way that's going to make it easy to work on in the future and how to design the app in a way and architect it in a way that it's going to stay pliable? And, you know, a lot of teams don't have those discussions. The pressures of day-to-day sprint work are too much to be able to really step back and then think about how do we refactor this or how do we build differently in the future? So I think it's very important to lead those discussions and they should be coming from the staff engineer levels.

Ensure high-quality deliverables through rigorous internal testing and reviews. I really you'll hear me say code review a couple of times in this presentation. I love code review. I think it is one of the best things that we have on any development team I've worked on. And if you don't have it, I you should. But testing is also important, too. I've really spearheaded making sure not just me, my whole team has made sure that our test coverage is some of the highest that our company and it really pays off because not only not only do we have fewer bugs and all the other upsides of testing, I don't need to sell you on the idea of testing. But when you write code that's well tested, the corollary of that is that you're writing better code.

Typically, if tests are painful to write, if tests are the worst part of your job, that's probably a code smell. And so having high tests sort of ensures high quality code, in my opinion. What else do we have here?

Advocate for and help implement best coding practices company-wide. This is not always easy to do, but you really need to be vocal as a staff engineer. You can advocate for non-negotiable things like accessibility and high test coverage. It's important to establish coding standards and guidelines and utilize internal tools for code quality and performance analysis. Driving innovation is also a responsibility of a staff engineer, trying out new strategies and backing opinions with actual experience.

But a lot of it is, you know, saying, look, I think I found a better way to do this or I think that if we, you know, change our strategy, I don't know. So you want to be you want to establish the main coding standards and guidelines on the team. This again comes to code review. I had a boss who once said that any rule that you're going to write in a knit, you should probably just make a linter rule for. So, you know, make sure there's a linter on your project, right. And make sure it's configured in the way that that you see and the rest of the team see as being like this represents good practices.

Utilize internal tools for code quality and performance analysis. Well, I just mentioned the linter, you know, you really want to make writing good code in your code base foolproof. Any comment that you leave in a pull request and you're like, well, you know, knit, I would like it to be done this way, right, that only exists in that pull request. Nobody's going back through your pull request looking for suggestions of how to write the code. So if it's a knit, it should probably be a linter rule or at least represented somewhere in documentation where somebody can do it. But if you can offload that work to automated tools, right, and have the linter and the type checker, etc., etc. enforce those for you, you will have a much easier time because these problems will never make it to code review and therefore you won't have to leave those comments.

Driving innovation, I don't know, I didn't realize this one turned out sideways. You know, this is pretty typical stuff, but, you know, I spent a lot of time trying out new things, trying out new strategies and writing them up and you learn just as much from the failures as you do from the successes. You know, there's always a lot of in the JavaScript world, a lot of hype about this is the way we're going. Oh, we're all using Redux. Oh, we're all using Zustand. Oh, we're all using whatever. Right. You're going to have to give those opinions to the staff engineer. And, you know, there's an expression about what opinions are like because everybody has one. But make sure your opinions are founded in actual experience. So many engineers, they just have this idea of here's the way I write code. But look, we're JavaScript engineers. This is this is a JavaScript conference we're at here, a React conference, right? The tides change and you need to know which of those changes are hype and which ones actually represent a change in the way that people are writing the code. We're not all using Enzyme to write tests anymore. Now we're all using, you know, test library. Right. And how do you evaluate what's better and what's going to work better? You have to try it.

You have to try it. If you have time to prototype, prototype. If you have the freedom to just use it, you know, in code, especially if you're talking about things like testing tools or linters, you know, just do it. Experimenting is really important.

Mentorship, we talked about. I can't emphasize enough how much being a good mentor makes a difference to your team in the future. You want people to feel emboldened to experiment and learn and try to improve themselves in the code base. And you want especially the more junior people are, the more important it is to empower them. Make no mistake, people quit because of bad senior engineers on the team. OK, so being a good senior engineer is really, really important. You want them to to to to walk away from the job and think of you as the person who helped them to grow. And and, you know, learning as an engineer is so important. I always say, you know, even if you whether you have a computer science background or you taught yourself, we're all self-taught as engineers. And, you know, I want people to be constantly challenging their their their ideas of what it means to be writing good code.

Which brings us back to the title of the talk, how to actually build influence, right, because a lot of these things, OK, it's easy to say I'm going to lead by example, but are people looking to me as a leader? Sometimes they are, sometimes they're not. The bigger the company is, the harder it is. And, you know, for me, I'm a very outgoing person. I'm the kind of person that that strikes up conversations and just voices my opinion. But not everybody is and not everybody should be. And you still need to be able to build influence, even if you aren't that kind of person. So how do we do it? The first thing is lead by example, and this, you know, we talked about we talked about how important it is to be writing actual code, you know, and doing sprint work on your app. You will never convince your team to do have good test coverage unless you are showing them how to write those tests. OK, you will never show them how to write, you know, type safe code that doesn't have any's in it unless you are also writing type safe code without any's in it. Your documentation should be, you know, chef's kiss. Beautiful, right? Use JS stock where you have to use TypeScript where it's possible, you know. In terms of project management, again, I think I mentioned earlier, I think a lot about the right ways to write tickets for me. I'm a big fan of I have this this goal of making all the work that I have to do just like perfectly parallelizable. You know, we have three front end devs on the team. I want people to just be able to pick up tickets and not step on each other's toes and be blocked by each other. And I want them to be able to learn to do this themselves.

So leading by example is just really, really important. When I leave feedback on a code review that says, you know, this is not a good practice, I really want to be able to point to places in the code where I have done it the way that I believe to be right. And I want those places to be supported by tests so that when other people try to implement those things and I say to them, you need to write tests, there is an example of how to do that.

Strategic thinking and problem solving. You know, it's really important to be thinking down the road when it comes to code, and this is something that rank and file developers aren't always able to do because they're not because of any problem with them, but they are getting pressure constantly from project managers and product managers and designers and their, you know, their tech managers to be, you know, this work has to get done by a deadline. And at the end of the day, sometimes spending an extra hour or two on a PR and making some changes will save you more work on the next PR, right?

It's your job as the staff engineer to be looking down the road. OK, so it means thinking beyond your immediate technical challenges and it means actually coming up with approaches for strategically solving, I'm just paraphrasing the approaches for strategic problem solving. It's really common for me to have this feeling when I'm working on a ticket of, you know, there's this pain point that I've run into three or four or 10 times before and you just have this aha moment where you realize that that there's we haven't actually figured out an approach for solving this problem. And that's why we keep on running into it.

Obviously, implementing these things and getting people to adopt them comes back to our last slide. Right. If I'm not writing code, I can say to somebody, here's what I think you should do. But am I actually accurately diagnosing the problem? And be who's going to listen to me if I haven't? I again, I don't have the authority to demand it on teams other than my own. Right. And so who's going to listen to me unless I'm showing them the right way to do it? In my opinion. I think it's really important to be a subject matter expert. This year, you hear about being a T-shaped developer, somebody that knows a lot about a lot of things, but also has one subject they're really deep on.

I actually think it's even better to be whatever the heck this shape is that I drew. There's a lot, you know, you should be it's good to be a subject matter expert, but don't limit yourself to the thing that you are a subject matter expert for when you got hired. I'm primarily a React developer, but as the company has, you know, we've all at my company started using Remix, which has meant needing a lot of what traditionally was thought of back end or full stack knowledge. And so because I have other areas of expertise besides just React, as we go into to using Remix, you know, there's insight that I can bring to it that I wouldn't have been able to. And I'm constantly trying to broaden my knowledge on those subjects so that as we run into new challenges and we are running into lots of them because none of us have created an SSR app before. Right.

This year, you hear about being a T-shaped developer, somebody that knows a lot about a lot of things, but also has one subject they're really deep on. I actually think it's even better to be whatever the heck this shape is that I drew. There's a lot, you know, you should be it's good to be a subject matter expert, but don't limit yourself to the thing that you are a subject matter expert for when you got hired.

I'm primarily a React developer, but as the company has, you know, we've all at my company started using Remix, which has meant needing a lot of what traditionally was thought of back end or full stack knowledge. And so because I have other areas of expertise besides just React, as we go into to using Remix, you know, there's insight that I can bring to it that I wouldn't have been able to. And I'm constantly trying to broaden my knowledge on those subjects so that as we run into new challenges and we are running into lots of them because none of us have created an SSR app before. Right.

Sorry, not SSR, SSG. You know, you need to you need to be able to spot problems and solve them, and you can't do that if you're too siloed. Every conference, including this one, is going to be talking about AI for the next several years, and I have one big opinion on AI. I actually really don't like using it for code generation, not because I don't think it's good or because I think it's good or not good at it, but because I like writing code. The part of the job that's hard to do is the language part, the natural language part, leaving good feedback on pull requests, communicating things in a way that makes people not be angry to you.

I had a boss who gave me the idea of using sentiment analysis on my PR request, so I installed Grammarly. And it had false negatives because if you said the word error, for example, which is a programming word, it would think you were being negative. But there were enough true times where it caught me speaking in a way that could have come across more judgmental or angry or terse than it needed to. And so I actually used sentiment analysis and improved the quality of my of my code review feedback. And this is important because I've seen people quit over having seniors that couldn't communicate effectively. Chat, GPT or Claude or other LLMs are a great way to do that as well. You may work at a company that doesn't allow you to use AIs for code. But, you know, being able to say how do I say to this developer that I think they're implementing an anti-pattern without sounding like a jerk and and chat GPT will do a good job of telling you how to do that.

This even goes there's something I didn't put on the slide, but I'm going to say it anyway. Can I recommend something I don't recommend? I kind of recommend it, which is that I had a boss many years ago before I was a developer who told me that my emails were too terse. This is a problem that I have. And her advice to me was to use emojis. And I know what everybody's thinking. But the truth is that a smiley face emoji at the end of a statement might do a lot to soften the way that is received. You can use that advice or not. Your mileage may vary. This is the most important thing about building influence, though, is everything you do has to be done in public. OK, well, not everything, but a lot of things.

DMs are the worst place to share knowledge. You can't search them. You can't index them. People forget about them. If somebody quits the company, can you even access them? And you certainly can't take them with you. So I think it's really important to make sure that a lot of what you're doing as a staff engineer is in public.

And I've sort of rank these in order of what I think, how I think they should be done. If you can get your company to allow you to open source some of your code, it does a lot for leading by example. It does a lot for sharing and enforcing best practices and code quality. Because you can really say we're not going to put bad quality code in open source repo. And it's also good for your career because that, you know, your your name is always going to be on those initial pull requests. You're always going to have been the person who started that repo.

Company blog posts, if you have them, most companies have a blog or would like to have a blog. And if they do, it's very difficult to find people who are enthusiastic about regularly posting. Again, it's great for your career. When you are applying for your next job, you're going to want to have those blog posts. And if you're not a staff engineer, you probably can still post on the blog. At my company, it's very the barrier for posting on the blog is very low. And yet people don't do it as much as they should.

The next would be confluence or similar documentation, because you can actually search through it. Same with public Slack channels, especially a conversation about gathering requirements or, you know, implementing a best practice. I'd love to see it in confluence and a public Slack channel, both because people will search for those things. And if somebody's having an issue, I would love for them to post about it in a public Slack channel so I can give them the answer in public and not in a direct message because then when the next person has that issue, you know, I'd like to be able to link them to it.

And then the last one is pull request comments. And I really pull request comments are good for things that are documented elsewhere. Right. If you're going to enforce something in a PR comment, hopefully you have a confluence or a blog post or an external reference somewhere you can link them to, because that's going to come up again and again. And nobody goes back through old pull request comments and searches for them.

The more public you are, the better it's going to help you in your company when you're doing your OKRs for the year and trying to justify your promotion. You can bet your butt that management loves to see blog posts and open source repos because, you know, they're concrete and they're not just for the nerds in engineering to see them.

Right. You can actually show them and say, this is the handy work that I've done. Open source code is so great because you can go to your next job and tell them, look, I write good code, but if you can actually show them your commits in public, then that's even better.

And so what I did at work was I actually managed to break a bunch of our code into its own repo and open source it. I want other people at the company to use it. Some of them are, but even if they didn't, right, I would still have that as a feather in my cap for having worked here, which is sort of a cynical way of putting it. It's a cynical way of looking at it. But, you know, we're talking about how to manage your career. So a certain degree of cynicism is warranted, which brings us to the end of the talk.

You know, just to summarize, you know, you can see a lot of different definitions of what it means to be a staff engineer, but it's just so important to make sure that people know your name and know who you are. And the way to do that is to do whatever you're doing in public. So that's my number one recommendation. You know, you don't have direct reports. You need people to think this person, Ian Schwartz, is the guy that I'm, if I have a question about React or testing, right, I'm going to go to Ian Schwartz. And that's true for a lot of people at my company. But, you know, increasing the number of people that think that way is really important and it can only be done by making sure that whatever you do is discoverable and open for the world to see. I don't have too much else to say about it other than that. Thank you so much for coming to my talk and paying attention thus far. And thank you. Enjoy the rest of the conference.