Demonstrating Ownership: Mid-Level To Senior Software Engineer

Transcript is auto-generated and may contain errors.

all right I'm headed to CrossFit here it's uh another super super cold day um I went to Reddit for a topic and it's kind of related to some stuff I was talking about in uh one of the videos yesterday or the day before I make a lot of videos now so I don't know what day it is um and I'm going to go through this idea of like midlevel and senior engineer to touch on a couple of things um and I think there's been I feel like I've been having conversations recently where where this has been coming up and it felt like a natural kind of uh thing to talk about the heater in this car smells very bad out of nowhere that's very odd oh it's the I just turned on the seed heater okay it's still early um okay so if you have

questions that you want answered leave them in the comments happy to to respond that or if you want to write something that's more in-depth keep it Anonymous look for Dev leader on social media Dev leader is my main YouTube channel with fully edited videos tutorials especially for C programming and uh a lot less rambling because I have the editor actually keep me on track uh but this channel is a lot more stream of Consciousness so uh sit back and enjoy but uh the idea primarily when I talk about mid-level and Senior in really like level progressions there's two major things that I sort of regularly talk about and that's um the scope of impact of the work you're doing continues to grow so you know if you take one end of the spectrum someone who's very Junior you have basically like smaller features or bug

fixes that probably someone else already understands and they basically assigned them to you uh because they you know want to help help ensure that you can build up the confidence that you can be delivering on these types of things uh in terms of ambiguous work though you're probably getting little of it not to say zero or that you can't handle it but generally people are giving you work that's like kind of like I was saying like it's not complex and it's well scoped and that way they can help ensure that they can they can help you they can assist you and you can kind of build up that momentum typically and so if you go to the opposite end of the spectrum for someone that is a you know sort of high level individual contributor they're generally leading projects that are uh like effectively organizational

or companywide so they have the scope of impact of their work is very great and of course there's everything in the middle right but the point is that uh the scope of impact continues to grow as your level increases the other thing that I always talk about is uh sort of like I don't know if I can call it like your circle of influence but in order to be delivering on very high impact work you essentially need to be able to like rally people with you to be able to accomplish that work you need to be able to effectively lead those projects um and that's usually how I try to describe this element of like uh your circle of influence okay okay so if you try to like just do really big organizational impact and then just try to take it all on by yourself

depending on the work you're doing that could be like essentially infeasible or impossible because you need other teams to be bought in and like participating in those work streams so those are the two major things that I usually talk about but something that's come up recently and it's making me kind of rethink not the it didn't re make me rethink how I find it but it made me realize I'm not like calling out something that's probably important um that I once I was hearing it I was like you know what maybe it's worth sticking a third thing in there that's uh that's uh I don't know a little bit more clear about even going from Junior to mid-level mid-level to senior kind of thing because one might argue that you'll have mid-level Engineers that are already starting to do projects that are a little bit

more ambiguous uh they might be cross team and then I'm seeing some conversations online or having questions around this where it's like well I'm already doing that isn't isn't that senior already um like the lines sometimes feel a little blurred before mid-level in senior and the element that I want to talk about here is ownership and if if I'm saying that word and you're like oh I watched the video the other day that was not the only reason um it was a fresh reminder but even I think yesterday at work it came up in like literally two or three completely unrelated conversations and I'm like okay it's a sign I should I should probably talk about this a little bit but um I wanted to talk about ownership because I think that is actually one of the uh differentiators when we start talking about like

a senior level so like what does it mean to take ownership on something and the way I wanted to maybe walk through uh an example of like I think we can demonstrate where ownership isn't and then maybe like talk through how that could look so I'm going to use a anonymized sort of pseudo example U but let's assume that we have a engineer that's working on something and we have time lines in place they're not necessarily like a super hard deadline like if things are off by a day like that's fine uh things are off by 2 days it's not the end of the world right but we have a rough idea it's going to be you know uh let's say four to 5 days of work and if we spill a little over and it's like a full week of work or something it's

not that's fine and let's assume then that when this person goes to do their work they've essentially completed like their coding part they've written unit tests they feel good about it uh and now they're saying okay I want to like put it into the uh the harness that exists the tooling for like integration testing I want to like I want to run this thing kind of live in a in some type of environment that's uh safe to do so and uh this is like a core part of their testing it's a core part of everyone's workflow so they go to do this and then they get a result back that's saying like the infrastructure is not there's not capacity for it and they're going okay that's weird um but like it's just not working okay like let me try again okay still not working and

then basically they reach this point where they go hm well that's a step I have to do and it's not working like what steps do I take and this is where I start to think that the element of ownership comes up because what can happen here is that you can take a little bit of ownership and you go okay I know that this um this other team owns this infrastructure that's telling me hey look like there's not enough available or it's not working whatever the error happens to be um so some other team owns that maybe like I should contact them so they contact them and the other team's like yeah like basically not really a good fix for it right now it might work if keep trying but like you know we don't it's not something that we have a a solution for uh

that's going to fix it 100% so the person goes okay they try their thing again still doesn't work and now they're kind of like well I guess either I'm stuck or or we acknowledge that we're not testing and they kind of like have these two options that are like neither of them are really great or they sit there and the third option is they go okay I'm going to you know I'll I'll wait maybe tomorrow it works and then they try it tomorrow and it doesn't work and then they say okay well maybe tomorrow it works and then they try it another day after still doesn't work now the deadline or the timeline is being pushed out so in this example I'm giving here there's like a little bit of ownership like let me go contact to like the team that is responsible for the

thing I'm using but what's happening is that in terms of owning a a successful project deliverable that's starting to SLP so you could either be like the one example I was saying they just say okay guess we're not testing okay maybe that's your quality and this obviously is a contrived example so obviously it's going to depend on you know the rest of how you feel confident in testing but uh let's assume that you're dropping out this major part of testing okay so a potential quality dip um if you're going to sit there and keep uh keep trying and you've done it for a couple days and it's still not holding out uh you know proving to be a possibility and now you're timeline slipping so the reason I'm saying this is only partial ownership is because it's like these are just things that are you're

sort of reacting to it's only reactionary right someone said hey you could keep trying it and you go okay I guess this is my only option I will retry doesn't work so your reaction to that is I will wait and retry later this is it's better than not doing anything to just say like I guess there's nothing to do and then literally just sit there blocked um you know at a minimum we'd want to raise aw it is but I say this is like minimal ownership because if we're looking at our criteria for success and that's going to include like you know well-written code it's going to include uh you know testing coverage this kind of stuff then then that stuff needs to get done the other thing is we talked about the the timeline for it right so that's also something that's you know

it was agreed upon so that's part of the project success and you might be listening to this in some cases maybe for you you have more flexible deadlines and stuff I'm just giving you a a specific example here that's contrived so if those are the criteria for Success if you're taking ownership the idea behind taking ownership is that you're saying I regardless of who else is involved I need to remain responsible for delivering on the success criteria so if you're in this situation where some other team uh is not like the the system is kind of stopping you from testing and that's a core part instead of saying like it's just their fault like the timeline's behind because it's their fault or we had to skip testing altoe because it's their fault that's not taking ownership that's placing blame right instead there cops flying by

no lights but they're flying um instead of doing that and if we reverse like the the way we're looking at this and it's like okay we have a dependency in this case we've contacted the owners of that dependency and it's not going how we'd like you still need to be responsible for the quality you still need to be responsible for the timeline so what are you doing what are you doing about that the reason I gave the examples and said it was minimal ownership is because in the one case you're at least reaching out to the responsible uh you know owners of that infrastructure that's minimal ownership better than none but that's addressing like the symptom of what you're experiencing that's not actually it's not actually saying okay like we tried that it's still not working you still need to be responsible for your quality

metric and your timeline so what are you going to do and when I've had some conversations about this recently um it's really about like where ownership really starts to shine is that you're like number one you can't be placing blame on people and just kind of removing yourself it all often means that you're taking additional action it might mean getting very creative it might mean uh you know pushing through some extra work that wasn't really planned for but ultimately the goal is that you have something to deliver oh man you got to speed up so I can merge or not you can wait back there um so in this case right like to to walk through like something that maybe is creative is thinking about what type of testing is going to be done on that infrastructure and then saying well why are we doing

that testing right like what confidence do those tests give us and if we acknowledge that we cannot use that infrastructure to get that confidence what else can we be doing to get that confidence is this something that we could act like based on our product or service we could go run it uh locally on someone's machine or in another Dev test environment or something and then are we still able to exercise those paths it might have been more automatic and more repeatable on the infrastructure but if we don't have access to that it's just not working and we really feel we want that coverage maybe we should try it this way you could also be asking yourself hey are we just doing this because this is you know air quotes part of the process but the value it's adding in this case if it were

to work is very very little maybe you should be having conversations it's maybe it's not actually dropping your quality by not doing this maybe you should have a conversation and do the analysis to say like what what gain are we getting in this scenario by running it because if it's just doing it because this is the standard process and there's no value at if you go through that analysis you could be proving that it's not actually skipping anything that's going to add value um my point here is that like what are you beeping at there's literally no there's no one in front of me um the uh the idea is essentially looking at other ways to go accomplish the goal that you have and while I was saying it can feel like extra work right it's not really planned for now you're like ah I

have to go figure out how to do this while that seems like it sucks the the thing that's really nice about it is that it puts you back in the driver's seat it's uh it can be really frustrating to be blocked on other teams or other people waiting for things uh so in this case you know you need your testing infrastructure to come back and you're like I can't do my job this sucks but I think sometimes what happens that people get used to like these things happening and if they don't take ownership it just becomes like a commonplace thing like oh yeah the testing infra is down like sucks yeah okay guess I just like guess my work will just keep getting pushed like there's a good excuse for it right the testing INF is down but like it just becomes kind of easy

to fall back to that is what I'm saying um but instead when you have ownership it's like it's not just making excuses or blaming things and my the reason I I want to keep hammering at this is because my point is not to say that like there is no responsibility of the other team sure like they have a responsibility in this example I keep using they're responsible for their infra yeah they should be accountable to that stuff but that's outside of your control you raised awareness to them great good job you still got you got to deliver so being someone that can take ownership is going to be demonstrating that you're reliable and accountable to the things that you were assigned and this can really stand out because I said this at the end of the video I think I think it was yesterday but

like people want people on their team that they can really rely on for this kind of stuff because when you have a team filled with people that are the other way where it's just oh like doesn't work yeah not my problem I guess I just have to wait like everything will always constantly slip especially as the systems that you're you're working in your environment becomes more complex everything will always slip instead you want to have people that are constantly like that's not working cool what are we doing instead what's the goal we're trying to achieve how are we going to do it instead how do we get creative here and it happen and in my opinion that was another one of the key pieces that uh senior Engineers really do and shine uh compared to mid-level again not that mid-levels cannot do it but it's

like I would expect that seniors are doing this kind of thing so just got the CrossFit I hope that helps um just so maybe a slightly different Twist on how that stuff looks so thanks for watching again if you have questions that you want to answer leave them in the comments or send a message to de leader on social media Dev leader is my main YouTube channel with uh more polished edited videos and uh on software engineering topics and then programming tutorials and C so thanks for watching I'll see you next time take care