4 Ways to Show Ownership as a Software Engineer (And 3 Anti-Patterns to Avoid)
What does "ownership" mean in Software Engineering? Examples & anti-patterns
This is the second post of the software engineering soft-skill series. Check all the posts here!
We often hear the concept of “ownership“, but don’t really know what it means. Especially how it applies to us as software engineers.
In short, ownership means you taking charge of your work and act as an owner of the project/product. That usually means going beyond just writing code, including driving projects forward, solving problems, and helping others.
In today’s post, let’s explain this concept with examples & anti-patterns!
Demonstrating Your Ownership
Here are some examples of demonstrating ownership skill:
1️⃣ Jumping On Problems (Including Gray Areas) 🏃
When you spot an issue, don't wait for someone else to fix it. Jump in and take charge. Don't assume someone else will handle it.
It does not mean that you should fix every problem. The point is to bring issues to the team’s attention. If necessary, escalate and put it on a meeting agenda.
For example:
Flaky tests on CI
Potential security issues
The team spends too much time on operations
PM makes unreasonable requests
This applies to gray areas as well. Not all teams have 100% clearly defined domains. Bring up any topic and help the team decide how to move it forward. As a result, all issues should be put on a backlog and prioritized accordingly.
For senior members, it could mean getting involved with discussions in other teams or other divisions. It’s an opportunity to expand the impact, and it’s a demonstration of ownership as well.
2️⃣ Offering Help 🙋
Building softwares involves an entire team. That means collaboration and communications.
Support other team members is part of ownership that drives the team forward.
Some examples:
Answer questions on Slack
Un-block stuck discussions
Do code reviews
Actively sharing new findings
(For senior members) check-in with others regularly
Also, offering help doesn't mean doing others' work for them. It's about providing support and sharing ideas.
3️⃣ Participating in Incident Handling 🚨
When incidents occur, whether you’re on-call on not, jump on it and take a look together. Your actions during tough times demonstrate true ownership.
This includes participation into:
Immediate mitigation
Short-term/long-term solution
Prevention measurement
Post-mortem report & meetings
Ownership means to help with the recovery and future preventions. You make the product better by participating into the process.
Likewise, it also doesn’t mean that you always have to be the incident commander. Just make sure that someone is able to lead and make decisions. You can still contribute by sharing insights and joining discussions.
4️⃣ Deliver Promised Work 🗓️
Software engineers usually don’t have problem delivering small features and bug-fixes. But as tasks get more complicated, it becomes harder to deliver.
I came across this post by
a few days ago and it resonated.We have many tasks that we don’t deliver. For example,
“We’ll refactor these codes later” but that “later” never comes.
“I’ll design it by myself” but the design turns out to be not maintainable.
“We can take these extra features” but they find resource issues later.
Unexpected changes can happen. This is why senior software engineers do not give promises easily.
Take ownership in what you say. Avoid over-promising. Once promised, make efforts to deliver. Also, keep open communications if there are unexpected situations. The point is to demonstrate your ownership skills and build credibility.
Three Anti-Patterns
Software engineers often fall into traps that hinder their growth and impact. These anti-patterns can derail your career and team success if left unchecked.
1️⃣ “Not My Problem“ 🤷
I once ran into a situation where an application was not able to connect to its database on AWS. We asked both backend engineers and SRE members to take a look.
Backend engineers checked their application configurations and codebase. They didn’t find any issue.
SRE members checked their database cluster. They didn’t find any issue.
Both parties had the same comment: “Our domain looks ok, it’s their problem 🤷”.
It turned out that the network configuration was changed in an irrelevant PR, which caused the connection to fail. It was in an area that both parties were not aware of.
If any of them could take a look at the big picture, they might find that there was some changes in the infrastructure. The mindset of “not my problem“ stopped them from owning the issue.
2️⃣ Blaming 😡
Pointing fingers is easy, but it blurs the focus of making the team better.
When things go wrong, resist the urge to blame others. Instead, focus on solutions. Use failures as learning opportunities. Conduct blameless post-mortems. What went wrong? How can you prevent it next time?
People rarely want to mess up intentionally. It’s usually an issue in the process. (I know there are some a-holes from time to time, but blaming is not a solution, either 😅)
For example, a bug was not caught in production. The questions not to ask:
❌ Why the developer was not careful enough to catch this issue?
Instead, we should ask:
✅ Why did we miss it? Do we have sufficient QA process? Is this part covered by unit tests?
Put the focus on the process. Improving the process can resolve most of the issues. On the other hand, blaming won’t resolve any issue.
3️⃣ Sitting on Issues ⏳
It’s common to say “I don’t know”. We are human and we don’t know everything. However, it’s a different story when you see a problem (or you are assigned with a task) and take no action.
For example, you are working on upgrading your web framework version from v1 to v2. A “circular dependency“ error comes out of nowhere.
You don’t know what to do, so you choose to work on something else first. However, you never have a chance to come back and take a look. Someone else found this issue only when it’s close to the release deadline.
Instead, the right action is to bring it to the team as soon as you get stuck. Demonstrate ownership by escalating. Do not sit on until it’s too late.
Last Words
Taking ownership leads to better sense of achievement, and can immensely contribute to your career growth. When you feel responsible for a project's success, you're more invested in the outcome.
Thank you for reading the post!
❤️ it if you like this article.
💬 Leave a comment if you have questions. Or let me know if you are interested in knowing any specific topics.
You can also find me on:
If you want more content like this, consider subscribe to my newsletter.
See you next time 👋