Ownership as a software engineer. What am I actually owning ?

---

You might hear the word “Ownership” a lot around you. As a software engineer do you often think, “I can write code and that's enough for my role”? While it might work in some cases just to get the job done, it might not be enough. You need to show more Ownership to succeed..!!

Definition

Ownership is the sense of responsibility and belonging to a task, initiative or team. It's a mindset of taking responsibility and accountability for the outcome. In life when you own things you care for them. If you own a house, you care for it, and clean it regularly, if something breaks you get that fixed, you upgrade it from a long term perspective. Along the same lines, owning in software engineering is to have a sense of need that whatever you own is in great shape and desire to make it even better for the future.

---

“When a team takes ownership of its problems, the problem gets solved. It is true on the battlefield, it is true in business, and it is true in life.”

— Jocko Willink(Author of Extreme Ownership)

---

Key areas a software engineering could display ownership

Ownership of codebase

For a software engineer, ownership of code is extremely important. What will you do if while working on your task you find something implemented inefficiency or incorrectly? If not directly related to your current task at hand, do you care to fix it or do you quietly leave for someone else to fix it in the future? Do you at least create a ticket to fix it later or just forget about it as “You” didn’t add it? This exactly reflects the ownership mindset of the engineer. Ownership requires the engineer to look beyond the exact task at hand and make effort to leave the code better than found. Being shepherd of the code base by caring about the code you are working on, improving the reusability and removing the inefficiencies/defects even if that might not directly affect the task at hand.

Ownership of a task/project

When you own a task/project, you drive it from start to completion. It's not about just doing what is mentioned in the ticket or is asked of you. But looking holistically, understanding why something is getting done, why it is important and how it adds value. Once planned, doing whatever is needed to get the task/initiative to completion. If there are challenges or risks along the way, finding solutions and alternatives instead of getting stuck and pointing them to someone else. Going outside your comfort zone to help guide various aspects of the project to completion. In general, treat the project (beyond just your portion of it) as something you truly have a vested interest in. This will lead you to act in ways that support the project and the team.

Ownership of domain

Try to become a resident expert. Act as a resource for advice and information, and you continually expand your knowledge of the entire project. Don’t just focus on WHAT but think about WHY. Make use of every opportunity to make incremental progress toward the north star vision for the domain. Along with building the new features and capabilities, prioritize reducing technical debt. Try to be proactive in looking into the issues affecting your domain.

Ownership of the processes

Following the right processes is very important for consistent delivery, in terms of value and quality, for any team. Don’t simply work on the processes as they are defined, but understand the processes and their purpose. If some process isn’t ideal, take initiative to change it. Participate actively in the processes like design reviews, code reviews, test coverage and anything else that’s important to maintain the quality of the code and domain.

---

Some intriguing questions that might help you understand if you demonstrate ownership or need to work on it.

1. Do you ever question why you are working on something or how the requirements help the domain?

2. Do you ever question the requirements if you think they aren’t correct?

3. Do you learn more about the domain beyond what is in the requirement ticket?

4. Do you just add code to get the job done or have a mindset of improving the code base?

5. Do you actively participate in your team processes with the intent of achieving more for the team?

6. If there is a challenge or unknown risk, do you get blocked and wait for someone to resolve the issue for you or strive for finding a solution?

7. Do you think about quality of code and how it aligns with the long term vision?

8. Do you add code per requirements and move on or think about how you would monitor post-rollout?

9. Do you care when something goes wrong in production or look if it is in your code, if not, move on?

10. Do you care about your domain?

This is in no means an exhaustive list, and doesn't cover all the areas where you need to show ownership(expectations might be different based on your level). If you truly have an attitude of ownership, you’ll know what to do and when. If you don’t, pondering on the questions above could be a starting point.

---

Conclusion

As a software engineer, it is very important the idea of ownership is clear in mind. Showing ownership means being a leader and doing whatever it takes to get the job done. The mindset will not just allow you to grow but allow the team to achieve new heights.

If you still have questions or are not clear, have a conversation with your manager or feel free to hit me up. If you are interested to learn how you can create the environment to cultivate the ownership mindset in the team, send me a comment and I could post an article on that.

**If you like the article, please follow me for the upcoming articles. Also that keeps the writer(me) motivated to generate further content 🙂.

** If interested in a book on ownership : https://amzn.to/3kQ9L6S

---

This post contains affiliate links. If you use these links to buy something I might earn a commission.