How to Take Ownership As a Jr. Developer

Morgan Lopes shared one of his cornerstone talks for anyone looking to make an impression in whatever stage of life they are in, whether in the job search, newly hired, or founding their something of their own.


[00:00:00] Team members who take ownership stand out within any organization. 

Welcome to effectively human, where we discuss how to close the knowledge gap between technology and the people who use it. Each week your host Morgan Lopes will share real life practical tools on how to bridge the gap. Let’s jump in.

We are going to talk about ownership. When the topic of ownership comes up, the first thing that can come to mind is that a business ownership. And it feels like if the business isn’t ours, then surely ownership is not something that we are responsible for or should be considering, but that’s actually not what I’m talking about.

What I’m referring to, as it relates to ownership is about the work taking responsibility. [00:01:00] And in many cases, accountability for the work that needs to get done. This could be on an entire project. This could be on a set of features, or it could be as small as on a task. Ownership is part of working as a team and allows organizations to move further, faster.

Team members who take ownership stand out within any organization. As we break down this idea of ownership in our work, a distinction that comes to mind is subjective versus objective ownership. Objective ownership implies very specific rules and requirements around how many poll requests, how many commits, how many lines of code are written. In the attempt to spell out objective ownership it often overlooks the fact that as software engineers, sometimes our greatest contribution to a project can actually be more about the code that isn’t written rather than trying to hit some objective standard. [00:02:00] So for me, the way that I prefer to think about ownership is subjective and having discussions with team members and trying to make it more clear this tension keeps coming up. Which is if we define it too clearly, to objectively what ownership means, and that leaves very little room for someone to come in and add value or think outside of the box. And great software is typically written when we are not trying to optimize for hitting a quota, but being really efficient and effective.

And in technology effective code or effective software can often stand out by the code that’s not written. This reminds me of an example. So a few years ago, a polar notion, we had a client who wanted to see keystrokes from every engineer for every week of the project. We had a team of about six to eight people off and on working on this for many months.

And from his perspective, we should [00:03:00] have that level of detail. Every time somebody touches a keyboard and his hope was to account for all of the work that had been done on the project. What’s hard though, is keystrokes is not necessarily indicative of great code being written. There were conversations. There were, brainstorming on whiteboards and all of these things. And so merely counting keystrokes is actually optimizing for the wrong thing. They were a large corporation and, what he had shared was, and their organization engineers are held accountable and them clocking in and clocking out every day comes back to actually the logged keystrokes on their computer.

As I wrestled with this challenge, I realized this is not the type of engineering organization I wanted to create. What I don’t think is optimizing for the right behaviors, nor does it take into account an appropriate definition of ownership. So if I had to break down, how I would think about ownership without forcing myself to come up with a number of [00:04:00] commits and poll requests, and conversations to be had around the code, but a subjective definition for ownership. I would then break it into two parts. First and foremost, I would talk about the human element of owning a project, a task set of features, and then the technology. So the humans and the tech.

When we look into the human element, of subjective ownership there are three parts.

The internal people. So those, we work alongside the people in our organization, the external, so those outside of our organization or team, and then the roadmap and vision for the product. So all of these we think about what does it look like to own our work to the people that are connected to it? The internal, the external and the, and the vision, right? Understanding where the product is headed. Those are really the three different buckets.

At New Story, all internal communication happens on Slack. So [00:05:00] how it plays out is very different, but then also the level of detail and clarity that is expected internally is often very different than what is external. External communication is a typically a little bit more baked or thought through maybe a little bit more you know, presented. And typically is not in Slack. It could be in a published format. It could be via email. And then the last piece, which is the roadmap or the vision, as we think about owning our projects or the work that we’re doing, we should have a clear sense and ability to articulate where this is headed.

What is it for? And so there’s a communication element. When we look at ownership, next is the technology. So as we think about owning technology, I would break it into three parts. Maintaining the technology. This involves, fixing things that are broken or bugs that emerge. This could fit into a typical [00:06:00] support structure. Below that  would be advancing the technology. So moving the code forward. So, as we own a project, not only should the, the program be well-maintained, but it also should be advancing. New features. Improvements. Reducing technical debt is an advancement of the technology. Then finally is what I would consider like the peripherals or the infrastructure, the performance, the things that allow it to keep running.

It isn’t inherently maintenance because it might not be broken yet. Right where nothing, there may not be any problems stemming from these peripherals. It also is not specific to advancing the technology because some of these things just have to exist. It could be keeping, uh, credit cards up to date or access permissions and some of the more soft skills that relate to the technology that we write.

When it comes to ownership within technology, it has to be maintained. It has to be [00:07:00] advanced and the peripherals need to be accounted for. And so a software engineer who is owning, taking ownership of that technology, isn’t necessarily going to do all of those things, but wants to make sure that they are all getting done.

So that’s an important thing to remember, which is you don’t have to do it all. Ownership is not about doing everything. However, It is about being accountable for making sure that the things get done. So this can be delegating. This could be trying to work around the problem so that it doesn’t have to involve doing more work, or in many cases it could actually involve stepping in and filling a gap that exists in moving the product forward.

One of my favorite quotes is that everything rises and falls on leadership. Now, to me, leadership is not a title. It is a mindset. We may look at our job, our role and think, well, I’m just a junior engineer. I just got [00:08:00] started at this company. And I do not believe to take ownership of the work that we are doing or to lead  that that has to be something that is a bestowed upon us. As we look for ways to set ourselves apart in technology team members, we take ownership of the work. The human element, the technology element, those that truly take ownership on a subjective level beyond just the metrics that are defined. Those who take ownership, stand out among their peers.

Thanks for listening to effectively human. Want to join in on the conversation? Submit your questions on effectively Jack them on the show. And of course you never miss a beat.

Get notified about updates, news, new content, and more. No spam. No selling your info.