Hey folks, and welcome to today's episode of Developer Team. My name is Jonathan Cottrell. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. Today's episode is going to be a pretty short episode. I'm going to focus on a misconception, a misconception that a lot of senior, sorry, people who want to become senior engineers, they are at that level below whatever your company calls this, the kind of associate engineer level, and you want to move into a more senior role. And this is true also for managers, by the way. This principle applies regardless of what track you're on. It probably applies outside of engineering as well. It especially applies in engineering in some particular ways. We're going to talk about that. But the concept is ownership. If you're my report, if you, that's not many of you probably, if you have worked in engineering for very long, if you're an associate engineer, if you've talked to your boss, and hopefully you have, about what it takes to get to a senior role, if that's something you care about, you have probably heard this term, right? You've probably heard that it requires you to be a senior engineer. You have to be a senior engineer to show ownership. And unfortunately, the industry has not done a great job of standardizing across roles, but this does tend to be one of the kind of aspects of moving along your career track. The higher up you go, the more senior you become, the more ownership is expected from you. But although that part has made its way... into most conversations, most performance conversations about how to move up in the organization, it very often is not well-defined. What do we mean by ownership? What exactly do I need to do in order to show ownership? And this is where most managers have not provided a lot of clarity. So let's take a step back and think about what this transition is. And really, I want to talk about a gradient. A gradient from the most entry-level engineer all the way up to principal or up to a director level, a VP level. I want to talk about this gradient of ownership. So let's say you're an intern, like a very, very early entry-level engineer. You're still kind of learning the basics of the various stacks you might be working on as an intern. You may barely know the language that you're coding in. And so you can still show a bit of ownership, but the amount of ownership that you're able to show is going to be limited by your experience pretty heavily at this point. And so most of the time, an intern or an entry-level engineer is likely going to do exactly the work that's handed to them to do. Right? This is very highly... You know, high level of detail and the tickets that you pick up. Maybe a very low-risk kind of work is going to be handed to these engineers. If you're working at a startup, you may have a little more risk tolerance. So you may get exposed to, you know, production environments a little bit earlier. You may get exposed to more complicated things a little bit earlier. But overall, the kind of one end of the gradient of ownership is at this entry-level where most of what you are doing, you are not necessarily owning. You are kind of operating under the patronage, you could say, of your manager or of another senior engineer or tech lead. And they're likely to be very hands-on with you. Right? They're likely to, you know, to review your code. They're likely to pair with you very closely. You know, they're trying to... As much as they are trying to get that ticket done with you, they're also trying to help you learn. How to get your feet under you. How to move towards more autonomous operation. And this is usually not just because they like you or because they want to, you know, to provide some kind of charity. That's not the goal in most cases. This is because they want to create an environment where you are more autonomous, where you're able to take on work and they can work in parallel and you all get a little bit more done. All right. So... That is kind of the next step. Right? As you begin to become more autonomous, the work may still be fairly well defined. You know, it's likely that your tickets are well refined by the time they make it to you. Maybe they're still fairly low risk. But overall, you're starting to have, you know, sessions of two or three hours where you're just focused heads down and you're actually able to produce code. So this is kind of a mid-level engineer. You know, if you get stuck, usually you can kind of just say, hey, I'm stuck. And then somebody will come over to you and help you out. Right? Virtually or in person. And this is where the trap that I'm talking about tends to happen. Is you're kind of in this mid-level engineer and you're handed tickets to do. You carry them through to completion. And this is as much as you can, you know, currently kind of the limits that you see on your ownership. Right? Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. At the end of the day, you may have taken the plunge and taken the plunge and taken the ownership for being assigned a tech lead role or being given a full project to do. We mistake ownership for some kind of scope of responsibility matching, right? You have to own a project. You have to own a deliverable. You have to own some particular outcome. And the truth is, ownership is a behavior that engineers, especially senior engineers, are displaying throughout almost every action that they take. I'm going to explain kind of how this works or what I look for as a manager, as a leader of other engineers. So most of the time, what I'm looking for is someone who is always thinking about what now. If you remember nothing else from this episode, I want you to remember that phrase, what now? What next? What do we do as a result of what I know, as a result of the thing that just happened, as a result of the way that I just got stuck, what do I do next? All right? And to always kind of have that mindset of moving on, moving forward, figuring out what the next step is. Now, you should pay really close attention to this little nuance. I want to call your attention to it. I am not saying that you should know what to do next every time. I'm not saying that you should always be able to learn all of the nuances, the technical detail. I'm not saying that you necessarily should inherently understand the work that you're doing to a degree of ownership in terms of executing every step in the process. What I am saying is that you are willing to take responsibility for figuring out what happens next. All right? This is a subtle distinction. You are willing to take responsibility. This means that you are willing to raise your hand and say, I will take care of this. What this really looks like in practice, you can kind of measure yourself. How often is your manager, is a tech lead, how often are they having to intervene? How often are they having to be in your situation? All right? In particular, without your prompting. Okay? So there's this interesting kind of little nuance here where we said ownership is knowing what to do or knowing that you need to figure out what to do next. So that might mean escalating to your manager. That might mean bringing in another engineer. It might mean bringing in product. Some subject matter. Some subject matter. Some subject matter. Some subject matter. Some subject matter. Somebody with a skill set you don't have. All of those things are things that I do. They're things that the highest level engineer does. Okay? So don't get too hung up on, oh, a senior engineer, they know everything. They know how to do everything. They know how to operate every system. They know how to write any algorithm and split them from. That's just simply not true. Okay? Instead, what they do know how to do is they know how to figure out, who to coordinate. They know how to figure out what to do next. How do I get unstuck? How do I make sure that this doesn't stall out? Now, a junior engineer may allow something to stall out without even knowing it. They don't even realize that things have slowed down or, you know, a junior engineer may not know that it is, what to do next. Ultimately, my definition here of ownership is you taking the responsibility, taking the accountability, to make sure things continue moving forward. Okay? So, and this doesn't always have to do with deliverables, by the way, right? This doesn't always have to do with, you know, pushing code through. This might be something like an organizational initiative to improve the culture, It might be something that you've identified. You identify a problem. Let's say you identify a problem in retro, for example, right? What does ownership look like in this scenario? If you identify a problem and then you just kind of like let it sit, right? If you just let that problem sit, then it's unlikely that some other person is going to take the initiative to pick it up. And so there's a hypothesis, kind of an implied hypothesis that just by bringing this problem up, you have done your due diligence in order to solve it. That somebody else, of course, the manager or another lead or somebody is going to pick it up. And this so often is not the case. And so what a, generally speaking, what a more senior engineer does is they try to translate, okay? To translate these problems into action or a decision, right? What that looks like is, okay, we're going to bring something up at retro. What do we want to do about it? That's the question that a manager should be asking. That's a question that you as a mid-level engineer wanting to become a senior, that is the question that you ask. What are the action items? Can I take an action item? Can I go and act on this thing? A lot of times. People kind of tend to accidentally avoid action items because they don't want to load their plate up. But this is what it means to have ownership, right? To show ownership over a problem is to take action on that problem and do it in a way that you're holding yourself accountable. You're not waiting for someone else to hold you accountable, right? You're not waiting for your manager to come and ask you what the status of something is. Go tell them what the status of that thing is, right? So hopefully. The theme here is that you are taking over your work, right? There's a lot of agency involved here. Hopefully, I've dispelled the idea that you have to know everything in order to do this, that you have to have the highest technical proficiency in order to do this. It's not the case. It's not the case. It's helpful to have some, right? Which is why this advice doesn't apply well to an intern. It doesn't apply well to an entry-level engineer. It applies. It applies excellently to an engineer that has a few reps, right? That you've shipped code to production. You kind of understand the domain, but you're being challenged with new work, with expanding scope, with harder things to solve. Maybe you're being challenged with roadmap collisions, or you have some inter-team dependency stuff that you need to figure out. These are the perfect opportunities. Even though you're not designated as a tech lead, these are the perfect opportunities for you to be able to do this. To step up and show ownership. For you to step up and show that you are going to choose, right? You're going to opt in to being held accountable for the outcomes of some situation, of some set of work, of solving some problem. So as you progress through your career, you'll realize that the more and more senior you become, the more this becomes. Really kind of all of your job, right? Is the ability to own something and to organize yourself and organize others around the things that you own. This isn't the only skill, right? Just to be clear, it's not like this is a magic skill that you're going to acquire and suddenly everything, you know, you get the promotion and confetti falls from the sky. That's not the case, but it is a critical mindset shift and possibly one of the most important mindset shifts. Yeah. Between an L2 and an L3, you move from being assigned work, right? Being pointed in a direction and being deployed, you know, by a manager and by a tech lead. You move away from that and you move towards mastery of the craft and towards ownership. Hopefully this is a clarifying discussion and you can start to think about my hope here that the best outcome is if you're looking at your, your, your, your career right now and you've been given this advice, you have to own things and you said, well, there's no projects coming up. There's no way for me to show ownership because I'm not given any opportunities to lead anything. Hopefully this dispels all of that. I hope you walk away feeling like, well, I don't have any more excuses left. And now is the time to show ownership. Thank you so much for listening to today's episode of developer T. Sorry for the potential interruption with this. this episode and other episodes being on YouTube versus not being on YouTube. This is largely because we have some, it's a little bit harder to get interviews up on YouTube. Sometimes we're going to be recording things that do get up to YouTube. There is a feed that goes to YouTube of every episode. That's pulling off of our normal RSS, our normal podcast RSS feed. And then sometimes we have these video episodes. Thank you so much for listening until next time. Enjoy your tea. Bye.