No matter where you are in your journey, you can take ownership over it and portray yourself as someone hirable, someone valuable to a team, and someone who just gets it.
No matter where you are in your journey, you can take ownership over it and portray yourself as someone hirable, someone valuable to a team, and someone who just gets it.
To submit you questions to the podcast, visit effectivelyhuman.tech.
[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.