This article was part of The Rising Dev newsletter issue #4, published on Mar 15, 2021.
Early in my career as a software developer, I received vague feedback about needing to take more ownership of my work. You may have received similar feedback, such as in an annual performance review, as I did.
When I asked for more specifics, for something actionable I could anchor to as a goal, I got the proverbial “you know, just own the stuff you are responsible for,” leaving me to figure out ownership through trial and error.
Later in my career, I got the other kind of feedback, the praise for taking ownership. And again, the feedback often came without any specifics, believe it or not. I was paying attention though, mostly since I was hoping to help others take more ownership.
A long career in software has taught me that “ownership” is a suitcase term, used by folks when they think you need to change something and not quite sure what that is.
The dynamic nature of software and teams doesn’t make understanding ownership any easier. Development teams tend to become cross-functional as they grow, blurring any lines that might have helped you understand where ownership lives. The various mutations of an agile process can blur the lines even further regarding who owns what. And yet, ownership is an enabler for getting things done effectively—ownership needs to happen.
If you can devise a strategy for taking ownership regardless of the unknowns, you are on a path to leveling up.
For these reasons, “taking ownership” is a concept that needs unpacking.
Three Strategies for Taking Ownership
✨ Contribute to the Momentum
Regardless of the size – a small task, a medium-sized feature, or a lengthy project – your work is at risk of being derailed for various reasons. Taking ownership is about creating the circumstances that surface these risks and the reasons behind them. Often the reasons include not having the who, what, when, and why clearly defined.
- Who else will work on this?
- What will success look like?
- When should it be completed by?
- Why are we working on this?
These are all questions with answers that can help reduce complexity and ambiguity. Without the answers, complexity will creep in, and you might miss your date, deliver something of low quality, or worse; your work will be put on the chopping block and cut for something better defined and understood.
I believe ownership starts during this early phase, where you can help others crystalize answers that help build momentum and ensure success. You can begin by asking these questions:
- Who else will be working on this with me? Who do I communicate with regarding dependencies (other developers, testers, stakeholders, etc.)?
- What does done look like, and what are the success criteria?
- When does my work need to be completed so that ample time is left for testing?
- Why am I working on this? How does it fit within other priorities, company goals, and the expected impact?
If you’re fortunate, you’re at a company with a built-in process for generating these answers before the work ever gets to you, but this won’t always be the case. Either way, It’s still important to ask them for confirmation.
What you are looking for when asking these questions is resolution, usually in the form of one of the following:
- You have answers to all questions, and you understand those answers. Therefore you have positive momentum and have reduced risk.
- You have enough answers, and the rest are either missing or not completely understood. Therefore you have some positive momentum to build upon, and your team and stakeholders are aware of the risk and have accepted it.
- You have a few answers, and they are unclear. Therefore you have negative momentum, and your work is at risk before it starts. In this case, you raise a red flag and express doubt. Ideally, your team regroups and pivots to a better strategy. Or you at least agree that the impact or reward is worth the ambiguity, and you choose to charge forth and slay some dragons.
As you can see, there might be various outcomes. You and your team will analyze new information at different stages of a project and work together to devise approaches that reduce risk and help keep things on track. You can show ownership by asking the right questions upfront and surfacing the information to help keep your project from being derailed.
✨ Carry Things From Start to Finish
Most of the work you do as a software developer will be part of a lifecycle usually called the development or implementation phase. This phase is often followed by varying degrees of testing, followed by that work being deployed to production (live to the public), assuming all functions as planned. Taking ownership means more than just being accountable and responsible for your phase of the lifecycle.
Most developers who receive their work at the start of the implementation phase will forget about it and move on to the next task after their work has been code reviewed and handed off to the next phase. Except for instances where the work comes back to them for bug fixes, the work is no longer top of mind as they have moved on to the next priority. To show ownership, you will need to go a few steps further.
I believe ownership supersedes the phase boundaries in this software development lifecycle. The edges of a phase can still be respected, but they are not signals indicating you are done or free of accountability.
When you pick up the work at the beginning of the implementation phase, you show ownership by committing to the successful delivery of that work to the customer or end-user. Here’s what that looks like:
- Because you contributed to your work’s momentum (by asking questions) as described in the previous section, you know what success looks like as well as the agreed-upon timeframe. You show ownership by proactively communicating any blocker to completing your work against the given success criteria and agreed upon timeframe; you don’t wait to be asked.
- When you submit work for review, a code review, in this case, you show ownership by reaching out to the reviewers and confirming any needed context is presented to help inform them of your work’s details. You also captured this context somewhere through documentation. You show additional ownership by checking in and ensuring your work is reviewed promptly. If more time than usual passes by, you speak up and inform your team of the potential risk.
- After your work has been reviewed and is promoted to the testing phase, you show ownership by reaching out to testers to confirm they have all the context needed to test your work correctly. You express that you are available to them should any questions arise, and again you check-in to ensure your work gets tested on time, and you speak up if things take longer than usual.
- When your work has been tested and confirmed to be working as needed and finally deployed to production and live to the world, you show ownership by reviewing and ensuring for yourself that everything functions as you intended. If you see any deviation from what was intended, you speak up. The difference may be an indication of an underlying issue or bug that needs attention.
These four items above are part of ownership. They allow you to account for the progress and current state of the work you took responsibility for.
✨ Create Long Term Impact
Creating a long-term impact is one of my favorite actions related to showing ownership. In my experience, few software developers think about long-term impact since they have often moved on to another role, team, or organization for it to affect them.
Nothing screams ownership like doing the things that will help others in the longer term after you have moved on. It’s one of the fundamentals of leadership; how things play out and unfold in your absence matter.
You show ownership here by considering how your work, and everything relating to it, can enable others in the future. The best way to create a long-term impact is to document and share:
- The discussions and rationale that went into your approach to the work you did. Doing this will help others expand on the work in the future.
- The gotchas, the brittle parts of the work that may provide clues to bugs or errors. Doing this will help others troubleshoot anything related to your work should issues arise later.
- The operational and maintenance requirements related to your work. If changes to a system are required in the future, should your work be altered somehow for compatibility? If your work is dependent on something else functioning correctly, make that clear.
Ownership Is All About Communication
You may have picked up on the theme by now. Nearly everything I described around ownership for software developers is about communicating with others. Each action or question creates another communication touchpoint, where challenges and risks can be surfaced and tackled head-on.
There are some positive side effects to ownership I should mention. Consistently taking action on most of what I shared above will produce a sense of control, which is always a great feeling. Even when things don’t go as planned or your team needs to pivot strategies, you can get there in a more controlled and informed manner; this reduces stress and strengthens your team.
The next time you hear ownership mentioned or receive feedback related to showing more ownership, think about how you communicate. And consider the strategies above as actions for filling any gaps.
If you enjoyed this article and want all the latest posts, tips, and resources for rising as a software developer delivered straight to your inbox - Subscribe Here.
Top comments (0)