What Does Ownership Mean In Software Development?

Transcript is auto-generated and may contain errors.

Hey folks, we're going to experience devs today for a topic. I might do two. We'll see how it goes. Um, as in two on this drive. It'll be another video if I do a second one. Uh, first one is going to be about ownership and kind of what this word means in the workplace, especially with software development. And just from reading through the post, it kind of seems like posting some of the comments, it seems like some uh like a bit of a misnomer in some cases. Maybe that's not even the right word for it, like a um we have to disambiguate cuz I think it can mean a couple of different things depending on the context. And so just want to talk through that. And I don't think this is going to be like groundbreaking, but especially if you're more junior, this might be more helpful because you'll hear the word um in different contexts and it might mean slightly different things.

So there's one flavor of this which is probably the more common one for software developers which I would say is like you're being told in terms of like expectations and things like to take more ownership right what does it what does it mean to have ownership in this regard um really that that word is like accountability and responsibility Right. Um, so if you're uh on the path to being like a tech lead or something like that or even just like a subject matter expert in an area, you might not officially have like a a title change or something like that, but if you're the person who's the go-to person of a thing, like moving in that direction usually involves some type of like ownership. But ownership is a bit of a messy word because what I don't like about ownership is the word almost implies like you control it like it's yours and specifically yours.

And I think that's kind of like a gross thing. Um because I don't think that anything that we have uh in in teams should be like that. Personally, my philosophy is like I I feel like the best software I've seen and the best team interactions I've seen are when things are made in a way that anyone should be able to jump in. It doesn't mean that everyone should and does like you know just blast things into prod. But it means that like people should be welcome to come in be like hey I want to propose. This is kind of like if you wanted to make a pull request to some open- source thing, like you should be able to do that. Doesn't mean that it's automatically going to be accepted with no feedback kind of thing, but you should be able to, you know, to to contribute.

Um, and if you think about that, like what are the most effective ways that you uh that you could be set up to contribute? if the code is coherent, it has uh tests and things in place to guide you down a path. It has established patterns, it's not just like all over the place. Those types of things make it easier for you to contribute, right? Um but when it comes to ownership, I I think really it's like accountability and responsibility. So if you are taking more ownership of an area that means when there are bugs when there are regressions when uh there is a feature ask that we really need to like um maybe we have to refactor some of the code and pay down tech debt like you are becoming that go-to person for that and it's not like well I'm I'm just I'm just busy and like too bad like I'm just going to ignore it.

It's like no, like you you're taking responsibility for it. Um I don't I'm trying to think of some other better ways to explain that, but um yeah, it's not in my opinion, it's not about you control. So the word is a little bit kind of like backwards. when I think about uh you know engineers that I've worked with or even like I can talk about some projects that even that I've I've had where I'm like I need to take ownership um and I'm going to talk about this from the perspective of a software developer because I have been an engineering manager for most of my career but that will be the other sort of flavor that we'll talk about but in terms of projects I've had right like I I was the manager and one of the developers for uh a product that was doing mobile acquisitions of phones.

So like we would take the data off of phones, okay, for digital forensics. And like that was something that I prided myself in had like you know tried to take ownership of and again did not mean that like oh no people can't contribute code like no like not it's not the case at all but if something wasn't right there were customer issues whatever it was like I'm like hey like that's that's something that I feel like I have ownership on I want to take responsibility I want to be held accountable for that meeting a high quality are like just one one example. There were other things like really really early on in my career at the same company um I one of the first things I did was I rewrote one of the products or parts of the products was like the the viewing portion

of an application not the search engine part but the viewing part I rewrote it um and not uh not on a whim there was a reason for it uh and you know I'm at this point I'm still very much like a junior developer right like this is This is my first foray into real work outside of internships. So, I'm rewriting this thing. But, I I became like the go-to person for it. So, I had to make sure that I was helping others navigate it, that I could explain the patterns, that they were coherent. When things weren't working, I wasn't like, ah, like too bad, your problem now. Like, no, I had to take accountability. if the design patterns weren't right, it was like okay, how do I how do I take some ownership and responsibility there to to work with others to understand that and to say like what direction do we should we move in because clearly this pattern is problematic for people like how do we shift to something else.

So accountability and responsibility are are sort of those other words if you're hearing ownership. Um I would say especially in the context of like you know expectations with your manager and conversations like that for um you know for for advancement or that kind of thing. The other side of this is when you hear roles like product owner, okay? And when you have people that like own a product and this is I think more arguably even with like uh like with tech leads or team leads, by the way, tech lead and team lead can mean very different things and they can mean very similar things. Just really depends on where you work. Um but at some point and this is engineering managers get grouped into this too. Um but when we talk about ownership from this perspective, it's usually around like prioritization. Okay. So in the first context, it was a lot less about like as a developer, I don't necessarily think that you're responsible for like setting the priority when we're talking about ownership.

Um if you're, you know, there's definitely like principal engineers on my team, but they're like tech leads. And then when it comes to prioritization and ownership, I do look to them to be like, "Hey, like I know we got these things ultimately I will like if I need to I'll make the decision on priority, but I look to them to like to provide their technical insights, right? I have, you know, let's make up an example. There's 10 things that we are talking about working on for this particular uh area, right? this this service that we have that I have a tech lead for and like I might have some perspective from talking with partner teams and business expectations about what I think the priority is but I will go to the tech lead and talk about it right they have a lot of ownership in

this area they do take responsibility they do have accountability so that's sort of the first part but then I also have this expectation that I can have conversations with them around priority Now do they ultimately just get to set the priority and tell everyone what to do? No. And the reason for that is they will you know they will advocate for it but they will work with me or you know in general the you work with an engineering manager or product owner to try and like align people on it. Um, but they do have input into that and I would expect that they do and in any setup that I'm an engineering manager, I absolutely want to make sure that that's like a a joint effort. Um, but yeah, product owners when they're owning the direction of something that is kind of like this other this other end of it which is like we need to set direction.

Right? So they have accountability to sort of the customer if that makes sense. They're not doing a great job as a product owner if customers are asking for things. Customer in this context can be partner teams. It can be end user. It is the people that you are building software for. Okay. So, um, if the customer is not being like, uh, is not being satisfied with what the product owner is doing, the product owner is probably not doing a good job being responsible and accountable to the customer. So, uh, in some cases, an engineering manager takes the role of a product owner. Product owner is kind of like a a set of responsibilities. It's less of a like like a title. I would say it's like not very I'm not saying it doesn't happen, but I really think it's not common to like be hired as a product owner.

You'd probably be hired as like a product manager, which has product ownership. Um or like I was just saying, sometimes engineering managers are are product owners. I have worked in places where there is a like I'm the engineering manager of a team. There's a project manager who helps coordinate especially with schedules, external stakeholders, even just internal stakeholders, but like timelines and coordination, product managers who are listening to what customers are asking for and bringing those requests back to the engineering team. and then myself as the engineering manager where I'm working with all of them and the engineers to try and get alignment on the things that we're going to go build and and the priority. So that that ownership part does get shared. Ultimately, I end up having to in those situations, ultimately I end up having to own the engineering side of that, right?

The product manager in those cases owns the product and like they get to say what the, you know, the feature delivery will look like, but then I have to really partner with them on the engineering side. So hopefully, like, like I said, it's not really like a groundbreaking thing, but I I wanted to talk through this because number one, we haven't talked about it on this channel, and number two, like I actually do think that that's a perhaps a bit of a confusing set of words. Um, depending on how you're looking at it. So, I'll wrap it up there. Thanks for watching. If you have questions about software engineering, career, that kind of stuff, leave below in the comments. You can go to code.com, submit stuff anonymously. It's totally anonymous. I literally get an email for myself. I don't know who you are. Uh and then otherwise you can send a message to dev leader or find me on LinkedIn.

This is Nick Cosantino and I'm happy to try and make a video response for you if it helps. Thanks so much. I'll see you next time.