I'm A Staff Engineer and I'm OVERWHELMED

Transcript is auto-generated and may contain errors.

Hey folks, I am just headed to CrossFit here. I'm gonna turn off this overhead light. Um, we're going to experience dev subreddit. This one is from an individual who says something like, "Help, I've become too important at work." And then they go on to discuss how they've uh recently become a staff level engineer. But um they said but the reality is they've been kind of operating at that level for around 2 years now. So if you recall in some previous videos I was talking about for promotions like most of the time what you will see is that you have someone who needs to be operating at a level above already before you get promoted. So here's here's an example of that right like I've been operating at this level was promoted after already operating at that level. Um, but they're talking about burnout and they're saying like, you know, it's been 2 years.

They're feeling really burnt out. And essentially, they go on to describe at a high level like just being responsible for too many things for and too many things, by the way, can look different for different people. Like you might have one thing and you're taking all the responsibility of it and that one thing is too much, right? Right. It depends how you what the thing is and how you're you're looking at responsibilities. I think they talk about a couple of things and based on the significance of those they're saying like that doesn't give them any time. But the problem with this is that the expectation of you is now higher because you are operating at a higher level. You're operating at a staff level. So this person has expectations placed on them where they're expected to manage those things plus do you know the forwardlooking stuff not just managing the existing or taking responsibility over the existing projects.

So they're kind of like what the hell. um seems like from their perspective uh you know like switching companies or or something is kind of like the only way like they they got to pull the pull the parachute right like they got to get out because like otherwise how are they going to survive this? Um so I wanted to talk through this. One of the things that they they said which I'm probably going to spend most of my attention on is that um they said I don't have like other people to delegate this work to. And I would say full stop right there. Like that is your problem. That's the problem. Um and the answer to that is probably not what this person said. They're saying I don't have people to delegate to. Um, that sentence isn't complete though because it it's supposed to say I don't have people to delegate to yet.

And what I want to talk through is like the importance of being able to delegate that work and and what this person should consider doing. So, as a staff software engineer, it's true you're not going to have direct report. So, like you don't have people that report to you that you can delegate to. So, that part of the statement is true. And um the side effect of not having direct reports to delegate to is that you're going to feel like if you don't have the right connections, right, people to speak to about this kind of thing, like you're going to feel like your hands are tied because you're like, I don't have people to help, right? you would have to kind of be in a position where your own manager like this is the the more sort of common way that I would see people

getting assistance on something is like you talk to your own manager and they're like, "Oh yeah, we can get Billy from this other project to help out on this thing." But it's not always going to be the case, especially like number one, if your manager doesn't actually have people to help allocate to things. Number two, if the projects you're talking about at staff level are things that span multiple teams or should span multiple teams, like maybe the person you need to get help from and support from is on a different team. So like you can't just go to your manager and your one-on- ones and being like, "Oh man, like feeling feeling a little burnt out from this. I wish we had Billy from the other project to help with this." Um, this might be a thing where I mean, number one, you could and probably should talk to your manager about this anyway.

I This is like the the only thing I talk about on this channel is like talk to your manager about things. Um, because I think that you should and I think that even if there isn't like a a tangible action where your manager is like, "Oh, I can snap my fingers and solve this problem by moving a person." And I still think the right thing to do is to have the conversation, raise awareness of it at a minimum, right? At a minimum, having more awareness raised is helpful. But maybe there is um some recommendation your manager has on this if you haven't already talked to them. The thing that I would and like I saw one of the comments in in the Reddit thread that was touching on this and I I think it's the like what I would recommend is like if you're operating

at this staff level like you have whether you acknowledge it or not you have some type of influence right it doesn't mean that you get anything you ask for uh no one should realistically um but it does mean you have some type of influence influence. So what I would be recommending that you do is speak to your manager, speak to the other uh project or product managers that you're working with. Speak with the other engineering managers of the other teams that you're working with. Basically raise awareness that you need help with this. And what I would do is kind of structure what you are responsible for on a given project. And you can start to frame this as a couple of things, right? One is that you need support because it sounds like if you have full responsibility over this stuff, you are a single point of failure.

This is a business risk. This is something that needs to be addressed. Um, so that's one angle of this that's not like, oh, like, and by the way, I'm going to I'm going to make this sound like um kind of silly on purpose, but it's not like, oh, poor me. Like, I can't handle what I'm doing. like please uh please give me support. I need help. It's like nope. This is literally business justification for doing this. The reason I said that that way, by the way, is that like I do think that it's totally valid if you need help and support that you ask for it, but so that you can pitch it in a way that's going to convince other people. Cuz that's the tricky part. you might need help and support and you're going to be talking to other engineering managers that are like I hear you man but like we also need help and support.

So like at the end of the day what's the business justification for it right? So single point of failure I think is a really good one to be like, "Hey, look, I'm the single point of failure on this project, this other project, and this one. We're talking about project uh A right now. So that's why I'm talking with you folks. I'm the single point of failure here. We should do something about this so that I am not the single point of failure." I think that's one thing that you can consider. The next thing is that um you can take what feels like a selfish ask like please help share the load on this thing like that feels kind of selfish to be like I need help right cuz you're focused on you which by the way again I will keep saying it. I think that it's totally fair and reasonable that if you need to ask for help that you do.

I said what I said earlier in a funny way just to get your attention, but like the point is that I think that if you need help, ask for it. Um, the worst thing is that you don't and more stuff piles up and then you reach a point where you're like, "Oh I feel like it's impossible to survive because now you're already operating in a shitty spot and you got to get out." So, what do I mean by selfish and how to spin this around? Well, if you're framing it like I need help, I need help, which again, that's okay. Um, if you frame it that way, it makes it seem like other people need to give up something to help you. That is a more difficult cell, right?

You will have people that will do that that like that will say, "Hey, I acknowledge that we have people that can help." Um, but when I talk about this kind of stuff and I talk about soft skills and I talk about working with other stakeholders, I think something to keep in mind is that like you want to speak to other people when you need help from them. If you can switch things around to sound like you're benefiting other people because you are literally finding mutually beneficial opportunities, that is a great way to get people to help. Okay. So, you need help, right? So, what's something that you can offer to other people? Well, if you need help and someone, an engineering manager can help get a senior engineer or someone level appropriate to help you, you can help skill them up. You can help give them growth opportunities, right?

Like that is something that you are offering. Yes. the selfish motivation and again I'm not saying it's a bad thing but the selfish motivation is that you need help but you can literally pitch this in a way that's like if you have senior engineers or again level appropriate that need to stretch that need to grow that are looking for some opportunity I can be the person that helps them with that because you're giving them some new responsibility in an area they're going to have to learn about this thing they're going to have to learn the ins and outs to have to learn and understand the road map, the technology, the architecture. They're going to be growing into the one of the point people on this project area. I was going to say the point person.

I mean, that might selfishly be your goal is to to get out of being the single point person, but uh you ideally, you know, back to the first thing I said is like you don't want a single point to failure. So one of the point people if that just means to start off there's one more this other person you're talking about ramping up it's better than having zero more right. So you can pitch this as an opportunity to engineering managers where if they need you know growth opportunities for people on their team this could be a great thing. Um the rest of my thoughts around this are really just different ways that you can try to pitch like mutually beneficial opportunities. Okay. Um so instead of doing that and just wasting everyone's time, uh that's the the meta point here. And the other meta point is really around um like networking.

So I just wanted to spend a little bit more time on that. Let me check out where on the highway I am. What's going on here? Something's going on in my cup holder. This car does not work with uh phone holders. Unfortunately, I've lost many a phone holder. Um but I have a pair of sunglasses that was like forcing my phone to like be squished down in a really awkward way. Anyway, um it's still doing it. There's my map. Okay. Um I think that it's really important that you like especially when you're like at staff level that you have built up a network of people, right? like you have of course your immediate team that you work on and that makes sense, right? Like that's your home base, but your your team also starts to look like you have a I don't know like a sort like a call it a meta team or something.

I don't know fancy words to to describe this, but you have other people that form like a team for you. And it's the same with engineering managers, right? So like as an engineering manager, I have the team that reports up to me. We are a team. I'm also part of a greater team that reports up to my engineering manager. And like even from, you know, a business continuity perspective, an on call perspective, we like all of us that report up to my manager are on the same on call rotation. So when it comes to supporting live services, we're all responsible for for the same things. Even if we're not on a day-to-day basis working on the exact same stuff, when we're on call, we share. Now, beyond that, right, like there is then my skip level manager and then there's a bunch of engineering managers or or group engineering managers below him.

So like we don't share the same on call rotation but from my perspective like I have the team that reports up to me. I have my greater team under my engineering manager but I also have like another team that I work with which is the engineering managers under my skip level right like we form uh not a team of like you know uh delivering to a specific product necessarily but we are a team of similar roles and that means that we can lean on each other for insights information for for feedback for you know questions and answer like all this kind of stuff. We aren't a formal team, but that is, you know, a air quotes team of people that I need to work with in my role. And so, as a staff level engineer, I highly like I want to say recommend, but I almost like expect that you have in your mind sort of like your go-to people.

You have a network of people and that might be look different across different projects. that might look, you know, I'm not saying it has to look an exact way, but um the idea being that if you're this person who's on this Reddit thread, it sounds like, and I don't know this for sure, but like on the surface, it looks like their ability to effectively network and influence is um is maybe not where I would hope that it is at their level. And that's probably why they're feeling that friction. So, if they have good networking abilities and they have good influence, they should in theory be able to do some of the things I was describing earlier, right? You like kind of know, okay, I need to be talking with these people. Here's how I would influence them. Um, you know, looking for mutually beneficial uh paths forward.

But I can't stress this enough, like when you're at that level or or working towards that level, it's not just code. You've heard me say, if you watch my other videos, you've heard me say this a million times, right? Like, yes, code and technical skills are important and those are the things you're going to be practicing every single day for the rest of your career. You will continue to improve in those areas as long as you are, you know, at least keeping an open mind and working through some stuff. Now the things that you like if you if you're not aware of them like your soft skills, your networking, like your ability to influence, all these things, those are things that you will be trying to exercise as you're more and more senior on a very regular basis. But sometimes people just forget about these things or they think that like it's supposed to just happen.

But you need to actively work on them, especially if you're not aware of them when you're more junior. If you're not aware that this is like an active skill to work on, by the time you're working, you know, trying to become more senior, either at senior, staff, principal, whatever levels you're talking about, it it's going to feel frustrating because you will not know how to lean into those things and you're not going to be practicing them. So, this is just my friendly reminder to you that like you here's an example of someone on Reddit talking about being a staff level engineer. And in my opinion, based on what they've described, the biggest area that they're they're kind of uh having a challenge with isn't a technical one even though or like even like a time management thing even though that's kind of how you know they're talking about they're juggling too much.

I think it's like a networking and influence thing. talk to the right people, come up with the proposal to get support, and like that's your your networking and influence and soft skills. So, I'm just uh pulling up to CrossFit here. Uh hope that was a fun one to talk through, maybe kind of interesting, but um if you got questions, leave them below in the comments or go to codecame.com. You can submit questions anonymously there. There's a little check box to to let you do that. Uh, this channel is entirely driven by the questions that you submit. So, happy to try my best and answer what you got going on. You can check out my other YouTube channels. Go by Dev Leader, so you can see programming tutorials, resume reviews, live streams, podcast interviews with other software engineers, all sorts of stuff. But thank you so much for watching.

I will see you in the next one.