As developers, it is fairly easy to fall into an inattentive routine when it comes to development tasks as sprints go by. Just taking issue after issue in some sort of FIFO queue with no more care than meeting the acceptance criteria. While this work mentality could probably let you suffice your basic responsibilities, it is at best fairly limiting to the vast value you could provide to your team. There is a better way. The alternative work mentality is taking ownership.
Taking ownership means to go beyond completing coding tasks. It means understanding the purpose of a certain feature or epic, being conscious of the value it brings for users and the project as a whole, and figuring out the best techniques and tools to implement it.
When you take ownership, you genuinely care about the quality of the work being done both by you and fellow developers. It is not just some task to complete; it's your product, your craft. Just like an artisan deeply cares about his work of art, when you take ownership, you'll naturally care for the product being made.
This mindset has some impressive benefits both internally and externally. Here are some of them:
- Keeps you motivated throughout the sprint.
- Gives you a better sense of progress as issues are resolved.
- Produces satisfaction as the quality of the product (or beauty of the artwork) is ensured.
- Highly increases the value you bring to the project, and your team will likely notice.
All right, you've convinced me! But how do I take ownership? How does this actually look in practice? Below you'll find four practical ways you can take ownership in the workplace.
Look at the big picture
It is Monday and the PM just assigned you a task from a new epic or feature. You open the ticket, read the description, identify the acceptance criteria, and create a branch to start implementing. What did you do wrong?
Taking ownership means looking at the big picture. It is not just about the current ticket; it's about the whole feature and the value it brings to the whole project. As a developer, you have to assimilate the purpose of your work.
So, every time you take on a new task, make sure to read the epic/feature description, take a look at the other tasks that belong to the epic, and don't shy away from asking your PM or Team Lead anything you don't fully understand about it. Try to recognize, at least, what is the purpose of this feature and how does this feature bring value to the user?
Evaluate
Once you understand a feature, evaluate the best approach and tools for the job. This includes evaluating libraries, design patterns, existing components, third-party services, etc.
Don't take things for granted. If there's a better approach to the technical details provided in a ticket, respectfully suggest your ideas with sound reasoning and rationale, highlighting the benefits of the alternative in light of the big picture.
Be a team player
As I said before, when you take ownership, you genuinely care about the quality of the work being done both by you and fellow developers. This means that taking ownership requires being a team player. Here are some tips to keep in mind: Be eager to answer any questions from a teammate regarding the feature at hand. Be prompt to instant message or schedule a call with a teammate whenever your tasks happen to be related. Consciously review your teammates' PRs and provide detailed but concise feedback when necessary. Don't be afraid to ask questions to your teammates about things they might be more knowledgeable on.
Be mindful of meetings
Let's get serious for a moment. Meetings can be tedious. And sometimes we can quickly stop paying attention to them if we're not being addressed in the current conversation. It's very tempting to continue working on your task or do something else while in a meeting. However, meetings are one of the best scenarios to look at the big picture, evaluate, and be a team player.
Through meetings, you can also grasp an idea of what other people are working on and how their work relates to yours. You can use meetings to prevent duplicate work for instances where two tasks are very intrinsically related. Meetings also allow you to solve blockers and settle uncertainties regarding your and other teammates' tasks. There are many benefits we can reap from making the sacrifice and paying attention in meetings.
So, just be mindful of meetings.
Conclusion
Although there are certainly challenges when taking ownership in the workplace as a developer, the benefits you can reap from this and the value you'll provide to your team highly surpass the difficulties it entails.
Although this is not exhaustive, remember these four things as you try to take ownership as a software developer: Look at the big picture, evaluate techniques and tools, be a team player, and be mindful of meetings.
Top comments (0)